[OPENAM-4177] Update OAuth2 access_token endpoint to handle auth chain with non-name/password callback Created: 10/Jul/14  Updated: 02/Dec/16  Resolved: 23/Oct/15

Status: Resolved
Project: OpenAM
Component/s: oauth2, rest
Affects Version/s: 11.0.3, 12.0.2, 13.0.0
Fix Version/s: 12.0.3, 13.0.0

Type: Improvement Priority: Major
Reporter: Sachiko Wallace Assignee: Quentin CASTEL [X] (Inactive)
Resolution: Fixed Votes: 0
Labels: 13.0.0-Must-Fix, EDISON, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to OPENAM-2346 RFE: OAuth2 Resouce Owner Password Gr... Resolved
relates to OPENAM-8485 Resource owner password grant should ... Closed
Sprint: Sprint 77 - Sustaining, AM Sustaining Sprint 13
Support Ticket IDs:

 Description   

1. login to admin console
2. create auth chain with Windows Desktop SSO [Sufficient] and LDAP [Required]
3. set the newly created auth chain as default auth chain for organization
4. run login
curl --request POST --data "client_id=myClientID&client_secret=cangetin&grant_type=password&username=testuser01&password=cangetin" http://openam.example.com:18080/opensso/oauth2/access_token

It will return internal error with response code 400

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

 Comments   
Comment by Peter Major [X] (Inactive) [ 16/Jul/14 ]

I think the solution for this is to allow clients to specify the authentication chain they want to use for authentication. I don't think that it's the OAuth2 resource owner verifier logic's job to figure out how the auth chains are defined (or even how a given authentication module would like to interact with the user), instead the verifier should be able to work with different auth chains, for example use a chain different from the default one, where WDSSO module isn't defined, but only AD.

Comment by Sachiko Wallace [ 16/Jul/14 ]

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");
                }

I see what you mean by successful auth using chain, but if it's just about going through auth chain with NameCallback and PasswordCallback, then we can remove these lines and let the chain fail over to other modules. But it seems like WindowsSSODesktop module etc has some issues handling auth request from REST so I need to investigate about those issues.

Comment by Peter Major [X] (Inactive) [ 16/Jul/14 ]

What I meant is that AbstractIdentityVerifier should be able to call other ac.login methods, like ac.login(AuthContext.IndexType.SERVICE, "not_the_default_chain");
and then the not_the_default_chain could contain only the AD auth module, so it would only require NameCallback and PasswordCallback (which can be handled by the AbstractIdentityVerifier).

Generated at Tue Oct 27 01:08:27 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.