Authentication

Authorization

Role-based Access Control Matrix

SKFS is unique in that it does not make available a software library that needs to be linked to applications to use FIDO; it is a full-blown enterprise-class server built to the Java Enterprise Edition (JEE) architecture, leveraging a relational database (MariaDB), FIPS-certified cryptographic libraries, etc. When deployed on the StrongKey Tellaro appliance, it also takes advantage of a FIPS 140-2 Level-2 or Level-3 cryptographic hardware module.

Applications take advantage of a rich set of web services—SOAP or REST—to use FIDO capabilities. As a consequence, many of the explicit details of how FIDO works are shielded from business application developers.

When an application needs to register a new FIDO Authenticator, the applications calls the preregister web service on SKFS to get a challenge. The application sends this to the browser, which in turn, calls functions on the authenticator using FIDO Client to Authenticator Protocol (CTAP). When the user has completed necessary actions with their FIDO authenticator and returned a response to the application, the application calls the register web service to complete the registration process.

Similarly, when a user needs to authenticate to the application, the application calls the preauthenticate web service to get a challenge. Upon getting a digital signature from the authenticator, the application calls the authenticate web service to complete the authentication process.

All such transactions with SKFS involve calling one web service or another. However, to ensure that only authorized applications can make such web service requests, SKFS includes an authentication and authorization framework for applications.

Authentication

To determine an application’s authorization to call a specific web service for standard FIDO operations—registration, authentication, etc.—the application must be assigned a unique Service Credential. Much like a human supplies a username and a password to authenticate themselves, applications must be assigned a Service Credential Identifier (SCID)—a unique string, much like a username, that identifies the application. Some examples might be:

• payment-gateway-scid
• new-customer-registration-scid

Two options are available in SKFS to authenticate the SCID:

• A password string similar to what most humans are used to; the application making the web service request supplies this value as-is as the authentication parameter in the web service request
• A cryptographic secret key (usually in base64-encoded form which must be converted to a binary value) to calculate a hashed message authentication code (HMAC) on the web service method+parameters; the application making the web service request supplies the HMAC result (a.k.a. hash) as the authentication parameter in the web service request

An internal-facing application that performs administrative functions by calling a privileged web service performing administrative actions must be assigned an Administrator Credential Identifier (ACID)—a unique string, much like a username, that identifies the application. Some examples might be:

• mycompany-corporate-skfs-acid
• ecommerce-skfs-acid

Authenticating the ACID offers similar options as for the SCID (see above).

SKFS has distinct web services for the items listed below:

• FIDO Transaction operations (SCID)
• Administrative operations (ACID)
• FIDO Credential operations (FCID)
• Policy Management operations (PCID)
• Monitoring operations (MCID)

It is recommended to separate credentials according to the operations a specific application or command-line interface (CLI) tool might call from the SKFS. This ensures applications will have the least privileges necessary to perform a given function.

Authorization

Once an application’s web service request is authenticated, SKFS must determine its authorization to consume that web service. It does this by affirming that the SCID/ACID/FCID/PCID/MCID is part of an LDAP role (a.k.a. group) authorized for the operation in question.

SKFS organizes web services operations according to the privileges required to perform the operation. The following default names for the LDAP roles are used to clearly identify the operations; however, sites may choose to use their own role names as long as configuration properties for SKFS reflect the names of the LDAP groups present in the LDAP Directory Server used to determine authorizations.

The default names of the roles are listed here: 

• FidoRegistrationService-AuthorizedServiceCredentials—This role enables access to the preregister and register web services. This allows sites to dedicate applications responsible for registering new FIDO credentials for users, and create SCIDs for such applications. Applications with SCIDs that belong to this role can register new FIDO credentials within the SKFS.
• FidoAuthenticationService-AuthorizedServiceCredentials—This role enables access to the preauthenticate and authenticate web services. Applications with SCIDs that belong to this role can authenticate users with existing FIDO credentials within the SKFS.
• FidoAuthorizationService-AuthorizedServiceCredentials—This role enables access to the preauthorize and authorize web services. Applications with SCIDs that belong to this role can enable getting transaction confirmations (aka authorization) from users with existing FIDO credentials within the SKFS.
  

  NOTE: If a Relying Party site anticipates that all applications within their network will need to access registration, authentication, and transaction confirmation services, they can choose to collapse these three roles into a single FIDOCoreOperationService-AuthorizedServiceCredentials role and add unique SCIDs for each application to this role.
  

  Please also note that if the Registration, Authentication and Authorization roles are collapsed into a single "CoreOperation" role, the collapsed role name must be added to the SKFS configuration properties that affect registration, authentication, and authorization operations.

• FidoAdministrationService-AuthorizedServiceCredentials—This role enables applications to access the getKeys, updateKeys, deleteKeys, viewPolicy, addConfig, updateConfig, deleteConfig, viewConfig, ping, and updateUsername web services. Applications with ACIDs that belong to this role can perform these privileged administrative operations within the SKFS.
• FidoCredentialService-AuthorizedServiceCredentials—Registered users will, occasionally, want to perform their own “FIDO key-management” - as when they might choose to delete a credential for a lost Security Key, register a new device or Security Key or change the display-name that identifies a device or Security Key within their profile. Applications with FCIDs that belong to this role are authorized to access the getKeys, updateKeys, and the deleteKeys web services to support these operations within applications.
• FidoPolicyManagementService-AuthorizedServiceCredentials—This role enables applications to access the addPolicy, updatePolicy, deletePolicy, and viewPolicy web services. Applications with PCIDs that belong to this role can perform these privileged policy management operations within the SKFS.
• FidoMonitoringService-AuthorizedServiceCredentials—This role enables applications to access the viewPolicy, viewConfig, and ping web services. Applications with MCIDs that belong to this role can perform these privileged monitoring operations within the SKFS.

RP sites may create role with custom names within LDAP groups, or use any existing LDAP group name(s) from the RP's LDAP Directory Server, if desired. However, it will be necessary to modify SKFS configuration properties to identify the custom LDAP group-names before SKFS will use the new names.

Role-based Access Control Matrix

The following table shows the different roles and web service operations to which each role is authorized to consume: