Access Manager allows you to use OAuth2.0 protocol for authentication and authorization.
When using OAuth2.0, each application can get an access token by choosing one of the supported methods (Authorization Code, Implicit, Resource Owner Credentials, Client Credentials, SAML 2.0 Assertion).
When configuring a Resource Server, you can define as many scopes as you want:
Each access token is assigned with a scope that is being requested by the application on the authorization and token endpoints.
In addition to the authentication and authorization, the Access Manager has a UserInfo Endpoint that is used for getting Resource Owner’s claims. A client can send a request to UserInfo endpoint with a valid access token and get the claims that are authorized by Resource Owner to share.
Each scope can be assigned with claims (user attributes or virtual attributes), which is returned on the UserInfo response, if and only if the access token contains that specific scope.
Access Manager does not restricts OAuth2.0 applications from requesting and receiving scopes.
All scopes are published on the “scopes_supported” at the authorization server’s OpenID Metadata Endpoint.
That means that if we published a scope names “email”, that contains the user’s email address, all applications will be able to request this scope, and we will not be able to restrict that.
The way the this restriction may be achieved on Access Manager is by using “User Consent” flow, where the user is permitting\denying the application from getting a specific attribute, but this is not happening when we choose to not require the user permissions (consent) for this specific flow:
We want to be able to restrict application access to specific claims – the same as we have on SAML and WS-Federation.
We wrote a simple Java Servlet filter that can be integrated with the NIDP web application and restrict applications access to specific scopes.
Using this filter, you can define scopes that are public allowed for everyone, and scopes that are specific allowed to specific applications.
<publicScopes> <scope>address</scope> <scope>profile</scope> </publicScopes>
<clientSpecificScopes> <clientScopes> <clientID>428269de-79d7-42a3-905a-d08668538228</clientID> <scopes> <scope>email</scope> </scopes> </clientScopes> <clientScopes> <clientID>412349de-79d7-42a3-905a-d08668531118</clientID> <scopes> <scope>email</scope> <scope>phone</scope> </scopes> </clientScopes> </clientSpecificScopes>
<filter> <filter-name>EDPOAuthScopesFilter</filter-name> <filter-class>il.co.edp.nam.filters.OAuthScopesFilter</filter-class> <init-param> <param-name>oauth.filter.config.path</param-name> <param-value>/etc/edp/config/oauth_authorization_filter.xml</param-value> </init-param> </filter> <filter-mapping> <filter-name>EDPOAuthScopesFilter</filter-name> <url-pattern>/oauth/nam/authz</url-pattern> <url-pattern>/oauth/nam/token</url-pattern> </filter-mapping>
Now, every client that tries to request a scope that he is not allowed for, will get a HTTP 401 error from the Authorization Endpoint (/oauth/nam/authz)
The source code of the filter can be found on my GitHub account:
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.