By Kanishkmahajan-Oracle on Feb 20, 2015
Oracle Mobile Security Suite (OMSS) addresses BYOD challenges
by isolating corporate from personal data on consumers’ personal mobile devices without
needing to lockdown the entire device. Using a technique called containerization;
the Oracle Mobile Security Suite creates a Secure Workspace (SWS) in which corporate applications,email and
data are stored. Only authenticated users can access the secure workspace to run applications and access data and only applications provisioned or approved by corporate IT can be installed and executed from within this secure workspace. If the device is lost or stolen, corporate IT can remotely wipe the secure workspace without affecting any personal data.
The OMSS Secure Workspace (SWS) leverages OAM infrastructure for secure authentication (or even strong authentication/risk based access in the upcoming PS3 release) and seamless single sign on to corporate resources for all containerized apps. In this blog post I'll describe how the OAM Mobile & Social (M&S) OAuth Service allows OAM to provide secure authentication and enterprise single sign on to Oracle's Mobile Secure Workspace (SWS) .
How it Works
In order for the Mobile Security Access Server (MSAS) to authenticate users against Oracle Access Manager and retrieve Oracle Access Manager and OAuth tokens for integrated single sign on, the Mobile Security Access Server (MSAS) is registered as an OAuth Client with the M&S OAuth Service. In the current PS2 release we support the Confidential Client OAuth flow only; however in the upcoming PS3 release we will support Dynamic Client Registration as well.
Confidential Client Flow - In this flow MSAS is the OAuth 2.0 Confidential Client and M&S is the OAuth Server as well as the Resource Server. MSAS uses the clientid and secret entered in the container as confidential credentials for this flow. The confidential client first obtains an JWT User Token (referred to as User Identity Assertion) using this clientid, secret and the userid and password entered by the user in the secure workspace. The confidential client then obtains an OAuth2.0 Access Token using a standard OAuth 2.0 JWT user assertion flow on behalf of the resource owner. The OAM Tokens to access 11g or 10g protected resources are then obtained using the extension OAM Credential grant type using this JWT User Token. MSAS stores the encrypted JWT UT and the OAM MT (corresponds to an OAM_ID cookie for OAM protected web resources) in an STOKEN which is returned to the secure workspace app. This allows an authenticated secure workspace app user to single sign on to OAM protected resources with the OAM MT in the STOKEN and to any OAM OAuth REST interface using the JWT UT in the STOKEN.
Dynamic Client Registration - In this authentication model, a workspace is dynamically registered with M&S through MSAS and the workspace itself obtains the JWT Client Token after successful workspace registration. Compare this to the Confidential Client Flow flow above where the workspace app uses the client credential of MSAS. The registration of the workspace basically involves app and device profile attributes to be automatically sent to the M&S OAuth Server which creates a JWT Client token based on the unique "fingerprint" specific to the app and the device of the workspace app. The rest of the flow is similar where the workspace app itself is the OAuth Client (mobile OAuth client) and M&S is the OAuth Server as well as the Resource Server. In this flow we support step up authentication (using KBA or OTP) and device context based fine grained authorization during both user authentication to the workspace app and subsequent single sign on to corporate resources from any of the containerized apps. This is now possible because M&S uses its built-in integration with OAAM (using the Security Handler Plugin) to perform risk analysis based on the device and app context now available in this authentication.