Practical aspects of using and operating Mobile and Social Services include:
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.
The Android, iOS, and Java SDKs will send the tokens, credentials, and other data required by the Mobile and Social server.
Table 48-4 describes the tokens required and returned based on the client device or application.
Note:
For a detailed look at the credentials, see “Mobile and Social 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 48-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 |
|
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.) |
|
Client Registration Handle |
You can choose to protect User Profile Services and Authorization Services when configuring a Mobile and Social 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.
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 and Social Services' authentication flow with Access Manager, see Registration Flow for a Mobile Device With User Authentication.
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 Configuring Mobile and Social Services for Oracle Adaptive Access Manager.