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.

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.

Friday Oct 25, 2013

Using the OAM Mobile & Social SDK to secure native mobile apps - Part 2 : OAM Mobile & Social Server configuration

In the second part of this blog post I'll now cover configuration of OAM to secure our sample native apps developed using the iOS SDK. First, here are some key server side concepts:
  • Application Profiles: An application profile is a logical representation of your application within OAM server. It could be a web (html/javascript) or native (iOS or Android) application. Applications may have different requirements for AuthN/AuthZ, and therefore each application that interacts with OAM Mobile & Social REST services must be uniquely defined.
  • Service Providers: Service providers represent the back end services that are accessed by applications. With OAM Mobile & Social these services are in the areas of authentication, authorization and user profile access. A Service Provider then defines a type or class of service for authentication, authorization or user profiles. For example, the JWTAuthentication provider performs authentication and returns JWT (JSON Web Tokens) to the application. In contrast, the OAMAuthentication also provides authentication but uses OAM SSO tokens

  • Service Profiles:  A Service Profile is a logical envelope that defines a service endpoint URL for a service provider for the OAM Mobile & Social Service. You can create multiple service profiles for a service provider to define token capabilities and service endpoints. Each service provider instance requires atleast one corresponding service profile.The  OAM Mobile & Social Service includes a pre-configured service profile for each pre-configured service provider.

  • Service Domains: Service domains bind together application profiles and service profiles with an optional security handler.

    So now let's configure the OAM server. Additional details are in the OAM Documentation and this post simply provides an outline of configuration tasks required to configure OAM for securing native apps. 


    Create The Application Profile

    Log on to the Oracle Access Management console and from System Configuration -> Mobile and Social -> Mobile Services, select "Create" under Application Profiles. You would do this  step twice - once for each of the native apps - AvitekInventory and AvitekScheduler. Enter the parameters for the new Application profile:

    • Name:  The application name. In this example we use 'InventoryApp' for the AvitekInventory app and 'SchedulerApp' for the AvitekScheduler app. The application name configured here must match the application name in the settings for the deployed iOS application.
    • BaseSecret: Enter a password here. This does not need to match any existing password. It is used as an encryption key between the client and the OAM server. 
    • Mobile Configuration: Enable this checkbox for any mobile applications. This enables the SDK to collect and send Mobile specific attributes to the OAM server. 
    • Webview: Controls the type of browser that the iOS application will use. The embedded browser (default) will render the browser within the application. External will use the system standalone browser. External can sometimes be preferable for debugging
    • URLScheme: The URL scheme associated with the iOS apps that is also used as a custom URL scheme to register O/S handlers that will take control when OAM transfers control to device. For the AvitekInventory and the AvitekScheduler apps I used osa:// and client:// respectively. You set this scheme in Xcode while developing your iOS Apps under Info->URL Types. 
    • Bundle Identifier : The fully qualified name of your iOS application. You typically set this when you create a new Xcode project or under General->Identity in Xcode. For the AvitekInventory and AvitekScheduler apps these were and respectively

    Create The Service Domain

    Select create under Service domains. Create a name for your domain (AvitekDomain is what I've used). The name configured must match the service domain set in the iOS application settings. Under "Application Profile Selection" click the browse button. Choose the application profiles that you created in the previous step one by one. Set the InventoryApp as the SSO agent (with an automatic priority of 1) and the SchedulerApp as the SSO client. This associates these applications with this service domain and configures them in a 'circle of trust'. 

    Advance to the next page of the wizard to configure the services for this domain. For this example we will use the following services: 

    • Authentication:   This will use the JWT (JSON Web Token) format authentication provider. The iOS application upon successful authentication will receive a signed JWT token from OAM Mobile & Social service. This token will be used in subsequent calls to OAM. Use 'MobileOAMAuthentication' here.

    • Authorization:  The authorization provider. The SDK makes calls to this provider endpoint to obtain authorization decisions on resource requests. Use 'OAMAuthorization' here.

    • User Profile Service:  This is the service that provides user profile services (attribute lookup, attribute modification). It can be any directory configured as a data source in OAM. 

    And that's it! We're done configuring our native apps. In the next section, let's look at some additional features that were mentioned in the earlier post that are automated by the SDK for the app developer i.e. these are areas that require no additional coding by the app developer when developing with the SDK as they only require server side configuration:

    Additional Configuration 
    Offline Authentication

    Select this option in the service domain configuration to allow users to log in and authenticate to the application locally. Clear the box to block users from authenticating locally.

    Strong Authentication

    By simply selecting the OAAMSecurityHandlerPlugin while configuring mobile related Service Domains, the OAM Mobile&Social service allows sophisticated device and client application registration logic as well as the advanced risk and fraud analysis logic found in OAAM to be applied to mobile authentication. Let's look at some scenarios where the OAAMSecurityHandlerPlugin gets used.

    First, when we configure OAM and OAAM to integrate together using the TAP scheme, then that integration kicks off by selecting the OAAMSecurityHandlerPlugin in the mobile service domain. This is how the mobile device is now prompted for KBA,OTP etc depending on the TAP scheme integration and the OAM users registered in the OAAM database. Second, when we configured the service domain, there were claim attributes there that are already pre-configured in OAM Mobile&Social service and we simply accepted the default values- these are the set of attributes that will be fetched from the device and passed to the server during registration/authentication as device profile attributes. When a mobile application requests a token through the Mobile Client SDK, the SDK logic will send the Device Profile attributes as a part of an HTTP request. This set of Device Profile attributes enhances security by creating an audit trail for devices that assists device identification. When the OAAM Security Plug-in is used, a particular combination of Device Profile attribute values is treated as a device finger print, known as the Digital Finger Print in the OAAM Administration Console. Each finger print is assigned a unique fingerprint number. Each OAAM session is associated with a finger print and the finger print makes it possible to log (and audit) the devices that are performing authentication and token acquisition. Finally, if the jail broken option is selected while configuring an application profile, the SDK detects a device is jail broken based on configured policy and if the OAAM handler is configured the plug-in can allow or block access to client device depending on the OAAM policy as well as detect blacklisted, lost or stolen devices and send a wipeout command that deletes all the mobile &social relevant data and blocks the device from future access.

    Social Logins

    Finally, let's complete this post by adding configuration to configure social logins for mobile applications. Although the Avitek sample apps do not demonstrate social logins this would be an ideal exercise for you based on the sample code provided in the earlier post. I'll cover the server side configuration here (with Facebook as an example) and you can retrofit the code to accommodate social logins by following the steps outlined in "Invoking Authentication Services" and add code in LoginViewController and maybe create a new delegate - AvitekRPDelegate based on the description in the previous post.

    So, here all you will need to do is configure an application profile for social login, configure a new service domain that uses the social login application profile, register the app on Facebook and finally configure the Facebook OAuth provider in OAM with those settings. Navigate to Mobile and Social, click on "Internet Identity Services" and create a new application profile. Here are the relevant parameters for the new application profile (-also we're not registering the social user in OAM with this configuration below, however that is a key feature as well):

    • Name:  The application name. This must match the name of the of mobile application profile created for your application under Mobile Services. We used InventoryApp for this example.

    • SharedSecret: Enter a password here. This does not need to match any existing password. It is used as an encryption key between the client and the OAM Mobile and Social service. 

    • Mobile Application Return URL: After the Relying Party (social) login, the OAM Mobile & Social service will redirect to the iOS application using this URI. This is defined under Info->URL type and we used 'osa', so we define this here as 'osa://'

    • Login Type: Choose to allow only internet identity authentication for this exercise.

    • Authentication Service Endpoint : Make sure that /internetidentityauthentication is selected.

    Login to using your Facebook account and click on Apps and register the app as InventoryApp. Note that the consumer key and API secret gets generated automatically by the Facebook OAuth server. Navigate back to OAM and under Mobile and Social, click on "Internet Identity Services" and edit the Facebook OAuth Provider. Add the consumer key and API secret from the Facebook developers site to the Facebook OAuth Provider:

    Navigate to Mobile Services. Click on New to create a new service domain. In this example we call the domain "AvitekDomainRP". The type should be 'Mobile Application' and the application credential type 'User Token'. Add the application "InventoryApp" to the domain. Advance the next page of the wizard. Select the  default service profiles but ensure that the Authentication Service is set to 'InternetIdentityAuthentication'. Finish the creation of the service domain.


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


    « July 2016