RFE-187

Improve responses from authenticate and deregister webservices

The responses to authenticate and deregister webservices have been improved to be more descriptive and informative.

{
 "Response": "Successfully processed sign response",
 "responseCode": "FIDO-MSG-0008",
 "username": "johndoe",
 "jwt": "eyJhbG.......HIL9wQ",
 "skfsVersion": "4.12.0",
 "registrationVersion": "4.12.0",
 "skfsFQDN": "example.strongkey.com",
 "TXID":"1-169-1679354369053"
}

{
 "Response": "Successfully processed authentication response",
 "responseCode": "FIDO-MSG-0008",
 "username": "johndoe",
 "jwt": "eyJhbl.......58irDiM",
 "skfsVersion": "4.13.0",
 "registrationVersion": "4.13.0",
 "skfsFQDN": "example.strongkey.com",
 "TXID": "1-1-78-1718644717338"
}

{
 "Response": "Successfully deleted",
 "responseCode":"FIDO-MSG-0010",
 "skfsVersion":"4.12.0",
 "skfsFQDN":"example.strongkey.com",
 "TXID":"1-169-1679354369053"
}

{
 "Response": "Successfully deleted keyid: 1-1-6",
 "responseCode": "FIDO-MSG-0010",
 "skfsVersion": "4.13.0",
 "skfsFQDN": "example.strongkey.com",
 "TXID": "1-1-70-1718645214828"
}

RFE-189

Add DID to the definition of transaction ID (TXID) in all webservices

SKFS now includes the cryptographic domain identifier (DID) in the transaction ID (TXID) generated when the servlet receives a webservice request. This transaction ID is printed within every log message associated with that webservice request and can be used to track a transaction across different modules of SKFS by log monitoring tools.

TXID Example:

1-1-71-1717801565621: Server ID aka SID
1-1-71-1717801565621: Cryptographic domain ID aka DID
1-1-71-1717801565621: Thread ID
1-1-71-1717801565621: Current time in millseconds

RFE-205

Update Glassfish and MySQL aliases to Payara and MariaDB equivalents

BASH aliases, which permitted the strongkey' user to execute sudo commands, referenced 'Glassfish' and 'MySQL' within scripts; these have been changed to use 'Payara' and 'MariaDB' equivalents, respectively.

service glassfishd start/stop/restart
service mysqld start/stop/restart
service sladp start/stop/restart

systemctl start/stop/restart payara
systemctl start/stop/restart mariadb
systemctl start/stop/restart slapd

RFE-206

Migrate SKFS to Jakarta Enterprise Edition (JEE) 10

All SKFS modules have been updated to use Jakarta EE. This implies that all 'javax' dependencies (with exceptions listed here) have been replaced with the 'jakarta'-equivalent dependencies: api and web-api.

Other minor changes have been made to ensure a smooth Jakarta EE transition such as updates to persistence files, XSD files, WSDL files, soap stubs, serialization, and generated package names.

These changes are transparent to customer applications that use SKFS webservices (with the exception of SOAP stub-regeneration) as webservices have not changed.

Note:  Please regenerate any SOAP stubs used by clients when upgrading to SKFS version 4.13.0.

RFE-207

Update software distribution for MariaDB

MariaDB
MariaDB has been upgraded from version 10.6.8 to 11.4.2. This newer version of MariaDB now highly recommends using `mariadb` commands as a replacement to the conventional `mysql` commands. As such, some changes have been made in RFE-208 to apply this recommendation to SKFS.

MariaDB java client
MariaDB java client has been upgraded from 2.2.6 to 3.4.0.

RFE-210

Change SKFS default from JDK 11 to JDK 21

With the OpenJDK 11 reaching end of life later this year, the StrongKey FIDO Server (SKFS) software has been upgraded to use OpenJDK 21 by default -  (version 21.0.3.0.9-1 at the time of release)

RFE-211

Update Payara version

Payara Application Server has been upgraded from version 5.2021.6 to 6.2024.4

BUG-99

Fix the residentKey/requireResidentKey failure during Preregistration

SKFS returns Registration and Authentication options during a Preregister or Preauthenticate call and SKFS 4.12 (RFE-147) updated the code to match the code to match the W3C WebAuthn specification to represent residentKey options.

A prior release of SKFS FIDO policy restricted this option to only a single value; as a result SKFS was not returning the correct JSON attribute key for this option.

This has been fixed in SKFS 4.13. It now returns the correct value for the residentKey/requireResidentKey option when there is only one value specified in the discoverableCredential in the FIDO Policy.

BUG-101

Fix bug in the Registration process when attestation certificate is missing (example Self or None Attestation)

The FIDO protocol allows two ways to provide attestations for the packed attestation format when new FIDO credentials are registered at a site – either an attestation provided by a separate “attestation key-pair” established by the manufacturer of the Authenticator, or an attestation provided by the newly generated key-pair of the user performing the registration activity (a “self-attestation”). However, in earlier releases SKFS did not check the type of attestation that was received while performing metadata statement service (MDS) validations. As self-attestation relies on newly generated key-pairs of the user, validating such an attestations against MDS is not possible – the MDS service supports only a form of validation known as “PKIX Validation” with a chain of digital certificates.

SKFS has been updated to skip PKIX Validation if it receives a self-attestation or none attestation from a newly registered key, as long as the FIDO policy has been configured to accept self-attestations or none attestations.