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.

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


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


« June 2016