LetsOAuth - OAuth with Access Manager Sessions
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 Implementation: https://www.netiq.com/documentation/access-manager-45/admin/data/b1dj6b2f.html
- 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
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
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
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
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 OAuth Claims
Video 1 - 15 uses the default resource server/default claims/ default scopes
- Session 19: OAuth SAML Bearer Grant
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.
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:
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.
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:
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
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> 2021-03-18T22:44:58Z SEVERE NIDS OAuth: invalid_grant: Grant name is not valid as per the Oauth Specification </amLogEntry>
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.
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.
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:
resourceServer: Identity Server
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
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
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:
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.