feat(jans-auth-server): Improve DCR / SSA validation for Dynamic Client Registration

[nynymike]

Currently, there are four options for software statement validation

1. softwareStatementValidationType=script - default one, jwks and hmac secret are returned by dynamic client registration script
2. softwareStatementValidationType=jwks_uri, allows to specify jwks_uri claim name from software_statement. Claim name specified by softwareStatementValidationClaimName configuration property.
3. softwareStatementValidationType=jwks, allows to specify jwks claim name from software_statement. Claim name specified by softwareStatementValidationClaimName configuration property.
4. softwareStatementValidationType=none, no validation.

Note: 2-4 should all be deprecated--we should print a note to the logs if these are configured by the admin. They don't convey any trust. We should add another value: builtin: which passes the JWT to Auth Server for validation and client provisioning.

There is another claim that controls how the dynamic client registration ("DCR") JWT is validated:

• dcrSignatureValidationJwks - Key if asymetric JWT signature is used
• dcrIssuers - List of issues if MTLS private key is used to sign DCR JWT
• dcrSignatureValidationSharedSecret - if HMAC is used, this is the shared secret

While we should maintain this functionality for backwards compatibility with open banking implementations, we can define a more elegant solution for the future.

I propose making one Auth Server property that uses a JSON object to define which issuers are trusted for both DCR and Software Statement validation. What if it looks something like this:

{
{“id”: “1”, “type”: “ssa”, “displayName”: “Example”, "description": "Blah, blah", “jwks_uri”: “[https://example.com/jwks1"](https://example.com/jwks1%22), “scope”: [“email”, “profile”, “openid”], "allowed_claims": ["scope", "software_id", ...]},
{“id”: “2”, “type”: “ssa”, “displayName”: “Acme”, “jwks”: “shfkjahsjkfhks”, “scopes”: [“api.read, “api.write”, “openid”]},
{“id”: “3”, “type”: “dcr”, “displayName”: “Spam”, “jwks”: “shfkjahsjkfhks”, "allowed_claims": ["application_type", "software_statement"]},
…
}

• id - REQUIRED primary key for the entity
• type - REQUIRED either ssa or dcr
• displayName - Human friendly name in case we build an admin GUI for this
• description - Human friendly details
• scope - For SSA only -- list of allowed scopes the issuer can enable the client to request automatically. If not present, all scopes are allowed.
• allowed_claims - Any claims not listed in this list will be dropped. If not present, all claims are allowed.
• jwks - Public key
• jwks_uri - URI of public key
• issuers - For MTLS, list of issuers trusted
• configuration_endpoint - points to discovery page, e.g. https://examle.com/.well-known/openid-configuration
• configuration_endpoint_claim - e.g. ssa_jwks_endpoint
• shared_secret - for MTLS HMAC

One of jwks, jwks_uri or issuers or configuration_endpoint is required

This JSON object will be used during dynamic client registration--whether it should be allowed at all, or especially what scopes should be assigned to the client. Other claims should also be used if they are allowed. For example, perhaps the software statement passes the software_id claim. If it's allowed for that SSA issuer, it should be populated automatically via DCR.

[maduvena]

@yuriyz - Please notify me after this is implemented for documentation

[yuriyz]

@maduvena sure

[yuriyz]

@nynymike proposals:

1. new "software_statements" claim in DCR
   Similar to how OB use standard "software_statement" claim in DCR I propose to introduce "software_statments" (with "s" at the end) which indicates json array.

{
    "client_name": "my_client",
    "software_statements" : [
        eyJraWQiOiJlNWNkMzA1ZS04ZmZiLTRkNGEtYWMzYS00NGIwNzY5OTIwYmRfc2lnX3Jz...,
        eyJraWQiOiJlNWNkMzA1ZS04ZmZiLTRkNGEtYWMzYS00NGIwNzY5OTIwYmRfc2lnX3Jz...,
        ...
   ]
}

2. When we get multiple SSAs we should decide conflict resolutions. For example:

2.a join for arrays

• SSA1 scopes: ["api.read", "openid"]
• SSA2 scopes: ["api.write", "openid"]
  Results in scopes: ["api.read", "api.write", "openid"]

2.b if single value is use, e.g.

• SSA1 client_name: "name1"
• SSA2 client_name: "name2"
  We can have in SSA "priority": <integer> claim which will decide which SSA has higher priority. If priority is not set then use the natural order in "software_statments" (first win).
  Result: name1 (for natural order without priority)

[nynymike]

I had not considered that a client might present multiple software_statements during DCR. I think its more common that an OP might trust more then one SSA issuer, but I don't think a developer presenting more then one SSA would be common. For simplicity right now, maybe we should not allow it. Client scopes can always be appended after DCR.

[yuriyz]

Maybe you are right, it's always possible to construct SSA_sum = SSA1 + SSA2 with exact desired values. So ignore it.

[yuriyz]

@maduvena I've added documentation in this commit however I'm sure there is plenty of room for improvements.