This chapter provides an in-depth understanding of Oracle Adaptive Access Manager device fingerprinting and identification technology. Depending on the specific situation Oracle Adaptive Access Manager can utilize combinations of the device attributes to fingerprint and identify a device being used in an access request or transaction. Device fingerprinting data may be gathered from multiple sources including secure cookie, flash shared object, user agent string, custom agent, mobile application, browser header data. 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. This is especially important in large consumer facing deployments.
A device is identified using proprietary logic and a set of specialized policies to process available data and arrive at identification. This chapter covers the important fingerprinting and identification concepts, technology and use cases customers need to understand when deploying OAAM.
Out of the box, OAAM supports browser, mobile application and digital fingerprints. Digital can be either flash or one of the custom types defined by the user. OAAM provides the framework so users can use other fingerprints if needed.
Device fingerprinting and identification is one of the many attributes OAAM utilizes to assess the risk of an access request or transaction. 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.
This section provides information about Device Fingerprinting concepts that are related to device identification.
Oracle Adaptive Access Manager device fingerprinting is a capability used to recognize the devices a user utilizes to login and conduct transactions, whether it is a desktop computer, laptop computer, mobile device or other web enabled device. Oracle Adaptive Access Manager can use any combination of standard attributes, including browser user agent string data, proprietary OTS (One Time Secure) cookies, Flash shared objects, mobile application data, custom client data and advanced "Auto-Learning" device identification logic, to identify a device. The Oracle Adaptive Access Managers patent-pending fingerprinting process is not vulnerable to "replay attacks" and does not place any logic on the client side where it may be vulnerable to exploit. The device identification is not merely a static list of attributes but is instead dynamic capture, evaluation and profiling of the specific combinations of attributes available in each access request or transaction.
When an end user is accessing a protected application via a web browser OAAM performs browser based fingerprinting. In the majority of deployments this is the predominant use case. Browser based fingerprinting and identification utilizes browser user agent string data as well as secure cookie and Flash shared object data if available. The fingerprinting functions the same for desktop/laptop PCs as well as mobile devices and smart phones that run full function browsers. By design each browser will be given its own unique device identifier. The identification logic and policies are designed to deal with scenarios where only a subset of the data is available. For example, 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 utilized previously and locations the user has accessed from in the past.
OAAM device fingerprinting can be extended to allow development of custom clients if desired. The digital fingerprint that accepts Flash shared object data in the standard browser access use case can instead accept data from a custom client. 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.
Oracle Adaptive Access Manager is capable of fingerprinting, identifying and tracking mobile devices even when access is not via a browser. 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. OAAM has unique handling for mobile devices allowing for a strong binding between user and device. Mobile cookies are listed in the following table.
The process of identifying the device and assigning a "Device ID" to involves three stages:
Data Gathering
Data Processing
Data Storage
Oracle Adaptive Access Manager captures information about the devices that a user utilizes when accessing protected applications. This information consists of many different data points gathered through a variety of means. The data collected is encoded into a unique fingerprint for the device.
Once this data is gathered, the OAAM Server must process the device fingerprint data and determine if this device has ever been seen before. Device fingerprinting uses data from and about the device and browser sessions to assess the risk of doing business with the person utilizing that device. The more data collected, the better OAAM can assess the risk.
Once a device has been given an ID, new rotating cookie values are generated and set. If the device identification scheme chosen is flash, the secure cookie is set as an HTTP cookie, and the digital cookie is set as a Flash Local Shared Objects (LSO) by the flash movie. These two values are the only values stored on a user's computer during the device identification process.
A device is generally fingerprinted as soon as it logs in to a protected application, prior to any authentication attempt. 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.
Generally the login page is embedded with a few lines of static HTML code. 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.
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.
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.
There are two categories of data: secure and digital. Each of these categories have 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 cookie) and the other is the digital cookie (also known as the flash cookie).
Secure data is gathered from the user's browser. This data includes the user-agent string, and an HTTP cookie value. The User-Agent is used as the secure fingerprint. The HTTP cookie value is a unique one-time use cookie that is set every time a user logs in. This cookie value is retrieved from the user's browser upon login.
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.
Secure Cookie and Browser Characteristics
Secure browser cookies are one of the attributes used to identify the device. The secure cookie is only good for one use and is replaced every time the device is fingerprinted. 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 table below.
| OS/Browser | Characteristics |
|---|---|
| Operating System |
|
| Browser |
|
| Locale |
|
Flash Shared Object and Device Characteristics
Similar to Secure Cookie, Oracle Adaptive Access Manager can utilize 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, this adds additional granularity to the device ID. For a full list of the characteristics, refer to the table below.
| Hardware/Software | Characteristics |
|---|---|
| System |
|
| Settings |
|
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.
Some of the attributes utilized for the analysis are listed below:
| IP Details | Description |
|---|---|
|
IP Address |
Address mapped to location |
|
City Name |
Geographic name of the city. |
|
State Name |
Geographic name of the state. |
|
Country Name |
Geographic name of the country. |
|
Connection Speed |
Internet connection speeds or bandwidths (high, medium, low). |
|
Connection Type |
Describes the data connection between the device or LAN and the internet. See the Connection Type mapping. |
|
IP Routing Type |
Tells how the user is routed to the internet. |
|
Carrier Name |
The name of the entity that manages the ASN entry. |
|
ASN |
Globally unique number assigned to a network or group of networks that is managed by a single entity. |
|
Top-level Domain |
The top-level domain of the URL. For example, .com in www.example.com. This is mapped through the Quova reference file. |
|
Second-level Domain |
The second-level domain of the URL |
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, OS, 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 as well as run risk evaluations.
Oracle Adaptive Access Manager utilizes 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 out of the box for all customer deployments. Given this Oracle does not recommend or support alterations to the device identification policies.
The following list of policies are utilized for device identification and should therefore never be deleted or altered in any way.
OAAM Device ID Policy
OAAM System Deep Analysis Flash Policy
OAAM System Deep Analysis No Flash Policy
OAAM Mobile Device Identification Policy (mainly used for Oracle Access Management Mobile and Social integrations)
Some sample scenarios to illustrate expected device identification behavior.
The secure cookie stored by the 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.
If OAAM is able to find this cookie in the browser, it compares this cookie with an expected value. If the two values match, it means 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 is ignored. If the cookie is not present in the browser, it is a new request. In any case this cookie is discarded and a new cookie is generated.
From the OAAM server logs it should be apparent that the application is generating the secure cookie value successfully. This can also be verified by HTTP headers. Note that the OAAM cookie is necessary for OAAM to track the devices. If the OAAM cookies are not set on the browser, a new device ID will be generated until OAAM determines by other means that the device is the same.
No Cookie, No Flash Shared Object, Browser Fingerprint, User ID and IP Match
This scenario shows a what happens 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 the after three successful fingerprints the device can be recognized as a consistent device ID.
| Ses | User | IP | User Agent | Secure Cookie | Digital Cookie | Digital 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 |
| 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.
Out of the box fingerprint type 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 finger print 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
OAAM allows you to display and search for custom fingerprinting data generated by a custom device identification applet along with the out of the box available fingerprint data in various details tabs and pages. Custom fingerprint information is available for native Mobile and applet.
You can set up custom fingerprinting at the time of deployment. See the "Extending Device Identification" in the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager for setup instructions.
The following detail pages display custom fingerprint information:
The Summary tab of the User Details page provides fingerprint data in the Profile Data section.
To see fingerprint information from the User Details Summary page:
Click the User ID or User Name link from the Sessions page for a valid user.
The User Details page is displayed. For information, see Section 6.11, "User Details Page."
View the fingerprint information in the User Details Summary tab.
This tab lists fingerprints created for the user during login. For information, refer to Section 6.11.1, "User Details: Summary Tab."
The Fingerprint Data ID numbers shown on this panel is the same as those shown in the Fingerprint Data tab. The difference between Fingerprint Data and the Fingerprint Data tab is that the tab shows the ID numbers and other information such as the browser, locale, and so on.
The Fingerprint Data tab in the User, Device, Alert, Location, and IP details pages provides custom fingerprint data as filters and search results along with the available out of the box fingerprint information.
The Add Fields filter items to choose from depend on the fingerprint type selected. For example, if the you select Browser and Flash in the Fingerprint Type field, then the Add fields only list the search fields relevant to those fingerprint types. By default, the fingerprint type is set to the browser.
The list in the drop down and the results column for each fingerprint type is determined at deployment time. Not all parameters from a fingerprint type are available for the search.
The Fingerprint Details Summary tab shows the custom fingerprinting type and parameters along with available out of the box fingerprint information.
The Session Details Summary shows additional information about the custom fingerprinting type along with available out of the box fingerprint information. Browser type and Operating System are always displayed. Flash and Browser fingerprint ID are displayed.
The Digital Fingerprint Type field in the Session Details Summary tab displays the type of digital fingerprint used to collect the digital fingerprint. If custom fingerprinting is used, it shows the custom fingerprinting type name.
The Device Details Summary tab shows the hierarchical view of the browser and digital fingerprint data information including the custom fingerprinting data.
Browser fingerprint is supported by default. OAAM shows one custom fingerprint.
If a device has Flash as the custom fingerprint, then in addition to the browser fingerprint, the digital fingerprint shows flash fingerprint details such as operating system type, browser type, Player Type, Has audio, Has mp3, Supports streaming audio, and so on. Flash fingerprint details and parameters are not displayed if Flash is not associated with the device.
If the digital fingerprint changes for a particular device, the device ID is retained and a new device will not be created because the secure cookie is the same as the previous request, so it continues to be used as the existing Device ID.
The following are use cases that illustrate how custom fingerprinting is deployed and how it behaves.
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 utilize 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.
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 utilizes 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.
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.
Oracle Adaptive Access Manager does not solely rely on one element to develop the "device fingerprint". If the digital cookie is cleared, Oracle Adaptive Access Manager still has other information to use in identifying the device. OAAM only supports FSO out of the box, but custom client can also be used. OAAM is able to 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).
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 movie and HTTP headers for device identification.
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?