WSO2Uvindra Dias Jayasinha

Extended Security with WSO2 API

Management Platform

30th April, 2015

**

About the Presenter

Uvindra joined WSO2 in November 2013. He is a SeniorSoftware Engineer in the WSO2 API Manager Team. Hehas a background in Telecom Billing Systems andFinancial Trading systems, including High PerformanceSoftware development

**

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

**

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

**

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 toobtain limited access to an HTTP service, either on behalf of a resource owner byorchestrating an approval interaction between the resource owner and the HTTPservice, or by allowing the third-party application to obtain access on its ownbehalf." [1]

[1] http://tools.ietf.org/html/rfc6749

**

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

**

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

**

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

**

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

**

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

**

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

**

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

**

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.

**

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

**

Federated Identity

● Demo Scenario - Using Facebook as a Federated identity provider to act as a Auth Server to obtain a

API Access Token

**

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.

**

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

**

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

**

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/

Contact us !