Problem Statement

As per the ODIC standards, for Authorization code or implicit flow the OAuth client application can send the acr_values parameter in the request to enforce authentication at Authorization Server. Currently only the client application can control the level of authentication for the user.  Ideally the Authorization Server(Identify Server) must enforce the level of authentication for the user to get authorization code or token. 

The Access Manager Administrator does not have control of enforcing which authentication contract must be satisfied for an OAuth client application. However server side control on authentication for proxies, protected resources and SAML2 are possible with Access Manager.

Many organizations prefer to have the authentication contract enforcement to be done at server side rather than at client application due to various security reasons.

Solution

The server side authentication level enforcement for OAuth can be done by creating custom authentication class and configure this class as default contract in Access Manager and the client application does not need to send acr_values parameter in the request.

This article is about how to write custom authentication class in Access Manager to solve this case.

Design/Approach

The attached custom authentication class is developed using Access Manager SDK. This class identifies which authentication contract should be executed for an OAuth client application, this can be configured as class properties in Administration console. You can also configure another property to execute default contract. The default contract will be executed when the request does not match with the configured client application ID or if the request is not an OAuth request.

For the above mentioned scenario a sample custom authentication class code is attached in this article. 

Note: 
1. This sample custom authentication class code can be modified according to the needs like all OAuth client should have a different default authentication contract and all non OAuth client application request should execute different default authentication contract etc.
2. This approach is just a workaround, however this solution does not solve the issue completely. That is when the authorization code or token request contains acr/acr_values parameter the priority will go to this contract rather than default contract (i.e., the custom authentication class). 

Deploying Custom Authentication Class

1. Copy the custom authentication class jar to IDP server location /opt/novell/nam/idp/webapps/nidp/WEB-INF/lib folder
2. Restart IDP Tomcat service

Configuring Custom Authentication Class in Access Manager Admin Console

1. Edit IDP cluster edit -> Create custom authentication as shown below

2. Add below class properties to define what contract to be executed for which OAuth client application and when the request is not an OAuth request or if client application id does not match what is the default contract to be executed as shown below.

3. Create a contract using this custom class and configure it as a default contract for Identity Server.

 Default contract configuration

Verify the changes

You can verify the changes by sending an OAuth authorization code/implicit request.

For example as per above sample configuration, when the request contains the client application id as ‘a8df6bf4-f91f-4369-b15e-95bc2be6bb9a’ will execute the secure basic authentication contract.

• When the request contains client_id as ‘8f4e2d28-4fa9-47e4-a91e-eece5a2f84d6’, will execute risk based contract.
• When the request is not an OAuth request or client application id does not match will execute default contract which is secure name password form authentication.