BUG-35

SKFS FIDO Keys CRUD operation optimization for replication and rollback

An add/update to the FIDO_KEYS table entry would first persist an entry to the local database and then replicate to the other nodes in the cluster. If for some reason an exception occurred after the replication has been initialized but before a response is sent to the server, it would create database inconsistencies between the nodes in the cluster.

The issue has been resolved in the 4.10 release, and the replication code is now executed as the final step before returning a response to the calling application. This change enables the successful completion of transactions, along with replication, or else everything is rolled back.

BUG-50

Update FIDO Policy did not parse the policy JSON to check validity before persisting

SKFS update policy bean parsed the policy for schema validation after the database persist which would have introduced invalid policies in the database.

The issue has been resolved in the latest 4.10 release. The code now performs a policy validity check before saving it to the database.

BUG-52

Incomplete Hash Map replication

SKFS maintains information in a hash map between pre-register and register operations: or pre-authenticate and authenticate operations: or pre-authorize and authorize transactions. This hash map is replicated to all nodes in the cluster so that the 'pre' operations and 'register/authenticate/authorize' operations can be performed on different nodes in the cluster. Certain values in the hash map were not replicated, causing a failure during the authorization transaction.

This has been fixed in 4.10 release and the code replicates all the required values when replicating a hash map entry.

BUG-59

Get keys web service for a user takes very long to return results

SKFS offers a web service that provides users with easy access to information about their registered FIDO keys. In a recent update, keys were allowed to be marked as deleted instead of being removed from the database, ensuring they cannot be used further.With this change, users now have the potential to possess a vast number of database entries, with only a few remaining in a non-deleted state. Retrieving keys for these users became time-consuming based on the number of registered keys in the database.

This has been fixed in 4.10 release and the code now only gathers the not deleted entries and returns them back.

RFE-23

Add Support for Discoverable credentials

With v4.10.0, StrongKey FIDO Server(SKFS) supports authenticating users with "discoverable credentials". This is a user experience where web applications authenticate users to the relying party's site without having the user provide their username - the browser and user's FIDO Authenticator negotiate the capability between them, and make the user experience seamless. [Note: You can see a demonstration of this in the StrongKey Discover demo here].

The premise of this authentication flow is that most users have a primary FIDO credential registered with an RP site, which they use frequently from the same platform. In such a situation, if the RPID on the site matches that of a credential within the FIDO Authenticator, the browser does not need to prompt the user for any text (unless a PIN has been enabled on the Authenticator) - without typing a username or password, the user is authenticated to the site. If the user has multiple FIDO Authenticators accessible/connected to the platform, the browser may display a "chooser" identifying the type of Authenticator the user must select to authenticate with. On the chosen Authenticator, if there is only a single credential for the user to the RP site, the user is authenticated with the "discoverable credential" flow.

If the user has multiple usernames and FIDO credentials registered to the same RP site on a single Authenticator, the browser will display a "chooser" to select a username to authenticate with [Note: While the authentication flow using "discoverable credentials" does not require typing in a username, the registration of such a credential does require specifying one - this is why the browser can display usernames associated with FIDO credentials when there is more than one username-credential associated with the RPID].

In this release, SKFS added support for "discoverable credentials" by making the "username" parameter optional for the preauthenticate web service - the parameter can be set to NULL, an empty value or eliminated from the input JSON data structure entirely. Such a preauthenticate request returns a response with the challenge and an empty "allowedCredentials" array - indicating that the Authenticator(s) available on the platform must discover any/all FIDO credentials registered for the specific RPID, and permit the user to choose the one they will authenticate with. If there is only one Authenticator available to the platform, and if such an RPID-scoped credential is available on it, the user is authenticated with just the user-presence/user-verification prompt without the need for the username. This is what makes "discoverable credentials" seamless.

Example input payload from new preauthenticate web service request for discoverable flow:

	"payload": {
		"username": null,
		"options": {}
	}

	"payload": {
		"username": "",
		"options": {}
	}

	"payload": {
		"options": {}
	}

Preauthenticate response for any of the three inputs above will resemble something like the following:

Example {
  "Response": {
    "challenge": "nd54MgbnS0RkFZhBgwQtGg",
    "allowCredentials": [],
    "rpId": "strongkey.com"
  },
  "responseCode": "FIDO-MSG-0006"
}

It should be noted that due to mixed support for WebAuthn's "credential properties" aka "credProps" extension by browsers, SKFS' Policy Module cannot enforce a FIDO policy to mandate "residential keys" - which in StrongKey's traditional understanding implies that the key-pair is generated on the Authenticator and the private key never leaves the Authenticator in any circumstance. For now, suffice to know that if an RP requires that FIDO keys must be generated on a cryptographic hardware device and the private key must remain on the Authenticator, the RP should discuss this with Authenticator manufacturers for affirmation.

RP web applications must also specify "residentKey" in AuthenticatorSelectionCriteria to signal their intent for a "discoverable credential" by setting "authenticatorSelection.requireResidentKey" to 'true' and "authenticatorSelection.residentKey" to 'required'. Web applications should be prepared to receive an error from the Authenticator if such a resident key cannot be created. (WebAuthn L3 specification expects to change much of this; StrongKey will implement L3 when it is finalized by W3C and will explain its rationale for the implementation at that time).

RFE-70

Add username to authenticate response object

For applications to leverage the discoverable flow introduced in version 4.10, the authenticate response now contains a username that may be used by the calling application if required.

Example response from old authenticate web service request:

{
	"Response": "Successfully processed sign response",
	"responseCode": "FIDO-MSG-0008",
	"jwt": ""
}

Example response from new authenticate web service request:

{
	"Response": "Successfully processed sign response",
	"responseCode": "FIDO-MSG-0008",
	"username": "testuser",
	"jwt": ""
}

RFE-76

Update key generation script for SSO keystores to only use keytool 

Before version 4.10, JWT and SAML generated their own self signed root ca and signing key pairs. It generated 'N' keypairs per server per domain. This has been modified in version 4.10 and it generates a single mini PKI with a SSO Self Signed Certificate Authority with 'N' number of keypairs for each use case (SAML & JWT).

The two scripts were combined into a single script (keygen-sso.sh) and updated to replace all possible openssl commands with keytool commands.

RFE-83

Update SKFS policy to reflect the new SSO keystore generation

Before version 4.10, JWT and SAML generated their own self signed root ca and signing key pairs. It generated 'N' keypairs per server per domain. This has been modified in version 4.10 and it generates a single mini PKI with a SSO Self Signed Certificate Authority with 'N' number of keypairs for each use case (SAML & JWT). The policy object has been updated to reflect this change and new sub json has been added which lists the Distinguished Names (DNs) for all valid key pairs including the root ca.

Example subjson from new policy object. This gets populated automatically during the upgrade.

"signcerts": {
      "rootca": {
         "subjectdn": " CN=StrongKey FIDO Server RootCA,...",
	"serialnumber": "1232165D",
	"pemcert": ".",
	"jwtcerts": {
	    "default": [{
			"subjectdn": " CN=SKFS JWT Signer 1...",
			"serialnumber": "6E1391C8",
			"pemcert": " ......"
			},
			{
			"subjectdn": " CN=SKFS JWT Signer 2...",
			"serialnumber": "2055BCF5",
			"pemcert": "..."
			},
			{
			"subjectdn": " CN=SKFS JWT Signer 3...",
			"serialnumber": "1B44980E",
			"pemcert": "."
			}]
		},
	"samlcerts": {
     	    "default": [{
			"subjectdn": " CN=SKFS SAML Signer 1...",
			"serialnumber": "731070AC",
			"pemcert": "."
			},
			{
			"subjectdn": " CN=SKFS SAML Signer 2...",
			"serialnumber": "71E9A8A4",
			"pemcert": "."
			},
			{
			"subjectdn": " CN=SKFS SAML Signer 3...",
			"serialnumber": "493F0442",
			"pemcert": "."
			}],
	    "citrixidp": {
			"subjectdn": " CN=SKFS SAML Signer 1...",
			"serialnumber": "731070AC",
			"pemcert": "."
			}
		}
	}
}

RFE-92

Get Keys to return unique messages in use cases where keys have invalid database signatures

SKFS has a new unique error code that can be returned in a specific use case. If a user attempts to retrieve all the registered keys and none of them pass the database's signature verification, the FIDO server will now return the following error. This error serves as an indicator there is an issue with the database records for the specific user, prompting the relying party to investigate the situation further..

Please contact your Help Desk/Administrator with this code: FIDO-ERR-7000; this credential <credential-id> cannot be used currently. 

RFE-97

Pseudo Randon number generator (PRNG) seeded from a True random number generator (TRNG) for SKFS if installed as part of SAKA appliance

If SKFS is installed as part of an appliance, it will reside on a hardware device with  access to a TPM or HSM. In this use case, the PRNG is initialized on bootup with a TRNG  which is then used to issue challenges for all FIDO operations.