By Kanishkmahajan-Oracle on Aug 20, 2015
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: https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-23. 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.