Configuring Authentication
Section Topics
- OIDC Authentication Request
- Authentication flow selection for OIDC authentication request
OIDC Authentication Request
- Requested Authentication Context Class Reference values are defined by acr_values request parameter and acr claims request.
- Request may be essential or non-essential.
- prompt has options
- none, The Authorization Server MUST NOT display any authentication or consent user interface pages. Translates to isPassive.
- login, The Authorization Server SHOULD prompt the End-User for reauthentication. Translates to forceAuthn.
- consent, The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client
- select_account, The Authorization Server SHOULD prompt the End-User to select a user account. Not supported by current implementation.
- max_age, specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP.
Authentication flow selection for OIDC authentication request
Exercises
ACR value
RP does not request for ACR by default. Modify the RP to request for password authentication.
nano +418 /etc/httpd/conf.d/auth_openidc.conf OIDCAuthRequestParams acr_values=password systemctl restart httpd
Run authentication sequence and verify from the logs that password authentication is being requested
OP does not seem to respond with ACR claim value - there is no [OIDC_CLAIM_acr] on your landing page. The authentication method principals are set in /opt/shibboleth-idp/conf/authn/general-authn.xml. See https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/AuthenticationConfiguration on how to add "password" authentication method principal for password flow.
- Run authentication sequence and verify the use of ACR claim.
Verify the ACR claim value from your landing page.
The value is set in action AddAcrToIdToken. Verify from the logs the action has taken place.
Client receives the ACR claim in ID Token. Locate ID Token from Token Response (field "id_token") in the logs. Decode the ID Token and verify the existence and value of ACR claim. Use for instance https://jwt.io/ to decode the ID Token.
Select flow by ACR value
Modify client to request for ACR value "ipaddress".
nano +418 /etc/httpd/conf.d/auth_openidc.conf OIDCAuthRequestParams acr_values=ipaddress systemctl restart httpd
- Run authentication sequence.
Follow log entries, identify requested ACR and what is actually sent back as ACR in the response. Can you explain why they do not match?
Activate IPAddress authentication, configure it for acr "ipaddress" and verify it is actually used as preferred authentication flow.
Create essential claims request for ACR values urn:mace:incommon:iap:silver and urn:mace:incommon:iap:bronze. This is now request that must (but will not) be met.
nano +418 /etc/httpd/conf.d/auth_openidc.conf OIDCAuthRequestParams claims=%7B%22id_token%22%3A%7B%22acr%22%3A+%7B%22essential%22%3A+true%2C%22values%22%3A+%5B%22urn%3Amace%3Aincommon%3Aiap%3Asilver%22%2C%22urn%3Amace%3Aincommon%3Aiap%3Abronze%22%5D%7D%7D%7D systemctl restart httpd
Start a new authentication sequence and see the result. This behavior should be something you are used to in SAML2 world.
Let's return to the original state
nano +418 /etc/httpd/conf.d/auth_openidc.conf #OIDCAuthRequestParams claims=%7B%22id_token%22%3A%7B%22acr%22%3A+%7B%22essential%22%3A+true%2C%22values%22%3A+%5B%22urn%3Amace%3Aincommon%3Aiap%3Asilver%22%2C%22urn%3Amace%3Aincommon%3Aiap%3Abronze%22%5D%7D%7D%7D service httpd restart nano +121 /opt/shibboleth-idp/conf/idp.properties #Remove IPAddress as active authentication option idp.authn.flows=Password systemctl restart shibboleth-idp
prompt=consent and other prompt parameters
Set the consent to be requested
nano +417 /etc/httpd/conf.d/auth_openidc.conf OIDCAuthRequestParams prompt=consent systemctl restart httpd
- Authenticate the user few times and verify this feature actually works as expected.
- Try different combinations of the parameter