Thursday Aug 20, 2015

Achieving SAML interoperability with OAM OAuth Server


This post is long overdue and is in response to a large number of customer requests that want achieve interoperability between SAML and OAuth flows. Essentially the goal is that having previously established a trust relationship through the exchange of SAML metadata, how do we allow an OAuth 2.0 server to leverage that trust relationship and issue an OAuth access token on behalf of the subject of the assertion.

This is a key use case now for 1) customers that deploy or offer our OAuth related Cloud APIs/services but where the user store/users are not located on-premise and 2) for customers that expect these OAuth Services to be offered to their same B2B partners that were being offered SAML related Federation Services from them .


So how do we do this?

OAM OAuth 2.0 implements the SAML2 Bearer Assertion Profile for OAuth 2.0 by supporting a SAML 2 assertion to be used as an authorization grant type –i.e. it allows an OAuth client to use a SAML2 assertion to request an OAuth access token on behalf of the subject of the assertion. This is based on the specification outlined here: However, the OAM implementation does not provide any plumbing outside the specification which makes the usage of this profile impractical. Specifically it does not provide a mechanism for how the OAuth client may 1) obtain the SAML assertion (either from the SAML IDP or the SAML SP) and 2) obtain the signature of the issuer (SAML IDP) required by it to validate the signature and contents of the SAML assertion.

Fortunately for 3-legged OAuth flows since OAuth and Federation are both fully converged OAM services and use OAM auth schemes for user authentication, there is a configuration workaround. In this approach, the OAM consent page (used by the resource owner (user) in a 3-legged flow to provide explicit consent to the OAuth client to access the OAuth resource) can be protected by the Federation Scheme instead of the default LDAP scheme. Secondly, the OAM server that is used as the OAuth 2.0 server must also be configured as a SAML 2 SP with the third party SAML IDP used for user authentication. The user is redirected via Federated authentication (SP initiated SSO) to the SAML IDP. The user is asked to authenticate at the IDP where the user store resides or if the user session already exists at the SAML IDP, the user is simply redirected with the SAML assertion to OAM SAML SP which validates the SAML assertion and creates an OAM session. Since the consent page is also OAM protected and hence when the OAuth Server detects an OAM session for the user, the OAuth Server has proof of an authenticated user identity and continues with the OAuth flow -- and issues the authorization code to the client subsequently allowing the OAuth client application to exchange the code grant with an OAuth access token.

Friday Feb 20, 2015

Enabling Mobile Application Management with secure enterprise single sign on


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.

Sunday Jan 18, 2015

Providing a REST enabled Cloud Identity Backend with the Access Portal Service


The Cloud Identity backend Access Portal Service provides multi-tenant REST enabled interfaces for authentication, credential CRUD operations, session management , auditing and logging to OAM (Oracle Access Manager) server. It is released for the Oracle Public Cloud and is relevant for our on-premise and hybrid cloud customers as well. In this post I'll provide a high level sketch of functional areas that benefit from this REST enabled Cloud identity backend.

Use Cases

1. On-premise to SaaS/PaaS using Access Proxy

The Access Proxy built on the high performance, high throughput OTD (Oracle Traffic Director) based proxy technology provides a built-in webgate and form filling service. The form filling service can now leverage these REST interfaces for application detection, credential capture, credential injection and session management as well as provide a responsive UI to support form factors across any mobile or desktop (mac,pc) browser. 

2. IDaaS

Identity as a Service (IDaaS) by definition is a control point for cloud access—i.e the user's browser from a tenant org must always be redirected to the IDaaS portal first. This provides IDaaS with a key vantage point to easily launch IDaaS server side execution using these multi-tenant REST enabled interfaces for enabling form filling/password vaulting for several  SaaS/PaaS applications that still do not support protocols such as SAML or OAuth. The REST enabled Access Portal Portal service now supports direct form submission that easily supports sites that do not perform security checks/balances on the form submission or require monitoring for subsequent response (login/pwd change) that may occur later in the session.

3. Mobile Wallet

A Mobile Wallet is essentially a native mobile app which allows secure access to a user's credentials for any app on the mobile device as well as provides secure offline storage of those credentials. Most mobile wallets also provide an embedded browser in the mobile app to support the launch and injection of credentials into websites. Besides providing the primary ability to CRUD app credentials from a REST enabled server and manage user sessions on the server, the Access Portal REST interfaces also provide mechanisms to support delegation capabilities from user to user without exposure to the credentials themselves as well as the ability to generate a strong password based on rules and directly inject on password change forms. A mobile "workspace' app can simply leverage these features to provide a mobile wallet and couple them with native mobile OS capabilities (--that are outside the scope of current discussion) -  for e.g. by using the native accessibility APIs (on Android/iOS) or copy/paste of the password onto the clipboard --to further enable secure single sign on for this user to any other mobile app on the device.

4. Desktop Clients

New and existing Enterprise Single Sign On (ESSO) customers can seamlessly leverage these REST enabled interfaces to enable secure authentication and single sign on to traditional desktop clients specifically thick client applications, mainframe applications or web based browser based applications via form filling technology. Modernizing the classic ESSO product so that it can leverage the same multi-tenant REST enabled server side interfaces now allows seamless integration with the other aspects of the IDM stack (OAM, OPAM, OAAM, OIM etc) by extending end to end enterprise identity management capabilities such as strong authentication, risk and fraud analysis, fine grained authorization, user self service and password management, privileged user management etc to desktop clients.

Thursday Dec 25, 2014

Using OAM OAuth interfaces to secure mobile apps


When using OAuth interfaces in OAM Mobile Services, there are two high level options to secure native mobile apps. This simple post is hopefully useful to our new customers and describes a sample flow for each of those options as well as the token types involved irrespective of using the SDK or using native REST interfaces directly from within the app. In subsequent posts I'll describe these interfaces in more detail.

Use 2-legged OAuth flow

  1. User opens the mobile application
  2. Application sends application information and device profile to OAMMS. This happens automatically behind the scenes. OAMMS performs application registration and creates a unique client assertion for the user
  3. User inputs username (login) and password.
  4. If user authentication is successful then the user is issued a JWT User Assertion otherwise the user is displayed an error message
  5. User then obtains a JWT Access Token and accesses a REST API resource within the application
  6. If the user wants to now access an OAM protected resource -
    • The application code performs a token exchange and first obtains an OAM Master Token from the JWT User Assertion
    • The application code then obtains a OAM Access Token from the OAM Master Token by passing in the application resource context
  7. The user accesses the OAM protected resource from the mobile application

In this case, you can use OAuth REST APIs within the Android or iOS application. In PS3 we will have an SDK to support this flow. However with the PS3 SDK you cannot do step 6 in this flow. In PS3 when using REST APIs directly you will also be able to strong authentication for this user using KBA after step 3.

Use 3-legged OAuth flow

  1. User opens the mobile application
  2. Application sends application information and device profile to OAMMS. This happens automatically behind the scenes. OAMMS performs application registration and creates a unique client assertion for the user
  3. User inputs  username (login) and password.
  4. If the user authentication fails here, then an error is thrown/error page is displayed
  5. If OAM-OAAM integration is configured via the TAP scheme, the user is prompted for strong authentication via KBA
  6. If the strong authentication fails, then an error is thrown/error page is displayed
  7. User is then asked to provide explicit consent on a consent page—to verify that the client application is  allowed access to the REST API. The consent page is OAM protected
  8. The consent page can be displayed in the embedded browser or in the external browser
    1. If the consent page is displayed in the embedded browser, the mobile app also obtains an OAM_ID cookie that it can use to access OAM protected resources—as the OAM_ID cookie is stored/issued within the context of the mobile app.
    2. If the consent page is displayed in the external browser, the mobile app does not obtain an OAM_ID cookie that it can use to access OAM protected resources –as the OAM_ID cookie is stored/issued outside the context of the mobile app.
  9. If user authentication is successful and the user has provided consent then the user is issued a JWT User Assertion otherwise the user is displayed an error message.
  10. User then obtains a JWT Access Token and accesses a REST API resource within the application.
    • If step 8.1 was followed the user can seamlessly access an OAM protected resource within the app as well
    • If step 8.2 was followed and the user wants to access an OAM protected resource -The application code performs a token exchange and first obtains an OAM Master Token from the JWT User Assertion
      • The application code then obtains a OAM Access Token from the OAM Master Token by passing in the application resource context
      • The user accesses the OAM protected resource from the mobile application

In this case again, you can use OAuth REST APIs within the Android or iOS application. Also in PS3 we will have an SDK to support this flow.

Token Types in OAM Mobile Services

Here are the token types and what they represent in OAMMS-
  • OAM MT – user session token representing authenticated OAM session. It can be set as OAM_ID cookie
  • OAM AT - represents access token authorizing access to scoped OAM webgate protected resource. It is basically the OAM AuthnCookie.
  • OAM UT – OAM AT scoped for OAMMS server
  • JWT Client Assertion – represents the client application
  • JWT AT – represents access token authorizing access to scoped REST resource
  • JWT User Assertion :  JWT AT with global scope

Also note that in a 3 legged flow, the mobile app automatically leverages OAM password policies such forgot/change/reset password, account lockout functionality through native OAM password policy functionality (or via OAM-OIM integration) since user (resource owner) authentication is performed while accessing an OAM protected consent page while in the case of a 2 legged flow, the resource owner username/password are sent in a basic authorization header directly to the LDAP server (bypassing OAM in step 3,4 in the 2-legged flow) and hence only native LDAP password policies apply.

Finally, if you want to implement token exchange where you want to reissue an expired OAM token based on a longer duration JWT UT, then you will again to need to use REST interfaces directly as there is no PS3 SDK support for this. We support PIN based authentication for this as documented here -

Wednesday Jan 29, 2014

Under the covers - Using Mobile OAuth for Native app authentication and Server side Single Sign On


As we roll out OAM's Mobile OAuth functionality and address our customer's use cases around securing native mobile apps accessing OAuth enabled services and APIs, this blog post outlines a real world mobile enterprise extranet use case and unravels the syntax and HTTP requests/responses for OAM's OAuth REST interfaces that are to be used by Mobile OAuth clients with whatever be their mobile platform of choice - iOS or Android.

Use Case

Avitek Retail is a large multi brand retail enterprise. In addition to several other products, Avitek Retail also sells shoes and accessories from different competing brands in their retail outlets. Avitek Retail’s warehouse managers must ensure that adequate inventory levels are maintained to meet customer demand and they typically need access to supplier catalogs to replenish inventory.

Avitek Retail- an Oracle Access Manager customer has built its own inventory replenishment application that is used by its warehouse managers. Avitek Retail originally built its inventory replenishment application as a web based application but has also recently made it available as a mobile native application for both the iOS and Android platforms that can be downloaded from iTunes or the Google Play app stores. In our scenario, ABC Designer Shoe Inc provides a catalog of designer shoes as a REST service that requires a valid OAuth 2.0 access token. This catalog needs to be accessed by Avitek Retail’s Inventory Replenishment application. From an OAuth perspective then we have the following scenario: 

  • OAuth 2.0 Server: Oracle Access Manager 11gR2PS2 deployed at Avitek Retail
  • OAuth 2.0 Client: Avitek Retail’s Inventory Replenishment application
  • OAuth Resource Server: ABC Designer Shoe Catalog
  • Resource Owner: Tom Dole- Warehouse Manager at Avitek Retail who owns the shoe catalog provided by ABC Designer Shoe Inc to Avitek Retail.

Mobile OAuth Flow

Following is the entire mobile flow:

  1. Tom Dole (ABC Shoe Inc Catalog Resource Owner and Avitek Retail Warehouse Manager) attempts to access the Inventory Replenishment application (Mobile OAuth Client)
  2. The Inventory Replenishment application (Mobile OAuth client) requests a pre-authorization code with a device token from the OAM OAuth 2.0 Server.
  3. The OAM OAuth 2.0 Server returns pre-authorization code over APNS(iOS).
  4. The Inventory Replenishment application (Mobile OAuth Client) sends a registration request with device claims and pre-authorization code to the OAM OAuth 2.0 Server. The OAM OAuth 2.0 server uses user-agent redirection, authenticates the user, checks for device security, gets user consent for Mobile OAuth Client registration ( - if Tom Dole is accessing the app for the first time on the mobile device) and returns a client token over APNS/GCM to the Mobile OAuth Client.
  5. The traditional OAuth flow starts now. The OAuth server checks for device security and depending on the configuration, presents the user with a consent page for accessing the ABC Shoe Designer Inc Catalog
  6. The OAM OAuth 2.0 authorization server sends an authorization code to the Inventory Replenishment application (Mobile OAuth client)
  7. The Inventory Replenishment application (Mobile OAuth client) requests for an access token from the OAuth authorization server by sending the authorization code, client token and device claims.
  8. The OAM OAuth 2.0 server returns access token with optional refresh token to the Inventory Replenishment application (Mobile OAuth Client)
  9. The Inventory Replenishment application (Mobile OAuth Client) presents the Access Token to the ABC Shoe Designer Inc Catalog (OAuth 2.0 Resource Server)
  10. The ABC Shoe Designer Inc Catalog (OAuth 2.0 Resource Server) validates the token with the OAM OAuth 2.0 Authorization Server
  11. The ABC Shoe Designer Inc Catalog (OAuth 2.0 Resource Server) provides the requested content to the Inventory Replenishment application (Mobile OAuth Client)

Solution - Under the covers

And here's the secret sauce-- a working sample of the HTTP requests/responses and the syntax of the Mobile OAuth REST interfaces used to enable the Mobile OAuth client application:

Step 1 Create Pre Authorization Code for Client Token
curl -i -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' -H 'Cache-Control: no-cache, no-store, must-revalidate' --request POST -d 'grant_type=client_credentials&client_id=1097ae507ea649da81a660293e75d8e2&oracle_device_profile=eyJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6c2RrdmVyc2lvbiI6IjExLjEuMi4wLjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6Z2VvbG9jYXRpb24iOiJMb2NhdGlvbiB1cGRhdGUgZmFpbGVkLExvY2F0aW9uIHVwZGF0ZSBmYWlsZWQiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bmV0d29ya3R5cGUiOiJXSUZJIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om9zdHlwZSI6ImlQaG9uZSBPUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpwaG9uZWNhcnJpZXJuYW1lIjoiVU5LTk9XTiIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpsb2NhbGUiOiJlbi1VUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpvc3ZlcnNpb24iOiI2LjEiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6amFpbGJyb2tlbiI6ZmFsc2UsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDp2cG5lbmFibGVkIjpmYWxzZSwiaGFyZHdhcmVJZHMiOnsib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OnVkaWQiOiJFQjY5QzZCOC0yNTJBLTQyOTQtQkYyMy1CQUIwNTU2RkNCMjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6cGhvbmVudW1iZXIiOiJVTktOT1dOIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om1hY2FkZHJlc3MiOiIwMDoxRjo1QjpGNzpDRDo4OSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiJ9fQ==&oracle_requested_assertions=oracle-idm%3A%2Foauth%2Fassertion-type%2Fclient-identity%2Fmobile-client-pre-authz-code-client'

Status: 200

Step 2 Create Authz code for Client Token

Step 3 Create Client Token
curl -i -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' -H 'Cache-Control: no-cache, no-store, must-revalidate' --request POST -d 'grant_type=authorization_code&code=eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGgucmVkaXJlY3QtdXJpIjoiaHR0cDovL3NsYzAxbWtrLnVzLm9yYWNsZS5jb206NzAwMS9pZG1vYXV0aHRvb2wvIiwib3JhY2xlLm9hdXRoLmN0LnJlZ191c2VyX2lkX3R5cGUiOiJMREFQX1VJRCIsImlzcyI6Ind3dy5vcmFjbGUuZXhhbXBsZS5jb20iLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6aW1laSI6IlVOS05PV04iLCJvcmFjbGUub2F1dGguc3ZjX3BfbiI6Ik9BdXRoU2VydmljZVByb2ZpbGUiLCJpYXQiOjEzODg5NzkxNzkwMDAsIm9yYWNsZS5vYXV0aC5hemMudHRjIjoiY2xpZW50X2Fzc2VydGlvbiIsIm9yYWNsZS5vYXV0aC50a19jb250ZXh0IjoiYXpjIiwiZXhwIjoxMzg4OTgwMDc5MDAwLCJvcmFjbGUub2F1dGguY3QucmVnX3VzZXIiOiJ3ZWJsb2dpYyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDptYWNhZGRyZXNzIjoiMDA6MUY6NUI6Rjc6Q0Q6ODkiLCJwcm4iOm51bGwsImp0aSI6IjYyNmY2MWVhLTdjODktNGM1MC05NzdmLTVhNThiNmUxNTMzYiIsIm9yYWNsZS5vYXV0aC5jbGllbnRfb3JpZ2luX2lkIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJvcmFjbGUub2F1dGguaWRfZF9pZCI6IjEyMzQ1Njc4LTEyMzQtMTIzNC0xMjM0LTEyMzQ1Njc4OTAxMiIsInVzZXIudGVuYW50Lm5hbWUiOiJEZWZhdWx0RG9tYWluIn0.Wm8Xx_lWvq80yLwfThx4rOxwLsDanws0Dzbr3yUdncJe4VBvg0Oz-zGAtNk5i0kjeknyyrt5J3BC7of9NOYYR5dwgwpXMB8uf6qnfdnsxfvX8PFAgsX_rJ68rViFRksghg9Z0juiFPGBE3upBYjawKQXm6bx5UCce6h-N0856wM&client_id=1097ae507ea649da81a660293e75d8e2&'

Status: 200

Step 4 Create Pre Authorization Code for Access Token
curl -i -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' -H 'Cache-Control: no-cache, no-store, must-revalidate' --request POST -d 'grant_type=client_credentials&client_id=1097ae507ea649da81a660293e75d8e2&oracle_requested_assertions=oracle-idm%3A%2Foauth%2Fassertion-type%2Fclient-identity%2Fmobile-client-pre-authz-code-access&oracle_device_profile=eyJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6c2RrdmVyc2lvbiI6IjExLjEuMi4wLjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6Z2VvbG9jYXRpb24iOiJMb2NhdGlvbiB1cGRhdGUgZmFpbGVkLExvY2F0aW9uIHVwZGF0ZSBmYWlsZWQiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bmV0d29ya3R5cGUiOiJXSUZJIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om9zdHlwZSI6ImlQaG9uZSBPUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpwaG9uZWNhcnJpZXJuYW1lIjoiVU5LTk9XTiIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpsb2NhbGUiOiJlbi1VUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpvc3ZlcnNpb24iOiI2LjEiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6amFpbGJyb2tlbiI6ZmFsc2UsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDp2cG5lbmFibGVkIjpmYWxzZSwiaGFyZHdhcmVJZHMiOnsib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OnVkaWQiOiJFQjY5QzZCOC0yNTJBLTQyOTQtQkYyMy1CQUIwNTU2RkNCMjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6cGhvbmVudW1iZXIiOiJVTktOT1dOIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om1hY2FkZHJlc3MiOiIwMDoxRjo1QjpGNzpDRDo4OSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiJ9fQ=='

Status: 200

Step 5 Call

Request an Access Token
curl -i -H 'Accept: */*' --request POST -d 'grant_type=authorization_code&client_id=1097ae507ea649da81a660293e75d8e2&code=eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGgucmVkaXJlY3QtdXJpIjoiaHR0cDovL3NsYzAxbWtrLnVzLm9yYWNsZS5jb206NzAwMS9pZG1vYXV0aHRvb2wvIiwib3JhY2xlLm9hdXRoLnVzZXJfb3JpZ2luX2lkX3R5cGUiOiJMREFQX1VJRCIsIm9yYWNsZS5vYXV0aC51c2VyX29yaWdpbl9pZCI6IndlYmxvZ2ljIiwiaXNzIjoid3d3Lm9yYWNsZS5leGFtcGxlLmNvbSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiIsIm9yYWNsZS5vYXV0aC5zdmNfcF9uIjoiT0F1dGhTZXJ2aWNlUHJvZmlsZSIsImlhdCI6MTM4ODk3OTE5NzAwMCwib3JhY2xlLm9hdXRoLnRrX2NvbnRleHQiOiJhemMiLCJleHAiOjEzODg5ODAwOTcwMDAsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDptYWNhZGRyZXNzIjoiMDA6MUY6NUI6Rjc6Q0Q6ODkiLCJwcm4iOm51bGwsImp0aSI6Ijk2MjVjYWZkLWVkYmUtNDJjNC05ZGMzLWEyMmMyOWMxZTlmZCIsIm9yYWNsZS5vYXV0aC5zY29wZSI6IlVzZXJQcm9maWxlLnNlY3JldGtleS5tYW5hZ2VtZW50IFVzZXJQcm9maWxlLnVzZXJzIFVzZXJQcm9maWxlLm1lIFVzZXJQcm9maWxlLmdyb3VwcyIsIm9yYWNsZS5vYXV0aC5jbGllbnRfb3JpZ2luX2lkIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJ1c2VyLnRlbmFudC5uYW1lIjoiRGVmYXVsdERvbWFpbiIsIm9yYWNsZS5vYXV0aC5pZF9kX2lkIjoiMTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtMTIzNDU2Nzg5MDEyIn0.knflM_0d1NvEZD2Vs5N-piHj-tq3KMNoXLiJkqNTwd73lwAxnwkiy02RLOvyOt3FM05chszQGWl2ahEog7g8tNgTmRG5sDrmLm9HWkpuwqWTStYXf-Sz-thOV3IRU5BN311T-neHb81sq5f6kslqTGvjBnfXXeBzlUDld5DVYVI&oracle_device_profile=eyJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6c2RrdmVyc2lvbiI6IjExLjEuMi4wLjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6Z2VvbG9jYXRpb24iOiJMb2NhdGlvbiB1cGRhdGUgZmFpbGVkLExvY2F0aW9uIHVwZGF0ZSBmYWlsZWQiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bmV0d29ya3R5cGUiOiJXSUZJIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om9zdHlwZSI6ImlQaG9uZSBPUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpwaG9uZWNhcnJpZXJuYW1lIjoiVU5LTk9XTiIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpsb2NhbGUiOiJlbi1VUyIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDpvc3ZlcnNpb24iOiI2LjEiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6amFpbGJyb2tlbiI6ZmFsc2UsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDp2cG5lbmFibGVkIjpmYWxzZSwiaGFyZHdhcmVJZHMiOnsib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OnVkaWQiOiJFQjY5QzZCOC0yNTJBLTQyOTQtQkYyMy1CQUIwNTU2RkNCMjAiLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6cGhvbmVudW1iZXIiOiJVTktOT1dOIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50Om1hY2FkZHJlc3MiOiIwMDoxRjo1QjpGNzpDRDo4OSIsIm9yYWNsZTppZG06Y2xhaW1zOmNsaWVudDppbWVpIjoiVU5LTk9XTiJ9fQ==&client_assertion=eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCIsImtpZCI6Im9yYWtleSJ9.eyJvcmFjbGUub2F1dGguY3QucmVnX3VzZXJfaWRfdHlwZSI6IkxEQVBfVUlEIiwic3ViIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJpc3MiOiJ3d3cub3JhY2xlLmV4YW1wbGUuY29tIiwib3JhY2xlOmlkbTpjbGFpbXM6Y2xpZW50OmltZWkiOiJVTktOT1dOIiwib3JhY2xlLm9hdXRoLnN2Y19wX24iOiJPQXV0aFNlcnZpY2VQcm9maWxlIiwiaWF0IjoxMzg4OTc5MTkxMDAwLCJvcmFjbGUub2F1dGgucHJuLmlkX3R5cGUiOiJDbGllbnRJRCIsImV4cCI6MTM4OTU4Mzk5MTAwMCwib3JhY2xlLm9hdXRoLmN0LnJlZ191c2VyIjoid2VibG9naWMiLCJvcmFjbGUub2F1dGgudGtfY29udGV4dCI6ImNsaWVudF9hc3NlcnRpb24iLCJvcmFjbGU6aWRtOmNsYWltczpjbGllbnQ6bWFjYWRkcmVzcyI6IjAwOjFGOjVCOkY3OkNEOjg5IiwicHJuIjoiMTA5N2FlNTA3ZWE2NDlkYTgxYTY2MDI5M2U3NWQ4ZTIiLCJqdGkiOiIxYWIyZTg1ZC1lYWM5LTRhMzItODU4MC0xODE5ODhjNDFlZTUiLCJ1c2VyLnRlbmFudC5uYW1lIjoiRGVmYXVsdERvbWFpbiIsIm9yYWNsZS5vYXV0aC5pZF9kX2lkIjoiMTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtMTIzNDU2Nzg5MDEyIn0.aW-Vkkb3YTN6xWOwMHQn0W1drhorC9vW9hTK512_VW0JwYlGd924p9qd4cR1qhJqv802j7NsUPhmra9mYgrKaFrT-aIvPOGHpWcOqu3-tvwkGY7DM_twmRh-jQn_CqHvLpgflbpDYO8KAsp3xyVF6qupM8l2wc4IuQ7hZUMHI5c&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&'

Status: 200

Wednesday Jan 22, 2014

Using Oracle STS to connect to Amazon Web Services


While we do see fewer opportunities for Oracle STS than say traditional browser based identity federation or more recently OAuth for enterprises to securely connect to cloud hosted applications or services, Oracle STS still offers a compelling differentiation for several customers. In this post, I'll share a key use case for one of our marquee customers that is an ideal fit for Oracle STS.


The customer's application needs to securely access resources hosted by Amazon Web Service as outlined here in the graphic below from

Essentially with AWS, the client application that needs to access AWS hosted resources for a user needs to first securely get user information from the enterprise identity store in the form of a SAML assertion. Users don't have direct access to AWS.  Also, the application then needs to exchange that SAML assertion with AWS for temporary security credentials with the appropriate authorization for the user so that it can access user specific resources from AWS.

How can we accomplish it with OSTS

- A  App executed by the client sends a WS-Trust request to the OSTS with

o username/password in SOAP headers

o AppliesTo set to

- O  OSTS would be configured to

o Validate credentials against LDAP user store

o Have a Relying Party partner representing the AWS STS, with a mapping URL set to

- O  OSTS validates the creds, creates Assertion based on user LDAP record (specified in the OSTS SAML Issuance template)

o NameID format is set to persistent

o NameID value is set to an LDAP User ID (it cannot be random string, as this is not supported in STS use cases, only in Federation SSO)

o SAML Attributes include and

- T   AWS STS would need to be configured to trust OSTS based on:

o The OSTS issuerID/providerID (specified in the OSTS SAML Issuance template)

o The OSTS signing key (see, section

Monday Jan 20, 2014

The case for Mobile OAuth in the OAM OAuth service


Several OAuth Clients are consumer applications that cannot keep the client secret confidential (application password or private key). These OAuth Clients are called public clients or non-confidential clients. Mobile Client applications i.e. native applications on mobile devices are also categorized as public clients because when a native application is first downloaded from an app store to a device, the client credentials that uniquely identify the client application are baked into the application. Since all users that download the native application have access to the binary, a malicious user could easily decompile the client credentials out of the binary and insert their own credentials. During an OAuth flow when the access code gets exchanged for the access token this leads to a major vulnerability as there is now no secure means of really identifying who is actually receiving and using the access token.

Hence, providing a mechanism to secure the mobile application on the device in order to ensure trusted access is a key requirement specifically for enterprise mobile applications that routinely require access to sensitive data. The OAM OAuth Service provides key features in the OAM OAuth 2.0 Service’s Mobile OAuth flow to facilitate secure enterprise mobile access for OAuth Client applications.

How it's done : Overview - Mobile Application Registration and Mobile Device Identification

The OAM OAuth  Service provides built-in support for a mechanism for mobile applications to be first registered with OAM to use OAuth Access Services. Security is enforced for mobile applications by creating a client profile and issuing client tokens specific to the application on a device. The user provides explicit authorization to register each mobile OAuth application. In the OAM OAuth 2.0 Service, mobile application registration is modeled using the same paradigm as the OAuth protocol flow where mobile application registration is modeled as a scope for which the user needs to provide explicit consent. As a result of the mobile application registration the application is issued a client token. The mobile application always submits this client token as an input parameter for accessing OAM OAuth 2.0 Service end points. Furthermore, the OAM OAuth 2.0 service also allows easy coupling of device identification with mobile application registration where mobile devices and applications can be checked against fraud and security using a built-in integration with Oracle Adaptive Access Manager (OAAM). The mobile application passes device claims along with the client token for accessing OAM OAuth 2.0 Service end points and the OAM OAuth2.0 Service provides a configuration to make certain claims as mandatory and certain claims as optional.

Sunday Jan 19, 2014

Using the OAM Mobile SDK to secure native mobile apps - Android SDK


In this blog post I'll round out addressing a key strategic area for our customers--i.e. securing mobile native apps with Oracle Access Manager using the mobile client SDK. In previous posts I covered securing iOS based mobile clients using the iOS SDK as well as covered the required OAM server side configurations involved in securing these applications. In this post I'll cover the Android SDK. Finally, the sample android app used here in this post as an Eclipse ADT project is available for download at :

Invoking Authentication Services


The first step is to create an object of OMMobileSecurityService and initialize the Android SDK by providing required Mobile and Social server details.

This constructor initializes the OMMobileSecurityService object using the Map<String, Object>:

public OMMobileSecurityService(Context context, Map<String, Object> configProperties,OMMobileServiceCallback callback)

This enables you to specify required and optional parameters to initialize the SDK using the OM_PROP_* properties in the Map. The OM_PROP_OAMMS_URL parameter is the URL (including protocol, host name, and port number) required to reach the Mobile and Social server. Only the HTTP and HTTPS protocols are supported. The OM_PROP_APPNAME parameter is a unique identifier that identifies the application. This String value must match the application "Name" value located in the Application Profile section of the Mobile and Social server administration console. The OM_PROP_OAMMS_SERVICE_DOMAIN parameter specifies the name of the service domain that has been created on the Mobile and Social server. The application profile that the OM_PROP_APPNAME refers to should be defined as an application profile in this service domain.

The following snippet in ConfigurationActivity#OnClick() populates the Map<String,Object>:

Map<String, Object> oamConfigProp = new HashMap<String, Object>();










oamServerURL + ":" + oamPort);

The following snippets in LoginActivity#getMobileSecurityService() and LoginApplication#getMobileSecurityService() create a OMMobileSecurityService object:

if (mss == null)



mss = ((LoginApplication) getApplication())


new OMMobileServiceCallbackImpl());

  }  ...


public OMMobileSecurityService getMobileSecurityService(Context c,

OMMobileServiceCallback callback) throws OMMobileSecurityException {

if (!isMssInitialized) {

if (mOAMConfigMap != null) {

mss = new OMMobileSecurityService(c, mOAMConfigMap, callback);

isMssInitialized = true;



return mss;


The context argument is the context of the Application object. Pass the context that is returned by Context#getApplicationContext(). The callback argument specifies an instance of a class that has implemented the interface OMMobileServiceCallback. The SDK uses this to return control to the application after calling OMMobileSecurityService#setup() and OMMobileSecurityService#authenticate().


You need to register the current activity with the SDK before invoking certain methods in the OMMobileSecurityService, such as setup(), authenticate(), processSSORequest(), and processHttpRequest() and deregister the activity when it is not in the foreground. This is done to ensure that there are no memory leaks. To give the reference to the current activity, register the current activity in onResume() and deregister the activity in onPause() for activities that call the methods mentioned previously. If you call any of these methods in onCreate() of the activity, register the activity before calling these methods. To deregister the activity, when the activity moves to the background, use the OMMobileSecurityService#deregisterActivity() method.

LoginActivity#getMobileSecurityService() and LoginActivity#OnResume() registers the current activity in our sample application:

private OMMobileSecurityService getMobileSecurityService()


if (mss == null)





if (mss != null)




protected void onResume()



if (mss != null)







The setup method gets the configured security policies and the application profile from the Mobile and Social server. This method also gets a list of the service endpoints (the URLs) that are required for connecting to the authentication, authorization, and user profile services on the Mobile and Social server. This is an asynchronous call. When the application profile download completes, or if a problem like network unavailability is encountered, the SDK returns control to the calling activity by calling callback.processSetupResponse(OMApplicationProfile profile, OMMobileSecurityException mse). If the application profile could not be downloaded, the exception details can be found in OMMobileSecurityException mse. The SDK downloads and stores the application profile. The SDK will not download the application profile on subsequent calls to OMMobileSecurityService#setup() until the ProfileCacheDuration setting has expired. The ProfileCacheDuration setting is defined in the application profile.

The following snippets in LoginActivity#OnClickView() and LoginActivity#initSetUp() invoke setup() on the OMMobileSecurityService object:

public void onClick(View v)


switch (v.getId())




if (!((LoginApplication) getApplication())






private void initSetUP()


mss = null;

if (getMobileSecurityService() != null)




The following snippet in LoginActivity#OMMobileServiceCallbackImpl#processSetupResponse() implements the logic when the SDK returns control back to the application after performing setup:

public void processSetupResponse(OMApplicationProfile profile, OMMobileSecurityException mse)


if (profile != null)


((LoginApplication) getApplication()).setSetupCompleted(true);

Toast.makeText(LoginActivity.this, "Setup Done",






Toast.makeText(LoginActivity.this, "Setup failed",


((LoginApplication) getApplication()).setSettingsFailedOAM();


mss = null;




Once the setup successfully completes, the business application can perform authentication by either calling OMMobileSecurityService#authenticate() or OMMobileSecurityService#processSSORequest(). Use the processSSORequest()instead of authenticate() if your app also needs to act as an SSO agent—the OMMobileSecurityService#processSSORequest() supports both self authentication as well as the ability to allow the app to act as an SSO agent.

Both these calls are asynchronous calls and the SDK will return control to the application once authentication is completed or if authentication has failed for some reason. The control will be returned to the application through OMMobileServiceCallback#processAuthenticationResponse(OMAuthenticationContext context, OMMobileSecurityException mse). All the details with respect to the authenticated session are available in the OMAuthenticationContext context. If authentication fails for some reason, the details are available in OMMobileSecurityException mse. If an application (SSO client) needs to authenticate using the SSO Agent App, the main activity has to call OMMobileSecurityService#processSSORequest(intent)

The authenticate() and the processSSORequest() methods return a ViewFlipper object that holds the processing view. When the view is focused it will trigger the actual authentication flow. If a valid authentication context is already available in the cache for the above request, then it will return control back to the calling business application without performing any request to the server.

The following snippet in LoginActivity#OnClickView() demonstrates authentication:

authView= getMobileSecurityService().authenticate();

LinearLayout.LayoutParams params = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.MATCH_PARENT, LinearLayout.LayoutParams.MATCH_PARENT); relLayout.addView(authView, 1, params);

The following snippet in LoginActivity#OMMobileServiceCallbackImpl#processAuthenticationResponse implements the logic when the SDK returns control back to the application after performing authentication:

public void processAuthenticationResponse(OMAuthenticationContext context, OMMobileSecurityException mse)


Log.d(TAG, "Process authentication response() context = " + context);

String msg;

if (context == null)


isAuthenticated = false;




isAuthenticated = true;



if (authView != null)


if (isAuthenticated)


Intent i = new Intent();


i.putExtra(LoginConstants.USER_AUTHENTICATED, true);

startActivityForResult(i, LoginConstants.AUTH_SUCCESS);




Offline Authentication

Mobile and Social from R2PS1 onwards supports offline authentication. This feature requires that first the “Offline Authentication” setting is enabled in the Application Profile in the OAM Admin Console. Next, while initializing the SDK to create the OMMobileSecurityService object, add the OM_PROP_CONNECTIVITY_MODE key as a parameter to the Map<String,Object> as shown earlier in the Initialize section . You can specify the way that offline authentication should happen by providing one of the following values to this key:

OMConnectivityMode.ONLINE - Always authenticate with the server. Fails if device cannot reach the Internet.

OMConnectivityMode.OFFLINE - Authenticates locally with cached credentials. Offline authentication happens even if the device is online and can reach the server.

OMConnectivityMode.AUTO - Authentication happens with the server if the server is reachable and happens offline if the device is not connected to the Internet.

Invoking Relying Party Authentication

From an SDK perspective, Relying Party Authentication is identical to invoking Authentication Services as outlined above. Additionally, there are two areas to be considered:

1. To authenticate using a Relying Party, the data scheme in the main activity of the application should match the URL scheme configured in the Application profile. The main activity is the activity that has the <data android:scheme="xyz" /> in its <intent-filter> in the Android Manifest and xyz should be the same as the URL scheme configured in the Application profile. Finally, the main activity name is the name that should be used as the Android Package name in the Application Profile configuration.

2. If your apps will authenticate against different OAM servers, or with the same OAM server but different authentication schemes, then one OMMobileSecurityService instance should be created for every server or authentication scheme. So, for example, in this case since the same Login app authenticates against OAM server and against Facebook for different use cases, we need to create separate instances of OMMobileSecurityService to handle each use case.

Invoking REST Services

The Mobile SDK makes it easy to securely access REST services that are protected by OAM. The Android Client SDK automatically injects an access token when invoking an OAM R2 Webgate protected REST resource. It maintains a cache of access tokens that it has obtained during the mobile application's lifetime. It then either fetches an access token for the webgate from its cache or if an access token for the Webgate is not available in the Mobile and Social SDK cache, it sends a REST request to the Mobile and Social server to obtain the Access Token for the Webgate--provided the resource is protected by an Access Management 11g R2 Webgate. If a valid user token is not found for the current application (for example, if the user is not authenticated), the SDK throws an exception.

The following snippet in AccountStatement#RetrieveSummary demonstrates invoking a REST service:

class RetriveSummary extends AsyncTask<String, Integer, ArrayList<String>>



protected ArrayList<String> doInBackground(String... params)


// super.

ArrayList<String> resultList = new ArrayList<String>();

if (mss != null)


Log.d("AccountStatement", "rest service = " + restService);

// create a Http Request with the webservice

HttpRequest httpreq = new HttpGet(restService);

// in order to access the protected web service add the user-agent which is configured in the webgate settings.

httpreq.setHeader("User-Agent", "OIC-Agent");



// invoke sdk processHttpRequest() on the mss instance.

HttpResponse response = mss.processHttpRequest(httpreq);

final JSONArray array;



array = new JSONArray(parseHttpResponse(response));

for (int i = 0; i < array.length(); i++)





catch (IOException e)





catch (OMMobileSecurityException e)




catch (JSONException e)




return resultList;


return resultList;


As can be seen above, the Mobile and Social Android Client SDK provides a simple OMMobileSecurityService#processHttpRequest(HttpRequest httpRequest) method to access REST Web services or any Web resource protected by Access Manager. However, the "user-agent" http header value must be set to the OAMAuthUserAgentPrefix value that is defined in the webgate configuration to activate non browser client functionality.


Kanishk Mahajan is Senior Manager, Product Management in Oracle Identity Management


« July 2016