RFE-28

Change database to include last_used_date

A "last_used_date" attribute has been added to the fido_keys table. This date is set to null on FIDO Credential creation, and updated to the current date each time the FIDO Credential is used for authentication. This value can be retrieved from the getkeysinfo or getuserkeys web services.

Example response from old getkeysinfo web service request:

{
    "Response": {
        "keys": [{
            "keyid": "1-1-1",
            "fidoProtocol": "FIDO2_0",
            "credentialId": "YnTEu0Vg...5kRg1xcM",
            "createLocation": "Sunnyvale, CA",
            "createDate": 1673396114000,
            "lastusedLocation": "Sunnyvale, CA",
            "modifyDate": 1679080360000,
            "status": "Active",
            "displayName": "johndoe",
            "attestationFormat": "packed",
            "authenticatorType": "securitykey"
        }]
    },
    "responseCode": "FIDO-MSG-0012"
}

Example response from new getkeysinfo web service request:

{
    "Response": {
        "keys": [{
            "keyid": "1-1-1",
            "fidoProtocol": "FIDO2_0",
            "credentialId": "YnTEu0Vg...5kRg1xcM",
            "createLocation": "Sunnyvale, CA",
            "createDate": 1673396114000,
            "lastusedLocation": "Sunnyvale, CA",
            "lastUsedDate": 1679080360000,
            "modifyDate": 1679080360000,
            "status": "Active",
            "displayName": "johndoe",
            "attestationFormat": "packed",
            "authenticatorType": "securitykey"
        }]
    },
    "responseCode": "FIDO-MSG-0012",
    "skfsVersion": "4.9.0",
    "skfsFQDN": "example.strongkey.com",
    "TXID": "1-174-1677279652057"
}

Note: Extra highlighted part of getkeysinfo response json addressed in RFE-35 and RFE-38

SKFS 4.9.0 "fido_keys" table description:

MariaDB [skfs]> show columns from fido_keys;
+----------------+----------+------+-----+---------+-------+
| Field          | Type     | Null | Key | Default | Extra |
+----------------+----------+------+-----+---------+-------+
| ...            |          |      |     |         |       |
| last_used_date | datetime | YES  |     | NULL    |       |
| ...            |          |      |     |         |       |
+----------------+----------+------+-----+---------+-------+

RFE-35

Added SKFS version and hostname to top level SKFS API JSON response

SKFS version and hostname will now be printed to the API's top level JSON response for the following web services (ping excluded):

FIDO operations: preregister, register, preauthenticate, authenticate, preauthorize, authorize, getkeysinfo, updatekeyinfo, deregister

Admin operations: getuserkeys, updateusername, getpolicy, getallpolicies, addpolicy, updatepolicy, deletepolicy, getconfiguration, updateconfiguration, deleteconfiguration

Example response from authenticate web service request:

{
    "Response": "Successfully processed sign response",
    "responseCode": "FIDO-MSG-0008",
    "jwt": "eyJhbGci...jz5gfUPk",
    "skfsVersion": "4.9.0",
    "skfsFQDN": "example.strongkey.com",
    "TXID": "1-174-1677279652057"
}

Note: Extra highlighted part of authenticate response json addressed in RFE-38

RFE-36

Included Hex encoded RPID hash with Base64 encoded RPID hash FINE log prints

Where the SKFS would normally print the base64 encoded rpid hash from the SKFS policy (at all logging levels), it now prints both the base64 encoded and hex encoded RPID hash in FINE level logs.

Example old authenticate INFO server log:

[2023-03-15T15:49:18.292-0700] [Payara 5.2021.6] [FINE] [FIDO-MSG-2001] [SKFS] [tid: _ThreadID=72 _ThreadName=http-thread-pool::http-listener-2(3)] [timeMillis: 1678920558292] [levelValue: 500] [CLASSNAME: com.strongkey.skfs.utilities.SKFSLogger] [METHODNAME: log] [[
 FIDO-MSG-2001: FIDO 2 Debug Message : rpidHash : WnTBrV2dI2nYtpWAzOrzVHMkwfEC46dxHD4U1RP9KKM=, [TXID=1-72-1678920558274]]]

Example new authenticate FINE server log:

[2023-03-15T15:49:18.292-0700] [Payara 5.2021.6] [FINE] [FIDO-MSG-2001] [SKFS] [tid: _ThreadID=72 _ThreadName=http-thread-pool::http-listener-2(3)] [timeMillis: 1678920558292] [levelValue: 500] [CLASSNAME: com.strongkey.skfs.utilities.SKFSLogger] [METHODNAME: log] [[
 FIDO-MSG-2001: FIDO 2 Debug Message : base64 rpidHash : WnTBrV2dI2nYtpWAzOrzVHMkwfEC46dxHD4U1RP9KKM=, hex rpidHash : 5a74c1ad5d9d2369d8b69580cceaf3547324c1f102e3a7711c3e14d513fd28a3, [TXID=1-72-1678920558274]]]

RFE-37

Separated SKFSClient CLI into SKFSClient and SKFSAdminClient CLIs

Currently the SKFSClient is used to run both normal FIDO user operations (R, A, AZ, G, U, D) and admin user operations (P, UU, GP, CP, UP, DP, GC, UC, DC, GUK).

These two sets of operations from the previous SKFSClient CLI are now separated into a SKFSClient CLI (FIDO user) and a SKFSAdminClient CLI (Admin user) with their respective operation sets.

In addition to this CLI change, other CLI changes have been made:

• PatchPolicy has been changed to UpdatePolicy in CLI usage.
  
• When updating a policy, the server now logs the previous policy that has been replaced.

RFE-38

Added TXID/AppTXID to the responses of SKFS web services

A simple change to add the TXID/AppTXIDs to the SKFS web service API's top level responses, much like how the SKFS version and hostname were added in RFE-35

In addition to this change, a new property has been added:

skfs.cfg.peroperty.auth.return.responselevel

This property determines the level of authentication detail that is returned in the preauthenticate and authenticate web service responses, allowing an administrator to choose whether to keep authentication responses simple or detailed.

For now, the two accepted values are 0, for no extra response details, and 1, for adding the key/value pairs specified in RFE-35 and RFE-38.

RFE-51

Added AAGUID to getkeysinfo response

The getkeysinfo web service now includes the aaguid of each key returned.

Old getkeysinfo response:

{
    "Response": {
        "keys": [{
            "keyid": "1-1-1",
            "fidoProtocol": "FIDO2_0",
            "credentialId": "YnTEu0Vg...5kRg1xcM",
            "createLocation": "Sunnyvale, CA",
            "createDate": 1673396114000,
            "lastusedLocation": "Sunnyvale, CA",
            "lastUsedDate": 1679080360000,
            "modifyDate": 1679080360000,
            "status": "Active",
            "displayName": "johndoe",
            "attestationFormat": "packed",
            "authenticatorType": "securitykey"
        }]
    },
    "responseCode": "FIDO-MSG-0012",
    "skfsVersion": "4.9.0",
    "skfsFQDN": "example.strongkey.com",
    "TXID": "1-174-1677279652057"
}

New getkeysinfo response:

{
    "Response": {
        "keys": [{
            "keyid": "1-1-1",
            "fidoProtocol": "FIDO2_0",
            "credentialId": "YnTEu0Vg...5kRg1xcM",
            "aaguid": "2fc0579f-8113-47ea-b116-bb5a8db9202a",
            "createLocation": "Sunnyvale, CA",
            "createDate": 1673396114000,
            "lastusedLocation": "Sunnyvale, CA",
            "lastUsedDate": 1679080360000,
            "modifyDate": 1679080360000,
            "status": "Active",
            "displayName": "johndoe",
            "attestationFormat": "packed",
            "authenticatorType": "securitykey"
        }]
    },
    "responseCode": "FIDO-MSG-0012",
    "skfsVersion": "4.9.0",
    "skfsFQDN": "example.strongkey.com",
    "TXID": "1-174-1677279652057"
}

RFE-52

Added pretty print option to SKFSAdminClient's GetPolicy operation

SKFSAdminClient now accepts option to pretty print the policy when performing a GP request. Accepted values: true | false

Old SKFSClient GP usage:

java -jar skfsadminclient.jar GP <hostport> <did> <wsprotocol> <authtype> [ <accesskey> <secretkey> | <svcusername> <svcpassword> ] <metatdataonly> <sid> <pid>

New SKFSAdminClient GP usage:

java -jar skfsadminclient.jar GP <hostport> <did> <wsprotocol> <authtype> [ <accesskey> <secretkey> | <svcusername> <svcpassword> ] <metatdataonly> <sid> <pid> <prettyprint>

Example output of the pretty printed GP operation can be found here.

BUG-17

Prevented adding a new SKFS FIDO Policy to a domain that already has an existing SKFS FIDO Policy

In previous versions of SKFS, a user was allowed to assign multiple SKFS FIDO Policies to a single domain. The FIDO Policy that would take effect for that domain in that scenario was most recent (based on the "startDate" found in the FIDO Policy, and NOT the "create_date" attribute in the "fido_policies" table in the database) active FIDO Policy found in the database. This scenario was rare, but when it happened, users could not immediately tell which FIDO Policy was in effect for the domain in question. To fix this in SKFS 4.9.0, the server now rejects adding new FIDO Policies to a domain if it already has one assigned to it.

This change comes with other changes:

• Only a single SKFS FIDO Policy is allowed per domain. New SKFS 4.9.0 installs will not have issues with this, but SKFS installs prior to 4.9.0 will need to run the upgrade script to deal with this issue.
  
• Removed ability to set policy status to active/inactive. Since only a single FIDO Policy is allowed per domain, it is assumed the domain's singular FIDO Policy is always active. The SKFS API has not changed, but any policy-related status added to API request will not be read into the database.

BUG-28

Re-integrated PKI2FIDO with the current release of StrongKey FIDO Server

Earlier releases of PKI2FIDO were designed to work with StrongKey CryptoEngine (SKCE) which included a FIDO server that supported the Universal 2nd Factor (U2F) protocol.

Since U2F is now merged with the FIDO2/WebAuthn protocols, StrongKey has created a new release of a FIDO2 open source FIDO certified server: StrongKey FIDO Server (also available on SourceForge).

This release of PKI2FIDO integrates with the current release of SKFS.

BUG-29

Integrated PKI2FIDO with OpenLDAP Directory Server

Earlier releases of PKI2FIDO depended on the LDAP Directory Server capability that was integrated into the StrongKey CryptoEngine (SKCE).

Since the StrongKey FIDO Server (SKFS) now stands alone as an independent module, PKI2FIDO must rely upon an explicit LDAP Directory Server to perform the authorization checks demonstrated for registering FIDO credentials.

This release of PKI2FIDO integrates with OpenLDAP Directory Server v2.62. The OpenLDAP Directory Server must be installed and available for PKI2FIDO to work.