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.
Posts
