×

IDMWORKS Blog

Injecting OAuth With SAML Using OGNL


Enterprises with existing SAML 2.0 based Single Sign-On (SSO) may need to provide support for OAuth 2.0 (in future) to enable various mobile, consumer and social applications to grow their business. The purpose of this blog is to provide a simple implementation of these two technologies working together.

Terminologies in OAuth 2.0 & SAML 2.0

1. Identity Provider – It is the enterprise which will use its identity to access any services from the external vendor. It is the issuer of the SAML Assertion.

2. Service Provider – It’s the 3rd party vendor which will allow the enterprises to access its system with their native enterprise identity. It is the consumer of the SAML Assertion.

3. Resource Owner – The resource owner is the user who authorizes an application to access their account.

4. Resource Server – This is the web-server from where you are trying to access information. The resource server hosts the protected user accounts.

5. Client – This could be a browser-based web app, a native mobile app, a desktop app, or a server-side app. This acts as a medium for user to communicate with the Resource server.

6. Authorization Server – This is the server that owns the users’ identities and credentials. It verifies the identity of the user and issues access tokens to the application.

7. OAuth Access Tokens – Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. OAuth tokens can be limited by:
● Scope- what clients are allowed to ask for. For ex- the app can only see your contact list.
● Time- duration of the limit of access token can be set.
● Action- what action is needed to be taken by access token. Ex- read only.

 

SAML 2.0

SAML (Security Assertion Markup Language) is an XML Based protocol created by OASIS (Organization for the Advancement of Structured Information Standards) that used security Assertions to pass information between SAML Authority (Identity Provider) and SAML Consumer (Service Provider).

SP Initiated SSO Flow

OAuth2.0

OAuth 2.0 is an open protocol that allows an application to access user’s information from another webservice without revealing the identity or credentials of the user. It is an open standard for authorization.

 

Advantages of OAuth 2.0
1.  It provides secure delegated access, meaning that an application, called a client, can take actions or access resources on a resource server on the behalf of a user, without the user sharing their credentials with the application.

2. People find sign up and account creation tedious, and rightly so. Consumer web sites and apps may suffer abandoned shopping carts because of that, which means loss of business and sales.

3. It doesn’t require the request signing procedure, which is not exactly difficult but is certainly fiddly.

 

 

How we are going to Inject both Protocols together?

Though there are multiple ways to inject both the protocols together like exchanging SAML with OAuth using SAML Bearer Assertion or having SAML Setup within OAuth flow, following is one of the better and easier way to achieve it.

1. First, xml data file is imported from the machine.

2. Through the file, the contents (Issuer id & Base URL) are updated automatically on the Ping Federate server.

3. SP & IDP Initiated use case is then enabled (based on the requirement).

4. After enabling the Use Case, the Issuer id is configured with the Adapter which has its own set of attributes mapped.

5. In IDP (Identity Provider) we can define an attribute as API Token and at run time we will generate an access token using an OGNL (Object Graph Navigation Language) expression in ping federate.

6. In Ping Federate SDK there is an Access Token Issuer Interface where it will request an access token and then that access token will be inserted into the SAML Assertion. Example of passing OAuth access token through OGNL Expression is below:

#attrs = new java. util.HashMap(),attrs.put(“uid”,#this.get(“username”)),attrs.put(“email”, #this.get(“email”)), #val = @com.pingidentity.sdk.oauth20.AccessTokenIssuer@issueToken(#attrs,”scope”,”issuer id”)

 

The above expression will issue a new access token and return the opaque token value as the result of evaluating the expression. That value will be assigned as the attribute value for whatever field the expression is mapped into. In this example, the access token will have two attributes “uid” and “email”. The values of those attributes are the values of the “username” and “email” attributes, respectively, from the attributes input into the mapping.

7. SAML Bindings based on the requirement is allowed. On General basis POST & Redirect is allowed.

8. SAML Attributes will POST to the defined Assertion Consumer Service URL.

9. Service Provider can use the access token and call the API. So, Service Provider will insert the access token into a standard authorization header and then calls the OAuth protected API.

OAuth with SAML Flow

1. Service Provider will generate an AuthnRequest that is sent to the Identity Provider (name of the service is the saml2AuthnRequest).

2. User will be prompted to login to Identity Provider where they will enter their credentials and gets authenticated.

3. OAuth access token is dynamically generated and inserted into the SAML Assertion along with the standard user attributes.

4. Service Provider will validate SAML Assertion and passes attribute into target application.

5. Service Provider can then make use of Access tokens to make API calls back to Identity Provider.

Benefits of having OAuth with SAML

1. Systems which already use SAML for both authentication and authorization and want to migrate to OAuth as a means of authorization will be facing the challenge of integrating the two together. It makes sense for such systems to keep using SAML as it is already set up as an authentication mechanism.

2. It allows API access for existing federation partners.

3. It involves a simple implementation where a custom attribute is passed in SAML Attribute Fulfilment.

4. It is less complex to distribute OAuth access tokens within the SAML Attribute by using OGNL (Object Graph Navigation Language) Expression.

5. It is useful to integrate SAML based mobile applications.

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *