RFE-254

Update SKFS error codes to be unique and error messages to be clearer

In some parts of SKFS, the server returned incoherent error messages because a code-block would do multiple functions, but sometimes return the wrong type of error message. This led to confusion about the root-cause of the error. Starting 4.15, ALL error codes and messages are unique to a specific problem in the server. As a result, simply by knowing the error code, it is possible to locate the unique location of the server-code where the problem originated. If customers are using log-management tools to catch critical errors from SKFS logs, they are recommended to review the revamped codes/messages to ensure their monitoring tools are working as expected. You can view a list web service specific error codes here.

RFE-255

SKFS domain specific Related Origin Requests (ROR)

With the release of SKFS 4.14, support for Related Origins Request (ROR) was introduced (RFE-245). In the 4.14 release, ROR support in the SKFS was only available for all cryptogrFIDO Domains (DIDs) or none of them.

With SKFS 4.15, the code has been updated to support ROR for multiple domains. With the use of the updateconfiguration admin web service, ROR may now be enabled for a specific domain and the generated webauthn file will now be stored in a domain specific folder on the file system.

skfs.cfg.property.fido2.rp.relatedorigins.enabled
skfs.cfg.property.fido2.rp.relatedorigins.origins

Path in SKFS 4.14 =

/usr/local/strongkey/skfs/etc/webauthn

Path in SKFS 4.15 =

/usr/local/strongkey/skfs/etc/1/webauthn (for DID 1)
/usr/local/strongkey/skfs/etc/2/webauthn (for DID 2)

...and so on. SKFS 4.15 differentiates ROR requests across FIDO Domains, currently supporting only authentication requests, with registration support coming in the next release.

Additional checks and log messages are also introduced to verify an ROR origin is properly configured and prints a warning for any entry that is not a valid origin.

RFE-256

Add support for Android Digital Asset Links

SKFS 4.15 now supports Digital Assets Links (DAL).

When a native android app is built using android API's, it may leverage the Credential Manager API which supports multiple sign-in methods, such as username and password, passkeys, and federated sign-in solutions (such as Sign-in with Google) in a single API, thus simplifying the integration for developers.

With version 4.15.0, SKFS introduces support for Digital Asset Links (DAL), enabling an RP to verify FIDO registrations and authentications generated by native apps using the Credential Manager API. SKFS administrators can now configure properties for a specific domain using the admin API to enable DAL and create a whitelist of SHA 256 certificate fingerprints.

When the Credential Manager API is used, the clientDataJson that is received by SKFS contains the following in the origin android:apk-key-hash:<sha256_hash-of-apk-signing-cert>

To enable support for passkeys for a native android app, the app needs to be associated with the website that owns the app. This can be achieved by declaring the association using a Digital Asset Links file and host it at the site controlled by the relying party. For example, if the sign-in domain is login.example.com  the DAL file should be hosted at https://login.example.com/.well-known/assetlinks.json

The server hosting the "assetlinks.json" document must ensure it is served with a content type of application/json.

The "assetlinks.json" file has the following content:

[
  {
    "relation" : [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target" : {
      "namespace" : "android_app",
      "package_name" : "com.example.android",
      "sha256_cert_fingerprints" : [
        SHA_HEX_VALUE
      ]
    }
  }
]

More information about the assetlinks.json file can be found here.

Note: DAL feature is not applicable to applications with target namespace of web. In this case, it will continue processing based on AppID or Related Origins Requests (ROR) rules.

When DAL is enabled and configured (through properties shown below), the "assetlinks.json" DAL file is generated by SKFS and stored in the SKFS configuration directory (/usr/local/strongauth/skfs/etc) for StrongKey Tellaro appliances and (/usr/local/strongkey/skfs/etc/) for software installations). Note that the properties MUST be configured on ALL nodes of an SKFS cluster for DAL to work on the cluster.

The server supports DAL for multiple domains. With the use of the updateconfiguration admin web service, DAL may be enabled for a specific domain and the generated assetlinks.json file will be stored in a domain specific folder on the file system.

skfs.cfg.property.fido2.android.digitalassetlinks.enabled (true or false)
skfs.cfg.property.fido2.android.digitalassetlinks.namespace 
skfs.cfg.property.fido2.android.digitalassetlinks.package
skfs.cfg.property.fido2.android.digitalassetlinks.fingerprints

Path in SKFS 4.15 =

/usr/local/strongkey/skfs/etc/1/assetlinks.json (for DID 1)
/usr/local/strongkey/skfs/etc/2/assetlinks.json (for DID 2)

...and so on. This will ensure that SKFS can differentiate between the DAL requests across FIDO Domains. SKFS 4.15 will supports DAL for both registration and authentication requests.

BUG-122

Fix Error when authentication response level > 0 and sendfakekeyhandles is enabled

An error has been identified when the authentication response level (skfs.cfg.property.auth.return.responselevel) is set to a value > 0 and sendfakekeyhandles (skfs.cfg.property.fido2.user.sendfakeKH) is enabled.

In the preauthenticate or preauthorize process, if the response level is > 0, the server includes the FIDO credential's registrationVersion in the response (the version of the SKFS when this FIDO credential was registered). However, having sendfakekeyhandles enabled results in an error, as fake FIDO credentials lack this value.

The server now returns a default value when the two conditions mentioned above are met: "<4.8.0" (the same value for FIDO credentials created before 4.8.0).