Uvindra Jayasinha from WSO2 presented on extending security with the WSO2 API Management platform. He covered best practices for OAuth 2.0 access tokens, adding SAML single sign-on, federated identity with third-party providers, enforcing fine-grained entitlement policies, and accessing user attributes. The presentation explained key OAuth concepts like grant types, actors, and tokens. It also described using SAML assertions, XACML policies, and JWT claims to pass user information and control access.

1. WSO2
Uvindra Dias Jayasinha
Extended Security with WSO2 API
Management Platform
30th April, 2015

2. **
About the Presenter
Uvindra joined WSO2 in November 2013. He is a Senior
Software Engineer in the WSO2 API Manager Team. He
has a background in Telecom Billing Systems and
Financial Trading systems, including High Performance
Software development

3. **
Agenda
● Best practices when requesting OAuth 2.0 Access Tokens
● Adding SAML based Single Sign On (SSO) capabilities to API management and
leveraging SAML2 Bearer Tokens to request OAuth 2.0 Access Tokens
● Federated identity: How to use a third-party identity provider with API
Manager
● Enforcing fine-grained entitlement policies at the API management layer
● Accessing API user's attributes to make decisions

4. **
APIs and Security
Exposing Services as APIs means we need to address how those APIs are going to
be secured
● Primarily protecting APIs via API Access Tokens
● But also so much more than that…...
❏ Forced to deal with different kinds of users and applications
❏ One size does not fit all when it comes to security

5. **
OAuth 2.0 - The Cornerstone
OAuth definition from the OAuth 2.0 IETF specification -
"The OAuth 2.0 authorization framework enables a third-party application to
obtain limited access to an HTTP service, either on behalf of a resource owner by
orchestrating an approval interaction between the resource owner and the HTTP
service, or by allowing the third-party application to obtain access on its own
behalf." [1]
[1] http://tools.ietf.org/html/rfc6749

6. **
OAuth 2.0 - Grant Types
Depending on the trustworthiness of the application that is
trying to access the API, oauth provides different methods
that can be used for granting access
● Authorization Code
● Password(Resource Owner Credentials)
● Client Credentials
● Implicit

7. **
Understanding the actors involved
Resource owner
The Person who owns the data or has rights to the data that will be exposed by the Service via an
API
Resource Server
The server that hosts the actual Service/API that exposes the data
Application
Considered as the ‘client’ in OAuth circles. The one requesting access to the API
Auth Server
Grants access to the Application after authenticating it with the Resource Owner

8. **
Key OAuth concepts
Client ID
A unique string representing an Application registered with the Auth Server
Client Secret
A secret password that is used by the Auth Server to authenticate if the Application is an authorized Application
Access Token
A key provided by the Auth Server to the Application which allows access to a given API for a limited amount of
time. After the time expires the key will be considered invalid
Refresh Token
A secondary key that can be used by the Application to request a new Access Token from the Auth Server

9. **
Authorization Code Grant Type
Category of Application - 3rd Party untrusted
Locality of Application - Resides remotely from the Resource Owner
● Resource Owner gets involved initially to decide if the Auth Server should grant API access to the
Application
● ‘Auth Code’ is returned by Auth Server to the Application which uses it to request Access + Refresh
Tokens from the Auth Server
● The Application may store the Access + Refresh Tokens and reuse them to access the API, no longer
needing intervention from the Resource Owner
● Considered the most secure grant type

10. **
Implicit Grant Type
Category of Application - 3rd Party untrusted
Locality of Application - Resides locally to the Resource Owner(eg: Web browser, Mobile device)
● A simplified version of the Authorization Code grant type with the elimination of the Auth Code
issuing step
● Since Resource Owner is present in proximity to App there is nothing to be gained by issuing an Auth
Code
● Once Resource Owner approves App, Auth Server provides Access Token directly to App
● Access Token validity periods should be relatively short, no Refresh Token is issued
● App should rely on the Resource Owner to get involved again to get a new Access Token

11. **
Password Grant Type
Category of Application - 3rd Party trusted
● Since the App is trusted the Resource Owner is able to share their own username and password
directly with the App
● By providing their credentials to the App, the Resource Owner is delegating authority to the App to
authenticate itself with the Auth Server and get Access + Refresh Tokens

12. **
Client Credentials Grant Type
Category of Application - Resource Owners App
● Since the App belongs to the Resource Owner there is no need to authenticate the App via the
Resource Owners credentials or require that the Resource Owner get involved to help the Auth
Server decide if access should be granted
● All that is required by the Auth Server is to identify if the App requesting the Access Token is in fact
the Resource Owners App
● The App only needs to provide the Client ID and Client Secret to the Auth Server to get the Access
Token

13. **
Single Sign On
● The WSO2 API Management platform can be configured to support SAML 2.0 based SSO
● Security Assertion Markup Language 2.0 - XML-based protocol that uses security tokens containing
assertions to pass information about a principal (usually an end user) between a SAML authority,
that is, an identity provider, and a SAML consumer, that is, a service provider
● SAML is a widely established means of identity federation in enterprises.

14. **
Advantage of SAML based SSO
● Provides convenience when working with multiple store/publisher web applications
● Reduces password fatigue
● Able to exchange the SAML token issued by the Identity Provider for an OAuth 2.0 access token,
avoiding the need to explicitly be authenticated by an Auth 2.0 Auth Server. This is an advantage for
enterprises that already have an existing SAML identity provider

15. **
Federated Identity
● Demo Scenario - Using Facebook as a Federated identity provider to act as a Auth Server to obtain a
API Access Token

16. **
Fine-grained entitlement policies
● API Manager supports Auth 2.0 scopes to restrict access to API resources based on user roles
● But when more fine grained entitlement policies are required XACML policies can be used
● XACML stands for "eXtensible Access Control Markup Language", which defines a declarative access
control policy language implemented in XML and a processing model describing how to evaluate
access requests according to the rules defined in policies.

17. **
Accessing API users attributes to
make decisions
● Its often useful for the API hosting service to make decisions based on information associated with
the user who initiated the API invocation such as,
○ Username of end user
○ The organization the end user is associated with
○ The email of the end user
○ The gender of the end user

18. **
Passing Claims via JWT
● Claim - user attribute that is mapped to the underlying user store
● Claim dialect - A set of predefined claims
● API Manager can be configured to pass a Claim Dialect via a JSON Web Token[1] to the back end API
along with the API invocation
[1] http://openid.net/specs/draft-jones-json-web-token-07.html#anchor3

19. **
Resources
● [Article] OAuth2 Grant Types and Need For Implicit Grant for JavaScript and Mobile Applications
http://wso2.com/library/articles/2014/12/article-
oauth2-grant-types-and-need-for-implicit-grant-for-javascript-mobile-applications/
● What is the purpose of the implicit grant authorization type in OAuth 2?
http://stackoverflow.com/questions/7522831/what-is-the-purpose-of-the-implicit-grant-authorization-type-in-oauth-2
● Enforcing fine grained entitlement policies With XACML
http://xacmlinfo.org/2014/10/24/authorization-for-apis-with-xacml-and-oauth-2-0/

20. Contact us !