RFE-139

End-of-Life (EOL) for HMACs when calling SKFS webservices

Starting with version 4.14.0, SKFS web services no longer support HMAC authentication. This change was made because HMAC authorization lacked the granular control provided by other authentication mechanism.

The only supported authentication mechanism now is the LDAP username-password method, which offers enhanced flexibility. With this mechanism users can be separated into groups, each with distinct authorization levels. For example, service credentials in the FidoRegistrationService-AuthorizedServiceCredentials group are restricted to executing only the pre-register and register web services.

Previously, HMAC-based authentication allowed a single access key/secret key combination to perform all SKFS operations, which did not support such fine-grained control.

Click here for more details.

RFE-214

Database signatures protecting the integrity of FIDO credentials to include Authenticator counters when generating the signature

By default, SKFS signs every row stored in the MariaDB database to ensure data integrity. Previously, the counter column in the FIDO_KEYS table was excluded from the database signature.

Starting with the 4.14.0 release:

• The value in the counter column is included by default in the calculation of the row-level signature.

• For upgrades from prior versions of SKFS, backward compatibility is maintained by configuring the SKFS instance to exclude the counter column from the signing and verification process.

During an upgrade from a prior release to 4.14.0, the following property is added to the SKFS configuration file in /usr/local/strongkey/skfs/etc/skfs-configuration.properties.

skfs.cfg.property.db.signature.includecounter=false

Note: This property must be set to either true or false before SKFS begins registering credentials. Once the FIDO_KEYS table has been populated, this configuration cannot be changed.

RFE-234

Update Basicdemo and the FIDO Policy sample web applications to eliminate the need for a local database

StrongKey provides several FIDO-enabled sample applications as part of the open-source release of SKFS (https://docs.strongkey.com/index.php/skfs-v3/skfs-developer/sample-applications) to demonstrate different capabilities and methods for FIDO-enabling applications. Some of these applications utilize a local database to manage user credentials registered within the application. This approach restricted using a single registered FIDO credential across multiple web applications.

In this release, local database has been removed from Basicdemo and the FIDO Policy sample web applications. These applications now share a common database on a single instance of SKFS; users can register and authenticate in one sample application, and authenticate into these web applications supported by SKFS. This is made possible when all web applications relying upon registered credentials from another application are configured to use the same FIDO Domain within SKFS.

Note: The E-commerce sample web applications still rely on the local databases but will transition to a shared database in the future release.

RFE-236

Re-introduce keyhandle encryption/decryption

Regulations around the world are beginning to require that credential usernames be psuedonymized using tokens to protect the privacy of users. For customers using SKFS on the StrongKey Tellaro appliance, the appliance has had the ability to encrypt and tokenize information since 2009.

SKFS takes advantage of this capability in the Tellaro appliance to encrypt and tokenize the credential id (keyhandle) before storing in the database. This feature is optional currently and must be configured during installation. If this feature is enabled after installation, FIDO credentials created before this feature was enabled CANNOT BE USED ANYMORE. So, it is strongly recommended that customers understand the implications of this feature before enabling it.

Properties associated with this feature – with default values - are as follows:

skfs.cfg.property.db.keyhandle.encrypt=true

In order to enable the tokenization of credential identifiers, a Tokenization Service Credential (TSC) username and password must be provided to the SKFS module. This service credential is created using DACTool – a tool available for administering the Tellaro appliance’s Encryption Domain. The TSC username must be given encrypt, decrypt, and search permissions within DACTool. Once created, the following properties:

skfs.cfg.property.saka.cluster.1.domain.[domain].username=[TSC username]

skfs.cfg.property.saka.cluster.1.domain.[domain].password=[TSC username’s password]

Note: This feature is only available for SKFS instances on the StrongKey Tellaro Appliance.

RFE-241

Modify response for the updateusername webservice to be consistent with responses from other SKFS webservices

The response to updateusername webservice has been modified to provide a response that is consistent with responses from other SKFS webservice.

{
    "status": true,
    "message": "FIDOJPA-MSG-2015: Successfully updated username",
    "responseCode": "FIDO-MSG-0077",
    "skfsVersion": "4.13.0",
    "skfsFQDN": "example.strongkey.com",
    "TXID": "1-1-73-1717786650941"
}

{
    "Response": "Successfully updated username",
    "responseCode": "FIDO-MSG-0077",
    "skfsVersion": "4.14.0",
    "skfsFQDN": "example.strongkey.com",
    "TXID": "1-1-75-1731008314250"
}

RFE-245

Added support for WebAuthn Level-3 Related Origin Requests (ROR)

The FIDO protocol was originally designed for 2-party communication: a human user authenticating to a web application operated by a company – the Relying Party (RP) – with whom users register FIDO credentials for strong authentication.

However, there are business situations where a human user must authenticate to the RP (where the FIDO credential is registered) through an intermediary, using a web application created by the intermediary. This is a 3-party communication which the current FIDO protocol did not handle.

Some example business situations where such 3-party communications are prevalent, are:

• In an e-Commerce environment, a Consumer buying a product at a Merchant’s web site, and the Bank with the Consumer credit card account needs to authenticate the Consumer before authorizing the payment;

• In an Open Finance environment, a Consumer transferring money to someone – for example, to pay a plumber for installing a new faucet - with a mobile app created by a third-party Payment Service Initiator (PSI), and the Bank with the Consumer account needs to authenticate the Consumer before authorizing/executing the transfer.

In these situations, the user is interacting with the intermediary’s – Merchant or Payment Service Initiator - application, but the FIDO credential is registered with the RP – in these examples, the Bank – that must authenticate the Consumer. The current FIDO protocol doesnot not support this feature. Note: An older FIDO protocol - Universal 2nd Factor aka U2F – did (AppID and TrustedFacets); but when U2F was merged into the current FIDO protocol – FIDO2/WebAuthn - the feature was removed!

Recognizing the need tor such a capability, the feature has been reintroduced in WebAuthn Level-3 as the Related Origin Requests (ROR). While the specification is not yet final, multiple browsers have implemented the feature, and as such web applications can leverage it if a FIDO server and its RP support it.

With version 4.14.0, SKFS introduces support for ROR, enabling an RP to authenticate their users either directly or through an intermediary’s application at defined web origin(s). Read more about ROR here.

When ROR is enabled (through properties shown below), a configuration file named “webauthn” 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 enabled on ALL nodes of an SKFS cluster for ROR to work on the cluster.

This webauthn file contains necessary information to allow web applications hosted on named web origins, to use FIDO credentials registered with the RP, on all the named web origins.

The SKFS administrator must take a copy of the "webauthn" file (from any of the configured SKFS instances’ configuration directories) and store it in the location specified in the ROR specification. This location is a directory named “.well-known/” on a publicly accessible website on the internet with a web origin matching the RPID configured in SKFS for that FIDO Domain. Thus, if the RPID for an SKFS FIDO Domain is “myshoppe.com”, the ROR configuration file must be accessible at https://myshoppe.com/.well-known/webauthn. If the RPID of another FIDO Domain on the same SKFS instance is “mypaymentapp.net”, the ROR configuration file must be accessible at https://mypaymentapp.net/.well-known/webauthn.

Since this configuration file is generated by the RP (on their SKFS machine) and stored on a site controlled by the RP (since it corresponds to their RPID), it ensures only web applications running on known, predefined web origins are permitted to authenticate users using FIDO credentials generated for the RP’s use.

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

To support ROR, the following configuration properties are introduced in SKFS 4.14.0 (Note: Once WebAuthn Level-3 is a formal standard, and if ROR remains a part of the Level-3 standard, SKFS will incorporate ROR configuration properties into its FIDO Policy module in a future release. Since it is NOT a current WebAuthn standard, it is implemented as an SKFS configuration property in this release):

Property to enable ROR which is set to false by default. 
Allowed values are true | false. 
The default value should be changed to "true", and the associated "origins" property shown below must also be filled out:

skfs.cfg.property.fido2.rp.relatedorigins.enabled=false

Property to specify a list of related web origins whose web applications are authorized to use FIDO credentials registered with the RP hosting the “webauthn” file, is as follows. Valid web origins must be comma-separated and must include the scheme, port number (if any) and context (if any):

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

Example:
skfs.cfg.property.fido2.rp.relatedorigins.enabled=true
skfs.cfg.property.fido2.rp.relatedorigins.origins=https://myshoppe.com,https://mypaymentapp.net

Another Example:
skfs.cfg.property.fido2.rp.relatedorigins.enabled=true
skfs.cfg.property.fido2.rp.relatedorigins.origins=https://fido.example.com,https://fido.example.co.uk

Ensure all web origins listed are valid in accordance with RFC standards.

Please Note: This will ONLY work for a single FIDO domain of an SKFS instance and that there will be a release within the next 4-6 weeks that will add support for multiple domains as well as registration.

RFE-250

SKFS failing to register/authenticate users when web application origins were deeper (longer) than RPID+1

Web applications typically choose their origins (URLs) based on their business needs – some are simple, such as https://myshoppe.com or https://mybank.com. Others may be more complex – such as https://partner.logistics.ecom.bigerp.mycompany.net. While these are still valid web origins for the application, with FIDO there is new complexity.

The FIDO protocol – supported by SKFS – requires web sites to define a relying party ID (RPID) that uniquely identifies the site’s FIDO infrastructure. RPIDs are generally simple and resemble DNS domain names – such as myshoppe.com, mybank.com or mycompany.net.

In earlier releases, SKFS checked to verify that web application origins were only one DNS sub-domain longer than the RPID – so https://ecommerce.myshoppe.com or https://mortgage.mybank.com were valid origins – but https://toys.ecom.myshoppe.com or https://mortgage.loans.mybank.com were deemed invalid and resulted in errors.

With this release, SKFS has been fixed to support web origins at any depth, so that https://toys.ecom.myshoppe.com, https://mortgage.loans.mybank.com or https://partner.logistics.ecom.bigerp.mycompany.net are valid for their respective RPIDs of myshoppe.com, mybank.com or mycompany.net.

BUG-108

SKFS not checking for for missing User-Agent or Client IP address (CIP) before creating JWT

When SKFS is configured to return a JSON Web Token (JWT) to successful FIDO authentication webservice requests, the response payload includes the User-Agent and Client IP address (CIP) extracted from the request headers or the authentication webservice request. Previously, SKFS did not verify if these values were present before creating the JWT.

This release fixes this bug and the authentication webservice request now fails , and appropriate error messages are logged when the User-Agent or Client IP is missing.

BUG-109

Fix Payara application server restart time-outs in Rocky Linux

The Payara application server sometimes take longer to start up after a restart (or after a reboot of the StrongKey Tellaro appliance) due to house-keeping tasks SKFS may be performing. This increased start-up time causes Linux’s systemd service to time out and kill the process, thus preventing Payara from starting.

Additionally, in larger deployments, an error occurs when Payara starts up faster than the MariaDB database service. This causes errors since SKFS cannot access the database to perform its work; error messages in Payara’s log file are a symptom of this problem.

To prevent these problems, the default timeout for starting the Payara application server by systemd has been increased to 900 seconds.

BUG-116

Fix for Linux’s systemd not loading environment variables

An issue was found where starting the Payara application server using systemd did not load environment variables set in user-specific “rc” files like .bashrc or skfsrc.

https://wiki.archlinux.org/title/Systemd/User: Section 2.1: "Units started by user instance of systemd do not inherit any of the environment variables set in places like .bashrc etc."

The ExecStart directive in “payara.service” has been updated to explicitly mention required environment variables:

Previous Configuration:

ExecStart=/usr/local/strongkey/payara6/glassfish/bin/asadmin start-domain 

Updated Configuration:

ExecStart =/bin/bash -c '. /etc/skfsrc; /usr/local/strongkey/payara6/glassfish/bin/asadmin start-domain'

BUG-119

Fix missing JARs for SOAP in skfsclient

A prior update to SKFS neglected to include a SOAP library for skfsclient and caused it throw an error. The following library has been included in this release:

• jaxws-rt version 4.0.2
• istack-commons-runtime version 4.1.2