In order to protect valuable assets and application access user authentication is a requirement when performing Federated Single sign on. 

IBM Cloud Identity now offers contextual risk-based authentication that facilitates the single sign on process, makes it more secure and provides an improved authentication experience to users. 

A risk-based authentication process adapts to the context in which the authentication attempt is made. It can be configured and applied via Access Policies. 

An access policy engine evaluates the current user authentication context against a set of rules and makes an authentication decision of either Deny, Permit or Challenge application access. 

Risk Evaluation Vectors 

In order to make an authentication decision of Deny, Permit or Challenge the following vectors or a combination of thereof are evaluated: 

• User’s AD group memberships 

• Originating IP address 
• User’s Current geographical location 

Groups 

A user’s group memberships can be used to assess the risk of granting this user access unchallenged access to an application. For example, a talent management application should only be accessible to members of the ‘management’ group. If the current user is a member of the configured group, the policy rule should ‘challenge’ the user to perform a 2nd factor authentication. 

IP Address 

The (browser) IP address that the authentication request originates from can be used to determine whether the user is trying to access the application from a whitelisted, neutral or blacklisted IP, IP range or subnet. For example users accessing an application from within the IBM subnet of 9.0.0.0/24 could be permitted access instantly while users from outside will be denied access. 

Geo Location 

The geographic location of a user’s browser can be determined by its IP address. If a user has safely authenticated themselves from a given location, application access could be permitted instantly when the same user authenticates from the same location the next day. This would improve the user’s authentication experience while guaranteeing the same level of protection. Additionally, the user would have to re-authenticate if they change their location, i.e. access the application from a different IP address. 

Risk based Access Policy Evaluation 

Access policies consist of a set of rules that may get applied to the current authentication context during policy evaluation. Each rule has a set of conditions that describe the risk vector parameters that will be matched against the current authentication context during evaluation. The rule also contains an action that will be performed when the current context matches the conditions. 

Figure 1: Access Policy Schema 

Evaluation Algorithm 

The policy rule evaluation process follows a simple  

If () then () – Else If () then () - … - Else then() 

logic. 

For the configuration in Figure 1 the following logic would be executed. 

Authoring Policies 

The CI administration console provides a UI to build simple policies: 

From here add a policy and populate the new policy form. First enter policy name and description, then start adding rules to the policy. 

In this example the new rule will give members of the ‘managers’ AD group direct access to an application. 

After adding this group rule we need to adjust the default rule action (the last ‘Else’ return action in the rules processing logic) – to be ‘Deny’. This way users that are not members of the management group are not able to access the application. 

After saving the policy it is available to be associated with an application. When users try to access the application the associated policy’s rules will be evaluated. 

In this example we’re adding ‘Asana’ for managers. 

In the new application wizard’s ‘sign-on’ parameters select the ‘Manager Group Policy’ we have  

just created. 

After adding ‘Asana’ to the user dashboard   

Users that are not part of the ‘managers’ group will not be able to access the application and will see the following screen: 

A real world example 

The CI security administrator – Shannon, 35, f. - has to configure access for a development portal application for in-house developers and contractors. Contractors move about quite a lot however in-house developers use the app every day from the office. 

Shannon would create the following policy 

Developers 

With this set of rules in-house developers would only be required to perform a step-up authentication the first time they access the development portal. Afterwards the developer would be allowed access immediately when they access the portal from the same location. 

Contractors 

Contractors will be challenged with a step-up authentication the first time and then every time they log in from a different location, however if they return to a trusted location the previous elevated authentication will be remembered. For example, they can switch between the office and up to 4 other locations without being challenged after the initial step-up authentication. 

Conclusion 

This article explains how federated SSO applications can be protected by defining flexible risk-based access policies that allow fine-grained access control while delivering an improved authentication experience to users.  

Outlook 

IBM is constantly extending the range of risk vectors available to configure risk-based access policies. At the moment CI offers group membership, IP address and location as risk vectors more vectors will be supported and made available in the policy editor.