SSO PKI Generation

Creating SKFS SSO PKI in a SAKA Environment

In a standalone SKFS environment, the server will always load SSO keys from file; all SSO keys must be generated from the keygen-sso.sh script bundled with the SKFS distribution. However, if the server is not running a standalone SKFS in a SAKA environment, then with version 4.12.0, this key generation responsibility has been moved from the keygen-sso.sh script (although it will still exist within our SKFS and SAKA distributions) to the Domain Setup (New-Domain-Setup-Wizard.sh) and Domain Replication (Secondary-SAKA-Replication-Final.sh) wizards.

Domain Setup Wizard (New-Domain-Setup-Wizard)

A new "Create Domain SSO PKI" page has been added to the new Domain Setup wizard which is responsible for creating the SSO PKI for the newly created encryption domain. This PKI consists of a Root CA and multiple JWT and SAML leaf certificates, resembling a 1-tier PKI hierarchy.

[Image of page in new domain wizard]

Upon reaching this "Create Domain SSO PKI" page, the domain administrator will have a chance to change the subject DNs of the Root CA, JWT, and SAML certificates. By default, they will be:

CN=StrongKey FIDO Server RootCA,OU=DID {DID},O=StrongKey
CN=SKFS JWT Issuer {COUNT},OU=DID {DID},O=StrongKey
CN=SKFS SAML Issuer {COUNT},OU=DID {DID},O=StrongKey

Upon SSO PKI creation, the "{DID}" keyword for each subject DN will be replaced with the domain ID of the newly created encryption domain.

Similarly, the "{COUNT}" keyword will be replaced with the certificate number. By default, 3 certs are created per SSO type. If the "{COUNT}" keyword has been removed, only a single certificate for the respective SSO type will be created instead.

If the "RSA SAML Keys" checkbox is checked on SSO PKI creation, the SAML key algorithm will use RSA instead of EC.

Unless a specific SSO requirement has been made for the SKFS, it is recommended that the values in each text field stay default.

When the "Create" button is clicked, a number of things happen:

SSO PKI creation. Below are the default values for each key/cert that is created:

Root CA:
DN: CN=StrongKey FIDO Server RootCA, OU=DID ${DID}, O=StrongKey
  Duration: 20y
  Key algo: ECDSA
  Key size: 521 bits
  Sign algo: SHA512 with ECDSA

JWT Leaf Certs:
  DN: CN=SKFS JWT Issuer ${COUNT}, OU=DID ${DID}, O=StrongKey
  Duration: 10y
  Key algo: ECDSA
  Key size: 384 bits
  Sign algo: SHA256 with ECDSA

SAML (EC) Leaf Certs:
  DN: CN=SKFS SAML Token Issuer ${COUNT}, OU=DID ${DID}, O=StrongKey
  Duration: 10y
  Key algo: ECDSA
  Key size: 384 bits
  Sign algo: SHA256 with ECDSA

SAML (RSA) Leaf Certs:
  DN: CN=SKFS SAML Token Issuer ${COUNT}, OU=DID ${DID}, O=StrongKey
  Duration: 10y
  Key algo: RSA
  Key size: 2048 bits
  Sign algo: SHA256 with RSA
Create SKFS FIDO Policy. This creates and populates a minimal SKFS FIDO policy with certificate details from the newly created SSO PKI.
Keystore encryption. The keystore that contains all of these newly created keys is converted to base64 and split into blocks of 10,000 characters (The max number of character that can be encrypted with KeyAppliance). The KeyAppliance (KA) then uses the new domain to encrypt these base64 blocks and return a list of token numbers for the SSO PKI keystore base64.
Set escrowed keystore base64 tokens to SKFS properties. The SKFS properties file on the system is searched for the "skfs.cfg.property.sso.keystore.encrypted.tokens" property. If not found, it will be added with an initial entry of:
```
[new did]:[token]-[token]-....
```
If this property does exist, then it is appended to a list of entries. Ex. If creating a 2nd domain, the new property may look something like this:
```
skfs.cfg.property.sso.keystore.encrypted.tokens=1:1000000000000123-1000000000000456,2:1000000000000002-1000000000000003
```
Write property to file for replication. The wizard will write the "skfs.cfg.property.sso.keystore.encrypted.tokens" property value for the new domain to a {DID}-domainEscrowedSSOKeystore.properties file in the same location the domain administrator keystore was saved to. This will be used to set the property in the Domain Replication wizard.
Write certificates to the on-file truststore. If the SKFS SSO truststore used is found on the appliance in its appropriate location (/usr/local/strongauth/skfs/keystores/ssosigningtruststore.bcfks), it is loaded and the certificates generated during this wizard are added to it. If no truststore is found, it will be created and populated with the new certificates.
Write CSR files. When the SSO PKI is created, the CSR files are kept for use in an external PKI. These files are written to the usual .csr location on the appliance (/usr/local/strongauth/strongkeylite/etc/).

Domain Replication Wizard (Secondary-SAKA-Replication-Final.sh)

Similar to the Domain Setup wizard, the Domain Replication wizard has also received a new page. The new "Import SSO property" page has been added to the new Domain Replication wizard which is responsible for simply setting the skfs property value that was set during the Domain Setup wizard on the primary appliance.

[Image of domain SSO replication page]

In this page, simply click the "Browse" button and path to the location of the {DID}-domainEscrowedSSOKeystore.properties file that should be in the same directory as the new domain administrator keystore.

SSO Creation Alternatives

If the server is a standalone SKFS or if there is some requirement for the server to have the SSO keystore on the file system and not encrypted by the KA, the keys may still be created through the keygen-sso.sh script. This script can be found bundled within either SKFS or SAKA distributions. Once the SSO keys for a domain have been generated by the script, ensure that the SKFS property "skfs.cfg.property.sso.keystore.encrypted.tokens" does not contain an entry for the specified domain. On Payara restart, the server will check the property to see whether any given domain contains an entry in the aforementioned property, and if not, will instead load the SSO keys from the SSO signing keystore found on the file system (/usr/local/strongauth/skfs/keystores/ssosigningkeystore.bcfks).
If the SSO keys must be generated outside of the Domain Creation wizards, the strongkeyliteEscrowSSOKeyTool.jar GUI can be used to generate the SSO keys and either write them to file or escrow them through the KA, returning a list of token numbers similar to the Domain Setup wizard. However, the property must be set on the other servers in the cluster manually, as there is no wizard to perform that step.

Managing SSO Keys and Certificates

All certificate information can be found in the SKFS FIDO policy for the newly created domain. This policy can be retrieved either by calling the getpolicy API, utilizing the FIDO administrator CLI client, or by manually checking the database. Once the policy is retrieved and its base64 is decoded, the subject DNs, serial numbers, and PEM-encoded certificate can be found for the Root CA, JWT, and SAML certificates of the domain in question.