Product Documentation

Fixes and Changes in SKFS 4.16.0

 

#

Explanation

RFE-277

Dynamic reloading or Related Origin Requests (ROR) and Digital Asset Links (DAL) configurations.

The StrongKey FIDO Server (SKFS) 4.15.1 release introduced support for two yet-to-be-standardized WebAuthn features: Related Origin Requests (ROR) and Digital Asset Links (DAL), allowing for unique configurations across FIDO domains. Previously, implementing these features required tedious updates to configuration properties and a Payara restart with every change. However, the current release of SKFS 4.16 has made this an easier process.

ROR and DAL have been integrated into the FIDO Policy module and database, enabling limitless origin configurations and dynamic updates without a Payara restart. Now, when a FIDO administrator modifies the policy or database with new ROR and/or DAL values, they are instantly refreshed in the hash maps, ready for SKFS to utilize.

The two new elements added to the FIDO Policy are as follows:

1) ROR
 "relatedOriginRequests": {
            "enabled": false,
        }

2) DAL
"digitalAssetLinks": {
            "enabled": false,
        }

 

Both JsonObjects have the following attributes:

  • "enabled" : indicating whether the feature is enabled for a FIDO domain. By default, it is disabled. Updating it requires the use of the skfsadminclient tool with an administrator credential.

Three new database tables have been added to SKFS database schema:
  • RELATED_ORIGINS - containing authorized web URL origins whose hosted applications can make FIDO service requests to the relying party's back-end application;
  • DIGITAL_ASSET_LINKS - containing metadata information of Android native app used as FIDO authenticators. The meta-information defines the 'namespace' and 'packagename' for the Android app making FIDO service requests.
  • DIGITAL_ASSET_LINK_X509_FINGERPRINTS - containing information about X509 digital certificates used to digitally sign the native Android app making FIDO service requests. This is a child table to the parent DIGITAL_ASSET_LINKS table.

To manage the ROR and DAL configurations, new web service endpoints have been added to the FIDOAdminServlet. Only service credentials possessing 'Admin Authorization' within the LDAP Directory store will have the ability to execute ROR and/or DAL operations.

The following representational state transfer (REST) web service endpoints have been added (You can click HERE to learn more about the new web services) :

1) /ror: This endpoint supports the ability to Add, Get, and Update authorized ROR  web origins to a FIDO domain.

Endpoint: https://<FQDN>:8181/skfs/rest/ror

2) /dal: This endpoint supports the ability to Add, Get, and Update DAL targets and authorized X509 certificate fingerprints associated with targets.

Endpoint: https://<FQDN>:8181/skfs/rest/dal

 

Using the skfsadminclient, a FIDO Administrator will utilize the above web service to Add, or Update ROR web origins or DAL targets. Once these have been updated, a FIDO administrator will utilize the /updatepolicy web service endpoint to enable the feature in the FIDO Policy.

Click HERE to learn how to enable or disable ROR feature.

Click HERE to learn how to enable or disable DAL feature.

Please Note: When upgrading from SKFS 4.14.0 or 4.15.1 if ROR and DAL were previously configured as properties, you must now use the new web services to reconfigure these values in the database. Any existing configuration properties will be ignored by SKFS and a FIDO administrator should delete the old configurations using the /deleteconfiguration web service endpoint.

 1. Additional information is available at https://passkeys.dev/docs/advanced/related-origins/
 2. Additional information is available at https://developer.android.com/training/app-links/verify-android-applinks

 

Upcoming Changes in SKFS 4.17

This section is intended to enable customers and users of SKFS to prepare for upcoming changes in SKFS that WILL have an effect on applications using SKFS. Such RP sites must allocate time/resources to be prepared to work with the future release. StrongKey is providing this information in advance so that customers/users are not unprepared for these development activities.

#

Explanation

RFE-287

Response for errors returned by SKFS will be updated to provide more information as well as a consistent format.


Current:

SKFS responds to webservice requests in two (2) different ways:
    • When the service request is successful, a JSON Object is returned as a String that can be reassembled into a first-class object using an appropriate library. An example follows:

      {

       "Response": "Successfully processed registration response",
       "responseCode": "FIDO-MSG-0004",
       "pkixValidated": false,
       "skfsVersion": "4.15.1",
       "skfsFQDN": "example.strongkey.com",
       "TXID": "1-1-75-1711751776586"
      }


  • However, when the service request fails, the response is a simple String message that cannot be converted into a JSON object, as follows. This forces applications to deal with two different response types:

    FIDO-ERR-1501: SKFS Domain does not exist: skfs did= 2


New:

In the next release of the SKFS (4.17), the success response will have the 'Response' key changed to 'response' and 'TXID' changed to 'txid':

{
 "response": "Successfully processed registration response",
 "responseCode": "FIDO-MSG-0004",
 "pkixValidated": false,
 "skfsVersion": "4.15.1",
 "skfsFQDN": "example.strongkey.com",
 "txid": "1-1-75-1711751776586"

}


The error response will be made consistent by sending a JSON Object as a String that can be reassembled back into a first-class JSON object, as follows:

{
 "response": "SKFS Domain does not exist: skfs did= 2",
 "responseCode": "FIDO-ERR-1501",
 "skfsVersion": "4.15.1",
 "skfsFQDN": "example.strongkey.com",
 "txid": "1-1-75-1711751776586"
}

 

This change will be implemented in 4.17. We are sorry for the confusion and inconvenience.