This blog post covers the following security aspects of the Oracle Mobile Cloud service platform in brief

• The security features
• It’s foundations
• Supported mechanisms (protocols)

What Are the Security Features?

Oracle MCS supports the following

• Authentication: verifying the identity (and associated credentials) of a mobile app user
• Authorization: restricting the access arena of the authenticated mobile app user to a set of resources configured for his.her role
• Identitypropagation: ability to pass on security context of authenticated users to external systems (APIs, services)

Building Blocks

Authorization, authentication and user management capabilities are powered by the following core components

• Users: valid users of your mobile apps
• Roles: they help define permissions/privileges for your mobile app users
• Realms: container for user information (including credentials) and associated roles
• MobileBackend: a container for resources to be used by the mobile apps i.e. APIs and related associations such as realms, storage collections etc.

Wait...What are We Protecting ?

In MCS, (almost) everything flows via the Mobile Backend. The protected artefacts are

• PlatformAPIs: exposes a rich set of features – user management, storage, notification, device registration, offline data, analytics, database access & management, application configuration
• CustomAPIs: you can build your own set of APIs and expose them via RESTful end points (based on JavaScript and Node.js)
• ConnectorAPIs: a facade layer on top of heterogenous external systems/service/endpoints (REST, SOAP, cloud/on-premise applications etc.)

Simple Flow

An end user uses the mobile app feature which in turn invokes the APIs configured within the MobileBackend which is linked to the particular mobile app. The authentication and authorization is taken care of by the realm associated with the Mobile Backend

Access Gateways for MCS Resources

Mobile apps access core MCS backend resources using

• REST API: MCS features/platform APIs have a RESTful interface for HTTP based clients
• Platform specific SDK (Android, iOS, Windows, JavaScript): makes it easy for mobile app developers to use the MCS Platform features (mentioned above) infrastructure and things like authentication etc. are handled in a seamless manner

Inbound Authentication Support

Invocations triggered via mobile apps pass through the MCS backend layer which are protected using the below mentioned techniques

• HTTP Basic: send the Authorization header with the base 64 encoded username and password information as well as an additional Oracle-Mobile-Backend-ID header which consists of the ID of the Mobile Backend to which the resource (API) is associated with
• OAuth: a combination of the (pre configured) OAuth client ID & secret along with (optional) username & password combination is required to fetch the OAuthtoken which is then sent to the configured OAuth endpoint

Here is an example showing a simple HTTP GET request (to fetch information for user jdoe) invoked at a REST endpoint and the authorization headers in action

Difference b/w OAuth and HTTP Basic

The following are the differences (in the context of Oracle MCS)

• For OAuth, the Base64 encode username-password combo is replaced by the OAuth token and is prepended with Bearer e.g. Authorization: Bearer <my-oauth-token-007>
• Also, the Oracle-Mobile-Backend-ID header is not required in case of OAuth mode

Anonymous Login

If you do not want to leverage username & password combination, you can just configure your mobile backend to use an anonymous token which can then be passed by the mobile app (client). This is applicable for HTTP Basic authentication

Inbound Authorization

Authorization revolves around user-role memberships which itself is defined within a realm. The Mobile Backend allows for configuration where one can specify which roles are allowed to access which Custom API endpoints i.e. one can define a permission based access model with the help of roles e.g. users belonging to PREMIUM role can access advanced features while others cannot

Outbound Identity Propagation

Oracle MCS provides the capability to propagate (authenticated) identity information while interacting with external services. As mentioned above, Connector APIs help facilitate this. They are available in three flavors, each of which cater to a different category of service

• REST Connector APIs – facade over external REST services
• SOAP Connector API – layer on top of external SOAP endpoints
• ICS Connector API – helps integrate with other cloud as well as on-premise services

External services invoked by the above mentioned components might have their custom security restrictions. Oracle MCS provides abstracts this with the help of Oracle Web Service Manager strategies/policies which can be declaratively applied on top your connectorAPIs

• HTTP Basic header
• SAML token
• WSS UserName token

Note: There might be different sub-types of the above mentioned policies which result in the multiple permutations and combinations e.g. HTTP basic over SSL, SAML 2.0 token, WSS username token over SSL etc. 

There are a lot of details which were omitted, but hopefully, this helps get an overview of security basics of Oracle MCS along with some of its related features