[OPENAM-8485] Resource owner password grant should continue along an auth chain when the first module fails due to being non-username/pwd based Created: 04/Mar/16  Updated: 22/Jul/20  Resolved: 22/Jul/20

Status: Closed
Project: OpenAM
Component/s: authentication, oauth2, OpenID Connect, rest
Affects Version/s: 13.0.0
Fix Version/s: 7.0.0

Type: Improvement Priority: Major
Reporter: Joe Starling Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: Backlog, CustomerRFE
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
is related to OPENAM-4177 Update OAuth2 access_token endpoint t... Resolved
Support Ticket IDs:

 Description   

Currently when the first module of the default authentication chain does not require username and password, requesting an access token with password grant flow fails.

We should allow authentication to continue down the chain until it reaches an appropriate module.

Current behaviour:

  • Create default authentication chain with WDSSO SUFFICIENT as the first module, DataStore REQUIRED as second.
  • Attempt login

    curl -X POST --user "myOauth2Client:oauth2client" --data "grant_type=password&username=demo&password=changeit&scope=openid" http://oauth2provider.example.net:48080/openam/oauth2/access_token -v

  • {"error":"server_error","error_description":"Internal Server Error"}

Comments from OPENAM-4177:

org/forgerock/openam/oauth2/provider/AbstractIdentityVerifier.java retrieves AuthContext and that has information about auth chain. The thing that's stopping AbstractIdentifier#authenticate from going through the chain is :

                // there's missing requirements not filled by this
                if (missing.size() > 0) {
                    throw new ResourceException(Status.SERVER_ERROR_INTERNAL,
                            "Missing requirements");
                }

from /openam-oauth2/src/main/java/org/forgerock/openam/oauth2/OpenAMResourceOwnerAuthenticator.java.

Adding an 'auth_chain' parameter can get around this successfully by specifying a different chain to use, however it is not compliant, and the authentication method should be transparent; the client should not know about different methods.

Also attempted to use 'acr_values' parameter mapped to different authentication chains, as this is standards compliant. It works for the authorize endpoint, but not access_token.



 Comments   
Comment by Andy Hall [ 10/Oct/17 ]

The intention would be to deliver this functionality using Authentication Trees.

Comment by Andy Hall [ 22/Jul/20 ]

This should now be possible in trees.

Generated at Wed Nov 25 08:00:07 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.