Adaptive Access and Fraud Prevention

Adaptive Access and Fraud Prevention

Adaptive Access delivers risk-aware, context-driven access management. The Adaptive Access service is built on a scalable, fault-tolerant, multi-tier deployment architecture including the following components:

• Adaptive Access Administration for managing the Adaptive Access Server. 
• Adaptive Access Server consisting of three layers: Presentation leveraging the strong authenticator functionality using the interfaces provided by the business layer to access its services; Business Logic containing the core application logic that implements the risk-analyzing engine; and Data Access connecting the environment to the supported relational database systems. 

Adaptive Access supports the following functionality:

•  Real-time and batch risk analytics to address fraud and misuse across multiple channels of access (real-time evaluation of multiple data types helps stop fraud as it occurs). 
•  Device fingerprinting, real-time behavioral profiling and risk analytics harnessed across both web and mobile channels. 
• Risk-based authentication methods including knowledge-based authentication (KBA) challenge infrastructure with server-generated one-time passwords (OTP). 
• Standard integration with Oracle Identity Management (Identity Governance and Access Management). 
•  Leverages Access Management’s core services and enhances its authentication methods. 
• Key support for mobile devices using Access Management’s Mobile and Social service.

Adaptive Access includes the following features:

• Auto learning: A mixture of real-time and predictive auto-learning technology is used to profile behavior and detect anomalies (recognize high risk activity and proactively take actions to prevent fraud and misuse). Auto-learning automates risk evaluations and keeps track of changing behaviors. 
• Configurable risk engine: Flexible architecture supporting three methods of risk evaluation that work concurrently to evaluate risk in real-time: configurable rules, real-time behavioral profiling, and predictive analysis. 
• Virtual authentication devices: Server-driven services (i.e., no client-side software or logic that can be compromised by key-loggers and other common malware – personalized images and phrases are known only to the server and the end user). The security of the user credentials during entry is ensured by not capturing or transmitting the actual credential of the end user (strong authentication). Virtual authentication devices include TextPad, a personalized device for entering a password or PIN using a regular keyboard (defends against phishing); PinPad, a lightweight authentication device for entering a numeric PIN; QuestionPad, a personalized device for entering answers to challenge questions using a regular keyboard; and KeyPad, a personalized graphics keyboard used to enter alphanumeric and special characters (passwords and other sensitive data such as credit card numbers). 
• Device fingerprinting: Designed to support desktops, laptops, mobile devices or other web-enabled devices, providing standard browser-based access and mobile browser-based access without additional client software. Adaptive Access device fingerprinting integrates with the Access Management Mobile and Social SDK and REST interface, and monitors multiple device attributes. 
• Knowledge-based authentication (KBA): Secondary authentication in the form of KBA questions presented after successful primary authentication. The KBA infrastructure handles registration, answers, and the challenge of questions. Adaptive Access Management's rules engine and organizational policies are responsible for determining if it is appropriate to use challenge questions to authenticate the customer. 
• Answer Logic: Increases the usability of KBA questions by accepting answers that are fundamentally correct but may contain a small typo, abbreviation, or misspelling. 
•  OTP Anywhere: Risk-based challenge mechanism consisting of a server-generated one-time password (OTP) delivered to an end user via SMS, email, or instant messaging. The challenge processor framework supports custom risk-based challenge solutions combining third-party authentication products with Adaptive Access realtime risk evaluations. 
•  Mobile access security: Security policies available with Adaptive Access can dynamically adjust when user access originates from a mobile device. IP geo-location velocity rules behave differently if the access request is via a cellular connection or Wi-Fi. When used with Mobile and Social, Adaptive Access provides device fingerprinting, device registration, risk-based challenge mechanisms, and lost and stolen device. 
• Universal Risk Snapshot: Allows an administrator to instantly save a full copy of all Adaptive Access policies, dependent services, and configurations for backup, disaster recovery, and migration. 
• Fraud investigation: Forensic interface for security analysts and compliance officers allowing agents to save “case” information in a repository. 
• Adaptive policy management: Policies and rules are designed to handle patterns or practices, or specific activities. The administrator can define when rules should be executed, the criteria used to detect various scenarios, the group to evaluate, and the appropriate actions to take when suspicious activity is detected. 

Adaptive Authentication with Oracle Mobile Authenticator Oracle 

Mobile Authenticator is a token-based authentication mobile app available for download from the Apple Store and Google Play. Oracle Mobile Authenticator enables organizations to cost-effectively provide strong authentication and prevent unauthorized access to vital company and customer data by generating a time-based security code or one-touch notification enabling soft-token authentication. As part of the Oracle Access Management platform, Oracle Mobile Authenticator leverages adaptive, dynamic authentication and strong authentication services.

For Technical Implementation please refer my other blogs.

Identity Federation

Identity Federation :- The Identity Federation service is an integral part of the Oracle Access Management platform, leveraging the authentication core services  such as credential collectors and authentication plug-ins.
Identity Federation services can protect both on-premise and cloud resources leveraging several industry standards:

•  SAML-based federation (authentication, attribute sharing)
•  OpenID-based federation (delegated authentication) 
•  OAuth-based federation (delegated authorization) 
•  Social-identity-based federation (redirected authentication) 
•  Form-fill-based federation (Access Portal) 

 Identity Federation services are enabled from the central access management console,

Identity Federation services are seamlessly weaved into the authentication and authorization process.

Identity Federation leverages the Access Management platform’s shared services.

SAML-Based Federation :-The Security Assertion Markup Language (SAML) is an open framework for sharing security information on the Internet through XML documents.
SAML was originally designed to address the following requirements:

•  Limitations of web browser cookies to a single domain: SAML provides a standard way to transfer security information across multiple Internet domains (Note: Cross domain SSO can be supported by Oracle Access Management (without federation) if all domains leverage the same Access Management server – in all other cases, Access Management Identity Federation is required).
•  Proprietary web single sign-on (SSO): SAML provides a standard way to implement SSO within a single domain or across multiple domains. 
• Federation: SAML facilitates identity management (e.g., account linking when a single user is known to multiple web sites under different identities). 
• Web Services Security: SAML provides a standard security token (a SAML assertion) that can be used with standard web services security frameworks (e.g., WS-Security, WS-Trust, etc.). 
• Identity propagation: SAML provides a standard way to represent a security token that can be passed across the multiple steps of a business process or transaction. 

Typically, SAML involves two parties: 

• Identity Provider (IdP): Asserting party that provides identity information to other services. 
• Service Provider (SP): Relying party that consumes the identity information sent by the asserting party to grant access to services hosted by the SP. 

Oracle Access Management Identity Federation supports a large set of use-case scenarios: 

•  Known name or attribute: Email address, X.509 Subject Name, Windows Domain Qualified Name, Kerberos Principal name, Attribute (e.g., employee number). 
• Opaque identifier: The principal is identified by a persistent randomized string private to the identity provider and service provider pairs. 
• Anonymous user: The principal is never explicitly identified by a persistent identifier, i.e., there’s no need to maintain a user (principal) entry at the service provider. 
•  Attribute Sharing: Identity Federation’s attribute-sharing plug-in allows Oracle Access Management to request user attributes from an identity provider. 
• Identity Provider Proxy: This use case involves three parties: Original Service Provider; Proxying Identity Provider (Oracle Access Management Federation acting as Identity Provider and becoming a Service Provider); and Proxied Identity Provider (Oracle Access Management services that authenticate the user). 

Oracle Access Management Fedlet :- 

Fedlet provides a standalone, light-weight SAML 2.0-compliant component for a Service Provider (SP) interacting with Access Management Identity Federation or a third-party SAML Identity Provider (IdP). 

Fedlet can be embedded and integrated with an application at development time. Fedlet can be deployed on premise or in the cloud supporting multiple environments: 

• Java version deployable as a Web Archive (WAR) on Oracle WebLogic Server and other market-leading Java EE containers. 
•  .NET version designed to support asp.net applications, deployable to Microsoft IIS (DLL) . 

Additionally, Fedlet can be deployed in conjunction with an IdP Discovery Service allowing users to select a preferred IdP. 

OpenID-Based Delegated Authentication :-

OpenID is a delegated authentication standard that any web site can leverage without having to develop its own authentication system. As a user, the OpenID standard allows you to log in to multiple OpenID-enabled sites with a single OpenID token. Identity data is communicated through the exchange of an OpenID identifier (a URL or XRI chosen by the end-user) and the Identity Provider provides OpenID authentication. Oracle Access Management Identity Federation support the following functionality: 

• OpenID 2.0 Authentication and SSO: An OpenID token contains the NameID of the user and (optional) attributes, outgoing tokens (or “assertions”) are signed.
•  OpenID 2.0 NameID Format: OpenID defines the NameID as being a random string. Identity Federation uses one of the following as the value for the NameID: A hashed user attribute (such as DN); a generated random value stored in the Federation Data Store (requires the use of a Federation Data Store). 

OAuth Delegated Authorization 

OAuth (Open Authorization) is an industry standard designed to support delegated authorization. Before OAuth, if a third-party (e.g., a money manager) wanted to access your account, you’d have to share your credentials with them, thus compromising your environment. 

OAuth was originally designed to allow a User (Resource Owner) to transparently share his private data stored on one site (Service Provider, or Resource Server) with another site (Consumer, or Client). 

With the advent of OAuth 2.0, the original consumer-centric delegated authorization use case extends to the enterprise and the cloud. OAuth 2.0 enables a third-party application to obtain access on its own behalf (two-legged process) or obtain limited access to an HTTP service on behalf of a Resource Owner by orchestrating an approval interaction between the Resource Owner and the HTTP Service Provider (three-legged process).

Although focusing on mobile clients, OAuth was originally intended for web applications that need access to resources owned by private users.

Oracle Access Management’s Support for OAuth 

OAuth is supported by multiple Oracle Access Management services: 

• Oracle Access Management Identity Federation (license for web clients only (i.e., non-mobile)). Oracle Access Management Mobile and Social (license for both web clients and mobile clients). Oracle API Gateway (typically, OAG acts as the resource server while the Oracle Access Management OAuth service acts as the authorization server; an OAG filter validates the Access Management OAuth token before allowing access to the resource). 
• Web Services Manager (future release): OAuth client-side support and integration with Oracle Access Management OAuth service for obtaining an access token, propagating it to a WSM-protected resource, and verifying the access token on the service side. 

Identity Federation OAuth Service 

The Identity Federation OAuth service extends the Access Management server (both administration and runtime) to provide Token Issuance, Token Validation, Token Revocation and User Flows in accordance with the OAuth 2.0 standard. The OAuth service increases security by eliminating the use of end-user passwords in many service-toservice interactions and reduces administrative costs by centralizing trust policies and associations in a large deployment. 

The standard OAuth Service is implicitly enabled if the Oracle Access Management Identity Federation service is enabled, To also enable Mobile OAuth, the Mobile and Social service (described later in this document) must be enabled, in addition to the Identity Federation service.

 Oracle Access Management Cloud Federation 

•  Microsoft Office 365 SAML 2.0 federation: Oracle Access Management Identity Federation is the Identity Provider, MS Office 365 is the Service Provider 
• WS-Federation Passive Requester Profile: Cross-domain Web SSO (HTTP Redirect, HTTP Post), local log out supported (i.e., log out is not broadcast to all WS-Federation endpoints in the circle of trust). 
• Web Services and APIs Security: Support for federation and delegated authorization with Salesforce, Google, Amazon AWS, SQS.

For Technical Implementation please refer my other blogs

Oracle Access Management Core Services

Oracle Access Management core services provide the primary perimeter access control services for the whole Oracle Access Management platform, including web authentication, web single sign-on (SSO), and coarse-grained authorization.

Oracle Access Management core services are deployed in a layered architecture across web, application, and data tiers as shown below

1) Users access protected web applications by authenticating to Oracle Access Management. 

2) The user request is intercepted by a filter referred to as WebGate acting as a Policy Enforcement Point (PEP) deployed in the DMZ. 

3) The WebGate communicates with Oracle Access Management’s policy server, which acts as the Policy Decision Point (PDP).

4) The administrator sets up security policies and selects authentication schemes from the administration console, which acts as the Policy Administration Point (PAP). 

5) If authentication is successful, a cookie is returned to the user’s browser to enable repeated log-ins to the same application or SSO with other web applications similarly protected by Oracle Access Management. 

6) For authorization, the WebGate prompts the Access Management policy server to look up authorization policies. The Access Management policy server evaluates the user’s identity and determines the user’s level of authorization for the requested resource (coarse-grained authorization). 

Few more features about Oracle Access Management in short:-

Persistent log-in :- OAM  lets users log in without credentials after first-time log-in,  based on configurable cookie technology. This capability, known as “persistent log-in,” is enabled by the application domain’s system administrator.

Basically this means that OAM will have the option to remember a user’s session for some defined period of time so even if they close their browser, they’ll be able to log back in again without providing credentials.

At the High level you need to perform the below steps to setup persistent login :-

• Check the “Allow Persistent Login” option on your Application Domain.
• Run a WLST command to enable persistent login globally in OAM
• Create a new Authentication Scheme with an additional Challenge Parameter: enablePersistentLogin=true
• Associate your resources with this new Authentication Scheme.
• For your Authorization Policies, add a new session response called allowPersistentLogin with value true.

All of these steps are fairly straightforward from the doc (which can be found here)

 WNA/Kerberos:- Oracle Access Management supports Windows Native Authentication (WNA) whereby a client logs in to their Windows desktop, opens an  browser, navigates to an Access Management protected HTTP resource, and is let in using the Kerberos Service Ticket without being challenged. Credentials are sent to the Access Management runtime servers for collection, regardless of where the login pages are (sample log-in pages are provided out-of-the-box). Find more details in my another blogs. 

DCC(detached credential collector) :-   Oracle Access Management extends WebGate 11g with a detached credentials collector (DCC) capability enabling the decoupling of credential collection from the server thus providing additional security (end-user HTTP sessions get terminated in the DMZ), and reducing overhead on the server in addition to improving performance.  Find more details in my another blogs. 

Session Management :- Oracle Access Management supports the session management life cycle (session life time, idle timeout, maximum number of sessions, database persistence of active sessions). Server-side session management allows for advanced session management across nodes via Oracle Coherence-based caching. Client-side session management stores the session details in the browser cookie with no information saved on the server side (stateless session), providing higher performance and smaller footprint than server-side session management. 

For Technical Implementation please refer my other blogs