Strategies for managing OAAM to OAM connections in production

Many Oracle Access Management 11g customers opt to deploy a combination of Oracle Access Manager and Oracle Adaptive Access Manager using the Advanced Integration option. This combination of product features can provide strong, adaptive authentication and fraud mitigation for online applications. In this post, we examine a number of strategies for configuring the connectivity between these components in order to provide scalability and high availability for production deployments.

OIM-OAM-OAAM integration using TAP

I was going to make a test post just to test our RSS feed.  However, Atul Kumar published a good introductory post today on OAM-OAAM-OIM integration.  So I figured that I would share that with you today and suggest it as a little light weekend reading.

You can find Atul's post here.

Risky Business

Incorporating risk detection and mitigation capabilities into apps is becoming all the rage. There are plenty of real-life examples of cases where prevention of cyber-security threats and fraudsters might have kept governments and companies out of the news, and with more money in their accounts. These are just the events that we know about. There are probably many more that have been kept on the down-low or haven’t been detected yet. Oracle’s Adaptive Access Manager provides a risk engine that can help you model, detect and mitigate those threats.

The quickest way to start using the Adaptive Risk Manager (henceforth ARM), is to call the Strong Authenticator. This is done by browsing to http://<oaam_host>:14300/oaam_server. Login with any username and password ‘test’ and you should be ‘authenticated’. I put authenticated in quotes because OAAM doesn’t go against any directory service out of the box. At this point you should be able to browse to the ARM console and see your session information. Browse to http://<oaam_host>:14200/oaam_admin and doubleclick ‘Sessions’. You should see an entry in the table for the user you just authenticated as.

There are 3^rd party tools like ARMAutomator that provide extensive testing on ARM testing, but for onesie-twosie testing and demoing, you can use this native integration JSP I put together. To set up native in your own Java EE web app, do the following:

Copy the following jars to your client-side web app WEB-INF/lib:

- oaam_core.jar

- oaam_native_wrapper.jar (had to extract it from the native lib war)

- oaam_uio.jar

Copy bharosa_properties folder from /Oracle_IDM1/oaam/cli to /WEB-INF/classes

Update the JDBC URL in oaam_core.properties in bharosa_properties folder to your environment.

Include the following bharosa_server.properties in your WEB-INF/classes folder and update the SOAP URL.

vcrypt.tracker.soap.url=http://<oaam_host>:14300/oaam_server/services

bharosa.config.impl.classname=com.bharosa.common.util.BharosaConfigPropsImpl

bharosa.config.load.impl.classname=com.bharosa.common.util.BharosaConfigLoadPropsImpl

vcrypt.tracker.soap.useSOAPServer=true

vcrypt.soap.auth=false

I cheated a bit and disabled the basic auth constraint on the server side. If you have a 10g setup with a soap keystore setup, you can leave this in place, but if you want disable it, perform the following steps on the OAAM server:

- cd /Oracle_IDM1/oaam/oaam_server/ear

- back oaam_server.ear

- jar xvf oaam_server.ear oaam_server.war

- jar xvf oaam_server.war WEB-INF/web.xml

- Edit web.xml and remove <security-constraint>...</security-constraint>

- jar uvf oaam_server.war WEB-INF

- jar uvf oaam_server.ear oaam_server.war

- Redeploy oaam_server.ear

If you haven’t upgraded to OAAM BP01 (p10022410), I would do that upgrade before removing this constraint. If done correctly, you should be about to browse the following URL without being prompted by Basic Auth prompt:

http://<oaam_host>:14300/oaam_server/services/VCryptRulesEngineWS?wsdl

A very quick ‘n dirty way to see how OAAM geo-spatial capability can work is to load the test data included in the tool. Quova from what I’ve heard is the top-tier service for IP Geo-location. Here’s a perl script to convert those numbers to IP address format:

sub numToStr {

my ($ipnum) = @_;

my $z = $ipnum % 256;

$ipnum >>= 8;

my $y = $ipnum % 256;

$ipnum >>= 8;

my $x = $ipnum % 256;

$ipnum >>= 8;

my $w = $ipnum % 256;

print "$w.$x.$y.$z";

return "$w.$x.$y.$z";

}

print "IP Address is ";

&numToStr($ARGV[0]);

Assuming you’ve imported the IP GeoLocation test data, you can take a value from /oaam/cli/test_data/test_MaxMindBlocks.csv and pass it into the tool.

perl convertLongToIP.pl 209868800

Credit to Maxmind for that little tool.

Here is the JSP I use to call ARM for post-authentication results:

<%@ page import="com.bharosa.client.BharosaHelper"%>
<%@ page import="com.bharosa.client.BharosaUtil" %>  
<%@ page import="com.bharosa.client.BharosaSession"%>
<%@ page import="com.bharosa.vcrypt.common.util.VCryptServletUtil" %>  
<%@ page import="com.bharosa.client.enums.BharosaEnumAction"%>
<%@ page import="com.bharosa.vcrypt.tracker.util.CookieSet" %>  
<%@ page import="com.bharosa.client.enums.BharosaEnumAuthStatus" %>
<%@ page import="com.bharosa.common.util.StringUtil" %>  
<%@ page import="java.util.List" %>
<%@include file="common_imports.jsp"%>   
<%
     String loginId = request.getParameter("loginId");     //Group name should be come from the application based on which product or group the user belongs to.  
     String groupName = request.getParameter("groupName");
      if( groupName == null  groupName.trim().length() == 0 ) {  
        groupName = "Default";
      }  
     if (loginId == null  loginId.trim().length() == 0) {
         String errorMessage = "Login Id was not found in the HTTP request.";  
            out.println(errorMessage);
     } else {  
        loginId = loginId.trim();
         groupName = groupName.trim();  
         BharosaHelper bharosaHelper = BharosaHelper.getInstance();
         BharosaSession bharosaSession = bharosaHelper.createNewBharosaSession();  
        bharosaSession.setLoginId(loginId);
         bharosaSession.setExternalUserId(loginId);  
         bharosaSession.setLocale(request.getLocale(), request.getLocales());
         bharosaSession.setExternalGroupName(groupName);  
         String ipAddress = request.getParameter("ipAddr");
         if (!StringUtil.isEmpty(ipAddress)) {  
            ipAddress = ipAddress.trim();
         } else {  
            ipAddress = VCryptServletUtil.getRemoteIP(request);
         }  
        bharosaSession.setRemoteIPAddr(ipAddress);
  // Set the client's timezone offset  
    String clientOffsetStr = request.getParameter("clientOffset");
     bharosaSession.setOffset(clientOffsetStr);  
     String secureCookie = getCookie(request, "bharosa");
     Object[] browserFpObjects = VCryptServletUtil.getBrowserFingerPrint(request);  
    String browserFp = (String) browserFpObjects[1];
     CookieSet cookieSet = bharosaHelper.fingerPrintBrowser(bharosaSession, bharosaSession.getRemoteIPAddr(), request.getRemoteHost(),  
            BharosaEnumAuthStatus.PENDING, secureCookie, browserFp);
     if (cookieSet != null && cookieSet.getVCryptResponse().isSuccess()  
            && cookieSet.getSecureCookie() != null) {
         setCookie(request, response, "bharosa", cookieSet.getSecureCookie());  
    }
     // Run post-authentication rules  
    bharosaEnumAction = bharosaHelper.runPostAuthRules(bharosaSession, BharosaHelper.getHeaderContextMap(request));
    if (bharosaEnumAction == BharosaEnumAction.CHALLENGE){  
      out.println("POST-AUTH-CHALLENGE");
     } else if (bharosaEnumAction == BharosaEnumAction.REGISTER_USER){  
      out.println("REG_USER");
       session.setAttribute("isOptional", "false");  
    } else if (bharosaEnumAction == BharosaEnumAction.REGISTER_QUESTIONS){
             out.println("REG_Ques");  
      session.setAttribute("isOptional", "false");
     } else if (bharosaEnumAction == BharosaEnumAction.REGISTER_USER_OPTIONAL){  
            out.println("REG_USER_OPT");
       session.setAttribute("isOptional", "true");  
    } else if (bharosaEnumAction == BharosaEnumAction.BLOCK){
       out.println("BLOCK");  
    } else if (bharosaEnumAction == BharosaEnumAction.ALLOW){
         out.println("POST-AUTH-ALLOW");  
    } else if (bharosaEnumAction == BharosaEnumAction.SYSTEM_ERROR){
         out.println("SYSTEM_ERROR");  
    }
   List POST_AUTH_RUNTIME_LIST = Collections.singletonList(new Integer(2));  
   int riskScore  = bharosaHelper.runRules(bharosaSession, POST_AUTH_RUNTIME_LIST, BharosaHelper.getHeaderContextMap(request)).getScore();
   out.println("Risk Score = " + riskScore);
        //Store the session object the HTTP Session  
        BharosaUtil.storeBharosaSession(session, bharosaSession);
          //Store the requestID in the session.  
        session.setAttribute("vcrypt_requestId",bharosaSession.getBharosaSessionId());
    }
  %>  

Once this is in place, test the web app with a URL like:

http://<client_side_host>:<port>/webapp_sample/runRules.jsp?loginId=harry.help&clientoffset=-5&ipAddr=12.130.88.0

This JSP simply displays the action and the risk score.

I typically start with Phase 2 Post-Authentication Flow Phase 2 and add rules & conditions as necessary. You may need to change the policy to be “all users” from “linked users” to get this policy to fire.

I added a rule for restricted countries. I disabled some of the KBA checks that were pre-existing for this policy.

This is the condition that is added to the rule:

Where “Axis of Evil” is a Country group (not like Dixie Chics) that contains my blacklist of restricted countries. Here is where we set the action and alert block, as well as the risk score:

Here is an example of the session detail for the request above:

You can see the alert that results from the condition rendering true as well as the risk score and the action that results from the restricted country.

This is a very small set of the OAAM capabilities but this is intended as a bootstrap.

If you’re looking for a partner in this area, I recommend the folks at Integral who have a lot of experience with this product.

Another pattern that is interesting to me is to factor an OES attribute retriever to call ARM and write OES policies based on risk score, i.e. DENY (…) if risk_score > 500. At some point I plan to take the sample that’s floating around and make it a tidy re-usable attribute retriever.

CAPTCHA vs. Strong Authentication (with OAAM)

A colleague was asked by a customer for a comparison between using a CAPTCHA solution and Oracle Adaptive Access Manager (OAAM). As people try to understand the role of CAPTCHA and different “advanced” authentication solutions in general, this type of question is actually pretty common.

The most common CAPTCHA solutions involve a user picking a series of alphanumeric characters (often distorted or partially obfuscated) out of a generated image and entering the characters along with the rest of the input.

CAPTCHA injects this specific type of challenge-response flow into an authentication (or other web input) to ensure that the input is really coming from a human and not a computer. It is often used with authentication, self-registration, and other application specific interactions like concert ticket buying systems to prevent various denial of service attacks and other mass input abuses of the system.

While CAPTCHA (arguably) does a good job at making sure that a user really is human, that is all that it does. It does nothing to make an actual user authentic stronger. It does nothing to prevent phishing, nothing to detect or prevent fraud, nothing to mitigate stolen passwords. The credentials being supplied in a username and password form with CAPTCHA is still just a username and password.

On the other hand, strong authentication is about adding additional “stronger” credentials into the authentication to go along with a username and password. Usually this means incorporating something a user has like an ATM card, hardware authentication token, or software token or alternatively something a user knows like a series of personal questions that other people aren’t likely to know.

Along with strong authentication often come secure input technologies like personalized pictures and phrases, keypads, and sliders that are utilized to prevent phishing and stolen passwords in general.

OAAM is an exceptionally powerful yet easy to use and deploy strong authentication and fraud prevention solution. You can read more about its capabilities here and by reading the white paper found here. On a personal note, I think OAAM is a very strong product and a leader in the space.

While there is overlap between OAAM (or strong auth in general) and CAPTCHA technologies in that a strong auth solution can help ensure that an application is interacting with a human, there is still a conceivable need for both.

Strong authentication is for well… authentication and requires that a user exist and that additional authentication factors be provisioned prior to the authentication. This makes it inappropriate for registration and other interactions where the user may be anonymous. On the other hand CAPTCHA can be used without knowing specifically who a user is.

It may also be appropriate to use CAPTCHA in an interaction that occurs at some point after (strong) authentication to ensure that a human is still in control of the client system.