Mapping Rules
- authenticationTime
- The max_age scenario requires an authentication time attribute which is added to the authsvc_credential mapping rule.
For more information, refer to the oidc_op_conformance.zip file for the following examples:
- OIDC Conformance-Example 1.1.1 in the
authsvc_credentialmapping rule. - OIDC Conformance-Example 1.1.2 in the
pre_tokenmapping rule.
- OIDC Conformance-Example 1.1.1 in the
- produce_userinfo_jwt
- One of the conformance scenarios is to be able to sign the userinfo response. This can be achieved in IBM Verify Identity Access by sending userinfo response as a signed JWT.
To achieve conformance, a snippet of code is added to check if the userinfo_signed_response_alg is requested, based on that an STS chain is invoked to convert the STSUniversalUser to a signed JWT.
STS chain samples are available in the same zip file.
For more information, refer to the OIDC Conformance-Example 1.2 in the oidc_op_conformance.zip file in the
post_tokenmapping rule.The mapping rule snippet retrieves the userinfo_signed_response_alg and uses STSClientHelper to call an STS chain.
- redirect_uri
- In IBM Verify Identity Access we provide some flexibility for the redirect_uri check. Howerver, the OIDC conformance performs a strict check on the redirect_uri for it to be an identical match.
If the redirect_uri
https://test.com/isamis registered in IBM Verify Identity Access and request came in with a redirect_uri which ishttps://test.com/isam?example=one, IBM Verify Identity Access flow succeeds.However, OIDC conformance suggests that an error is thrown if it is not an exact match. To retain flexibility, IBM Verify Identity Access made the choice to flag an error at the mapping rule. Hence the following snippet is added into the
pre_tokenmapping rule to throw an error based on the redirect_uri.For more information, refer to the OIDC Conformance-Example 1.3 in the oidc_op_conformance.zip file in the
pre_tokenmapping rule.The mapping rule snippet retrieves the requested redirect_uri and compares it to the registered redirect_uri. It throws an error if an identical match is not found.
- nonce
- In OpenID connect specification, nonce is not a required parameter for authorization_code flow. In IBM Verify Identity Access during an authorization_code flow, if a nonce is requested it is not returned as a claim in the id_token when the code is exchanged for token and id_token.
To enable this, see to the OIDC Conformance-Example 1.4 in the oidc_op_conformance.zip file in the
pre_tokenmapping rule. The mapping rule snippet retrieves the nonce during the code flow and during the token flow retrieves the nonce associated with the state_id and adds nonce as an id_token claim. - assert_no_code_reuse
- The OAuth specification dictates that the Authorization server should revoke access tokens which are issued to a code, if that code is reused. In order to enable this enforcement a snippet in the
post_tokenand thepre_tokenmapping rule must be enabled.See OIDC Conformance-Example 1.5.1 and OIDC Conformance-Example 1.5.2,the in pre_token and post_token mapping rule respectively.