Using OAAM Risk Evaluation in OAM Authorization Policies

We recently encountered an interesting requirement about taking decision within OAM Authorization policy based on the Risk-evaluation performed by OAAM during Authentication flow. Considering the interesting nature of the requirement / use-case, I thought to share details about the implementation approach through this blog post.

Before I go into details about the implementation approach, let me explain the requirement / use-case as example with a few bullet points:

  • Requirement was to allow users from only selected country/state to access selected resources after authentication.
  • User should be authenticated only once.
  • Only certain applications / resources should be restricted based on the geo-location identified by IP Address.

Using above mentioned use case, idea here for this blog post is to provide details about how risk-evaluation performed by OAAM during Authentication flow can useful while taking decision as part of Authorization policy in OAM. The approach would be useful for other use-cases as well of similar nature.

The implementation approach (using feature known as IdentityContext) we are going to discuss further is considering the assumptions mentioned below:

  • IAM Suite version 11.1.2.2.0 or later
  • Advanced integration between OAM and OAAM using TAP (TapTokenVersion v2.1)

Identity Context (shared between OAM and OAAM) allows context-aware policy management and authorization capabilities built into the Oracle Access Management platform. The Identity Context feature is helpful in securing access to resources using traditional security controls (such as roles and groups) as well as dynamic data established during authentication and authorization (such as authentication strength, risk levels, device trust and the like).

The solution approach is as follows….

  • OAAM policy will set risk score (in Post Authentication Checkpoint) based on client’s geo location. i.e. If the client’s geo location is matching with policy/rule configuration, OAAM will set risk level/score to some specific number.
  • OAAM will then pass the score (generated from Post Authentication Checkpoint) as an Identity Context to OAM.
  • OAM will get the Identity Context (set by OAAM) and it will set an authentication response session attribute according to the Identity Context. i.e. As Authentication Response in OAM, values from IdentityContext will be stored in session attributes. The session attributes can be checked by OAM Authorization policies.
  • OAM Authorization policy will take decision (allow or deny) based on the rule/condition configured to check risk score available from session attributes (set by OAM Authentication response)

Out-of-the-box polices in OAAM generate risk scores like 100, 200, 300, 500 and OAM Rule/Condition in Authorization policy allows string comparison on session attribute with operators such as “equals”, “starts-with”, “contains” and “ends-with”. Our new policy in OAAM can generate score like 1 for client IP address of ABC Countries and 0 for client IP address of XYZ Countries. So with new OAAM policy in place in as a Post Authentication Checkpoint, risk scores will be like 101, 201, 301,… for client IP address of ABC Countries. This will allow us to configure OAM Rule/Condition in Authorization policy to check risk score with the “ends-with” operator.

Risk Score generated by OAAM Checkpoint execution will be available from Identity Context. So, OAAM polices can be configured in a way to generate risk scores in specific way and accordingly, OAM Rule/Condition in Authorization policy can be configured to take appropriate action based on the risk score. Above mentioned logic is just one example to add 1 or 0 to risk score from OAAM policies.

Following are the steps/changes for above mentioned solution approach for the example use case. These steps are only to give the basic understanding of the configuration to meet the requirements. Important steps/changes to note here from the perspective of Identity Context are about the way Authentication Response configuration is used to save values in session variables and use the same during Authorization.

A)

Configure OAM-OAAM integration using TAPScheme (documentation)

B)

Configure OAM and OAAM for Identity Context (documentation)

  • Change TapTokenVersion to v2.1 in OAM (oam-config.xml). If Thirdparty TAP Partner is yet to be registered in OAM, with WLST execution of “registerThirdPartyTAPPartner”, parameter tapTokenVersion=”v2.1″ can be used to avoid manual changes in oam-config.xml
  • Update / Add configuration parameter in OAAM (Properties section of OAAM Admin Console). oaam.uio.oam.dap_token.version=v2.1

C)

In OAAM, update Groups/Policies configuration to generate required risk score

  • Create a policy in OAAM with two rules to generate risk score 0 (for request from XYZ Countries on in other words, NOT from ABC Countries) or 1 (for request from ABC Countries)
    • Create a group in OAAM to contain countries ABC. This group will be used in Rules we will add to new OAAM policy.
    • Add ABC Countries to the group.
    • Create a group in OAAM to contain countries XYZ. This group will be used in Rules we will add to new OAAM policy.
    • Add XYZ Countries to the group.
    • Create a new OAAM policy for checkpoint “Post authentication”.
    • Associate the policy with “All Users” so that the policy is executed for each post authentication checkpoint execution
    • Add a new rule “Request from ABC Countries” to policy “TEST: Policy to return specific risk score” for checking request from ABC Countries.
    • Add a condition “Location: In Country group” to rule “Request from ABC Countries”
    • Update the condition with correct value for parameters “Is in group” and “Country in country group”. Selected country group which was created in previous steps.
      Rule - Request from ABC
    • Update result for the rule “Request from ABC Countries” to generate score 1
    • Add a new rule “Request from XYZ Countries” (in other words, NOT from ABC Countries) to policy “TEST: Policy to return specific risk score” for checking request from XYZ Countries (in other words, NOT from ABC Countries).
    • Add a condition “Location: In Country group” to rule “Request from XYZ Countries” (in other words, NOT from ABC Countries)
    • Update the condition with correct value for parameters “Is in group” and “Country in country group”. Selected country group which was created in previous steps.
      Rule - Request from XYZ

      • or
        Rule - Request from XYZ (Not from ABC)
    • Update result for the rule “Request from XYZ Countries” (in other words, NOT from ABC Countries) to generate score 0
    • Policy with two rules and policy linked to all users to be executed for each post authentication checkpoint execution…
      Policy with two rules..

D)

In OAM, Update Authentication Policy to store OAAM risk score/level in session attribute

  • Add an Identity Context Response in the OAM Authentication Policy
    • Navigate to the Application Domain of the required application.
    • From the Authentication Policies tab select the respective protected policy.
    • From the Responses tab create a new response as follows (Name the response accordingly and write it down because it will be used in the authorization policy). Variable $session.attr.risk.level of Identity Context would be having risk score set by OAAM
      OAM AuthN Policy

E)

In OAM, Update Authorization Policy to Allow or Deny based on value for session attribute created in Authentication Policy

  • Update Authorization Policy to take decision based on the session attribute created in Authentication Policy
    • Navigate to the Application Domain of the required application.
    • Navigate to the Authorization Policies tab and select the Protected policy specific for the application needing geo location authorization.
    • Select the Conditions tab and create a new condition. Name the condition as needed to relate to the ABC Countries (risk score ending with 1) requirement. Normally OAAM returns risk scores like 100, 200, 300, 500, so note the Operator is set to “Ends with” because say OAAM returns a risk score of 300, then if the user is coming from the ABC Countries, it will add “1” and the finaly score could be 301. Therefore using the Operator “Ends With” and an Attribute Value of “1”, the score would see 301 as a match and determine the user is coming from the geo location of the ABC Countries.OAM AuthZ Policy B
    • You can repeat Condition creation for for another Condition if you want to create a rule for XYZ Countries (risk score ending with 0). OAM AuthZ Policy A
    • You should have the needed Conditions created now (Note your condition names may be different). Note if you need a XYZ Countries Condition you can repeat the creating a Condition and set the value to zero, or Ends With zero. This Condition could be used to Deny or Allow access based on NOT being in the ABC Countries.
    • Select the Rules tab in the Authorization Policy and configure the selected Conditions as needed. For example you could add the Condition ABC Countries to the Allow Rule for the Selected Condition. This affect would ALLOW a user IF they connected from the ABC CountriesABC Countries based on OAAM risk score asserted as an Identity Context to OAM.
      OAM AuthZ Policy Rules

Comments

  1. Vikas Arya says:

    Hi Kuldeep, it is nice article. Just to add on this tap integration v2.1 – if you are doing any manual change to oam-config.xml file , tap authscheme needs to be updated with following parameter TAPOverrideResource=http://IAMSuiteAgent:80/oamTAPAuthenticate

  2. Vikas Arya says:

    Hi Kuldeep, A good use case indeed. How about other way round, I mean, Is it possible to set some values in oam auth/authz policy that can be used in oaam rule conditions. e.g. setting something like appname= which would be consumed by oaam to take decision whether to challenge(kba/otp) the user or not for that particular app ?

    Thanks & Regards

  3. uday sambhara says:

    Hi Kuldeep,
    This is a nice article! one query i have though is , what other contexts apart from the 4 available ones can be passed back to OAM for different decisions apart from newdevice , level , safeforuser and fingerprint . Something like a generic context in OAAM to OAM as a header.

Add Your Comment