RFE-15

Add source Ip of the calling application to glassfish/payara logs

SKFS now adds the calling application's IP address to the TXID that is generated when the servlet receives any transaction. This TXID is printed with every log message associated with that transaction and can be used to track a single transaction by any log monitoring tool.

Example:

TXID=2-73-1710369529523, clientIP=10.0.2.20

RFE-34

Allow FIDO server to load private MDS files

In SKFS 4.11, the server only allowed loading of Metadata Statement (MDS) provided by FIDO alliance. With SKFS 4.12, the server now allows private MDS files to be loaded in the FIDO server with the requirement that the private MDS files follow the same format as the one provided by FIDO Alliance and are digitally signed. New configuration properties have been added to enable this and some existing properties have been modified to make all the properties consistent.

Existing properties:

# Property that enables MDS download
skfs.cfg.property.mds.enabled=true

#property that defines the fetch mechanism
# Allowed options : URL / File 
# In case of file the location can be  file on the local file system under the /usr/local/strongauth directory
skfs.cfg.property.mds.mechanism=url

skfs.cfg.property.mds.url=https://mds.fidoalliance.org/

skfs.cfg.property.mds.rootca.url=http://secure.globalsign.com/cacert/root-r3.crt

# Whether to continue or return error if an entry doesnt exist in the MDS
skfs.cfg.property.mds.allow.missingentry=true

New properties: (If the deployment is enabling MDS, please update properties with appropriate key, value pairs):

# Property that enables MDS download

skfs.cfg.property.mds.enabled=true

skfs.cfg.property.mds.missingaaguid.register=true

The "skfs.cfg.property.mds.mechanism" has been removed and replaced with the addition of four new properties that determine whether the MDS blob and Root CA will be loaded locally or from a URL. The SKFS now checks first to see if a URL is configured and can be accessed, if not it will attempt to read from the local file system. This applies to both the rootca as well as the MDS blob file.
#location URL for the MDS blob

skfs.cfg.property.mds.fidoalliance.loadmethod.url=https://mds.fidoalliance.org/

#location in the local file system

skfs.cfg.property.mds.fidoalliance.loadmethod.local=

#location URL for the MDS Root CA

skfs.cfg.property.mds.fidoalliance.rootca.loadmethod.url=https://valid.r3.roots.globalsign.com/

skfs.cfg.property.mds.fidoalliance.rootca.loadmethod.local=

The following properties add the ability to provide private digitally signed mds blobs.

Define the number of private MDS files to add with the following property:

skfs.cfg.property.mds.private.count=0

This property allows one to assign a unique name to each private MDS file. The count will increase with the addition of more private MDS files. The <name> must be distinct for each private MDS file and is limited to 20 alphanumeric characters.

skfs.cfg.property.mds.private.source.<count>=<name>

The following three property templates will determine how the private MDS file is loaded and its location. Ensure that the "<name>" matches the value of the property provided above.

skfs.cfg.property.mds.private.<name>.loadmethod=<url | local>
skfs.cfg.property.mds.private.<name>.loadmethod.url=
skfs.cfg.property.mds.private.<name>.loadmethod.local=

Example
skfs.cfg.property.mds.private.source.1=skmanufacturer01
skfs.cfg.property.mds.private.skmanufacturer01.loadmethod=local
skfs.cfg.property.mds.private.skmanufacturer01.loadmethod.url=
skfs.cfg.property.mds.private.skmanufacturer01.loadmethod.local=
/usr/local/strongauth/skfs/mds/skmanufacturer01.txt
 
skfs.cfg.property.mds.private.source.2=skmanufacturer02
skfs.cfg.property.mds.private.skmanufacturer02.loadmethod=local
skfs.cfg.property.mds.private.skmanufacturer02.loadmethod.url=
skfs.cfg.property.mds.private.skmanufacturer02.loadmethod.local=
/usr/local/strongauth/skfs/mds/skmanufacturer02.txt
 

The private MDS files must be been digitally signed in order for the SKFS to use them and the SKFS needs the certificate (public key) to verify the signature before the file can be accepted. The following properties define the location and password of the truststore that contains the required certificates. When adding the certificate to the truststore, the certificate alias needs to match the <name> identified for a specific private MDS file.
# properties for private MDS properties

skfs.cfg.property.mds.private.truststore.location=
skfs.cfg.property.mds.private.truststore.password=

RFE-147

Update code to match residentKey/requireResidentKey to the level 2 specification

The usage of "residentKey"/"requireResidentKey" within the request of the calling application's "options" JSON object was not used in conformance to the webauthn specification level 1 & level 2. In this release, SKFS 4.12 has been updated to match the webauthn specification and allows either option to be sent ("residentKey" from webauthn level 2 is preferred). All the applications calling SKFS web service APIs will have to be updated to use the new options.

Old input:(options inside the payload)

"options": {
    "authenticatorSelection": {
        "requireResidentKey": "required",
        "userVerification": "required"
    },
    "attestation": "direct"
}

New input: (options inside the payload) The new key/value pairs are highlighted. SKFS will accept either of the highlighted options or both but will always give preference to "residentKey" if both are specified and respond accordingly.

"options": {
    "authenticatorSelection": {
        "residentKey": "required",
        "requireResidentKey": true,
        "userVerification": "required"
    },
    "attestation": "direct"
}

The SKFS will first check the request for the "residentKey" key within the "options" JSON object and then for "requireResidentKey". If the value specified is allowed by the active FIDO policy, the server will respond with both the "requireResidentKey" and "residentKey" values.

Mapping of values:

"residentKey (Webauthn level 2)" -> "requireResidentKey (Webauthn level 1)"

"required"                   ->  true
"discouraged"             ->  false
"preferred"                  -> N/A

RFE-159

Add PKIX validation for attestation certificates used by authenticators

SKFS accepts attestation from multiple types of authenticators and some of these authenticators have a Metadata statement either provided by FIDO Alliance MDS or a private MDS file. The attestations sent by the authenticator contains an attestation certificate in the response which is used to validate the signature. This attestation certificate can be validated against a chain of trust if it is provided by the MDS files. SKFS 4.12 now checks to see if an MDS entry exists for the AAGUID provided in the attestation response and if it finds the chain of trust, it will perform PKIX validation. SKFS does not use the output of this check to determine the signature validity but returns this information to the calling application for it to make the final decision on whether to accept the response or not.

RFE-160

Add a new return parameter to indicate if PKIX validation was performed (Related to RFE-159)

SKFS now performs PKIX validation as stated by RFE-159 and it now returns the boolean output of PKIX validation to the calling application in the response.

"pkixValidated": true | false 

RFE-182

Populate SKFS FIDO Policy with SSO certificate info regardless of whether JWT or SAML are enabled

In cases where JWT or SAML were enabled post-installation, the SKFS FIDO Policy did not contain the SSO certificate details necessary for loading SSO keys, requiring manual policy updates. All SKFS FIDO Policies created during installation are now populated with SSO certificate details.

RFE-183

Improve SKFS SSO map loading readability

JWT and SAML signing instance maps were unnecessarily complicated. SignatureCertificateObject has been created to store necessary JWT and SAML key information better.

BUG-78

Return appropriate message when a FIDO credential is deleted from the FIDO server but not from the authenticator api call

During discoverable credential authentication flow, an error can happen if the credential is deleted from the FIDO server but not from the FIDO authenticator. In such a case, if discoverable flow is used, the authenticator has no indication of whether a credential has been invalidated on the server side and it can still use the "deleted" credential to create an authentication response. The server was not returning the right response in such a scenario.

The server has been updated to return an appropriate message:

DISCOVER-ERR-5001: Error returned while calling the SKFS: {"Response":"FIDO-ERR-2001: FIDO2 Error Message : {0}FIDO-ERR-7002: Unable to retrieve FIDO key from database"}

BUG-90

Fix Cross Origin verification failing during authentication

Fixed bug in cross origin verification introduced by BUG-67. Origin and RPID verification checks bypassed cross origin checks.

BUG-96

Fix incorrect FIDO_KEYS row order introduced in 4.4.0 upgrade

SAKA/SKFS 4.12.0 upgrade script now includes fix for bug in 4.4.0 upgrade script that mixed up the FIDO_KEYS table's row order.