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
- Identity propagation: 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
- Mobile Backend: 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
- Platform APIs: exposes a rich set of features – user management, storage, notification, device registration, offline data, analytics, database access & management, application configuration
- Custom APIs: you can build your own set of APIs and expose them via RESTful end points (based on JavaScript and Node.js)
- Connector APIs: 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 Mobile Backend 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 OAuth token 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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| GET /mobile/platform/users/jdoe HTTP/1.1 | |
| Host: fif.cloud.oracle.com | |
| Authorization: Basic Z3NlX2Nsb3VkLWFkbWluQG9yYWNsZWFkcy5jb206dGVuc2VIYXJkc2hpcF4y | |
| Oracle-Mobile-Backend-ID: id007 |
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 connector APIs
- 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
Cheers!
Head in the clouds 