Basics of Security in Oracle Mobile Cloud Service
Security has blossomed into a major concern for enterprise IT. Here's an overview of Oracle Mobile Cloud service's security features: what they are, the foundation, and what it being protected.
Join the DZone community and get the full member experience.
Join For FreeThis 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
Published at DZone with permission of Abhishek Gupta, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments