Extended Security with WSO2 API Management Platform
-
Upload
wso2 -
Category
Technology
-
view
381 -
download
6
Transcript of Extended Security with WSO2 API Management Platform
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 !