E Device Fingerprinting and Identification
Device fingerprinting/identification is one of the many attributes OAAM uses to assess the risk of an access request or transaction. Whether it is a desktop computer, laptop computer, mobile device, or other web-enabled device, depending on the specific situation, Oracle Adaptive Access Manager can use any combination of standard attributes, including browser user agent string data, proprietary secure cookies, Flash shared objects, mobile application data, custom client data and advanced Autolearning device identification logic to identify a device.
This chapter covers the important fingerprinting and identification concepts, technology, and use cases customers need to understand when deploying OAAM. It contains the following sections:
Note:
Positive device identification is not and should not be considered an authentication method, nor the sole determining factor of an allow or block decision. OAAM provides a full, layered security solution. Device fingerprinting and identification represents only one of the layers.E.1 OAAM Device Fingerprinting
Oracle Adaptive Access Manager device fingerprinting is a capability used to recognize the devices a user uses to login and conduct transactions. It collects information about the device like browser type, browser headers, operating system type, locale, and so on. Fingerprint data represents the data collected for a device during login process required to identify the device whenever it logs in the next time. The fingerprint details help in identifying whether a device is secure and determine the risk level of the authentication or transaction.
A device is identified using proprietary logic and a set of specialized policies to process available data and arrive at identification. The intelligent identification does not rely on any single attribute type so it can function on user devices not following strict specifications and in both web and non-web channels. The device identification is not merely a static list of attributes but is instead a dynamic capture, evaluation and profiling of the specific combinations of attributes available in each access request or transaction. This is especially important in large consumer facing deployments.
E.1.1 Fingerprinting Types
As standard, OAAM supports browser, Flash, JavaScript, and mobile fingerprints. The fingerprinting functions the same for desktop/laptop PCs and mobile devices and smart phones that run full-function browsers.
E.1.1.1 Web Browser-Based Fingerprinting
By design OAAM provides web browser based fingerprinting in a pure web environment. In other words, no client software is required, which makes deployment of the solution to large and diverse user populations manageable. As well, OAAM does not place any logic on the client side where it may be vulnerable to exploit.
When an end user is accessing a protected application via a web browser, OAAM performs browser based fingerprinting. Browser based fingerprinting and identification uses browser user-agent string data and secure cookie and Flash shared object data if available.
E.1.1.2 Flash Fingerprinting
In the OAAM Admin Console, when viewing fingerprint data in the details pages, a digital fingerprint refers to a Flash, JavaScript, or a custom fingerprint. Flash fingerprint data is only available if Adobe Flash is present on the device. During the login process, digital data is gathered from the user's Adobe Flash installation. The Flash system capability data is used as the Flash fingerprint.
E.1.1.3 JavaScript Fingerprinting
OAAM provides fingerprinting with JavaScript, which is enabled by default. JavaScript fingerprinting can be used as the primary digital fingerprint or co-exist with Flash fingerprinting. When both JavaScript and Flash fingerprinting are enabled (default), Flash will be used if data is available. When no Flash data is present, JavaScript will be used.
E.1.1.4 Mobile Device Fingerprinting
A mobile device is a device that runs a mobile operating system, such as the Android mobile operating system from Google or the iOS mobile operating system from Apple. Mobile device fingerprinting is a form of custom fingerprinting. OAAM has unique handling for mobile devices allowing for a strong binding between user and device if Oracle Access Management Social and Mobile is installed. Mobile application developers may integrate OAAM device fingerprinting into their applications via the Access Management SDK and REST (Representational State Transfer) services layer. Mobile specific data such as application ID, GPS/triangulation location and IMEI (International Mobile Equipment Identity)/MAC address (Media Access Control address) can be collected and communicated to OAAM along with other device data. Through OAAM, device data can be stored and used to create a more comprehensive fingerprint that can be compared to previously stored fingerprints or device attributes, and policies can use the device data to determine risk and respond accordingly. Through custom development, Oracle Adaptive Access Manager is capable of fingerprinting, identifying and tracking mobile devices even when access is not via a browser.
E.1.1.5 Custom Client Fingerprinting
The digital fingerprint that accepts Flash shared object data in the standard browser access use case can instead accept data from a custom client. If you want to capture Java applets, Quick time, and other attributes, you can extend device fingerprinting through custom development. For example, a signed Java applet could be developed to gather the MAC Address of a device and use the Java/.Net/SOAP API to set the data into the digital fingerprint for use in the fingerprinting and identification logic. For more information on setting up custom device fingerprinting, see Section E.1.8, "Setting Up Custom Fingerprinting."
E.1.2 What Makes Up a Device Fingerprint?
The overall fingerprinting of a user device is based on multiple factors which is explained in this section.
OAAM's fingerprinting technology does not solely rely on one element. Oracle Adaptive Access Manager uses dozens of attributes to recognize and fingerprint the device typically used to login, providing greater coverage. For example, where certain elements are unavailable, the system can still provide robust security utilizing other objects (secure cookie, Flash cookie, HTTP header, Real Media, QuickTime, and so on).
The HTML example code includes a Flash shared object and image tags to collect additional device characteristics. The Flash code internally makes a call to the application server thereby uploading the device characteristics.
Note:
The most recent OAAM Sample Application can be downloaded from the Oracle Technology Network at:Generally the login page is embedded with a few lines of static HTML code. A device is generally fingerprinted as soon as it logs in to a protected application, prior to any authentication attempt. In this way, the device fingerprinting information is available for risk evaluation at any checkpoint. Some common checkpoints are pre-authentication, post-authentication and in-session/transaction. As well, a device may be re-fingerprinted at any time during a session to help detect some forms of man-in-the-middle attack.
E.1.2.1 Secure Cookie and Browser Characteristics
Secure cookies are one of the attributes used to identify the device. Oracle Adaptive Access Manager generates a unique Secure Cookie for each identification and looks for the same cookie the next time any user logs in from the device. The cookie is only valid for that session on that particular device. If the end user logs out and logs back in, that cookie is used to identify the device at that point.
Note:
If there is a policy that does not allow cookies, the secure cookie will not persist.The Secure Cookie are extracted from the HTTP request. Along with the secure cookie, Oracle Adaptive Access Manager also extracts browser characteristics
For additional characteristics that are used to create a unique fingerprint for the device, refer to the browser fingerprint enum and table below.
| OS/Browser | Characteristics |
|---|---|
| Operating System |
|
| Browser |
|
| Locale |
|
The browser type enum is shown below to illustrate the information to be collected for a browser fingerprint.
#Enum for fingerprint type vcrypt.fingerprint.type.enum=Enum for fingerprint type vcrypt.fingerprint.type.enum.browser=1 vcrypt.fingerprint.type.enum.browser.name=Browser vcrypt.fingerprint.type.enum.browser.description=Browser vcrypt.fingerprint.type.enum.browser.userAgent=userAgent vcrypt.fingerprint.type.enum.browser.locallang=localLang vcrypt.fingerprint.type.enum.browser.localcountry=localCountry vcrypt.fingerprint.type.enum.browser.localvariant=localVariant vcrypt.fingerprint.type.enum.browser.header_list=locallang,localcountry,localvariant,userAgent vcrypt.fingerprint.type.enum.browser.search_list=locallang,userAgent vcrypt.fingerprint.type.enum.browser.result_list=locallang,userAgent vcrypt.fingerprint.type.enum.browser.header_value_nv=t,true,f,false,en,English,es,Spanish,de,German,it,Italian,ja,Japanese,fr,French,ko,Korean,zh,Chinese,ar,Arabic,cs,Czech,da,Danish,nl,Dutch,fi,Finnish,el,Greek,iw,Hebrew,hu,Hungarian,no,Norwegian,pl,Polish,pt,Portuguese,ro,Romanian,ru,Russian,sk,Slovak,sv,Swedish,th,Thai,tr,Turkish,BR,Brazil
E.1.2.2 Flash Shared Object and Device Characteristics
A "Flash cookie" is a Flash shared object. Shared objects function like secure cookies. Oracle Adaptive Access Manager can use a Flash Shared Object to store a one-time use token and replace it each time the device is fingerprinted.
The Flash shared object is sent to the server using an HTTP request. The Flash shared object captures and communicates additional device characteristics; such as system information and configuration settings, which adds additional granularity to the Device ID.
E.1.2.2.1 What Data is Collected During Fingerprinting
During the login process, data is gathered about a users device to form the device fingerprint. This data can be broken down into two categories: secure and digital.
Each of these categories has within them a fingerprint and a cookie.
Oracle Adaptive Access Manager uses two types of cookies to perform device identification. One is the secure cookie, also known as browser or persistent cookie, and the other is the digital cookie, also known as the Flash cookie. The terms secure cookie and Flash cookie are terms that will be used in this chapter. Flash uses flash shared object which is stored against the domain/webapp by flash. For the flash cookie name, the key for the value is "vc".
Secure data is gathered from the user's browser. This data includes the user-agent string, and an HTTP cookie value. This cookie value is retrieved from the user's browser upon login. A user-agent string provides information on which browser is being used, its version number, and details about the system, such as operating system and version. For more information about browser characteristics, see Section E.1.2.1, "Secure Cookie and Browser Characteristics."
Digital fingerprint can be based on other custom fingerprints such as Java applet, Quick time, or others. This data includes an array of Flash system capability data, and a Flash Locally Stored Object (LSO). The Flash capability data is used as the digital fingerprint representing the Flash system capabilities. The LSO contains a unique one-time use value that is set every time a user logs in. This value is retrieved using a Flash movie that runs upon login. OAAM also provides fingerprinting with JavaScript. When both JavaScript and Flash fingerprinting are enabled (default), Flash will be used if data is available. When no Flash data is present, JavaScript will be used.
In cases where images are blocked, the cookies might be extracted from the login request itself. Oracle Adaptive Access Manager uses these different modes of collecting the cookies to overcome some technical difficulties imposed by browser or the security settings on the device.
| Hardware/Software | Characteristics |
|---|---|
| System |
|
| Settings |
|
The Flash type enum is shown below to illustrate the information to be collected for a Flash fingerprint.
#Enum for fingerprint type vcrypt.fingerprint.type.enum=Enum for fingerprint type vcrypt.fingerprint.type.enum.flash=2 vcrypt.fingerprint.type.enum.flash.name=Flash vcrypt.fingerprint.type.enum.flash.description=Flash vcrypt.fingerprint.type.enum.flash.processor=com.bharosa.uio.processor.device.FlashDeviceIdentificationProcessor vcrypt.fingerprint.type.enum.flash.header_list=avd,acc,a,ae,ev,ime,mp3,pr,sb,sp,sa,sv,tls,ve,deb,l,lfd,m,os,ar,pt,col,dp,r,v vcrypt.fingerprint.type.enum.flash.search_list=deb,l,os,v vcrypt.fingerprint.type.enum.flash.result_list=deb,l,os,v vcrypt.fingerprint.type.enum.flash.header_name_nv=avd,Audio/Video disabled by user,acc,Has accessibility,a,Has audio,ae,Had audio encoder,ev,Embedded video, ime, Has input method editor (IME) installed,mp3, Has MP3, pr, Supports printer, sb, Supports screen broadcast applications, sp, Supports playback on screen broadcast applications, sa, Supports streaming audio, sv, Supports streaming video, tls, Supports native SSL, ve, Contains video encoder, deb, Debug version, l, Language, lfd, Is local file read disabled, m, Manufacturer, os, Operating System, ar, Aspect ratio of screen, pt, Player type, col, Is screen color, dp, Dots-per-inch (DPI), r, Screen resolution, v, Flash version #vcrypt.fingerprint.type.enum.flash.header_value_nv=t,true,f,false vcrypt.fingerprint.type.enum.flash.header_value_nv=t,true,f,false,en,English,es,Spanish,de,German,it,Italian,ja,Japanese,fr,French,ko,Korean,zh,Chinese,ar,Arabic,cs,Czech,da,Danish,nl,Dutch,fi,Finnish,el,Greek,iw,Hebrew,hu,Hungarian,no,Norwegian,pl,Polish,pt,Portuguese,ro,Romanian,ru,Russian,sk,Slovak,sv,Swedish,th,Thai,tr,Turkish,BR,Brazil
The JavaScript type enum is shown below to illustrate the information to be collected for a JavaScript fingerprint.
vcrypt.fingerprint.type.enum.javascript.name=Javascript vcrypt.fingerprint.type.enum.javascript.description=Javascript vcrypt.fingerprint.type.enum.javascript.processor=com.bharosa.uio.processor.device.JSDeviceIdentificationProcessor vcrypt.fingerprint.type.enum.javascript.header_list=acn,gl,amv,l,ce,an,av,p,u a,o,je,te,w,h,cd,aw,ah,tzo,mt,pl,osc,prod,prods,bid,pd,cc,dnt vcrypt.fingerprint.type.enum.javascript.search_list=acn,l,ua vcrypt.fingerprint.type.enum.javascript.result_list=acn,l,ua vcrypt.fingerprint.type.enum.javascript.header_name_nv=acn,App code name,gl,Geo location,amv,App minor version,l,Language,ce,Cookies enabled,an,App name,av,App version,p,Platform,ua,User agent,o,Online,je,Java enabled,te,Taint enabled,w,Width,h,Height,cd,Color depth,aw,Available width,ah,Available height,tzo,Timezone offset,mt,Mime types,pl,Plugins,osc,OS CPU,prod,Product,prods,Sub product,bid,Build ID,pd,Pixel depth,cc,CPU class,dnt,Do not track vcrypt.fingerprint.type.enum.javascript.header_value_nv=t,true,f,false,en,English,es,Spanish,de,German,it,Italian,ja,Japanese,fr,French,ko,Korean,zh,Chinese,ar,Arabic,cs,Czech,da,Danish,nl,Dutch,fi,Finnish,el,Greek,iw,Hebrew,hu,Hungarian,no,Norwegian,pl,Polish,pt,Portuguese,ro,Romanian,ru,Russian,sk,Slovak,sv,Swedish,th,Thai,tr,Turkish,BR,Brazil vcrypt.fingerprint.type.enum.javascript.is_device_fingerprint=true
E.1.2.3 Native Mobile Application
OAAM device fingerprinting is integrated into mobile applications via the Access Management SDK and REST services layer. Developers embed the SDK in their application to collect application ID, operating system, OS version, IP Address, one-time fingerprinting value, GPS/triangulation location, IMEI/MAC. These data elements are used by OAAM to fingerprint and identify the device and run risk evaluations.
Mobile cookies are listed in the following table.
| Attributes | Description |
|---|---|
|
IMEI Id |
IMEI (International Mobile Equipment Identity) ID is the mobile device's unique ID. An IMEI is given to every single mobile phone and is stored in a Equipment Identity Register database. The numbers that make up the IMEI provides information about the type approval code (TAC), the country code, the final assembly code, the manufacturer, and the serial number. |
|
MAC Address |
Network MAC address (Media Access Control address) for the device. The MAC address is a hardware address assigned to a network adapter or any device with built-in networking capability. The MAC address is an ID that is unique to a particular device. It provides numbers representing the company that manufactured or sold the device and numbers specific to the device. |
|
OS Type |
Operating system of the device |
The mobile type enum is shown below to illustrate the information to be collected for a mobile fingerprint.
#Enum for fingerprint type vcrypt.fingerprint.type.enum=Enum for fingerprint type vcrypt.fingerprint.type.enum.native_mobile=900 vcrypt.fingerprint.type.enum.native_mobile.name=Native Mobile vcrypt.fingerprint.type.enum.native_mobile.description=Native Mobile implementation using OIC vcrypt.fingerprint.type.enum.native_mobile.processor=com.bharosa.uio.processor.device.NativeMobileDeviceIdentificationProcessor vcrypt.fingerprint.type.enum.native_mobile.header_list=os.type,os.version,hw.imei,hw.mac_addr vcrypt.fingerprint.type.enum.native_mobile.header_name_nv=os.type,Operating System Type,os.version,Operating System Version,hw.imei,Hardware IMEI Number,hw.mac_addr,Hardware Mac Address vcrypt.fingerprint.type.enum.native_mobile.header_value_nv=t,true,f,false
E.1.2.4 IP Intelligence and Historical Context
The combinations of users, devices, locations and other context captured by Oracle Adaptive Access Manager are used to evaluate the probability a device is one identified previously. This evaluation is especially useful when the total amount of device attributes is limited. For example, if user accesses via a browser without a secure cookie of Flash shared object.
E.1.3 Setting Up Standard Fingerprinting
Out of the box, standard fingerprint types are provided and require no setup. The standard fingerprint properties are presented below. You can use these properties as examples for creating custom fingerprint types.
#Reference to the "vcrypt.fingerprint.type.enum" elementId for Digital Device Fingerprinting bharosa.uio.default.device.identification.scheme=flash #Enum for fingerprint type vcrypt.fingerprint.type.enum=Enum for fingerprint type vcrypt.fingerprint.type.enum.browser=1 vcrypt.fingerprint.type.enum.browser.name=Browser vcrypt.fingerprint.type.enum.browser.description=Browser vcrypt.fingerprint.type.enum.browser.userAgent=userAgent vcrypt.fingerprint.type.enum.browser.locallang=localLang vcrypt.fingerprint.type.enum.browser.localcountry=localCountry vcrypt.fingerprint.type.enum.browser.localvariant=localVariant vcrypt.fingerprint.type.enum.browser.header_list=locallang,localcountry,localvariant,userAgent vcrypt.fingerprint.type.enum.browser.search_list=locallang,userAgent vcrypt.fingerprint.type.enum.browser.result_list=locallang,userAgent vcrypt.fingerprint.type.enum.browser.header_value_nv=t,true,f,false,en,English,es,Spanish,de,German,it,Italian,ja,Japanese,fr,French,ko,Korean,zh,Chinese,ar,Arabic,cs,Czech,da,Danish,nl,Dutch,fi,Finnish,el,Greek,iw,Hebrew,hu,Hungarian,no,Norwegian,pl,Polish,pt,Portuguese,ro,Romanian,ru,Russian,sk,Slovak,sv,Swedish,th,Thai,tr,Turkish,BR,Brazil vcrypt.fingerprint.type.enum.flash=2 vcrypt.fingerprint.type.enum.flash.name=Flash vcrypt.fingerprint.type.enum.flash.description=Flash vcrypt.fingerprint.type.enum.flash.processor=com.bharosa.uio.processor.device.FlashDeviceIdentificationProcessor vcrypt.fingerprint.type.enum.flash.header_list=avd,acc,a,ae,ev,ime,mp3,pr,sb,sp,sa,sv,tls,ve,deb,l,lfd,m,os,ar,pt,col,dp,r,v vcrypt.fingerprint.type.enum.flash.search_list=deb,l,os,v vcrypt.fingerprint.type.enum.flash.result_list=deb,l,os,v vcrypt.fingerprint.type.enum.flash.header_name_nv=avd,Audio/Video disabled by user,acc,Has accessibility,a,Has audio,ae,Had audio encoder,ev,Embedded video, ime, Has input method editor (IME) installed,mp3, Has MP3, pr, Supports printer, sb, Supports screen broadcast applications, sp, Supports playback on screen broadcast applications, sa, Supports streaming audio, sv, Supports streaming video, tls, Supports native SSL, ve, Contains video encoder, deb, Debug version, l, Language, lfd, Is local file read disabled, m, Manufacturer, os, Operating System, ar, Aspect ratio of screen, pt, Player type, col, Is screen color, dp, Dots-per-inch (DPI), r, Screen resolution, v, Flash version #vcrypt.fingerprint.type.enum.flash.header_value_nv=t,true,f,false vcrypt.fingerprint.type.enum.flash.header_value_nv=t,true,f,false,en,English,es,Spanish,de,German,it,Italian,ja,Japanese,fr,French,ko,Korean,zh,Chinese,ar,Arabic,cs,Czech,da,Danish,nl,Dutch,fi,Finnish,el,Greek,iw,Hebrew,hu,Hungarian,no,Norwegian,pl,Polish,pt,Portuguese,ro,Romanian,ru,Russian,sk,Slovak,sv,Swedish,th,Thai,tr,Turkish,BR,Brazil vcrypt.fingerprint.type.enum.flash.avd=Audio/Video disabled by user vcrypt.fingerprint.type.enum.flash.acc=Has accessibility vcrypt.fingerprint.type.enum.flash.a=Has audio vcrypt.fingerprint.type.enum.flash.ae=Had audio encoder vcrypt.fingerprint.type.enum.flash.ev=Embedded video vcrypt.fingerprint.type.enum.flash.ime= Has input method editor (IME) installed vcrypt.fingerprint.type.enum.flash.mp3= Has MP3 vcrypt.fingerprint.type.enum.flash.pr= Supports printer vcrypt.fingerprint.type.enum.flash.sb= Supports screen broadcast applications vcrypt.fingerprint.type.enum.flash.sp= Supports playback on screen broadcast applications vcrypt.fingerprint.type.enum.flash.sa= Supports streaming audio vcrypt.fingerprint.type.enum.flash.sv= Supports streaming video vcrypt.fingerprint.type.enum.flash.tls= Supports native SSL vcrypt.fingerprint.type.enum.flash.ve= Contains video encoder vcrypt.fingerprint.type.enum.flash.deb= Debug version vcrypt.fingerprint.type.enum.flash.l= Language vcrypt.fingerprint.type.enum.flash.lfd= Is local file read disabled vcrypt.fingerprint.type.enum.flash.m= Manufacturer vcrypt.fingerprint.type.enum.flash.os= Operating System vcrypt.fingerprint.type.enum.flash.ar= Aspect ratio of screen vcrypt.fingerprint.type.enum.flash.pt= Player type vcrypt.fingerprint.type.enum.flash.col= Is screen color vcrypt.fingerprint.type.enum.flash.dp= Dots-per-inch (DPI) vcrypt.fingerprint.type.enum.flash.r= Screen resolution vcrypt.fingerprint.type.enum.flash.v= Flash version vcrypt.fingerprint.type.enum.monitordata=3 vcrypt.fingerprint.type.enum.monitordata.name=MonitorData vcrypt.fingerprint.type.enum.monitordata.description=Monitor Data vcrypt.fingerprint.type.enum.applet=999 vcrypt.fingerprint.type.enum.applet.name=Applet vcrypt.fingerprint.type.enum.applet.description=Applet vcrypt.fingerprint.type.enum.applet.processor=com.bharosa.uio.processor.device.AppletDeviceIdentificationProcessor vcrypt.fingerprint.type.enum.applet.header_list=java.version,java.vendor,os.name,os.arch,os.version vcrypt.fingerprint.type.enum.applet.header_name_nv=java.version,Java Version,java.vendor,Java Vendor Name,os.name,Operating System Name,os.arch,Operating System Architecture,os.version,Operating System Version vcrypt.fingerprint.type.enum.applet.header_value_nv=t,true,f,false vcrypt.fingerprint.type.enum.native_mobile=900 vcrypt.fingerprint.type.enum.native_mobile.name=Native Mobile vcrypt.fingerprint.type.enum.native_mobile.description=Native Mobile implementation using OIC vcrypt.fingerprint.type.enum.native_mobile.processor=com.bharosa.uio.processor.device.NativeMobileDeviceIdentificationProcessor vcrypt.fingerprint.type.enum.native_mobile.header_list=os.type,os.version,hw.imei,hw.mac_addr vcrypt.fingerprint.type.enum.native_mobile.header_name_nv=os.type,Operating System Type,os.version,Operating System Version,hw.imei,Hardware IMEI Number,hw.mac_addr,Hardware Mac Address vcrypt.fingerprint.type.enum.native_mobile.header_value_nv=t,true,f,false
The monitor data enum controls the data captured and displayed by the OAAM Admin dashboard for metrics.
E.1.4 Setting Up JavaScript Fingerprinting
Out of the box, JavaScript fingerprint types are provided and require no setup. The JavaScript fingerprint properties are presented below for your reference.
JavaScript fingerprint uses HTML 5 stored object as the cookie and uses the key "jc".
OAAM Server Properties for JavaScript Fingerprinting
#Enable / Disable javascript fingerprinting bharosa.uio.default.javascript.fingerprint.enable = true #Javascript file that contains js fp script bharosa.uio.default.javascript.fingerprint.file=js/oaam_fp.js #URL to post js fp data bharosa.uio.default.javascript.fingerprint.url=jsFingerprint.do #Delimiter used between fingerprint bharosa.uio.default.javascript.fingerprint.delim=& #Delimiter used between fingerprint list items bharosa.uio.default.javascript.fingerprint.listDelim=, #Enable / Disable prompting user for location information bharosa.uio.default.javascript.fingerprint.location.prompt.enabled=true #Time in milliseconds to wait for user to respond to location prompt bharosa.uio.default.javascript.fingerprint.location.prompt.time=6000
Properties for JavaScript Fingerprint Type Configuration
vcrypt.fingerprint.type.enum.javascript.name=Javascript vcrypt.fingerprint.type.enum.javascript.description=Javascript vcrypt.fingerprint.type.enum.javascript.processor=com.bharosa.uio.processor.device.JSDeviceIdentificationProcessor vcrypt.fingerprint.type.enum.javascript.header_list=acn,gl,amv,l,ce,an,av,p,ua,o,je,te,w,h,cd,aw,ah,tzo,mt,pl,osc,prod,prods,bid,pd,cc,dnt vcrypt.fingerprint.type.enum.javascript.search_list=acn,l,ua vcrypt.fingerprint.type.enum.javascript.result_list=acn,l,ua vcrypt.fingerprint.type.enum.javascript.header_name_nv=acn,App code name,gl,Geo location,amv,App minor version,l,Language,ce,Cookies enabled,an,App name,av,App version,p,Platform,ua,User agent,o,Online,je,Java enabled,te,Taint enabled,w,Width,h,Height,cd,Color depth,aw,Available width,ah,Available height,tzo,Timezone offset,mt,Mime types,pl,Plugins,osc,OS CPU,prod,Product,prods,Sub product,bid,Build ID,pd,Pixel depth,cc,CPU class,dnt,Do not track vcrypt.fingerprint.type.enum.javascript.header_value_nv=t,true,f,false,en,English,es,Spanish,de,German,it,Italian,ja,Japanese,fr,French,ko,Korean,zh,Chinese,ar,Arabic,cs,Czech,da,Danish,nl,Dutch,fi,Finnish,el,Greek,iw,Hebrew,hu,Hungarian,no,Norwegian,pl,Polish,pt,Portuguese,ro,Romanian,ru,Russian,sk,Slovak,sv, Swedish,th,Thai,tr,Turkish,BR,Brazil vcrypt.fingerprint.type.enum.javascript.is_device_fingerprint=true
Resource Bundle Values for Admin Fingerprint Value Display
The fingerprint definition enum contains name value pairs of the attributes as below:
vcrypt.fingerprint.type.enum.javascript.header_name_nv=acn,App codename,gl,Geo location,amv,App minor version,l,Language,ce,Cookiesenabled,an,App name,av,App version,p,Platform,ua,User agent,o,Online,je,Javaenabled,te,Taint enabled,w,Width,h,Height,cd,Color depth,aw,Availablewidth,ah,Available height,tzo,Timezone offset,mt,Mime types,pl,Plugins,osc,OSCPU,prod,Product,prods,Sub product,bid,Build ID,pd,Pixel depth,cc,CPUclass,dnt,Do not track
In the resource file, you specify for each name and its display string.
. vcrypt.fingerprint.type.enum.javascript.acn=App code name vcrypt.fingerprint.type.enum.javascript.gl=Location vcrypt.fingerprint.type.enum.javascript.amv=App minor version vcrypt.fingerprint.type.enum.javascript.l=Language vcrypt.fingerprint.type.enum.javascript.ce=Cookies enabled vcrypt.fingerprint.type.enum.javascript.an=App name vcrypt.fingerprint.type.enum.javascript.av=App version vcrypt.fingerprint.type.enum.javascript.p=Platform vcrypt.fingerprint.type.enum.javascript.ua=User agent vcrypt.fingerprint.type.enum.javascript.o=Online vcrypt.fingerprint.type.enum.javascript.je=Java enabled vcrypt.fingerprint.type.enum.javascript.te=Taint enabled vcrypt.fingerprint.type.enum.javascript.w=Width vcrypt.fingerprint.type.enum.javascript.h=Height vcrypt.fingerprint.type.enum.javascript.cd=Color depth vcrypt.fingerprint.type.enum.javascript.aw=Available width vcrypt.fingerprint.type.enum.javascript.ah=Available height vcrypt.fingerprint.type.enum.javascript.tzo=Timezone offset vcrypt.fingerprint.type.enum.javascript.mt=Mime types vcrypt.fingerprint.type.enum.javascript.pl=Plugins vcrypt.fingerprint.type.enum.javascript.osc=OS CPU vcrypt.fingerprint.type.enum.javascript.prod=Product vcrypt.fingerprint.type.enum.javascript.prods=Sub Product vcrypt.fingerprint.type.enum.javascript.bid=Build ID vcrypt.fingerprint.type.enum.javascript.pd=Pixel depth vcrypt.fingerprint.type.enum.javascript.cc=CPU class vcrypt.fingerprint.type.enum.javascript.dnt=Do not track
E.1.5 Disabling Flash or Javascript Fingerprinting
Both Flash and Javascript fingerprinting are enabled by default where Flash is given higher priority. You cannot change the priority (Flash is given priority since it contains more data). Each can be disabled individually. The properties are as follows:
bharosa.uio.default.flash.fingerprint.enable bharosa.uio.default.javascript.fingerprint.enable
E.1.6 Native Integration and Device Fingerprinting
The most recent OAAM Sample Application that illustrates API integration can be downloaded from the Oracle Technology Network at:
http://www.oracle.com/technetwork/index.html
APIs Used in Device Fingerprinting
Table E-2 lists the APIs used for device fingerprinting.
Table E-2 Device Fingerprinting APIs
| Module | APIs | Description |
|---|---|---|
|
Server |
APIs that construct the fingerprint are:
|
For method details on updateLog(), see the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager. |
|
Oracle Adaptive Access Manager Sample |
|
|
|
Oracle Adaptive Access Manager Sample |
|
Cookies in Device Fingerprinting
The following sample code shows how to fingerprint the device using browser and Flash cookies. See the code in handleFlash.jsp for details:
//Get Browse/Secure cookie
String secureCookie = getCookie(request, "bharosa");
Locale locale = request.getLocale();
String browserFp = VCryptServletUtil.getBrowserFingerPrint(request.getHeader("user-agent"),
locale.getLanguage(),
locale.getCountry(), locale.getVariant());
String client = request.getParameter("client");
String fpStr = request.getParameter("fp");
String flashFp = bharosaHelper.constructFlashFingerPrint( client, fpStr );
//Get the flash cookie
String flashCookie = request.getParameter("v");
CookieSet cookieSet = bharosaHelper.fingerPrintFlash(bharosaSession, bharosaSession.getRemoteIPAddr(), request.getRemoteHost(),
BharosaEnumAuthStatus.PENDING, secureCookie, browserFp, flashCookie, flashFp);
E.1.7 Setting Up Flash Fingerprinting in a Native Integration
For specifics of Flash Fingerprinting within an Oracle Adaptive Access Manager native integration, refer to Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
E.1.8 Setting Up Custom Fingerprinting
OAAM allows you to display and search for custom fingerprinting data generated by a custom device identification applet along with the standard available fingerprint data in various details tabs and pages. Custom fingerprint information is available for native Mobile and applet.
This section provides information on how to create fingerprint types so that Oracle Adaptive Access Manager can capture information about the devices that a user uses when accessing protected applications. Fingerprint types are contained in the oaam_custom.properties. If you want fingerprint types that are not provided out of the box, you must modify your oaam_custom.properties file to include these types at the time of deployment.
-
Open the
oaam_custom.propertiesfile in theWEB-INF/classes/bharosa_propertiesdirectory of theoracle.oaam.extensions.warfile. -
Add the enumeration for the fingerprint you want to capture. See Section E.1.3, "Setting Up Standard Fingerprinting" for format of the fingerprint enumeration.
-
Set the property
bharosa.uio.default.device.identification.schemeto the type of fingerprint you want to capture.For example, the
vcrypt.fingerprint.type.enumelementId for digital device fingerprinting is:bharosa.uio.default.device.identification.scheme=flash
E.1.9 Modifying the Mobile Device Fingerprint in a Native Integration
Out of the box OAAM provides a default mobile device fingerprint consisting of the following attributes:
-
Operating System Type
-
Hardware IMEI Number
-
Hardware MAC Address
These are specified through the enum element named vcrypt.fingerprint.type.enum.native_mobile. You can use the Properties editor option of OAAM Admin Console to view the attributes of this enum element.
To add mobile fingerprint attributes to capture:
-
Log in to the OAAM Admin Console.
-
In the Navigation pane, double-click Properties under the Environment node. The Properties Search page is displayed.
-
Enter
vcrypt.fingerprint.type.enum.native_mobilein the Name field and click Search.You should see the attributes of the property in the Search Results section.
-
If you must add more attributes that identify your mobile device, enter
vcrypt.fingerprint.type.enum.native_mobile.header_listin the Name field and click Search. -
Click to select the property in the Search Results section, add the list of attributes and click Save.
-
To provide the mapping of attributes to their display value, enter
vcrypt.fingerprint.type.enum.native_mobile.header_name_nvin the Name field and click Search. -
Click to select the property in the Search Results section, add the mapping attributes, and click Save.
-
To provide the mapping of actual value to the display value, enter
vcrypt.fingerprint.type.enum.native_mobile.header_value_nvin the Name field and click Search. -
Click to select the property in the Search Results section, add the actual value to display, and click Save.
Note: Do not add attributes that are very dynamic in nature like IP Address, and so on, as mobile device fingerprint attributes. Add only those that can uniquely identify the device.
The following example shows a mobile fingerprint enum:
vcrypt.fingerprint.type.enum.native_mobile=900
vcrypt.fingerprint.type.enum.native_mobile.name=Native Mobile
vcrypt.fingerprint.type.enum.native_mobile.description=
Native Mobile implementation using Mobile and Social
vcrypt.fingerprint.type.enum.native_mobile.processor=
com.bharosa.uio.processor.device.NativeMobileDeviceIdentificationProcessor
vcrypt.fingerprint.type.enum.native_mobile.header_list=
os.type,os.version,hw.imei,hw.mac_addr
vcrypt.fingerprint.type.enum.native_mobile.header_name_nv=
os.type,Operating System Type,os.version,Operating System Version,
hw.imei,Hardware IMEI Number,hw.mac_addr,Hardware Mac Address
vcrypt.fingerprint.type.enum.native_mobile.header_value_nv=t,true,f,false
E.1.10 Viewing Fingerprinting Data
OAAM allows you to display fingerprinting data in various details tabs and pages.
E.1.10.1 Session Details
To view information about secure and digital cookies, proceed as follows:
-
From the navigation tree, double-click the Sessions node.
-
Search for the session you are interested in viewing details about.
-
In the Search Results table, click the Session ID of the session of interest. The Session Details page for that session is displayed.
-
Click the Device tab.
In Basic Information, you can view the Device ID, Device Type, and Browser.
In Fingerprinting Details, you can view fingerprint type and its parameter in a hierarchical tree format. The Fingerprint Details section lists fingerprints created for the device during login.
E.1.10.2 User Details: Fingerprint Data
This tab shows all the fingerprint (browser, flash, custom) information collected when a particular user logs in. Custom fingerprint information can be collected for Native Mobile and Applet. For information, see Section 6.11.7, "User Details: Fingerprint Data."
-
Click the User ID or User Name link from the Sessions page for a valid user.
The User Details page is displayed.
-
Click the Fingerprints tab.
This tab lists fingerprints created for the user during login.
E.1.10.3 Location Details: Fingerprints Tab
This tab lists fingerprints created for the location during login.
-
From the results of a session search, click the country, state, city, or IP link.
The Location Details page for that country, state, city, or IP is displayed.
-
Click the Fingerprint Data tab.
-
Search by Fingerprint ID and Fingerprint type.
Figure E-1Location Details: Fingerprint Data
Description of "Figure E-1Location Details: Fingerprint Data"
E.1.10.4 Device Details
To open the Device Detail pages, proceed as follows:
-
Click the Device ID link in the Session search page or other pages.
The Device Details page is opened and shows additional details.
-
View the Summary tab.
The following general data is displayed:
-
Device ID
-
Device Type
-
External Device ID
-
Browser
-
Operating System
-
Create Time
-
Last Used On
-
E.1.10.4.1 Device Details: Summary Tab
The Fingerprint panel of the summary tab shows fingerprint information.
The Fingerprint Details section of the Device Detail summary page lists fingerprints created for the device during login. Out of the box, OAAM supports browser, mobile application, and digital fingerprints. OAAM provides the framework so users can fingerprint types other than browser, flash, and JavaScript if needed. A digital fingerprint refers to a Flash, JavaScript, or a custom fingerprint defined by the user.
Table E-3 Device Details Fingerprint Information
| Device Details Fingerprint Tab | Description |
|---|---|
|
Browser Fingerprint |
When the user accesses the system, OAAM collects information about the computer. By combining all that data, the site creates a fingerprint of the user's browser. This fingerprint could potentially uniquely identify the user. Information gathered that makes up the browser fingerprint include the browser type used, extensions installed, system fonts, and the configuration and version information from the operating system, and whether or not the computer accepts cookies. Information is shown such as:
|
|
Digital Fingerprint |
Information is shown for Flash, JavaScript, or a custom fingerprint defined by the user. The fields show information such as:
|
E.1.10.4.2 Device Details: Fingerprint Data Tab
This tab lists fingerprints created for the device during login.
Figure E-2Device Details: Fingerprint Data
Description of "Figure E-2Device Details: Fingerprint Data"
E.1.10.5 Fingerprint Details Page
To view digital fingerprint details, click the Digital Fingerprint ID link from the session details or listing page.
To view browser fingerprint details, click the Browser Fingerprint ID link from the session details or listing page.
The Fingerprint Details page opens with additional details.
E.1.10.5.1 Fingerprint Details: Summary Tab
The Fingerprint Details Summary page shows general fingerprint information and the data collected during device fingerprinting.
The Fingerprint Details Summary tab shows the fingerprinting type (Flash, browser, custom) and parameters.
The Fingerprint Details Summary page shows general fingerprint information and the data collected during device fingerprinting.
The Fingerprint Details Summary tab shows the fingerprinting type (browser, digital, or custom) and parameters.
Figure E-3 shows the collected digital fingerprint details in the Summary tab.
Figure E-3Digital Fingerprint Details Shown
Description of "Figure E-3Digital Fingerprint Details Shown"
Figure E-4 shows the collected browser fingerprint details in the Summary tab.
Figure E-4Browser Fingerprint Details Shown
Description of "Figure E-4Browser Fingerprint Details Shown"
E.1.10.5.2 Fingerprint Details: Users Tab
This tab lists all the users who used the fingerprint during the time frame specified. The Users tab of the Fingerprint Details page enables you to determine which users and how many times the fingerprint was used for each user during the login process.
E.1.10.5.3 Fingerprint Details: Devices Tab
This tab lists all devices for which the fingerprint was used.
The Device tab of the Fingerprint Details page enables you to determine which devices and how many times the fingerprint was used for each device during login process.
E.1.10.5.4 Fingerprint Details: Locations Tab
This tab lists all locations for which the fingerprint was used.
The Locations tab of the Fingerprint Details page enables you to determine which locations and how many times the fingerprint was used for each location during the login process.
E.1.10.5.5 Fingerprint Details: Sessions Tab
This tab lists of login sessions in which the fingerprint was generated for a particular period.
E.1.10.5.6 Fingerprint Details: Alerts Tab
This tab lists alerts that have been triggered for this device within the time frame specified in the search criteria.
E.1.10.5.7 Fingerprint Details Tasks
This section describes how to obtain information through the use of the Fingerprint Details pages.
View digital fingerprint details
To view digital fingerprint details, click the Digital Fingerprint ID link from the session details or listing page.
The Fingerprint Details page opens with additional details.
View browser fingerprint details
To view browser fingerprint details, click the Browser Fingerprint ID link from the session details or listing page.
The Fingerprint Details page opens with additional details.
Search and view the different users for which the fingerprint was used
To search and view the different users for which the fingerprint was used:
-
Click the Fingerprint ID link in the Session details or listing page.
The Fingerprint Details page is opened and shows additional details.
-
Click the Users tab.
This tab lists all the users who used the fingerprint during the time frame specified.
-
Search for the different users for which the fingerprint was used using the filter parameters.
Search and view the different devices for which the fingerprint was used
To search and view the different devices for which the fingerprint was used:
-
Click the Fingerprint ID link in the Session details or listing page.
The Fingerprint Details page is opened and shows additional details.
-
Click the Devices tab.
This tab lists all devices for which the fingerprint was used.
-
Search for the different devices for which the fingerprint was used using the filter parameters.
This report enables you to see which devices were used and how many times the fingerprint was used for each device during login process.
Search and view the different locations for which the fingerprint was used
To search and view the different locations for which the fingerprint was used:
-
Click the Fingerprint ID link in the Session details or listing page.
The Fingerprint Details page is opened and shows additional details.
-
Click the Locations tab.
This tab lists all locations for which the fingerprint was used.
-
Search for the different locations for which the fingerprint was used using the filter parameters.
This report enables you to see which locations and how many times the fingerprint was used for each location during login process.
Search and view all the login sessions or search login sessions for a particular period for the fingerprint
To search and view all the login sessions or search login sessions for a particular period for the fingerprint:
-
Click the Fingerprint ID link in the Session details or listing page.
The Fingerprint Details page is opened and shows additional details.
-
Click the Sessions tab.
This tab lists of login sessions in which the fingerprint was generated for a particular period.
-
Search and view all the login sessions or search login sessions by the Session Date for the fingerprint.
Searching by Session Date gets all the sessions during which the device logged in for the given time duration.
E.1.10.6 Alerts Details: Fingerprint Data
This tab displays the fingerprint information used when the alert was triggered during the time frame specified.
Figure E-10Alert Details: Fingerprint Data
Description of "Figure E-10Alert Details: Fingerprint Data"
E.2 Device Identification
Oracle Adaptive Access Manager uses dozens of attributes to recognize and "fingerprint" the device you typically use to login, providing greater "coverage" for an institution. Concepts about device identification are provided in this section.
E.2.1 Assigning the Device ID
The first time the user logs in, OAAM captures a unique combination of attributes of the device. At this point, the user does not have any cookie because he is logging in for the first time; therefore, the OAAM Server must process the device fingerprint data and determine if the device has ever been seen before. If the combination is found in the OAAM database, for example, a user's wife used the device, OAAM knows it is the same device and assigns the same Device ID to the user.
Oracle Adaptive Access Manager generates a unique secure cookie for each Device ID being created. The secure cookie stored by OAAM in the client's browser is merely a tracking cookie:
-
It does not store any information about the user.
-
It is only used to track if the user had logged in from this browser before to identify a device.
-
It is valid for a single user only.
Device ID is not based on cookie. For each device OAAM stores the cookie value it is expecting next. OAAM looks for the same cookie the next time any user logs in from the device. If OAAM is able to find this cookie in the browser, it compares this cookie with an expected value. If the two values match, OAAM does not look at the Flash data. It goes no further because it knows that the request has come from a previously used device; hence the Device ID is reused.
If it does not match, it may be a stale or a modified cookie, so it is ignored. This cookie is discarded and a new cookie is generated. In this case, configured rules are triggered and a higher score results and a new Device ID is generated. If the cookie is not present in the browser, it is a new request. If the OAAM cookies are not set on the browser, OAAM looks at the Flash shared object. If Flash is not enabled, OAAM looks at the browser user agent string data along with other contextual data available in the session. OAAM looks at and determines if the combination came in before from somewhere else so that it can potentially assign the same Device ID.
If the user disables the cookies on the browser side and prevents the cookies to be set, a default Device ID is given. The Device ID is then based on the other attributes such as the user-agent string.
If the user deletes his cookies, a new Device ID is generated.
Different Web Browser/Different Device ID
When using web browser based fingerprinting, by design each web browser will be given its own unique device identifier except when using Internet Explorer and Mozilla Firefox web browsers installed on the same laptop. In other cases with web browsers which are installed on the same laptop, the device may appear as two distinct Device IDs in the OAAM Admin Console because OAAM is profiling all the Device IDs used in a deployment both in relation to users and independently.
Internet Explorer and Mozilla Firefox Use/Same ID if Flash Available
If Flash is available, the device identifier would be the same even if you use Mozilla Firefox and Internet Explorer on the same machine. This is true only for Mozilla Firefox and Internet Explorer. Other web browsers might act differently. For example, if you use Chrome, a different device identifier results.
Only a Subset of Data is Available
The identification logic and policies are designed to deal with scenarios where only a subset of the data is available. If only the browser user agent string is available the OAAM logic will look at context data such as the composition of devices the user has used previously and locations the user has accessed from in the past. It automatically deals with situations where a user either deletes the cookies and Flash Shared Object or does not have them enabled at all.
OAAM will assign a new ID for a short period (3 logins) then revert back to the first ID from there on if a user's behavior is consistent (same user and IP for example). The device fingerprinting logic also accounts for common changes in device data such as an operating system or browser upgrade.
This scenario shows a what occurs if a user deletes both their secure cookie and Flash shared object after every session but the other data stays consistent across sessions. The OAAM device identification logic and policies determine that after three successful fingerprints the device can be recognized as a consistent Device ID.
| Ses | User | IP | User Agent | Secure Cookie | Flash cookie | Flash cookie Data | Action |
|---|---|---|---|---|---|---|---|
| 1 | jsmith | 1.1.1.1 | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 | No expected,
No cookie, Cookies enabled, Set |
No DC expected,
No FSO, Installed and set |
Type=Flash, Screen Aspect=1.0, A/V Disabled=F, Video Encoder=T … | New device
1234 |
| 2 | jsmith | 1.1.1.1 | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 | Cookie expected,
No cookie, Cookies enabled, Set |
DC expected,
No FSO, Installed, Set |
Type=Flash, Screen Aspect=1.0, A/V Disabled=F, Video Encoder=T … | New device
1235 |
| 3 | jsmith | 1.1.1.1 | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 | Cookie expected,
No cookie, Cookies enabled, Set |
DC expected,
No FSO, Installed, Set |
Type=Flash, Screen Aspect=1.0, A/V Disabled=F, Video Encoder=T … | New device
1236 |
| 4 | jsmith | 1.1.1.1 | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 | Cookie expected,
No cookie, Cookies enabled, Set |
DC expected,
No FSO, Installed, Set |
Type=Flash, Screen Aspect=1.0, A/V Disabled=F, Video Encoder=T … | New device
1237 |
| 5 | jsmith | 1.1.1.1 | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 | Cookie expected,
No cookie, Cookies enabled, Set |
DC expected,
No FSO, Installed, Set |
Type=Flash, Screen Aspect=1.0, A/V Disabled=F, Video Encoder=T … | Device by browser data
1234 |
| 6 | jsmith | 1.1.1.1 | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 | Cookie expected,
No cookie, Cookies enabled, Set |
DC expected,
No FSO, Installed, Set |
Type=Flash, Screen Aspect=1.0, A/V Disabled=F, Video Encoder=T … | Device by browser data
1234 |
Cookies Match /Different Fingerprint
There are cases where the user's cookies match, but he has a different fingerprint, for example, the user changed his resolution, OAAM gives the device the same Device ID, but a different score. The device looks the same, but it might be considered suspicious, so the risk score is raised based on what has changed. The Device ID is the same because he came in with the same cookie (cookies match), but the Flash is different from what it was before.
E.2.2 Device Identification Policies
The Device ID is determined by the configuration of the rules and trigger combinations.
Oracle Adaptive Access Manager uses the policy engine for many purposes including business logic to drive user experience, risk analysis and device identification. The device identification policies are designed to function for all customer deployments.
Note:
Oracle does not recommend or support alterations to the device identification policies.The following list of policies are used for device identification and should therefore never be deleted or altered in any way.
-
OAAM Base Device ID Policy
-
OAAM Mobile Device ID Policy (mainly used for Oracle Access Management Mobile and Social integrations)
-
OAAM Device ID Policy
-
OAAM System Deep Analysis Flash Policy
-
OAAM System Deep Analysis No Flash Policy
Note:
The OAAM System Deep Analysis Flash Policy and OAAM System Deep Analysis No Flash Policy will not be covered in this chapter.All the actions of the policies are taken from the trigger combination. Device ID depends heavily on trigger combinations.
For information on policies and trigger combinations, see Chapter 10, "OAAM Policy Concepts and Reference."
E.2.2.1 OAAM Base Device ID Policy
The OAAM Base Device ID Policy determines which Device ID policy to run for the client device identification.
The Base ID policy contains one rule to check if the user is a mobile user and if the login is coming in from a Mobile and Social integration. The rules contains two conditions:
-
The
Device: Check if device is using Mobile Browsercondition checks whether the current device is using a mobile browser to access the website. This is based on the user agent. -
The
Device: Browser header substringcondition checks whether the supplied string exists as a substring in the browser header information.
The Base Device ID Policy trigger combinations determine all actions to be taken.
If the device is mobile and coming in from a Mobile and Social type of integration, OAAM runs the Mobile Device ID policy. If the device is not mobile and is coming in from a UIO deployment or a more traditional deployment, OAAM runs the Device ID policy.
For information on the OAAM Base Device ID Policy, see Section 10.5.2, "OAAM Base Device ID Policy."
E.2.2.2 OAAM Mobile Device ID Policy
The OAAM Mobile Device ID Policy identifies the mobile devices specific to Oracle Access Management Mobile and Social (Mobile and Social) integrations.
The OAAM Mobile Device ID policy contains three rules:
-
Mobile Cookie Valid with the
Device ID: Is cookie valuecondition.The
Device ID: Is Cookie validcondition determines if there is a valid node for the given cookie. -
Mobile Known Header Match with the
Device ID: Header data matchcondition.The
Device ID: Header data matchcondition determines if the header is a match. -
Mobile Device Data Present with the
Device ID: Header data presentcondition.The
Device ID: Header data presentcondition determines if the header data is present.
All the actions are taken by the Mobile Device ID Policy trigger combinations. They check if there is already a mobile device assigned or if OAAM needs to assign a new one:
-
If the mobile cookie is valid and the device matches, OAAM finds the device by the mobile cookie itself.
-
If the mobile cookie is valid, but the header does not match, OAAM identifies the device by mobile cookie, but there may be some suspicion. Question might arise such as: Why would the header not match? Was there an upgrade? Was the mobile cookie copied from somewhere? Because of the suspicion, a high score is generated.
-
If the mobile cookie is completely not valid at all, which usually means the user is coming in new, a new Device ID is issued and a score of 200 is generated.
-
If there is no mobile cookie present which could mean that the user is always not coming in from the mobile cookie because everything has been disabled, OAAM tries to check if the device always comes in with no mobile cookie and assigns it a standard Device ID.
For information on the OAAM Mobile Device ID Policy, see Section 10.5.3, "OAAM Mobile Device ID Policy."
E.2.2.3 OAAM Device ID Policy
The OAAM Device ID Policy determines if the device should be identified by an existing ID or if a new one should be issued. It contains ten rules.
The Device ID policies check if the browser cookie is valid, if the Flash cookie is valid, if Flash is completely disabled, if Flash is present at all, if the browser fingerprint matches, if the Flash fingerprint matches, if the cookie matches, and other rules. The rules look for certain conditions. If you have customized device identification, you can use these rules or you can use completely new rules through custom development.
OAAM Device ID Policy contains ten rules.
-
The Browser Cookie Valid rule contains the
Device ID: Browser Cookie Validcondition.The
Device ID: Browser Cookie Validcondition determines if there is a valid cookie node for a given device value. -
The Flash Cookie Valid rule contains the
Device ID: Flash Cookie Validcondition.The
Device ID: Flash Cookie Validcondition determines if there is a valid node for the given cookie value. -
The Flash Cookie Disabled rule contains the
Device ID: Flash Cookie Disabledcondition.The
Device ID: Flash Cookie Disabledcondition determines if the cookie is disabled for the user based on the history. -
The Browser Cookie Disabled rule contains the
Device ID: Browser Cookie Disabledcondition.The
Device ID: Browser Cookie Disabledcondition determines if the browser cookie is disabled for the user based on history. -
Browser Cookie Present rule contains the
Device ID: Browser Cookie Presentcondition.The
Device ID: Browser Cookie Presentcondition determines if the cookie value is empty or not empty. The validation check is not included. -
The Flash Cookie Present rule contains the
Device ID: Flash Cookie Presentcondition.The
Device ID: Flash Cookie Presentcondition determines if the cookie value is empty or not empty. The validation check is not included. -
The Browser FP match rule contains the
Device ID: Header data matchcondition.The
Device ID: Header datamatch condition determines if the header data matches. -
The Flash FP match rule contains the
Device ID: Header data matchcondition.The
Device ID: Header data matchcondition determines if the header data matches. -
The Cookie match rule contains the
Device ID: Cookies Matchcondition.The
Device ID: Cookies Matchcondition checks the tracker node matches for both cookies. -
The Flash Data Present rule condition contains the
Device ID: header data presentcondition.The
Device ID: header data presentcondition determines if the header data is present.
Two trigger combinations will be explained to illustrate how the Device ID policy works. Each row in a trigger combination is one rule presented in the policy. Each vertical column represent the combination of the rules being triggered or not triggered.
Figure E-11Device ID Policy Trigger Combinations 1-3
Description of "Figure E-11Device ID Policy Trigger Combinations 1-3"
The first column represents a situation where the browser fingerprint match, the Flash fingerprint matches, and the cookies match. If this is the case, the action generated is OAAM device identified by secure cookie. OAAM uses that cookie and if there is already an existing device that uses the cookie, then, OAAM assigns that particular device to the session.
If the user logs in as a separate user from the same device or the same browser, the cookies are the same as well. Even if the user logs in as a different user, he arrives at the same device.
Sometimes it is logical not to use any score, but only generate an action or alert. In column 1, the cookies matched so OAAM reuses the device identified by the secure cookie.
The second column is a second set of conditions. If the first set of conditions were not met, OAAM proceeds to the second column. If the first set of conditions were met, no other column is executed. If not, OAAM proceeds to the second column.
Some of the columns have scores to generate if the conditions are met because the situation appears suspicious, for example in the second column, if the Flash cookie did not match, but the browser cookie matches. OAAM identifies the device by browser fingerprint, but does not understand why the device does not have Flash present, so OAAM generates a score. In this instance, the situation appears suspicious because Flash is not present. In any other policies downstream that generate scores that score will be factored in (the score will be used in post-authentication or challenge). This is called device risk gradient, a pre-conditions in rules. You cannot use the score in the Device Identification because the score is the result of this checkpoint.
E.2.3 Native Integration and Device ID
In addition to delivering the rules result, the Rules Engine can return a device ID, an internal Oracle Adaptive Access Manager identifier for the device used for the login session.
Note:
The most recent OAAM Sample Application that illustrates API integration can be downloaded from the Oracle Technology Network at:.NET Sample Code to Obtain the Device ID
The following sample code illustrates how the device ID is obtained:
VCryptRulesResult rulesResult = proxy.processRules ...);
If (!rulesResult.Response.IsSuccess) {
BharosaTrace.Error("Error running rules " + rulesResult.Response.ErrorMessage);
}
Long deviceId = rulesResult.DeviceId;
Important:
The code shown assumes that:-
You are using Oracle Adaptive Access Manager 10.1.4.5 or above
-
You have set the property
bharosa.tracker.send.deviceIdto true in Oracle Adaptive Access Manager:bharosa.tracker.send.deviceId=true
Java Sample Code to Obtain the Device ID
The following code sample illustrates how to obtain a device ID:
VCryptRulesResult rulesResult = new
VCryptRulesEngineImpl().processRules(<params..>);
If (!rulesResult.getVCryptResponse().isSuccess()) {
Logger.error("Error running rules " +
rulesResult.getVCryptResponse().getErrorMessage());
}
Long deviceId = rulesResult.getDeviceId();
When obtaining a device ID, ensure that:
-
The Oracle Adaptive Access Manager version is 10.1.4.5 or above
-
The property
bharosa.tracker.send.devideIdis set to true, so the device ID can be captured:bharosa.tracker.send.deviceId=true
E.2.4 Extending Device Identification
For most typical deployments, the out-of-the-box device identification satisfies client requirements, but you may be looking to have the ability to extend that process and include additional information in the fingerprint. Out-of-the-box device identification uses data from the browser and OAAM Flash movie. The following are the typical scenarios when you could consider extending device identification:
-
The OAAM Flash movie cannot be used to obtain client details as the client side browser does not support Flash. For example, iPhone, iPad, and so on.
-
There is a need to extract stronger device identification data from the client using a non-Flash extension that can run inside the browser
Starting from the 11.1.1.5 release of OAAM a framework exists that you can use to extend device identification and implement in both native integrations, and non-native integrations. The framework is separated into the client side extension, and the OAAM server device identification extension.
E.2.4.1 Prerequisites
The prerequisites for performing tasks to extend device identification in Oracle Adaptive Access Manager are provided in the following list:
-
You have knowledge of Java programming language since a custom device identification extension must be developed using Java.
-
You have determined what pieces of information about client device must be collected and what technology will be used to collect that. Typical technologies you can consider are applets, JavaScript, and so on.
-
You understand the process of developing and deploying the OAAM Extensions Shared Library.
For information on the using the OAAM Extensions Shared Library, see "Using the OAAM Extensions Shared Library to Customize OAAM" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
E.2.4.2 Developing a Custom Device Identification Extension
The custom device identification extension is software that extends the out-of-the-box device identification provided by Oracle Adaptive Access Manager.
E.2.4.2.1 Implement the Client Side Extension
Implementing the client side extension that can run in the client browser involves coding the extension using the appropriate technology.
The client side extension can be implemented in any technology if it can satisfy the following requirements:
-
It can run on the client side browser without altering the web page. It is invisible and does not alter user control flow.
The technology chosen to implement the client side extension must run in the context of the user's browser. Technologies such as Flash, JavaScript, Java Applets are typical choices.
-
It can communicate with OAAM Server and post data using the HTTP protocol.
The fingerprint data and secure cookie must be sent to the OAAM server if the standard integration is using the HTTP POST method.
-
Very Important: It can use the existing OAAM "HTTP Session" while posting the data. This is very important for the device identification to work properly.
The data sent to the server must be sent in the context of the user's session in order for the fingerprinting data to be associated with the user's login. The presence of a valid JSESSIONID is required for this to work.
-
The list of data/values that are collected by the extension uniquely identifies a client device.
In general the fingerprints collected by OAAM should be as unique as possible given the data constraints imposed by the user's device. When extending device identification, this is the best opportunity to gather additional data to uniquely identify a user's device.
-
The extension can retrieve and store a cookie equivalent on the client computer.
The concept of a secure cookie is core to the device fingerprinting process. The device identification must support the capability to store and retrieve the value provided to the extension by the OAAM server.
-
The extension can submit the following parameters to flashFingerprint.do URL on OAAM Server using HTTP Post:
Note: This requirement is only relevant when using the standard OAAM implementation.
Table E-4 Parameters to flashFingerprint.do URL
Name of the parameter Description client
Name of the client extension. A constant value that indicates the extension type.
fp
Concatenated string that has all the name-value pairs that identify the client side. Name-value pairs is concatenated using "&" and name-value is separated using "=".
Example: If os_name and os_version are collected by extension then the fp string value looks like "os_name=windows&os_version=7
<as determined by the implementation>
Send the cookie equivalent value stored/maintained by the client extension.
E.2.4.2.2 Add Properties Related to Custom Device Identification Extension to OAAM Extensions Shared Library
The static values are related to the properties that need to be defined within the OAAM Server to make it aware of the new extension.
For information on the using the OAAM Extensions Shared Library, see "Using the OAAM Extensions Shared Library to Customize OAAM" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
To create custom fingerprint types, proceed as follows:
-
Open the
oaam_custom.propertiesfile of the OAAM Extensions Shared Library war. -
Add the following properties as enum element to
vcrypt.fingerprint.type.enum.Note: Replace
<extension-name>with a string that represents your extension. Do not use the strings 'flash', 'browser' as they are already used by the OAAM product.Table E-5 vcrypt.fingerprint.type.enum elements
Property Name Value Description vcrypt.fingerprint.type.enum.<extension-name>
Integer value above 100
vcrypt.fingerprint.type.enum. <extension-name>.name
Name that represents the extension
vcrypt.fingerprint.type.enum. <extension-name>.description
Description of the extension
vcrypt.fingerprint.type.enum. <extension-name>.processor
Fully qualified java class name of the processor class that implements device identification logic on the server side. See the next section for details on how to implement this class.
vcrypt.fingerprint.type.enum. <extension-name>.header_list
Comma separated list of data that is collected by the client side extension.
vcrypt.fingerprint.type.enum. <extension-name>.header_name_nv
Comma separated list of data and readable name of those data.
vcrypt.fingerprint.type.enum. <extension-name>. header_value_nv
Comma separated list of mappings of value to readable string of those values
bharosa.uio.default.device.identification.scheme
<extension-name>
Note: This is very important for OAAM to use the custom device identification
-
Set the fingerprint scheme to the fingerprint type enum element ID/key.
For example:
bharosa.uio.default.device.identification.scheme=flash
The following Flash fingerprint type is shown as an example.
vcrypt.fingerprint.type.enum.flash=2
vcrypt.fingerprint.type.enum.flash.name=Flash
vcrypt.fingerprint.type.enum.flash.description=Flash
vcrypt.fingerprint.type.enum.flash.processor=
com.bharosa.uio.processor.device.FlashDeviceIdentificationProcessor
vcrypt.fingerprint.type.enum.flash.header_list=
avd,acc,a,ae,ev,ime,mp3,pr,sb,sp,sa,sv,tls,ve,deb,l,lfd,m,os,ar,pt,col,dp,r,v
vcrypt.fingerprint.type.enum.flash.search_list=deb,l,os,v
vcrypt.fingerprint.type.enum.flash.result_list=deb,l,os,v
vcrypt.fingerprint.type.enum.flash.header_name_nv=
avd,Audio/Video disabled by user,acc,Has accessibility,
a,Has audio,ae,Had audio encoder,ev,Embedded video,
ime, Has input method editor (IME) installed,
mp3, Has MP3, pr, Supports printer,
sb, Supports screen broadcast applications,
sp, Supports playback on screen broadcast applications,
sa, Supports streaming audio,
sv, Supports streaming video, tls, Supports native SSL,
ve, Contains video encoder, deb, Debug version, l, Language, lfd,
Is local file read disabled, m, Manufacturer, os, Operating System,
ar, Aspect ratio of screen, pt, Player type, col, Is screen color,
dp, Dots-per-inch (DPI), r, Screen resolution, v, Flash version
#vcrypt.fingerprint.type.enum.flash.header_value_nv=t,true,f,false
vcrypt.fingerprint.type.enum.flash.header_value_nv=
t,true,f,false,en,English,es,Spanish,de,German,it,Italian,ja,Japanese,
fr,French,ko,Korean,zh,Chinese,ar,Arabic,cs,Czech,
da,Danish,nl,Dutch,fi,Finnish,el,Greek,iw,Hebrew,hu,Hungarian,
no,Norwegian,pl,Polish,pt,Portuguese,ro,Romanian,ru,Russian,
sk,Slovak,sv,Swedish,th,Thai,tr,Turkish,BR,Brazil
E.2.4.2.3 Extend/Implement the DeviceIdentification Extension Class
Extend the DeviceIdentification extension class: com.bharosa.uio.processor.device.DeviceIdentificationProcessorBase and implement the methods documented in this section. The server-side extension extends all of the required methods.
E.2.4.2.4 getPlugInHTML
public String getPlugInHTML();
Implementation should return a valid extension HTML that can be embedded into login pages. The HTML should take care of handling exceptions like if the supporting technology is not available or disabled on the client.
An example of extension HTML is shown as follows:
<applet alt="Browser has Java disabled" name="OAAMDeviceIdentifier" width="0"
height="0"
code="com.bharosa.uio.processor.device.SampleAppletDeviceIdentifierClient"
codebase="applet"
archive="oaam_device_sample_applet.jar">
</applet>
Note: This method is called by the oaamLoginPage.jsp when the user navigates to login page.
E.2.4.2.5 getFingerPrint
public String getFingerPrint();
This method should implement logic that creates a unique fingerprint that identifies the client device using the data sent by the extension.
This method is called when the client side extension submits device identification data to OAAM Server.
This method should call the UIOContext.getCurrentInstance().getRequest to obtain the handle to the HttpServletRequest object to read the data sent by the client extension.
As mentioned in the previous section, the client extension sends a list of data points as a single string as the value of "fp" request parameter.
This class should "tokenize" this string to determine the list of datapoints and their values.
E.2.4.2.6 getDigitalCookie
public String getDigitalCookie();
Implementation should return the Flash cookie sent by the client extension. It is the responsibility of the client and server to designate an Http parameter that indicates the Flash cookie.
This method should call the UIOContext.getCurrentInstance().getRequest to obtain the handle to the HttpServletRequest object to read the data sent by the client extension.
E.2.4.3 Overview of Interactions
Following is the overview of how the device identification extension works and interacts with OAAM Server:
-
The user navigates to the OAAM user login page on the OAAM Server.
-
The OAAM Server uses the device identification configuration and appropriately instantiates the device identification extension class. It then asks the extension class for the HTML that must be embedded in the user login page. The OAAM Server returns the user login page with the device identification extension HTML.
-
Once the login page is rendered, the client based extension is activated and collects information about the device.
-
The client extension then submits the collected data to the device identification URL on the OAAM Server.
-
The OAAM Server then calls the device identification extension to obtain the fingerprint based on collected data from the client extension.
-
It then checks if the fingerprint corresponds to an existing device. If not, then it creates a new device and associates the fingerprint to that device.
-
The OAAM Server then calls the device identification extension to obtain the Flash cookie. If the Flash cookie does not exist then a new one is created.
-
The Flash cookie is returned to the client extension so that it is stored on the client system.
-
Once the User ID is entered, using the Flash cookie or browser cookie or both, the user request is associated to the device.
-
After the authentication (success/failure), the user request is updated with the authentication result.
-
If the same device is used for future logins, you can use the Flash cookie to look up the device without having to fingerprint.
E.2.4.4 Compile, Assemble and Deploy
Compile the custom device identification extension class and assemble the OAAM Extensions Shared library.
For information on the using the OAAM Extensions Shared Library, see "Using the OAAM Extensions Shared Library to Customize OAAM" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
E.2.4.5 Important Note About Implementing the Extension
When implementing the extension, keep the following points in mind:
-
Make sure the custom device identification class outputs a valid HTML required to activate the client side extension.
-
Make sure the client side extension posts the data to OAAM Server using the "existing HTTP Session".
E.3 Use Cases
| Use Case | Description |
|---|---|
| Both secure and Flash cookies are enabled. | Both secure and Flash cookies are missing. Flash request came through successfully. |
| Both secure and Flash cookies are disabled. | User has not used device from this location before |
| Secure cookies is enabled and Flash is disabled | Both secure and Flash cookies are missing. Also, the Flash request didn't come through successfully. |
| Secure cookie is disabled and Flash is enabled | Both secure and Flash cookies are missing. But Flash request came through successfully. |
| Use Case | Description |
|---|---|
| Both secure and Flash cookies are enabled. | Both secure and Flash cookie came. |
| Both secure and Flash cookies are disabled. | Both secure and Flash cookies are missing. Also, the Flash request didn't come through successfully. |
| Secure cookie is enabled and Flash is disabled | Only secure cookie came through successfully. |
| Secure cookie is disabled and Flash is enabled | Only Flash cookie came through successfully. |
| Use Case | Description |
|---|---|
| Browser upgrade. | Browser character mismatched |
| Device upgrade. | Flash data mismatched |
| Browser and Device upgrade. | Both browser and Flash data mismatch |
| Used different browser. Secure cookie is missing. | Secure cookie is missing. Browser characteristics are mismatch. Flash cookie is matching. Flash data is a match (except browser). |
| User different browser. Both cookie and browser characteristics mismatch. | Secure cookie is mismatch. Browser characteristics are mismatch. Flash cookie is matching. Flash data is a match (except browser). |
| Secure cookie out of sync and Flash is in sync. | Secure cookie is mismatch, but belonged to the same device. |
| Flash cookie out of sync and secure cookie is sync. | Flash cookie is a mismatch, but belonged to the same device. |
| Both secure cookie and Flash are out of sync. | Both the cookies are mismatch, but they belonged to the same device |
These use cases help to define Oracle Adaptive Access Manager's device risk gradient. The device risk gradient specifies the certainty of the device being identified. This is a standard pre-condition in all device type rules. For example, a device risk gradient of 0 is an exact match whereas a device gradient of 500 is a device with some unexpected by plausible variations from previous sessions, and a score of 1000 a device that has only minimal matching data to make an identification.
E.4 Device Fingerprinting Troubleshooting
The following is the sort of information to collect to aid you in troubleshooting device fingerprinting issues.
-
Does the use case as described seem to be OAAM functionality as designed?
-
Are the device fingerprinting polices loaded?
-
If this is a JAVA/.Net/SOAP integration, are API calls for device fingerprinting the same or similar to the sequence in the Sample application and documentation?
-
If this is a JAVA/.Net/SOAP integration, have all patches containing known bug fixes for device fingerprinting been applied?
-
Review the exact sequences and data.
To capture data execute the following SQL command:
select * from VCRYPT_TRACKER_USERNODE_LOGS where USER_LOGIN_ID=loginId and CREATE_TIME > beginTime and CREATE_TIME < endTime;
-
Note the browser and client application and settings of the end point machines involved. Are cookies enabled? Is Flash installed?
-
Try to determine if there was any unaccounted for use case steps such as an operating system or browser upgrade.
-
Collect HTTP header trace; are cookies and Flash object missing when they are expected?
E.5 Device Identification and Fingerprinting Frequently Asked Questions
This section contains answers to commonly-asked questions about the device identification and fingerprinting.
-
Question: Does the Device ID change when accessing Mozilla Firefox and Internet Explorer from the same machine?
Answer: The Device ID should be the same.
-
Question: Device ID is built based on many factors. What are the factors I want to change to obtain another Device ID?
Answer: Use different cookies or clean all the cookies in the browser that are set by OAAM.
-
Question: How do policies make decisions to first look at the top level and see if it should look more deeply for the Device ID?
Answer: There are decision trees in the Device ID policy to see if the device is a match based on cookies. If the cookies match, deep analysis is not performed. If the cookies do not match, then the policies check each element that the Flash or browser data provides and see if there is match of some percentage and which ones must match, and so on.
-
Question: What decides when to use same Device ID or create a new Device ID?
Answer: If the device is matched positively either by cookie or by analysis, then OAAM uses the same Device ID. Otherwise, if none of the devices OAAM has matches that profile, then OAAM creates another Device ID. This is decided in the Device ID policy.
-
Question: What occurs if I disable all the Device ID rules? Would Device ID be 0?
Answer: The same Device ID is used for all devices.
-
Question: What occurs if I disable all the Device ID rules? What is the default value?
Answer: This depends on the current sequence number of the device table, which usually starts at 1 for an empty database.
-
Question: How do you build a fingerprint based on a new client?
Answer: A fingerprint is made up of
name=valuepairs. For a new client, you need to provide the expected names of attributes in the fingerprint enum. Then OAAM looks for those names in the client data and fingerprints are generated when a unique combination of values is seen for the first time for all the values of the attributes specified by names. -
Question: What if there is a client that is non-browser and if you want to create a brand new client, what are the rules and conditions we can use to evaluate these values?
Answer: See the answer above. Fingerprint building does not depend on whether data is coming from a browser or not. Oracle Mobile and Social is a good example of a non-browser based fingerprint.
-
Question: The rules work off of configuration. Based on the configuration, what defines a fingerprint, how much policy work must be done to add a new device type?
Answer: If a new device type is to be defined, it needs to be added to the device type enum, and then a new Device ID policy must be created for it.
For example, if your new device type is "ATM machine," you will need to define a new fingerprint type for it, and then provide that data (
name=value) as digital data, and write a Device ID policy that defines how a new unique device can be identified. You will need to add known headers information to this new device type enum. Refer to existing device types as an example. -
Question: How do you set up a new fingerprint type if you have a new custom application? Do you have to set up separate parameters for that?
Answer: To set up a new fingerprint, define a new fingerprint type using the
fingerprint.type.enumenum and add values to it. Each parameter of that application will be a new attribute of that new fingerprint type.When data comes in as part of header that has parameter_name = some_value, OAAM starts building a fingerprint when OAAM sees a unique combination.
-
Question: OAAM APIs for creating sessions take fingerprint data as one of the parameters. What is the API that lets you pass on the parameters?
Answer:
createOAAMSession(….) is the API. For more information on this API, see the Oracle Fusion Middleware Java API Reference for Oracle Adaptive Access Manager. -
Question: How does introducing the session factor prevent against a stolen secure cookie scenario? Does OAAM have to keep the last Session ID of each device per user on the backend adaptive store?
Answer: You could steal the cookie, but it is a "one-time" use cookie. So there are two options; either:
-
The real user has already used his cookie once and the system has updated (changed, used up) the stale cookie so it is no good, or
-
The fraudster uses the cookie before the real user. It is certainly possible that the hacker could beat the user to use the one-time cookie but the device fingerprint would be different for the rogue user and they would then have to answer the user's KBA questions
On the possibility that the fraudster does use the cookie first and it succeeds (this might not even be possible), then the real user can receive a warning that their cookie is now stale, and that may tip them off that something is wrong. The real user can then change their password, and so on.
-
-
Question: Can you provide us with a device fingerprinting table with the a set of combinations and their expected behavior?
Answer: The device table is
Vcrypt_Tracker_Node.There are fingerprint columns in this table with Digital Fingerprint ID (Flash) and Fingerprint ID (browser). In the
VCrypt_Fingerprinttable, you will see the values against the fingerprint IDs that are given in the device table. For example, the device table may have a value of 23 for the fingerprint. In theV_Fprintstable, you will find the data and hash values of the data that was captured for that fingerprint, if you look for row that matchesfprint_id = 23. -
Question: How do Device ID polices behave?
Answer: Device ID policies behave the same as other policies. Based on some rules there are a set of actions that the Device ID policies emit. Those action decide if the new device or existing device is assigned for the session coming in.
-
Question: The default OAAM Device ID Policy has rules to check if the cookie is disabled for the device. Based on the Cookie Disabled rule, OAAM looks at the last 5 devices. If the user is always passing an empty cookie, from the 6th login, the old Device ID is reused based on this rule. Is the number of devices looked at configurable?
Answer: Configure the value using the
vcrypt.tracker.rule.cookiePatternCheck.previousAttemptsToCheckproperty. The value must be between 2 and 98, both inclusive. -
Question: How would device fingerprinting be performed (with the standard device identification policy) with NULL secure/Flash cookie?
Answer: It is performed based on the browser cookie and header if the Flash cookie is not present.
-
Question: Both Flash and Javascript fingerprinting are enabled by default where Flash is give higher priority. Is there a property that you can use to change the priority?
Answer: You cannot change priority. Flash is given priority since it contains more data.
-
Question: Are there properties to disable and enable Flash and Javascript fingerprinting?
Answer: The properties are:
bharosa.uio.default.flash.fingerprint.enable bharosa.uio.default.javascript.fingerprint.enable
-
Question: What is the Javascript file that is used to perform Javascript fingerprinting?
Answer:
js/oaam_fp.jsis the Javascript file that is included in the page in order to perform Javascript fingerprinting. -
Question: What is the Flash cookie name?
Answer: Flash uses the Flash Shared Object which is stored against the domain/webapp by Flash. The key for the value is
vc. -
Question: What cookie is used by the JavaScript fingerprint?
Answer: JavaScript fingerprint uses HTML 5 stored object as the cookie and uses the key
jc. -
Question: What is the one time name cookie?
Answer: One time name cookie is
ora_oaam_vsc. -
Question: What is monitor data enum used for?
vcrypt.fingerprint.type.enum.monitordata=3 vcrypt.fingerprint.type.enum.monitordata.name=MonitorData vcrypt.fingerprint.type.enum.monitordata.description=Monitor Data
Answer: The monitor data enum controls the data captured and displayed by the OAAM Admin dashboard for metrics.
-
Question: What is the HTTP cookie name controlled by?
Answer: The HTTP cookie name is controlled by the property
oaam.secure.cookie.name. This is used within the OAAM APIs.
E.5.1 Custom Attribute Use Cases
The following are use cases that illustrate how custom fingerprinting is deployed and how it behaves.
E.5.1.1 Custom Attribute Available
Mike is a web application developer at Acme Corp. He has developed a browser extension which captures the MAC address of an end user's machine and sends it to the OAAM server as part of the browser/server interaction. If OAAM device fingerprinting is set up to use the Media Access Control address (MAC address) as the digital fingerprint and the end user has the extension installed, then the OAAM Administration Console displays the MAC Address labeled as the Digital Fingerprint in the detail pages.
E.5.1.2 Custom Attribute Not Available and Flash Not Installed
In the Acme Corporation deployment, if the end user does not have the extension installed and he does not have Flash installed, OAAM device fingerprinting uses the secure cookie and browser data alone to fingerprint the device. The OAAM Administration Console does not display anything as the Digital Fingerprint in the detail pages.
E.5.1.3 Custom Attribute Search
Jeff is a security analyst at Acme Corp. He opens the Search Transactions page and configures search filters to locate any employee profile access transactions from a device with the specific Media Access Control address (MAC address) and from New York in the last 24 hours. The query returns 25 transactions.
E.5.1.4 Flash cookie Cleared
Oracle Adaptive Access Manager does not solely rely on one element to develop the device fingerprint. If the Flash cookie is cleared, Oracle Adaptive Access Manager still has other information to use in identifying the device. OAAM only supports Flash Shared Object standard, but custom client can also be used. OAAM can uniquely identify the devices, even if the digital fingerprint have changed or altered. OAAM needs some client fingerprint device to identify the device being used, in case, all of the fingerprints are missing (browser, Flash or applet).
E.5.1.5 Secure Cookies Deleted?
Oracle Adaptive Access Manager's fingerprinting technology does not solely rely on one element. Oracle Adaptive Access Manager uses dozens of attributes to recognize and fingerprint the device you typically use to login, providing greater "coverage" for an institution's customer base. If secure cookies are missing or disabled, Oracle Adaptive Access Manager uses other elements such as Flash movies and HTTP headers for device identification.