41 Understanding Mobile and Social

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

41.1 Introducing Mobile and Social

The Oracle Access Management Mobile and Social service acts as an intermediary between a user or client 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 customize identity and access management services without updating the user's client software or mobile applications. 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.

  • Social Identity 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.

    Note:

    Prior to version 11.1.2.2, Social Identity was named Internet Identity Services.

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 Social Identity to work together. For example, use Social Identity 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 Social Identity.

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.

41.1.1 Installing Mobile and Social

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

Table 41-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.

41.1.2 Deploying Mobile and Social

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

  • If deploying Mobile and Social together with Access Manager, both can be deployed together on the same server, either in the same domain or in separate domains. For details, see the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

  • If deploying Mobile and Social alongside Oracle Access Manager 10g or 11gR1 PS1, Mobile and Social and Oracle Access Manager need to be installed on different servers in different domains. For details, see Section 44.3, "Deploying Mobile and Social With Oracle Access Manager."

    Note:

    If Access Manager is already installed, you cannot add Mobile and Social to an Oracle Access Management installation by extending the OAM domain. Attempting to do so will result in an error similar to the following:

    CFGFWK-64071- the selection conflicted with templates already installed in the domain OAM with database policy store 11.1.1.3.0

  • If deploying Mobile and Social with a WebGate, Mobile and Social can generate the Oracle Access Management token that clients need to access the WebGate-protected resources. The following restrictions apply:

    • If you deployed Oracle Access Management 11gR2 (11.1.2), Mobile and Social can generate a token that can access either an 11g WebGate or a 10g WebGate.

    • If you deployed either Access Manager 11gR1 (11.1.1) or 10g, Mobile and Social can generate an Oracle Access Management token that can access a 10g WebGate only.

  • When moving Mobile and Social from a test environment to a production environment, see Section 44.4, "Configuring Mobile and Social After Running Test-to-Production Scripts."

41.1.3 Enabling Mobile and Social

To leverage the Mobile and Social functionality, the service should be explicitly enabled. Follow these steps to enable the Mobile and Social service.

  1. Log in to the Oracle Access Management Console.

    The Launch Pad opens.

  2. Click Available Services in the Configuration pane.

    The Available Services page opens.

  3. Click Enable next to Mobile and Social.

41.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 41.1, "Introducing Mobile and Social."

  • A server-side device store that can store security material, such as security tokens and security information required by the OAAM Security Handler Plug-in. The server-side device store provides several benefits: It improves security because tokens managed by the server-side device store are not sent to the client application where they can be copied if the device or client app is compromised; it eliminates the need for mobile client applications to manage and synchronize security material; and finally it allows security material to be shared and synchronized among multiple client apps.

  • 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 41.2.3, "Understanding Single Sign-on (SSO) for Mobile Services." The Mobile and Social Mobile Services Client SDK is described in Section 41.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.

41.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 Lynx 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 Oracle Access Manager tokens (if Access Manager is installed with Mobile and Social) and JWT (JSON Web Token) tokens. Each token type has a corresponding mobile and a non-mobile Service Provider. Mobile and Social provides four pre-configured Authentication Service Providers:

  • OAM Authentication

  • Mobile OAM Authentication

  • JWT Authentication

  • Mobile JWT Authentication

Two additional Authentication Service Providers can also be created:

  • JWT-OAM Authentication

  • Mobile JWT-OAM Authentication

Table 41-2 describes the Authentication Service Providers.

Table 41-2 Mobile and Non-Mobile Authentication Service Providers in Mobile Services

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.

JWTOAMAuthentication

Allows lightweight, long-duration JWT tokens to be exchanged for OAM tokens. OAM tokens provide SSO and OAM resource access to clients. This provider allows users using non-mobile applications to get a new OAM token without having to provide credentials if they have a valid, long-duration JWT token.

MobileJWTOAMAuthentication

Allows lightweight, long-duration JWT tokens to be exchanged for OAM tokens. OAM tokens provide SSO and OAM resource access to clients. This provider allows users using mobile applications to get a new OAM token without having to provide credentials if they have a valid, long-duration JWT token.

41.2.2 Understanding the Mobile Services Authorization Flow

The Mobile Services authorization flow is used if the client application implements mobile security using the Mobile and Social Client SDKs for Android, iOS, or Java, or if the client app goes through a Mobile SSO Agent app (covered later) to establish mobile security. In this flow the client app (or the Mobile SSO Agent) collects user inputs and maintains the user session on the mobile device.

The diagrams in the following sections depict the Mobile Services authorization flow:

41.2.3 Understanding Single Sign-on (SSO) for Mobile Services

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.

Note:

Mobile Services apps and Mobile OAuth apps require separate SSO implementations. For information about single sign-on for Mobile OAuth applications, see Section 45.2.8, "Understanding Mobile OAuth Single Sign-on (SSO)."

Understanding the Mobile SSO Agent App

A special application installed on a mobile device can be designated as a Mobile SSO Agent. This 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 the Mobile SSO agent app 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 42.7, "Defining Service Domains."

The Mobile SSO Agent handles device registration and advanced authentication schemes (including multi-factor authentication and one time password authentication), so 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 applications. 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.

  • The SSO Agent app stores tokens and security material on behalf of the mobile SSO Client, similar to the server-side device store.

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.

When using a mobile SSO agent, applications 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.

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.

41.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 41-3 documents each Mobile Services Client SDK feature and the software on which it works.

Table 41-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

✔

✔

  

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

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

41.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 41-1 and Figure 41-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 41-2.

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

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

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

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

41.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 41-3 and Figure 41-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 41-3).

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

      Description of Figure 41-3 follows
      Description of "Figure 41-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 41-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 41-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 41-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 41-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 41-4).

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

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

41.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 41-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 41-5 User Authentication Using REST

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

41.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 legacy authentication process is documented in the following flow. Figure 41-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 41-6 Authenticating User From Browser-based Web App on Registered Mobile Device

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

41.3.5 Authorization Using the Mobile OAuth Authorization Flow

The following diagram shows at a high level the interactions between a mobile app and the Oracle Access Management OAuth service in the context of Mobile Services. To understand the difference between the legacy authorization flow and the Mobile OAuth authorization flow, see Section 41.2.2, "Understanding the Mobile Services Authorization Flow."

For a detailed look at the OAuth authorization flow in the context of the OAuth Service, see Section 45.3.3, "Understanding Mobile OAuth Authorization."

  1. The mobile app requests a client verification code by sending a device token.

    The OAuth service returns the client verification code. If the APNS/GCM option is enabled, the OAuth service returns half of the code using push notification, and the other half over HTTPS. Push notification provides an extra level of assurance for confirming the identity of the application and device.

  2. The mobile app requests an authorization code by sending device claims and the client verification code.

    The OAuth service:

    • Authenticates the user

    • Requests the user's consent to register the app (optional)

    • Invokes OAAM for risk analysis

    • Returns the authorization code using push notification (optional) and HTTPS

  3. The mobile app requests a Client Token by sending the authorization code and device claims.

    The OAuth service returns the Client Token using push notification (optional) and HTTPS.

  4. The mobile app requests an Access Token by sending the Client Token, the authorization code, and the device claims.

    The OAuth service returns the Access Token.

  5. The mobile app requests access to the protected resources using the Access Token. (Not shown in the diagram.)

    The resource server returns the protected resources to the client application. (Not shown in the diagram.)

Figure 41-7

Surrounding text describes Figure 41-7 .

41.4 Using Mobile Services

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

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

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

41.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, Social 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, Social Identity Authentication, and so on)

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

41.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 41.3.1, "Registering a Mobile Device With User Authentication."

41.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 42.9.2, "Configuring Mobile Services for Oracle Adaptive Access Manager."

41.5 Understanding Social Identity

Social Identity 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 Social Identity functionality to a Web application, a developer connects the Web application to the Mobile and Social server using the Social Identity Client SDK. For details, see the "Developing Applications Using the Social Identity 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 Social Identity without using an SDK. For details about the authentication flow, see Section 41.6.4, "Authenticating a User With Access Manager and Social Identity."

  • Mobile applications running Android or iOS. Mobile applications running Android or iOS can be configured to authenticate with an Social 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.

Social Identity 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 41-5 is provided by Mobile and Social after installation.

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

Identity Provider Supported Protocol

Facebook

OAuth 2.0

Google

OAuth 2.0

LinkedIn

OAuth 2.0

Twitter

OAuth 2.0

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.

41.6 Understanding Social Identity Processes

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

  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 41.7.1, "Using Social Identity With Oracle Access Manager."

Additional scenarios are documented in these sections.

41.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 ID Repository 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 41-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 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 41-8 Authenticating a Returning User with a Local Account

Surrounding text describes Figure 41-8 .

41.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 ID Repository in the diagram). In this scenario, the User does not have a local account so Mobile and Social prompts to create one. Figure 41-9, 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 41-9 Authenticating a New User with No Local Account

Surrounding text describes Figure 41-9 .

41.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 41-10, 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. Because 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 41-10 Authenticating a User With an OAuth Identity Provider

Description of Figure 41-10 follows
Description of "Figure 41-10 Authenticating a User With an OAuth Identity Provider"

41.6.4 Authenticating a User With Access Manager and Social Identity

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 41-11, 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 41-11 Authenticating a User with Access Manager

Description of Figure 41-11 follows
Description of "Figure 41-11 Authenticating a User with Access Manager"

41.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 41-12, 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 41-12 Authenticating a User Locally

Surrounding text describes Figure 41-12 .

41.7 Using Social Identity

The following sections contain details about how you might use the Social Identity. For examples of ways to integrate Social Identity, see Section 41.6, "Understanding Social Identity Processes."

41.7.1 Using Social Identity With Oracle Access Manager

Users can choose to log in to Access Manager protected resources using credentials from a Social Identity Provider if you integrate Social Identity 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 Social Identity for authentication, see Section 41.6.4, "Authenticating a User With Access Manager and Social Identity."

41.7.2 Using Social Identity With Mobile Services

You can configure Mobile Services to allow mobile devices to authenticate using Social Identity. After an Identity Provider verifies a user's credentials, Social Identity 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 Social Identity Client SDK" chapter in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

41.7.3 Using the Social Identity SDK

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