LetsOAuth - OAuth with Access Manager Sessions

[srajamanjit]

These Sessions provides hands on to the OAuth component of Access Manager. This is not an OAuth concepts training, however it provides basic understanding of OAuth and explores different features of OAuth supported by Access Manager. Sessions are using a tool called LetsOAuth to explore the Access Manager OAuth options. But you can use any other tool as OAuth playground/PostMaster/Curl Scripts to explore the same.

Disclaimer: The sessions are made based on my understanding of the OAuth component of Access Manager. Hence, Comments, corrections, suggestions and feedback are welcome. If you want to see some other videos related to Access Manager implementation of OAuth you can provide a comment.

I suggest to use the documentation to explore all the different options of Access Manager while going through the sessions.

OAuth Concepts: https://www.netiq.com/documentation/access-manager-45/admin/data/t46a6sfeuiwr.html 

OAuth Implementation: https://www.netiq.com/documentation/access-manager-45/admin/data/b1dj6b2f.html 

OAuth Endpoint/Developer Doc: https://www.netiq.com/documentation/access-manager-45-developer-documentation/oauth-application-developer-guide/data/bookinfo.html 

Session Details:

• Session 1: Prepare NAM for OAuth

Enable OAuth in Access Manager
Enable Logging for OAuth
Extend user schema to add a new attribute nidsOAuthGrant
Check the Admin Edir objects
Create a client application in NAM
verify the edir object for client application

• Session 2: Introduction to Application LetOAuth

Deploy the client application LetsOAuth
Create Client Application in Admin Console for LetsOAuth
Verify the edir object for client application LetsOAuth
Introduction of LetsOAuth UI

Extract the attached file LetOAuth.zip to get LetsoAuth.war file.

Use command similar to "sed -i 's/idpurl:port/msingh23.lab.novell.com:8443/g' *.html"  in folder LetsOAuth and LetsOAuth/html to customize the tool for your IDP server.

• Session 3: Authorization Code Flow

Use LetsOAuth to get the Authorization Code and Access Token
User Consent
Check nidsOAuthGrant Attribute

• Session 4: Tokeninfo/UserInfo/TokenIntrospection

tokenifno -> to get the token information(obsolete), still present for backward compatability. TokenIntospection is the correct endpoint to use
token -> this is the token endpoint to get Access Token.
How to check OAuth logs for OAuth requests.

• Session 5: Lifetime of a token

Access Token Expiration
Refresh Token
Impact of Refresh Token on user attribute nidsOAuthGrant.

• Session 6: Implicit Code Flow

Implicit Code Flow
Response Mode : query, fragment, form_post
acr_values to execute specific contract

• Session 7: Resource owner credentials or Password Flow

• Session 8: Token Revocation

• Session 9: Client Credential Flow

• Session 10: Authorization Code Flow using PKCE

Code Challenge and Code Verifier

• Session 11: OpenID connect
  ID Token
  Hybrid Flow to get combination of code/token/id_token

• Session 12: Client Application Management - 1
  Users -> normal user/admin user/developer user
  Admin Role and DEVELOPER Role
  Revoke Access
  Client Management using IDP Portal 

• Session 13: Client Application Management - 2
  Create/modify/delete client application using REST
  List all Client Applications
  List client application using client id.

• Session 14: OAuth with Access Gateway 1
  Inject OAuth token to web server
  AG policies for OAuth

• Session 15: OAuth with Access Gateway 2

Inject OAuth token to Access Gateway to send OAuth properties to backend server
AG policies for OAuth

• Session 16: Access Token Encryption 1
  Do Not Encrypt
  Encrypt using Access Manager Key
• 
  Session 17: Access Token Encryption 2
  Encrypt using Access Manager Key

Check the attached document Session17.zip (tool : DecodeJWTToken.tar Doc: JWT_Decryption)

• Session 18:Custom Resource Server
  Custom Scopes
  Custom OAuth Claims
  Verify Token

Video 1 - 15 uses the default resource server/default claims/ default scopes

• Session 19: OAuth SAML Bearer Grant

[srajamanjit]

Adding the new LetsOAuth.zip. The older file contains some references to local system dns name.

mgalloway24:/opt/novell/nam/adminconsole/webapps/LetsOAuth/html # grep "msingh23" *
ClientList.html: xhttp.open("GET", "https://msingh23.lab.novell.com:8443/nidp/oauth/nam/clients/", true);
ClientList.html: var uri = "https://msingh23.lab.novell.com:8443/nidp/oauth/nam/clients/" + document.getElementById("client_id").value;
code_to_token.html:<form method="post" action="https://msingh23.lab.novell.com:8443/nidp/oauth/nam/token">

Either manually modify  msingh23.lab.novell.com:8443 to your idpurl:port or use the new file.

[jlrodriguez]

Following this guide I installed the LetsOAuth tomcat app and configure the Client Application. Trying the first test "Get Authorization Code - Authorization Code Flow Step 1", after confirming the Consent I receive the error

invalid_grant: Grant name is not valid as per the Oauth Specification

At the IDP log I can see the call received as:

.../nidp/oauth/nam/authz?null

Any idea?

Regards

[srajamanjit]

Is Authorization Grant enabled in both Global Settings and Client Application.

Did you assign the "Authorization Grant LDAP Attribute" and does permission is there to write the attribute.

You can enable IDP logs (application and oauth in debug mode) to get more idea of the error.

[jlrodriguez]

yes, Authorization Grant is enabled in both Global and Client and the nidsOAuthGrant is correct and working with other OAuth clients.

At the IDP logs, it shows the following:

<amLogEntry> 2021-03-18T22:44:58Z DEBUG NIDS Application: 

Method: CustomNidpHeaders.addHeaders

Thread: ajp-nio-127.0.0.1-9019-exec-15

Adding custom headers to HTTP response. </amLogEntry>

<amLogEntry> 2021-03-18T22:44:58.162Z INFO NIDS OAuth  *Server has received a request on thread ajp-nio-127.0.0.1-9019-exec-15

POST https://logintest.acme.com/nidp/oauth/nam/authz?null

324 > host : logintest.acme.com

324 > user-agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0

324 > accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

324 > accept-language : es-ES,en-US;q=0.8,es;q=0.5,en;q=0.3

324 > accept-encoding : gzip, br

324 > content-type : application/x-www-form-urlencoded

324 > content-length : 643

324 > Origin : https://logintest.acme.com

324 > connection : keep-alive

324 > referer : https://logintest.acme.com/nidp/oauth/nam/authz

324 > cookie : _PA_SDK_SSO_=dxvtVIWAwPPRLNvFJw0+TS9gBhLw5p3sraknwF9sZMeT25+Rx57D/fskRKbRhTSDjogfrQcOOtWLSZS4cdDiDQHmvdhCRRFvoNmnOQON3u/jeMZ82YqolDeXQPQm94iDPYv42GHf7eXI1diCl0pgkMlxJLjakxzMrxFtQy2qdUAe0L0apM3ZxD1I8i1rJtXWNM

/n47+XegsBV9AXv6K3CaDqiS8coYjQqJWr19NSY8Q+zeP/e9yAmgSEsnP/4Is2iuh0v6NwX82uOu3JJMH+IilXxsLFBgDieER+Hu2NIhI=; JSESSIONID=7E7D7BE2308BE87553FEF3738AA5AF6C; _ga=GA1.2.490518207.1593599695; _hjid=ee9c14b0-6feb-42f2-aab6-95ae8d7

36d33; ZNPCQ003-34313300=d6edb479; ZNPCQ003-39343400=5aa9b0ab; AAAA0312e82811=AQAAAAAAAACgKdDfhOtVScZB4Eqe84nl

324 > Upgrade-Insecure-Requests : 1

324 > Via : 1.1 logintest.acme.com (Access Gateway-ag-24CBBC553758B05A-2998)

</amLogEntry>

<amLogEntry> 2021-03-18T22:44:58Z SEVERE NIDS OAuth: invalid_grant: Grant name is not valid as per the Oauth Specification </amLogEntry>

[Sebastijan]

Based on the request (https://logintest.acme.com/nidp/oauth/nam/authz?null), problem is not in Access Manager.

This is request for authorization code and this request definitely needs some parameters, like client_id, redirect_uri and of course response_type, but in your request there is only one parameter (null).

So "invalid grant" response form AM is expected.

Kind regards,

Sebastijan

[srajamanjit]

i think you are passing the wrong value for response_type.

You can try to change the Method of file LetsOAuth/html/authcode.html from POST to GET. This will sends the parameters as query string and you check what wrong value is sent.

[jlrodriguez]

It's kind of strange. If I look at the call that is made initially, everything seems correct.

The first POST calls goes with all the parameters:

POST

client_id: 9a7bf040-0746-4bef-9af9-732ffdd4f1db

response_type: code

resourceServer: Identity Server

redirect_uri: https://amhqtest.acme.local:8443/LetsOAuth/jsp/OAuthResponse.jsp

scope: profile+email

state: authcodestate

acr_values:

response_mode:

And at the catalina.out I can see the call as:

<amLogEntry> 2021-03-19T07:18:37.946Z INFO NIDS OAuth *Server has received a request on thread ajp-nio-127.0.0.1-9019-exec-17
POST https://logintest.acme.com/nidp/oauth/nam/authz
340 > host : logintest.acme.com
340 > user-agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0
340 > accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
340 > accept-language : es-ES,en-US;q=0.8,es;q=0.5,en;q=0.3
340 > accept-encoding : gzip, br
340 > content-type : application/x-www-form-urlencoded
340 > content-length : 258
340 > Origin : https://amhqtest.acme.local:8443
340 > connection : keep-alive
340 > referer : https://amhqtest.acme.local:8443/LetsOAuth/html/authcode.html

Then, after authenticate at the NAM login form, the Consent page appears.

After accepting it, is when at the log file appears the ?null:

<amLogEntry> 2021-03-19T07:26:19.849Z INFO NIDS OAuth *Server has received a request on thread ajp-nio-127.0.0.1-9019-exec-6
POST https://logintest.acme.com/nidp/oauth/nam/authz?null
342 > host : logintest.acme.com
342 > user-agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0
342 > accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
342 > accept-language : es-ES,en-US;q=0.8,es;q=0.5,en;q=0.3
342 > accept-encoding : gzip, br
342 > content-type : application/x-www-form-urlencoded
342 > content-length : 643
342 > Origin : https://logintest.acme.com
342 > connection : keep-alive
342 > referer : https://logintest.acme.com/nidp/oauth/nam/authz

I don't know if it could be the cause, but I can see the following call in the browser with a 404 error:

https://logintest.acme.com/nidp/js/jquery.min.js

[srajamanjit]

It doesn't seem to be issue with LetsOAuth tool but it is a system specific issue. You can raise a support case to fix the OAuth problem.

[jlrodriguez]

Yes, I don't think the problem is LetsOAuth. The truth is that the case is very strange. Suddenly it has started to work and it has not happened to me with a single client. I have done tests registering new clients and the situation has been the same. It doesn't work, and in one of the tests, without having made any changes, it works. From that moment on, said client no longer fails.
I'll leave it here. If I encounter the problem again, I will open a case with support.

Thanks!