Claim Mappings

Each entry in the mappings section of the jwt or appcreds section is evaluated against the claims established during authentication.

• For Application Credentials this is only the id of the authenticated credential
• For JWTs this is the the nested JSON structure signed by the server that generated the token

Regular expression based matching

Each value in the supplied claims matcher is evaluated as a regular expression against the incoming claim at the same position.

Regular expression evaluation rules

• The regular expression must match the whole string.
• The regular expression matching is case insensitive
• Boolean/integer claims are converted to strings before matching against the expression.
• When an array of strings exists in the claim any entry in the array can match the regex.
• You can create nested matching rules, to match against nested structures in the claims.

Example

Take the following claim mapping:

{
    "ruleset": "rules1",
    "claims": {
        "email": ".*@mydomain\\.com",
        "access": {
            "roles": "dev.*",
            "level": "100"
        },
        "is_blockchain": "true"
    }
}

It would match this set of claims in a JWT, and map it to ruleset rules1:

{
    "email": "me@mydomain.com",
    "access": {
        "roles": [
            "user", "developer", "admin"
        ],
        "level": 100
    },
    "is_blockchain": true,
    "name": "Jane Smith"
}

• The me@mydomain.com string in full matches the .*@mydomain\.com regex
• The access.roles nested array, contains the string developer as one of the entries, which matches the regex dev.*
• The access.level number when converted to a string, matches the regex 100
• The is_blockchain boolean when converted to a string, matches the regex true
• The name claim is ignored, because there is no claim matcher specified for it

Dynamic Tenant Claim Mappings

Claim matchers can be specified as "templated": true to cause them to be dynamically replicated with templating against each tenant in the owning membership of the node that is tagged with the tennants_tag specified in the configuration.

Every time a tenant is added or removed from the tag, the rules are rebuilt dynamically without requiring a reset of the node.

Each match string in the claim mapping will be replicated by substituting values from the properties section of each tenant. The templating syntax is of the format {{.propertyName}}. The name of the property is case sensitive when inserting from the properties of the tenant, and all substitutions must be successful or no claim mapping will be generated for that tenant (but claim mappings for other tenants will still be generated).

Regular expression characters in the tenant properties will be escaped before inserting into the string.

See Multi-tenant Nodes for more details