Important Topic: WebLogic Domain Models for installing the Oracle Identity Management Suite

As most of you know, the current 11g version of the Oracle Identity Management Suite runs on top of a tech stack based on WebLogic Server. In essence, when you install any package from the 11g Identity Management Suite, you end up deploying the applications from the package into a WLS domain.

There are 2 basic models of domain architecture for the Oracle IAM suite:

1) Install a given package into a new, self contained, WLS domain.

2) Extend an existing domain. In other words, deploy the apps from the Identity Management package you are installing into a domain that is also running other software. This model includes several variations based on what else you are running in the domain. One variation is installing the different Identity Management suite packages (namely the Identity Management package containing OID, OVD, and OIF; and the Identity and Access Management package containing OAM, OIM, and OAAM) into one domain. Another variation would be installing one of the Identity Management Suite packages into a domain running another Oracle product such as WebCenter or SOA Suite. Finally, one might even consider installing an Identity Management Suite package into a domain running custom application code.

Basic coverage of the topic can be found in the documentation here: http://download.oracle.com/docs/cd/E14571_01/install.1111/e12002/extend.htm

My Advice

It might seem like one or more of the scenarios listed above in the “extend an existing domain model “option above would make life simpler. In particular, I think that many people who use the entire Oracle Identity Management suite might be tempted to create a single monolithic “IAM domain” containing both major packages such that (OID,OVD,OIF,OAM,OAAM, and OIM) would all run in the same domain.

However, I’m here to tell you that running multiple packages in one domain is most likely a bad way to go. The reason is that it introduces the risk that different components (libraries, jars, utilities) from the different packages that you are installing in the domain might be incompatible and cause problems across your entire domain.

I actually had this happen when I accidently installed the IAM package (OAM) into a domain that was only running the PS1 version (instead of the PS2 version) of the IM package (OID and OVD). The IAM package is only certified to run in the same domain as the PS2 version of the IM package and sure enough many things in the domain broke.

To make matters worse, there is little you can do outside of restoring a previous full OS backup to fix the situation if such an incompatibility occurs.

Beyond the risk of such an incompatibility, you also must consider how installing multiple packages into one domain reduces your flexibility to apply patches and upgrades. Let’s say a new patch set of the Identity Management package (OID and OVD) comes out. If you have installed the package into its own domain then you are good to go. However, if you have installed it into a domain with WebCenter or OAM/OIM then you must consider whether the patch set will be compatible with those other packages. So, you’ll have to open a support case to ask and if the answer is no then you might have to wait months for those other packages to catch up.

One exception to this warning is SOA Suite for OIM. SOA Suite is a prerequisite for OIM and as part of the stack that supports OIM should be installed in the same domain as OIM. However, if you use SOA suite for other purposes, you should consider setting up a separate install for running your own services, composites, BPEL processes etc.

Conclusion

While installing multiple Identity Management packages (or Fusion Middleware packages in general) into one domain might seem like a good idea as it gives you just less domains to manage, it is safer and better to install each Identity Management package into a separate, isolated domain.

To be clear, I am recommending that customers install the IAM package (OAM,OIM,OAAM) into a separate domain from the IDM package (OID,OVD,OIF).  I am not necessarily recommending that you install the various products inside of each package in separate domains.  If and when to do that is a topic for another discussion which I will try and post about soon.

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.

Tell what patches are installed in your Oracle IAM 11g deployments using OPatch

People often want to know how they can tell what versions (including patches) of software they are running in their different environments. Fortunately, there is a simple standard way to get this information for all software that uses the Oracle Universal Installer. The method I speak of uses the OPatch utility that is standard for all Oracle products that use the universal installer. This includes most, if not all of Fusion Middleware 11g and all of the 11g Identity Management packages.


OPatch is the utility used to patch Oracle products that utilize the Oracle Universal Installer. It is included in most product/package installs under that package’s ORACLE_HOME/OPatch.

Now, keep in mind that when you execute OPatch it will operate on the ORACLE_HOME that is set in the environment. So, if you are operating in an environment where you have multiple products/packages installed under one Fusion Middleware Home (FMW_HOME) you want to make sure that you have an ORACLE_HOME environment variable pointed to the product/package you are interested in patching or analyzing.

To get information on the version and patch levels of your Oracle product/packages run ‘opatch lsinventory’. Again, make sure that ORACLE_HOME is set to the product/package that you want the information for. If it is not set, then OPatch picks some default ORACLE_HOME from your FMW_HOME in a manor I have yet to figure out.

You can also use OPatch to tell you all the ORACLE_HOMEs that exist under your FMW_HOME by running ‘opatch lsinventory -all’.

The documentation for OPatch can be found in the Oracle Universal Installer and OPatch User Guide

Good write-up on Oracle Internet Directory / Active Directory integration

One thing I intend to do more of is to provide links to other good resources on the internet for Oracle IAM and Fusion Middleware security.

Atul Kumar has written a bunch of good articles on his blog including this one on OID/AD

synchronization using DIP.

If you need a good reason to subscribe to our twitter feed @fusionsecexpert, we will probably start tweeting some links that we don't actually put up on the blog.

New on the blog for 2011

We at the Fusion Security Blog are looking forward to a great 2011.  Look for new topics and products to be added to the blog this year including coverage of Oracle Identity Manager (OIM), Oracle Adaptive Access Manager (OAAM), Oracle Identity Analytics (OIA), Oracle Identity Federation (OIF), and maybe some discussion of our new eSSO solution from Passlogix.  Also look for some new bloggers to join our site, providing you with some fresh perspective.

Finally, we are getting onboard the twitter bandwagon.  You can now follow us on twitter @fusionsecexpert.

Thanks for reading and here is hoping that all your Oracle Middleware projects in 2011 are wildly successful!