5.1.2 Creating Custom Authentication Class to Obtain Unstored Transitional Data

Follow the procedure:

Click Devices > Identity Server > Servers > Edit > Local > Classes > New.
Specify the following values.

Display Name: Specify RHPClass

Java Class: Specify Other

Java class path: Specify com.novell.nidp.authentication.local.RequestHeaderParser
Click Next.
Click New to add properties.

REQUEST_HEADERS_LDAP_ATTRIBUTE_NAME = requestHeaders

REQUEST_HEADERS_KEY_VALUE_SEPARATOR = -->

REQUEST_HEADERS_SEPARATOR = ||
Click Local > Method > New to create a new method.
Specify a name to identify the method. Example: RHPMethod
Select RHPClass from Class.
Deselect Identifies User.
Select <Default User Store> from the list of Available User Stores.
Click Devices > Identity Servers > Edit > Local > Contracts > New.

Specify the following details:

Field	Description
Display name	Specify the name of the authentication contract. Example RHPContract
URI	Specify a unique value. It is used to identify this contract for external providers and is a unique path value that you create. No space is allowed. The following are examples: /mycompany/name/password/form http://mycompany.com/login secure/form/password/bcompany
Password expiration servlet	Specify a URL to a page where the user can change password when the password expires or is within the grace login period. You must use eDirectory to change the number of grace logins. Grace logins work only with eDirectory. For more information, see Using a Password Expiration Service.
Allow User Interaction	If you specify a password expiration servlet, you can select this option. This allows users to decide whether to go to the servlet and change their passwords or to skip the servlet. If you always want to force the users to go the servlet to change their passwords, do not select this option.
Login Redirect URL	Specify the URL to which users will be redirected. Use this setting in the following scenarios: Forcing the user to a specific home page after successful authentication. Forcing the user to configure challenge/response forgotten password questions. For more information, see Using Login Redirect URL Parameters.
Allow User Interaction	Select this option to allow the user to decide whether to continue to access a pre-configured URL or to continue to the page that the user usually accesses. For example, a user frequently accesses www.a.com and have specified the redirect URL as https://someservice.com/path/password?user=<USERID>&store=<STOREID>&returl=<RETURN_URL>, continue will allow the user to continue with that website that is www.a.com and redirect URL will take the user to the URL https://someservice.com/path/password?user=<USERID>&store=<STOREID>&returl=<RETURN_URL>&action=expire and then to www.a.com.
Authentication Level	Specify a number to indicate its security level or rank. This setting preserves authentication contracts of a higher security level. When you enable Satisfiable by a contract of equal or higher level, this value is used as a reference.
Authentication Timeout	Specify how long the session can be inactive before the user is prompted to log in again. The value can be from 5 minutes to 65535 minutes and must be divisible by 5. If you modify the timeout value for a contract, the new value is given to users as they log in. Currently logged in users retain the old value until they re-authenticate. Discover what values are best for your network configuration, your security requirements, and your users. Shorter timeouts increase back-channel traffic and require more threads for authentication checks, but quickly free resources that are being used by inactive users. If you have slow back-end services, users could get disconnected waiting for a response, and these disconnects can generate more authentication traffic. Longer timeouts, which allow inactive users to remain connected, increase memory requirements to store session information, but require fewer threads and don't generate as much back-channel traffic. For example, if you set the timeout to 5 minutes, an authentication check needs to be done 12 times each hour for each user authenticating with this contract. If the timeout is set to 60 minutes, an authentication check is done only one time each hour for each user. However, for the 5 minute timeout, resources can be freed within 5 minutes of inactivity by the user. For the 60 minute timeout, resources can take as long as 60 minutes to be freed, depending upon when the user goes inactive. NOTE:When Name/Password - Basic and Secure Name/Password - Basic contracts are assigned to a protected resource, the session is timed out. The session gets renewed after timeout without user’s intervention using the Basic header sent from browser to Identity Server. For information about using it with Access Gateway, see Assigning a Timeout Per Protected Resource.
Activity Realm(s)	Specify the name of the realm that can be used to indicate activity. Use a comma-separated list to specify multiple realms. This allows a user’s session to be kept alive when the user is accessing resources that are protected by different contracts. If both contracts belong to the same realm, activity on either resource keeps the session alive on the other resource. See Using Activity Realms.
Satisfiable by a contract of equal or higher level	Allows the system to satisfy this authentication contract if a user has logged in using another contract of an equal or higher authentication level, as specified in Authentication Level of an authentication contract. When you enable this option, consider the authentication levels you have set for other contracts and the level that has been assigned to the default contract. When the protected resource is configured with Name/Password -Form as authentication procedure, the user authentication details are prompted with transient federation. You must enable this option to avoid prompting for authentication in the target service provider.
Satisfiable by External Provider	Allows this contract to be selected when configuring an identity provider for Liberty or SAML 2.0. While configuring an authentication request, you can select a contract when this option is enabled for the contract and require the identity provider to use this contract for authentication to succeed.
Requested By	Select one of the following options: Do not specify: Specifies that the identity provider can send any type of authentication to satisfy a service provider’s request, and instructs a service provider to not send a request for a specific authentication type or contract. Use Types: Specifies that authentication types must be used. Select the types from Available types to use for authentication between trusted service providers and identity providers. Standard types include Name/Password, Secure Name/Password, X509, Token, and so on. Use Contracts: Specifies that authentication contracts must be used. Select the contract from Available contracts. To appear in Available contracts, you must select Satisfiable by External Provider for this contract. To use the contract for federated authentication, the contract’s URI must be the same on identity provider and service provider. For information about contract options, see Configuring Authentication Contracts. Most third-party identity providers do not use contracts.
Allowable Class	Specify the class that instructs a service provider to send a request for a specific authentication type to the identity provider. You can modify this option only when you select authentication types. In SAML 2.0 federation with Access Manager as a service provider, if an external identity provider authenticates a user, it sends the <AuthnContext> information after authentication in the response. Access Manager uses this <AuthnContext> to find a matching contract at the service provider to identify the user. It identifies the contract by trying to match <saml:AuthnContextClassRef> with AllowableClass attribute or <saml:AuthnContextDeclRef> with URI attribute of existing contracts at the service provider. For example, if the external identity provider sends the following AuthnContext: <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef> <saml:AuthnContextDeclRef>adroit:login:user:np</saml:AuthnContextDeclRef> </saml:AuthnContext> And Access Manager (as a service provider) has a contract A with uri = adroit:login:user:np or with Allowable class = urn:oasis:names:tc:SAML:2.0:ac:classes:Password, it matches the contract. NOTE:Allowable class is blank when an inbuilt authentication class is used in Identity Server.
Methods and Available Methods	Specify the authentication method to use for the contract. You can specify the order in which the methods are executed for login; however, this is not a graded list, so all the methods you specify are required. Available methods are the authentication methods you have set up. Example RHPMethod. The RHPMethod should be either the second or last in the order.

Click Update All next to the required Identity Server or cluster
Click Devices > Access Gateways > Edit.
Click Protected Resource for the proxy service with Authentication Procedure (RHPContract).
Click Policies > Policies.
Select the policy container, then click New.
Specify a name for the policy, select Access Gateway: Identity Injection for the LdapAttribute policy, then click OK.
Update Access Gateway.

The headers will be available in Ldap Attribute (requestHeaders) in format below. This can accessed from virtual attributes to perform modifications on the result.
Click Devices > Identity Server > Shared Settings > Virtual Attributes > Virtual Attribute.

Click + to create a virtual attribute. Create a virtual attribute for the requestHeaders using Advanced : Javascript Function. For more information, see Creating a Virtual Attribute.

Sample JavaScript:

'NameIDPolicy=' and returns value of it.

function main(P1){
  return getParameter(P1,'NameIDPolicy=');
}
function getParameter(attribute, param){
  var str=attribute.substring(attribute.search(param));
   return  str.substring(param.length,str.search('&'));  
}