Use Risk Based Authentication Method to Enable Role Based Access for SAML Federation


1. Introduction / Use cases

Using a SAML 2.0 connection, the service provider (web services or SaaS applications) trusts the identity provider (NAM IDP) to validate the user’s authentication credentials and to send identity information about the authenticated user. The service provider accepts the data and uses it to give the user access to the web service or application. This data exchange is transparent to the user. It allows the user to access the web service or SaaS application without providing additional credentials.

In most cases, the user’s account is already set up in service provider’s side by Administrators or service providers use Just-in-Time provisioning to set up user’s account.

NetIQ Access Manager IDP authenticates the user based on configured contracts and passes on user’s identity (i.e. user id, email, employee id etc.) as name-id attribute or any other additional attribute to the SAML assertion. NAM IDP can also be configured to pass user’s role information (i.e. Admin role, Approver role, User role etc.) to the SAML assertion so that Service Provider can perform authorization based on user’s role.

An Organization can have a requirement to perform the authorization before issuing SAML assertion. For example, Organization wants to enable access to certain Apps only for employees and wants to block access if any Contractor or Vendor tries to access the Apps. I have explained how to utilize Risk-Based Authentication Method to achieve this use case.

2. How it works

There are two ways to configure Risk-Based Authentication:

    1. Risk assessment and risk mitigation before authenticating a login attempt


    1. Risk assessment and risk mitigation after authenticating a login attempt

In this solution, we are going to use the 2nd option i.e. assess and mitigate risk after authentication.

Click here to read more about NAM Risk-Based Authentication.

3. Configuration Steps


3.1 Configure Risked Based Rule

    • Go to Policies -> Risk-based Policies -> Rules (tab) and create a new Rule.


    • Provide a Rule name and select Rule Definitions as “User Profile Rule”


    • Choose Type as “LDAP Attribute” and create your rule. For this example, I have chosen employeeType equals “employee”.

3.2 Configure Risk Policy

    • Go to Policies -> Risk-based Policies -> Risk Policies (tab) and create a new Risk Policy.


    • Provide Policy Name, Description, choose idp-cluster and create Risk-Based Auth Class.


    • In the Policy Rules, click Actions and choose Add Existing Rule.


    • Select the Rule created for identifying employees and choose Allow Access and Exit Policy if rule condition is met.


    • Add two Risk Levels. One is to allow access if Risk Score less than 100 and other one is to Deny access if the Risk score is Greater than or equal to 100.

3.3 Configure Risk Method

    • Go to idp-cluster -> Local -> Classes (tab), you will see the Risk Class is created.


    • Go to idp-cluster -> Local -> Methods (tab) and Create a new method. Provide a Display name and choose the Risk Class which was created. Make sure the “Identifies User” is unchecked.

3.4 Configure Contract (to use for federation)

Choose or create the contract which will be used by NAM IDP to authenticate a user for SAML federation and select the Risk-Method as the second method.

3.5 Configure SAML 2 Service Provider and use the contract

Go to idp-cluster -> SAML 2.0 -> chose the Service Provider -> Options and choose the Contract and apply changes.

4. Test the solution


4.1 Test Negative Use Case

Try to access the SAML 2 service provider URL (IDP initiated or SP initiated) and log in as non-employee user. You will get Access Denied Page. Here are the logs from IDP Server.

<amLogEntry> 2018-06-07T18:32:21Z DEBUG NIDS Application:

Method: RiskManager.evaluateRisk

Thread: http-nio-

Rule_Employee : false </amLogEntry>

<amLogEntry> 2018-06-07T18:32:21Z INFO NIDS Application: User: contractorTest  risk action: DENY        risk score: 100 </amLogEntry>


4.2 Test Positive Use Case

Try to access the SAML 2 service provider URL (IDP initiated or SP initiated) and login as employee user. User will be able to login. Here are the logs in IDP server:

<amLogEntry> 2018-06-07T18:25:52Z DEBUG NIDS Application:

Method: RiskManager.evaluateRisk

Thread: http-nio-

Rule_Employee : true </amLogEntry>

<amLogEntry> 2018-06-07T18:25:52Z INFO NIDS Application: User: employeeTest  risk action: ALLOW        risk score: 0 </amLogEntry>



How To-Best Practice
Comment List