Friday, January 7, 2011

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 3rd 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.

Thursday, January 6, 2011

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

Tuesday, January 4, 2011

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

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!

Monday, January 3, 2011

How do I secure my services?

I've been up early for a couple of days talking to a customer about how they should secure their services.

We started with the bit of advice "only make them as secure as you need to". In other words the "HelloWorld" service probably doesn't need an encrypted request with a signed SAML Assertion over a mutually authenticated SSL channel on a private, physically disconnected network segment. And the "launch nuclear weapon" service should probably be secured with something other than a simple username token.

Figuring out what sort of security your services require takes time and effort and lots of information. So I'm not going even try to give you a recommendation here. Instead I guess I'm going to tell you what I told them...

This customer has requests coming in from the Internet. Their users do NOT have individual certificates but do have a username and password. The plan, in as much as there is one, is to have OSB in the DMZ accept the SOAP request from the user and then route it to the real service behind the firewall. So the customer asked us what they should do to secure the services.

They tossed around a bunch of ideas including:

  • using an STS - the client would go to the STS and get a SAML assertion, then use that assertion to send the request to OSB.
  • using an STS with WS-Secure Conversation - same as above, but instead of just getting a SAML Assertion the client would do the more advanced session "stuff" that spec describes.
  • Publishing a certificate issuance SOAP endpoint. The SOAP client would call over to that service with a username and password and get a Certificate issued. The username and password would then be locked out and the Certificate would be the only way the user could authenticate after that point.
All of these solutions work - that is to say that they all provide some aspects of security and thus make the service more secure in some way. But they're all a bit heavy handed and require quite a bit of smarts on the client side. So we had a conversation about what they were actually trying to accomplish.

Turns out their requirements were that the data had to be transmitted securely - meaning nobody else could listen in and see the data. And they wanted to make sure that nobody could inject requests that didn't come from a real user into the flow. And that's it.

Those of you playing along at home know that one way SSL with the username and password in a WS-Security header meets those requirements. Plus it's really lightweight and simple to implement.

Sometimes simpler is better. And in this case turning all of the security levers up to 10 wouldn't have bought them anything but trouble.

So that's what they're going to go with - at least initially. In the future they'll revisit this solution and if things change they can always add new Proxy Services on the bus for other authentication methods.


Behind the bus was a whole 'nother story. They're going to use SAML assertions with the Sender Vouches confirmation method to pass identity down to the real services. But that's a story for another day.