RFE-314

Add support to store additional credential properties for a registered FIDO credential

In any SKFS environment, it is possible to register a large number (ex. hundreds) of FIDO credentials for a single username. While this may be uncommon, the SKFS has no problems handling it. However there is a disconnect with how the WebAuthn specification does not define a formal limit on how many credentials a browser may present to the user. There is a possibility that browsers may have constraints on how many credential id's can be sent during a FIDO authentication operation in the 'allowedCredentials' array, potentially resulting in an incomplete FIDO credential selection. This change adds additional properties attached to registered credentials to provide the relying party the ability to filter or prioritize credentials that are presented to the user while conforming to any size limits that browsers may impose. SKFS makes this optional feature available with v4.19.0.

This new feature is disabled by default and can be enabled by an administrator by updating the 'skfs.cfg.property.store.credentialproperties' property in the '/usr/local/strongauth/skfs/etc/skfs-configuration.properties' file. This property accepts 'true' or 'false' as values.

The new optional credential properties are stored when a FIDO credential is registered. The SKFS register request now accepts a new properties element under the strongkeyMetadata JSON element as shown in the example below. These additional properties as now stored in a new database table (credential_properties) that was introduced in version 4.19.0.

{
  "publicKeyCredential": { ... },
  "strongkeyMetadata": {
    "version": "1.0",
    "create_location": "Cupertino,CA",
    "username": "testuser-pwd",
    "origin": "https://app.strongkey.com:8181",
    "properties": {
      "customProperty1": "Value1",
      "customProperty2": "Value2"
    }
  }
}

When SKFS receives a pre-authenticate request, it returns the credential properties as part of the pre-authenticate response. It only adds the properties if they exist in the database and are grouped by credentialID as shown in the sample response below.

{
  "response": {
    "challenge": "3cPay7YjjvTKq1WvYZmZHg",
    "allowCredentials": [
      {
        "type": "public-key",
        "id": "VAnHnzW2cN...",
        "alg": -7
      },
      {
        "type": "public-key",
        "id": "U3XCDvJqy7...",
        "alg": -7
      },
      {
        "type": "public-key",
        "id": "TMqRFj24T2...",
        "alg": -7
      }
    ],
    "rpId": "strongkey.com"
  },
  "responseCode": "FIDO-MSG-0006",
  "skfsVersion": "4.19.0",
  "registrationVersion": "4.19.0",
  "skfsFQDN": "sk01.strongkey.com",
  "txid": "1-1-93-1769161637291",
  "credentialProperties": [
    {
      "id": "VAnHnzW2cN...",
      "properties": {
        "customProperty1": "Value1",
        "customProperty2": "Value1"
      }
    },
    {
      "id": "U3XCDvJqy7...",
      "properties": {
        "someProperty": "someValue"
      }
    }
  ]
}

RFE-316

Add more policy checks against FIDO Metadata service (MDS).

Until SKFS 4.18.0, the policy module was only making minimal checks against the FIDO MDS and SKFS just sent a boolean value indicating whether a credential attestation certificate was verified against FIDO MDS or not but did not take any necessary actions on failures. SKFS version 4.19.0 adds new JSON elements to the FIDO policy that enable additional checks against the MDS data and give the administrators the ability to decide on what a specific instance of SKFS should allow or deny. The below snippet from the FIDO policy shows the new elements with their default values that were added with this release.

{
  "checkResolutions": { 
    "enabled": true,           # Only proceeds if this element is set to true and skip the checks otherwise
    "noAaguidInMds": "ACCEPT", # Accepts the registration if AAGUID is not part of FIDO MDS
    "hasX5c": {                # Checks to see if the attestationStatment has the x5c element
      "hasMdsAttestation": {   # If x5c element is present, then checks to see if FIDO MDS has attestation certificte(s)
        "invalidPkix": "DENY"  # If PKIX validation against the certificates in MDS fails, then the registeration operation returns with an error, unless an administrator allows it
      },
      "noMdsAttestation": {
        "invalidPkix": "DENY"  # If PKIX validation against the certificates in MDS fails, then the registeration operation returns with an error, unless an administrator allows it
      }
    },
    "noX5c": {
      "hasMdsAttestation": {
        "formatNone": "DENY",
        "formatPacked": "DENY"
      },
      "noMdsAttestation": "ACCEPT"
    }
  } 
}

When the SKFS receives a register request, the server checks the attestation against MDS and takes appropriate action based on what is configured in the policy.