38 Understanding Mobile and Social

This chapter describes the purpose and capabilities of Oracle Access Management Mobile and Social. It includes the following topics.

38.1 Introducing Mobile and Social

The Oracle Access Management Mobile and Social service acts as an intermediary between a user seeking to access protected resources, and the back-end Access Management and Identity Management services that protect the resources. Mobile and Social provides simplified client libraries that allow developers to quickly add feature-rich authentication, authorization, and identity capabilities to registered applications. On the back-end, the Mobile and Social server's pluggable architecture lets system administrators add, modify, and remove identity and access management services without updating the user's client software or mobile application. Mobile and Social provides two complimentary feature sets:

  • Mobile Services connects applications and devices to the enterprise Access Management and Identity Management services available in the Oracle Identity Access Management product suite. This makes it easy to utilize sophisticated authentication and authorization services functionality (such as mobile device and application registration, and device fingerprinting) to restrict access to authorized devices only. Client applications can also implement knowledge-based authentication, a powerful feature that goes beyond basic password-based authentication.

    Note:

    Device fingerprinting and knowledge-based authentication both require Oracle Adaptive Access Manager.

    Mobile Services can be configured to require a valid device and client credential and a User Token with each application token request. This ensures that only an authorized user can access a protected resource, and then only if the user is running an authorized application on an authorized device. Mobile Services also provides easy access to User Profile Services if Mobile and Social is integrated with an LDAP compliant directory server.

  • Internet Identity Services allows Mobile and Social to serve as the relying party when interacting with popular cloud-based identity authentication and authorization services, such as Google, Yahoo, Facebook, Foursquare, Windows Live, Twitter, and/or LinkedIn. After deploying Mobile and Social, a user is provided with multiple log-in options without the need to implement each provider individually. This allows users to access protected resources using their credentials from a trusted Identity Provider.

In addition to tight integration with Access Manager, Mobile and Social is "pre-wired" to work with other back-end Identity and Access Management Service offerings, including Oracle Adaptive Access Manager and a variety of LDAP compliant directory servers. On the front-end, Mobile and Social provides easy to use SDKs for integration of client applications on the Java, Android, and iOS platforms. The client applications then use simple REST calls to communicate with the Mobile and Social server.

Note:

REST (REpresentational State Transfer) is the software architectural style with which the World Wide Web has been developed. It is lightweight and especially well-suited to building web-based applications and services.

You can configure Mobile Services and Internet Identity Services to work together. For example, use Internet Identity Services to let users authenticate with Google, Facebook, Twitter, and so on, and use Mobile Services to (a) provide local authentication functionality, or (b) generate a User Token by accepting a User Identity assertion from a social Identity Provider. Mobile Services can also enhance device registration security when used in conjunction with Internet Identity Services.

Note:

Mobile and Social provides security layer functionality to registered applications that run on either Android or iOS devices, or in a Java SE JVM, or that communicate with the service using REST calls. If you require additional mobile functionality, ADF Mobile, a complimentary Oracle product offering, provides an application development framework for creating full-featured applications for iOS-powered devices. For more information, see the Oracle Fusion Middleware Mobile Developer's Guide for Oracle Application Development Framework.

The following sections contain additional information and documentation links regarding the installation and deployment of Mobile and Social.

38.1.1 Deploying Mobile and Social

The following list contains information and links regarding several Mobile and Social deployments.

38.1.2 Installing Mobile and Social

You can install Mobile and Social by itself or in combination with either Access Manager or Oracle Adaptive Access Manager (OAAM), or you can install all three together. Depending on the software installed alongside Mobile and Social, the available features may vary. Table 38-1 provides the details.

Table 38-1 Features in Mobile and Social Based on the Companion Services Installed

Feature Mobile and Social Only Mobile and Social + Access Manager Mobile and Social + OAAM Mobile and Social + Access Manager + OAAM

Access Manager token support using native Access Manager authentication dialogs

  

✔

  

✔

JWT token support for authentication and authorization

✔

✔

✔

✔

Ability to uniquely identify connecting mobile devices (Device fingerprinting)

    

✔

✔

Basic (limited) device security checks during device registration, access requests

✔

✔

    

Advanced device security checks during device registration and access requests, including risk-based access controls (for example, allow or deny access based on geolocation and other device attributes)

    

✔

✔

Multi-step authentication support (knowledge-based authentication and one time password support)

    

✔

✔

Interact with a Directory server and support User Profile services

✔

✔

✔

✔

Relying party support for Internet-based Identity Providers (Facebook, Google, Twitter, LinkedIn, Yahoo)

✔

✔

✔

✔

For installation details, see the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

38.2 Understanding Mobile Services

Mobile Services connect applications running on client devices to the security services and products available in the Oracle Identity Access Management product suite. In addition, User Profile Services is a Mobile Services feature that connects client applications to many popular LDAP compliant directory servers. Mobile Services consists of the following components:

  • A server component that interfaces with your backend Identity Services infrastructure. The server acts as an intermediary between supported client applications (and the users using those applications) and your backend Identity services. This arrangement decouples the client applications from the backend infrastructure so that you can modify your backend infrastructure without having to update your client programs. You can enable the Mobile and Social service to run by itself or in combination with the Access Manager service and/or the OAAM product as discussed in Section 38.1, "Introducing Mobile and Social."

  • A Mobile and Social Mobile Services Client Software Development Kit (Client SDK) is available for Android and iOS devices and Java. It is used to build authentication, authorization, and directory-access functionality into applications that run on mobile and desktop devices. The Mobile Services Client SDK can also be used to build a mobile single sign-on (SSO) agent application (for Android and iOS devices only). Mobile SSO is described in Section 38.2.3, "Introducing Mobile Single Sign-on (SSO) Capabilities." The Mobile and Social Mobile Services Client SDK is described in Section 38.2.4, "Introducing the Mobile and Social Mobile Services Client SDK."

The following sections contain more detailed information regarding the Mobile Services portion of Mobile and Social.

38.2.1 Introducing Authentication Services and Authorization Services

Authentication and Authorization Services lets you extend an existing authentication and authorization infrastructure to include mobile and non-mobile applications. Mobile Services supports the following common token types:

  • A User Token grants the token bearer with the permissions associated with the person who has been authenticated.

  • An Access Token grants access to a specific protected resource, such as a web resource or a URL.

  • A Client Token grants access to a non-mobile hardware device, such as a web application or server application.

  • A Client Registration Handle (similar to a Client Token) is also used by Mobile Services. It represents a mobile client application running on a mobile device. Mobile and Social uses the Client Registration Handle to register mobile devices, whereas non-mobile Service Providers use Client Tokens to authenticate non-mobile devices.

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, while a non-mobile device is a device that runs a non-mobile operating system, such as Mac OS X, Windows 7, and Linux desktop. Because mobile devices and non-mobile devices present different security challenges, mobile authentication and non-mobile authentication are managed separately in Mobile and Social. New mobile devices come online much more frequently and therefore require greater scrutiny, including heightened fraud detection measures.

Note:

A non-mobile device can use either mobile services or non-mobile services as long as the correct input is provided.

Mobile and Social supports Access Manager tokens (if Access Manager is installed with Mobile and Social) and JWT tokens. Each token type has a corresponding, pre-configured mobile and a non-mobile Service Provider. The pre-configured Authentication Service Providers are described in Table 38-2.

Table 38-2 Pre-configured Mobile and Non-Mobile Authentication Service Providers

Authentication Service Provider Description

OAMAuthentication

Lets users running a web application from a desktop device authenticate using Access Manager.

MobileOAMAuthentication

Lets users using mobile devices authenticate using Access Manager

JWTAuthentication

Lets users running a web application from a desktop device authenticate using the JSON Web Token format. JSON Web Token is a compact token format that is suitable for space-constrained environments such as HTTP Authorization headers.

MobileJWTAuthentication

Lets users using mobile devices authenticate using the JSON Web Token format.

38.2.2 Introducing User Profile Services

User Profile Services makes it possible to build an application that lets a user in your organization access the User Profile Services from mobile devices. User Profile Services allows Web, mobile, and desktop applications to perform a variety of LDAP compliant directory server tasks including:

  • Create, read, update, and delete functionality for users and groups

  • Search functionality

  • Org (organization) chart reporting functionality

Towards this end, the Mobile and Social server can interface with many popular LDAP compliant directory servers including:

  • Microsoft Active Directory

  • Novell eDirectory

  • Oracle Directory Server Enterprise Edition

  • Oracle Internet Directory

  • Oracle Unified Directory

  • Oracle Virtual Directory

  • Open LDAP

  • WebLogic Server Embedded LDAP

Refer to the Oracle Fusion Middleware Developer's Guide for Oracle Access Management for sample code that demonstrates how to use the SDK for User Profile Services.

Note:

Any device capable of HTTP communication can use User Profile Services by sending REST calls to the Mobile and Social server. See "Sending Mobile and Social REST Calls With cURL" in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

38.2.3 Introducing Mobile Single Sign-on (SSO) Capabilities

Mobile Single Sign-on (Mobile SSO) lets a user run multiple mobile applications on the same device without having to provide credentials for each one. Both native and browser-based applications can participate in Mobile SSO.

For Mobile SSO to work, an application installed on the mobile device needs to be designated as a Mobile SSO Agent. The Agent application serves as a proxy between the remote Mobile and Social server and the other applications on the device that need to authenticate with the back-end Identity services. The Agent can either be a dedicated agent (that is, an application that serves no other purpose), or a business (client) application that also provides agent functionality.

Note:

Before an application can use Mobile SSO to authenticate with the Mobile and Social server, you must configure the application as either a Mobile SSO Agent or Client on the server. For more information about configuring Mobile Services security for Mobile SSO, see Section 39.7, "Defining Service Domains."

Mobile application developers benefit from utilizing the Mobile SSO Agent because it handles device registration and advanced authentication schemes (including multi-factor authentication and one time password authentication), assuring this functionality does not have to be built into each mobile application. When the Mobile SSO Agent is present, user credentials are never exposed to the mobile business application. The Mobile SSO Agent and SSO Client interact as follows:

  • The SSO Client application sends the device registration request, the application registration request, and the User Token request to the SSO Agent.

  • The SSO Agent makes the necessary acquisitions on behalf of the SSO Client.

  • The SSO Client application then requests any Access Tokens it needs using the registration handle and User Token.

A browser-based business application can also be configured to use a Mobile SSO Agent for authentication. If that is the case, launching a browser-based business application invokes the Mobile SSO Agent and causes the agent to collect a user name and password, and send them to the Mobile and Social server. If the business application and the agent are authorized for SSO, the Mobile and Social server authorizes access. The agent then requests an Access Token for the resource (on behalf of the business application) and redirects the browser to the URL of the business application with the Access Token included in the headers.

From the user's perspective, native and browser-based application open on the device without asking the user to provide credentials. If the agent is not installed on the mobile device, or if the business application is not approved for Mobile SSO, the user will have to directly and independently send his or her credentials to the Mobile and Social server with each and every application that is launched.

The Mobile SSO Agent can time-out idle sessions, manage global logout for all applications, and assist in device selective wipe outs. Furthermore, it supports basic offline authentication. The agent one-way encrypts user passwords for local storage. During offline authentication, the agent validates the user name and password with the locally stored version. The agent then enforces all session idle time-outs and local password expiration policies.

Oracle does not provide a pre-built Mobile SSO Agent, however, documentation is provided so that you can build a Mobile SSO Agent application using the Mobile and Social Mobile Services Client SDK for Android or iOS. For more information about creating a Mobile SSO Agent application, refer to either the Android or the iOS Mobile Services SDK documentation in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

Note:

The Mobile SSO Agent is only supported on Android and iOS devices.

38.2.4 Introducing the Mobile and Social Mobile Services Client SDK

The Mobile and Social Mobile Services Client SDK contains individual SDKs for Android and iOS devices, and for Java Virtual Machines (JVMs). Table 38-3 documents each Mobile Services Client SDK feature and the software on which it works.

Table 38-3 Android, iOS, and Java Features of Mobile and Social Mobile Services Client SDK

Feature Android  iOS Java

Build a mobile application that can acquire Client Registration Handle, User, and Access Tokens through a Mobile and Social Server

✔

✔

  

Build a desktop application that can acquire Client, User, and Access Tokens through a Mobile and Social Server

    

✔

Interact with a Directory server and implement User Profile Services

✔

✔

✔

Create a mobile single sign-on (SSO) application

✔

✔

  

38.3 Understanding the Mobile Services Processes

When a user tries to access a protected resource, Mobile and Social requires either a Client Token (if the user is connecting through a server or a computer which securely stores client credentials) or a Client Registration Handle (if the user is using a mobile device). Thus, client devices (including mobile devices) and client applications must register with Mobile and Social before access to protected resources can be granted.

Note:

Applications are also typically configured to require a User Token and an Access Token.

Client applications running on mobile devices follow this high-level authentication process before the mobile application can access a protected resource.

  1. The user enters a user name and password at the application login screen and authenticates with the Mobile and Social server.

  2. If a mobile device has not previously registered with the Mobile and Social server, the server sends the mobile device a Client Registration Handle after authenticating the user.

  3. The Client Registration Handle is submitted back to the Mobile and Social server to get a User Token.

  4. The Client Registration Handle and User Token are submitted back to the Mobile and Social server to get an Access Token.

A non-mobile application can also make use of Authentication Services provided by Mobile Services. In such cases, a Client Token takes the place of the Client Registration Handle. After the Client Token is obtained, a User Token and Access Token can be requested as documented above. Additional scenarios are documented in these sections.

38.3.1 Registering a Mobile Device With User Authentication

When the mobile device attempting to access a protected resource has not previously registered with Mobile and Social, a Mobile SSO Agent must be installed. The registration authentication process is documented in the following flow. Figure 38-1 and Figure 38-2 follow the text and illustrate the process.

  1. The user launches an application on a mobile device.

  2. The application redirects the user to the Mobile SSO Agent.

  3. The Mobile SSO Agent displays a login page.

  4. The user enters a user name and password.

  5. The Mobile SSO Agent sends the user name and password to the Mobile and Social server along with the device attributes and application ID.

  6. The Mobile and Social server forwards the user name and password to Access Manager which authenticates the user.

  7. The Mobile and Social server sends device attributes and other authentication results to the OAAM Mobile Security Handler Plug-in which executes the policy stored on the OAAM server.

    Note:

    OAAM has two registration flows—active and passive. The active flow prompts the user with a challenge before allowing the device registration process to proceed. The passive flow continues without challenging the user.

    The OAAM Security Handler Plug-in creates two security handles (snippets of data that Mobile and Social stores with either the Mobile SSO Agent or the business application itself). Each handle stores a name, value, and expiration timestamp.

    • The oaam.device handle represents the mobile device. (Different client applications on the same device all have the same device handle value.) OAAM uses this handle as a key to retrieve the full device profile stored in the OAAM database. This handle has a relatively long life span.

    • The oaam.session handle represents an OAAM login session for a client application. (Each client application on a device has a unique session handle value.) OAAM uses this handle as a key to retrieve details about the OAAM session stored in the OAAM database. When the user logs out from the client application, the oaam.session handle is removed.

  8. The Mobile and Social server returns the Mobile Client Registration Handle and OAAM device and session handles to the Mobile SSO Agent.

  9. The Mobile SSO Agent gets a User Token by passing the Client Registration Handle and OAAM device handles that it previously received to the server.

  10. The Mobile SSO Agent requests an Access Token from Access Manager. The request contains the Client Registration Handle and OAAM device handles. See Figure 38-2.

Figure 38-1 First Time Device/Application Registration and Authentication Process

Description of Figure 38-1 follows
Description of "Figure 38-1 First Time Device/Application Registration and Authentication Process"

Figure 38-2 Mobile SSO Agent Requests Access Token from Access Manager

Description of Figure 38-2 follows
Description of "Figure 38-2 Mobile SSO Agent Requests Access Token from Access Manager"

38.3.2 Authenticating a User With a Registered Device

This scenario describes a user with a mobile device (already registered with Mobile and Social) launching a Mobile and Social compatible business application. In this scenario the Mobile SSO Agent is already installed and the user needs to access a protected resource that requires an Access Token. The business application must first acquire the User Token before it can request the Access Token. The accompanying figures (Figure 38-3 and Figure 38-4) illustrate the process.

  1. The user launches the business application on a mobile device.

  2. The business application asks the Mobile SSO Agent for a User Token and one of the following occurs.

    1. If a valid User Token exists in the local credential store, the Mobile SSO Agent returns it to the business application. The business application inserts the User Token into a direct request to the Mobile and Social server for the Access Token. The flow completes when the business application uses the Access Token returned by the server to access the protected resource (as in Figure 38-3).

      Figure 38-3 Mobile SSO Agent Has Valid Access Token in Credential Store

      Description of Figure 38-3 follows
      Description of "Figure 38-3 Mobile SSO Agent Has Valid Access Token in Credential Store"

    2. If a valid User Token does not exist in the local credential store, the login flow continues (as in Figure 38-4).

  3. The Mobile SSO Agent presents a login page and the user enters a user name and password.

  4. The Mobile SSO Agent sends the user name, password, and Client Registration Handle to the Mobile and Social server. (Step 2 in Figure 38-4).

  5. The Mobile and Social server validates the Client Registration Handle, authenticates the user credentials (with either the JWT token service or the Access Manager token service), invokes OAAM for risk analysis and then returns the User Token to the Mobile SSO Agent. (Step 3 in Figure 38-4).

  6. The Mobile SSO Agent stores a copy of the user token in its local credential store and returns the User Token to the business application. (Step 4 in Figure 38-4).

  7. The business application uses the User Token to make a direct request to the Mobile and Social server for the Access Token. (This step is not shown in the diagram.)

  8. The Mobile and Social server returns the Access Token to the Mobile SSO Agent.

  9. The business application uses the Access Token to make calls to the resource protected by Access Manager or Oracle Enterprise Gateway (OEG). (Step 5 in Figure 38-4).

Figure 38-4 Mobile SSO Agent Does Not Have Valid Access Token in Credential Store

Description of Figure 38-4 follows
Description of "Figure 38-4 Mobile SSO Agent Does Not Have Valid Access Token in Credential Store"

38.3.3 Using REST Calls for User Authentication

In this scenario an application running on a mobile device interfaces with the Mobile SSO Agent, which communicates with the Mobile and Social server using REST calls. The server interfaces with Access Manager and OAAM as needed and returns the necessary tokens to the Mobile SSO Agent (again using REST calls). The agent forwards the tokens back to the application, which can now access the protected resource using either REST or SOAP calls. The process is documented in the following flow. Figure 38-5 follows the text and illustrates the process.

  1. The user launches an application on a mobile device.

  2. Because the client application needs to access a resource protected by Access Manager, the client application asks the Mobile SSO Agent for an Access Token.

  3. The Mobile SSO Agent gets the Application Profile from the Mobile and Social server.

  4. The Mobile SSO Agent prompts for a user name and password.

  5. The Mobile SSO Agent sends the user name and password to the Mobile and Social server along with the device attributes and application ID.

  6. The Mobile and Social server registers the device and authenticates the user.

  7. The server returns an Access Token to the Mobile SSO Agent.

  8. The Mobile SSO Agent saves the hashed password in its local credential store.

  9. The Mobile SSO Agent passes the Access Token to the client application.

  10. The client application accesses the protected resource by presenting the Access Token.

Figure 38-5 User Authentication Using REST

Description of Figure 38-5 follows
Description of "Figure 38-5 User Authentication Using REST"

38.3.4 Authenticating the User With a Mobile Browser-Based Web App

This scenario describes a user with a Mobile and Social registered mobile device launching a Mobile and Social compatible browser-based web application. In this scenario the Mobile SSO Agent is installed. The standard authentication process is documented in the following flow. Figure 38-6 follows the text and illustrates the process.

  1. The user opens a URL in a web browser on a mobile device.

  2. The application web server redirects the browser to Access Manager.

  3. Access Manager sends the web browser a URL redirect.

  4. The web browser responds to the redirect by launching the Mobile SSO Agent.

    If the agent is not installed, a link with instructions to install the Mobile SSO Agent application is displayed.

  5. The Mobile SSO Agent displays the User login page.

  6. The user enters a user name and password.

  7. The Mobile SSO Agent sends the user name, password, and Client Registration Handle to the Mobile and Social server. (This step is not shown in the diagram.)

  8. The Mobile and Social server validates the Client Registration Handle, authenticates the credentials with Access Manager, publishes the ID context to the Access Manager server, and invokes OAAM for risk analysis.

  9. Access Manager returns a User Token or an Access Token to the Mobile and Social server which, in turn, returns the User Token or the Access Token to the Mobile SSO Agent. (This step is not shown in the diagram.)

  10. The Mobile SSO Agent directs the browser to the Mobile and Social server where it injects a cookie.

  11. The Mobile SSO Agent sends the web browser a URL redirect and an Access Token.

  12. The mobile web browser responds to the redirect and opens the original web URL because the access request now includes an Access Token.

  13. The application web server sends the requested pages to the mobile web browser.

Figure 38-6 Authenticating User From Browser-based Web App on Registered Mobile Device

Description of Figure 38-6 follows
Description of "Figure 38-6 Authenticating User From Browser-based Web App on Registered Mobile Device"

38.4 Using Mobile Services

The following sections describe how you might use the Mobile Services.

38.4.1 Protecting the Mobile Client Registration Endpoint

A mobile device attempting to access a protected resource must register with the Mobile and Social server as the server rejects anonymous requests sent to its registration endpoint. Additionally, each Service Domain should be configured to require either a User password or a User Token to register an application. The following is a sample registration endpoint for mobile clients and mobile applications:

https:// host : port /idaas_rest/rest/mobileservice1/register

When registering with the Mobile and Social server, client applications using either the Java Client SDK or the REST API must present valid credentials to the server using one or more of the following schemes:

  • HTTP Basic Authentication

  • User ID and Password (UIDPASSWORD)

  • OAM Token Authentication

Client applications using the Android or iOS SDK will acquire a Client Registration Handle which uses the UIDPASSWORD authentication scheme to secure registration.

38.4.2 Exchanging Credentials

The Android, iOS, and Java SDKs will send the tokens, credentials, and other data required by the Mobile and Social server. Table 38-4 describes the tokens required and returned based on the client device or application.

Note:

For a detailed look at the credentials, see "Mobile Services REST Reference: Authentication and Authorization" in the "Sending Mobile and Social REST Calls With cURL" chapter of the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

Table 38-4 Token Requirements for the Mobile and Social Server

Device or App Type Seeking to Register Token(s), Credentials, and/or Data Required by the Mobile and Social Server Type of Token Returned

Non-Mobile Device (Unregistered)

An ID and password associated with a client application sent over HTTPS.

Client Token

Mobile SSO Agent App

  • A user ID and password sent over HTTPS.

  • Device profile data for the Mobile Device.

  • The name of the application (that is, the Client ID).

    Note - An Administrator must also add the name of the mobile SSO Agent to a Service Domain.

Client Registration Handle

Mobile SSO Client App

(For example, a business application that uses the Mobile SSO Agent App to register with Mobile and Social.)

  • One of the following:

    A user ID and password sent to the Mobile and Social server over HTTPS.

    - or -

    A User Token.

  • Device profile data for the Mobile Device.

  • The name of the application (that is, the Client ID).

    Note - An Administrator must also add the name of the mobile SSO Client application to a Service Domain.

  • The oaam.device handle (if Mobile and Social is integrated with OAAM).

  • Mobile SSO Client Registration Handle (previously obtained for the SSO agent), if the SSO Client application tries to register through the SSO agent application.

Client Registration Handle

38.4.3 Protecting User Profile Services And Authorization Services

You can choose to protect User Profile Services and Authorization Services as follows when configuring a Mobile Services Service Domain.

User Profile Services - Configure User Profile Services security by making the following selections for the Service Profile:

  • Choose the Authentication Service Provider (OAMAuthentication, MobileOAMAuthentication, JWTAuthentication, Mobile JWT Authentication, Internet Identity Authentication, and so on)

  • Protect the service by requiring a "Secured Application" security token and a "Secured User" security token

  • Set the "Allow Read" and "Allow Write" options

Authorization Services - Configure Authorization Services security by making the following selections for the Service Profile:

  • Choose the Authentication Service Provider (OAMAuthentication, MobileOAMAuthentication, JWTAuthentication, Mobile JWT Authentication, Internet Identity Authentication, and so on)

  • Protect the service by requiring a "Secured Application" security token and a "Secured User" security token.

38.4.4 Using Mobile Services with Oracle Access Manager

Developers can quickly create applications that access resources protected by either Oracle Access Management Access Manager, or the 10g or 11gR1 PS1 (11.1.1.5) versions of Oracle Access Manager. The Mobile and Social SDK handles authentication programatically after it collects user credentials using the credential collection interface. The SDK then uses the Mobile and Social REST interfaces to authenticate the user with the token service configured for the application. For more information about the Mobile Services' authentication flow with Access Manager, see Section 38.3.1, "Registering a Mobile Device With User Authentication."

38.4.5 Using Mobile Services with Oracle Adaptive Access Manager Services

Oracle Adaptive Access Manager (OAAM) can be used to make runtime authentication decisions, such as blocking authentication if the user is authenticating from an unauthorized country or location. The following functionality is also supported.

  • Multi-part login flows - for example, OAAM can challenge the user with knowledge-based authentication questions, or require the user to authenticate using one-time password (OTP) functionality if OAAM detects a risky or unusual usage pattern (using the device at unusual hours or if the user is geographically distant from the place where authentication last took place).

  • Check device attributes (such as the MAC Address assigned to a device) and verify that the device is not jail broken. Based on device attributes, OAAM can allow or deny access.

  • Device-selective wipeouts are also an option when using OAAM together with Mobile and Social.

  • Based on registered device info, OAAM can white-list or black-list specific devices.

For more information about using Mobile and Social with OAAM, see Section 39.9.2, "Configuring Mobile Services for Oracle Adaptive Access Manager."

38.5 Understanding Internet Identity Services

Internet Identity Services lets Mobile and Social serve as the relying party (RP) when interacting with cloud-based Identity Authentication and Authorization Services, such as Google, Yahoo, Facebook, Twitter, Windows Live, Foursquare and/or LinkedIn. Allowing users to log in to a protected resource using their credentials from a trusted Identity Provider is a convenience for the user. By deploying Mobile and Social, you can provide users with a convenient multiple log-in option without the need to implement each Provider individually. Users can use their credentials from cloud-based identity services to log in to any of the following application types.

  • Web applications that run on Java-compliant application servers. To add Internet Identity Services functionality to a Web application, a developer connects the Web application to the Mobile and Social server using the Internet Identity Services Client SDK. For details, see the "Developing Applications Using the Internet Identity Services Client SDK" chapter in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

  • Applications protected by either Access Manager, or the 10g or 11.1.1.5 versions of Oracle Access Manager. Applications protected by either the Access Manager service in the Oracle Access Management product, or the 10g or 11gR1 PS1 versions of Oracle Access Manager can be configured to work with Internet Identity Services without using an SDK. For details about the authentication flow, see Section 38.6.4, "Authenticating a User With Access Manager and Internet Identity Services."

  • Mobile applications running Android or iOS. Mobile applications running Android or iOS can be configured to authenticate with an Internet Identity Provider. To connect to the Mobile and Social server, Android and iOS applications use the Mobile Services SDKs for those platforms. A separate SDK is not required.

Internet Identity Services provides services for Identity Providers that support the following standards:

  • OpenID version 2.0

  • OpenID Simple Registration Extension 1.0

  • Open ID Attribute Exchange Extension 1.0

  • OpenID Provider Authentication Policy Extension 1.0

  • OAuth 1.0 and 2.0

Native support for the Identity Providers listed in Table 38-5 is provided by Mobile and Social after installation.

Table 38-5 Identity Providers That Mobile and Social Natively Supports

Identity Provider Supported Protocol

Facebook

OAuth 2.0

Google

OpenID 2.0

LinkedIn

OAuth 1.0a

Twitter

OAuth 1.0a

Yahoo

OpenID 2.0

Foursquare

OAuth 2.0

Windows Live

OAuth 2.0

Java programmers can add relying party support for additional OpenID and OAuth Identity Providers by implementing a Java interface and using the Mobile and Social console to add the Java class to the Mobile and Social deployment. For more information, see the "Extending the Capabilities of the Mobile and Social Server" chapter in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

38.6 Understanding Internet Identity Services Processes

The following scenario documents the basic authentication process when using Internet Identity Services.

  1. A user requests access to a protected resource and is redirected to Mobile and Social.

  2. Mobile and Social (RP) asks the user if they would like to log in using their credentials from, for example, Google (the Identity Provider).

  3. Mobile and Social redirects the user to a Google login page where a user name and password is entered.

  4. Google verifies the credentials and redirects the user back to Mobile and Social. At the same time the Identity Provider returns identity attributes to Mobile and Social based on its configuration.

    If the user does not have an account with your organization, the user can be prompted to register for one; the registration form will be prepopulated with the information that the Identity Provider returns.

Note:

In the case of Access Manager, a user MUST register locally, otherwise access is not given. If not using Access Manager, the user is redirected to the protected resource and allowed access even if they don't register. For details, see Section 38.7.1, "Using Internet Identity Services With Oracle Access Manager."

Additional scenarios are documented in these sections.

38.6.1 Authenticating a Returning User With a Local Account

This scenario describes the authentication flow between the User, the Mobile and Social server (the relying party), the Identity Provider, and the local user authentication service (represented by Local Auth and IdRepository in the diagram). In this scenario, the local Identity repository determines that the user already has a local account. Consequently Mobile and Social does not prompt to create one. Figure 38-7, following the text, illustrates the process.

  1. The user opens a URL for a protected resource in a web browser and the Mobile and Social server presents the user with a login page and a menu of Identity Providers (Google, Yahoo, Facebook, Windows Live, Foursquare, Twitter, or LinkedIn) from which to choose.

  2. The user chooses an Identity Provider.

  3. The Mobile and Social server redirects the user to the selected Identity Provider and a login page is displayed.

  4. The user enters a user name and password and, upon authentication, the Identity Provider sends the Mobile and Social server an authentication assertion.

  5. The Mobile and Social server checks with the Identity repository to see if the user has a local account.

    The Identity repository could be a directory server, a database, Oracle Identity Manager, or similar. The user is determined to be a User with a local account:

    • If a mobile application or a directly-integrated Web application is authenticating with Mobile and Social, the Mobile and Social server sends an authentication assertion to the user's browser.

    • If an application protected by Access Manger is authenticating, Access Manager creates the session for the user only if the user has a local account. (Newly registered users count as local account holders.)

  6. The user's browser sends the authentication assertion sent by Mobile and Social to the protected resource's Access Management Service.

  7. The Access Management Service carries out additional authentication steps as needed.

  8. The Access Management Service allows the user access to the protected resource.

Figure 38-7 Authenticating a Returning User with a Local Account

Surrounding text describes Figure 38-7 .

38.6.2 Authenticating a New User With No Local Account

This scenario describes the authentication flow between the User, the Mobile and Social server (the relying party), the Identity Provider, and the local User authentication service (represented by Local Auth and IdRepository in the diagram). In this scenario, the User does not have a local account so Mobile and Social prompts to create one. Figure 38-8, following the text, illustrates the process.

  1. The user opens a URL for a protected resource in a web browser and the Mobile and Social server (RP in the diagram) presents the user with a login page and a menu of Identity Providers (Google, Yahoo, Facebook, Twitter, or LinkedIn) from which to choose.

  2. The user chooses an Identity Provider.

  3. The Mobile and Social server redirects the user to the selected Identity Provider which displays a login page.

  4. The user enters a user name and password and, upon user authentication, the Identity Provider sends the Mobile and Social server an authentication assertion.

  5. The Mobile and Social server checks with the Identity repository to see if the User has a local account.

    The Identity repository could be a directory server, a database, Oracle Identity Manager or similar. The user is determined to be a user who does not have a local account. Mobile and Social proceeds as follows:

    • If the Identity Provider uses the Open ID protocol, the Mobile and Social server retrieves the user's profile attributes by processing data in the previously obtained authentication assertion.

    • If the Identity Provider uses the OAuth protocol, the Mobile and Social server makes a separate HTTP call to the Identity Provider with the previously obtained Access Token to retrieve the user's profile attributes.

  6. The Mobile and Social server sends a new user registration form to the user's browser.

    The registration form is pre-populated with the user profile attributes sent by the Identity Provider in the previous step.

  7. The user completes the registration form and sends it to which interfaces with the user registry (either a directory server or Oracle Identity Manager) to create the account.

    In cases where an Access Token is retrieved from the Identity Provider, the Access Token is also returned to the client application by way of Mobile and Social.

  8. The Access Management Service for the client application carries out additional authentication steps as needed.

  9. The Access Management Service allows the user access to the protected resource.

Figure 38-8 Authenticating a New User with No Local Account

Surrounding text describes Figure 38-8 .

38.6.3 Using OAuth For Access Token Retrieval

This section provides supplemental detail about the OAuth authentication and Access Token retrieval flow between the User, the Mobile and Social server (the relying party), and an OAuth Identity Provider. (Facebook, Foursquare and Windows Live use the OAuth 2.0 protocol, and LinkedIn and Twitter use the OAuth 1.0 protocol.) In this scenario, the server interfaces with the OAuth Identity Provider to get an authorization code and Access Token to access a resource protected by the OAuth Identity Provider. The Client application in this scenario could be either a Web application running on a Java-compliant application server, or a mobile application. Figure 38-9, following the text, illustrates the process.

  1. The user opens the client application which returns a protected web page to the user's browser.

  2. The user attempts to open the protected resource on the client application.

  3. The client application asks the Mobile and Social server for an Access Token so that the user can access the protected resource.

    If Mobile and Social has the valid Access Token in its cache, it will forward the Access Token to the client application and the authentication scenario would skip to step 10. This flow assumes Mobile and Social does not have the Access Token in its local cache.

  4. Since the Access Token is not in its local cache, on behalf of the user, Mobile and Social initiates an authorization request (utilizing HTTP headers to embed an OAuth Client ID, scope information, and a redirect URL) with the OAuth Identity Provider.

  5. The OAuth Identity Provider displays a login page.

  6. The user enters a user name and password into the OAuth Identity Provider login page and gives consent to the Identity Provider to provide the user's profile attributes to the Mobile and Social server (and, by extension, the client application).

  7. The OAuth Identity Provider sends an authorization code to the Mobile and Social server.

  8. The Mobile and Social server sends an Access Token request to the OAuth Identity Provider.

    Included in the request is the authorization code received in the previous step and the OAuth Client ID and client credential.

  9. The OAuth Identity Provider returns an Access Token to the Mobile and Social server.

  10. The Mobile and Social server caches the Access Token (with the User ID and the OAuth Client ID) and forwards the Access Token to the client application.

  11. The client application uses the Access Token to access the protected resource and returns the protected page to the user's browser.

Figure 38-9 Authenticating a User With an OAuth Identity Provider

Description of Figure 38-9 follows
Description of "Figure 38-9 Authenticating a User With an OAuth Identity Provider"

38.6.4 Authenticating a User With Access Manager and Internet Identity Services

This scenario describes the authentication process between the User, Access Manager, the Mobile and Social server (the relying party), and the Identity Provider. Note that the user must either have a local account or must register for a local account when prompted; otherwise Access Manager will not let the user access the protected resource and the User will be redirected to the login page. Figure 38-10, following the text, illustrates the process.

  1. The user attempts to open a protected resource on the client application.

  2. The WebGate protecting the resource intercepts the access request.

  3. Access Manager identifies the authentication policy protecting the resource and redirects the user to a login page provided by the Mobile and Social server.

  4. The login page presents a menu of Social Identity Providers.

  5. The user chooses an OpenID Identity Provider and Access Manager redirects the user's browser to the Mobile and Social server, which redirects the user's browser to the login page for the selected Social Identity Provider (Google, Facebook, Twitter, and so on).

  6. The user types a user name and password into the Social Identity Provider's login page.

    The Identity Provider completes the authentication process and requests the User's consent to share Identity information (if applicable).

  7. When authentication is complete, the Social Identity Provider redirects the browser back to the Mobile and Social server.

    After further processing of Identity assertions supplied by the Identity Provider and after retrieving user identity information, the Mobile and Social server redirects the user's browser to Access Manager. This time HTTP headers in the page request provide Access Manager with the user's authentication status and attributes.

  8. Access Manager creates a user session and redirects the user to the protected resource.

Figure 38-10 Authenticating a User with Access Manager

Description of Figure 38-10 follows
Description of "Figure 38-10 Authenticating a User with Access Manager"

38.6.5 Authenticating a User Locally

This scenario describes the authentication process if the user chooses not to authenticate through a Social Identity Provider but instead authenticates using a local account. Figure 38-11, following the text, illustrates the process.

  1. The user opens a URL for a protected resource in a web browser and the Mobile and Social server presents the user with a login page and a menu of Identity Providers from which to choose.

  2. The user chooses to use local authentication and types a user name and password at the login page.

  3. The client application's Access Management Service carries out additional authentication steps as needed.

    • If using the JWT Token Service, a User Token may be created.

    • The OAM Token Service does not return tokens during the local authentication flow.

  4. The Access Management Service creates a session for the user and the user accesses the protected resource.

Figure 38-11 Authenticating a User Locally

Surrounding text describes Figure 38-11 .

38.7 Using Internet Identity Services

The following sections contain details on how you might use the Internet Identity Services. For examples of ways to integrate Internet Identity Services, see Section 38.6, "Understanding Internet Identity Services Processes."

38.7.1 Using Internet Identity Services With Oracle Access Manager

Users can choose to log in to Access Manager protected resources using credentials from an Internet Identity Provider if you integrate Internet Identity Services with Access Manager. In this arrangement, users enter their Identity Provider credentials. Access Manager forwards the User's login request to Mobile and Social, which completes the authentication process with the Identity Provider in the background. Mobile and Social (the relying party) redirects the User to Access Manager. At the same time, Mobile and Social provides Access Manager with the User's authentication status and User attributes, which were sent by the Identity Provider. For more information about how Access Manager uses Internet Identity Services for authentication, see Section 38.6.4, "Authenticating a User With Access Manager and Internet Identity Services."

38.7.2 Using Internet Identity Services With Mobile Services

You can configure Mobile Services to allow mobile devices to authenticate using Internet Identity Services. After an Identity Provider verifies a user's credentials, Internet Identity Services can prompt the user to create an account with your organization. To pre-populate the new user registration form with data returned from the Identity Provider, refer to the "Developing Applications Using the Internet Identity Services Client SDK" chapter in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

38.7.3 Using the Internet Identity Services SDK

Developers who maintain Java-compliant Web applications can add Internet Identity Services functionality to their Web offering using the Mobile and Social Internet Identity Services SDK. This SDK is available for Java-powered Web applications only. For information about the SDK, see the "Developing Applications Using the Internet Identity Services Client SDK" chapter in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.