Identity Federation Patterns with WSO2 Identity Server

June 18, 2017

Darshana GunawardanaOmindu Rathnaweera

1

2017 Summer School Webinar Series

2

About WSO2

▪ All WSO2 products 100% free and open source▪ Licensed under Apache 2.0▪ Based on WSO2 Carbon platform▪ Componentized, modular architecture▪ Founded in 2005

3

WSO2 Platform

4

▪ Currently in its 5th generation▪ Latest release - WSO2 Identity Server 5.3.0▪ Addresses critical IAM needs both in customer IAM and workforce IAM

spaces▪ Extensive support for open standards - no vendor locking▪ Large scale deployments over millions of users▪ Rich eco system with 40+ connectors

(https://store.wso2.com/store/assets/isconnector/list)▪ Support for multi-tenancy▪ Extensible product architecture to address complex IAM needs

About WSO2 Identity Server

5

Identity Federation Patterns

withWSO2 Identity

Server6

Agenda

▪ Need of the Identity Federation in reality▪ Identity Federation is the solution!▪ Capabilities of an Identity Broker▪ Federation Problems & Patterns▪ Q&A

7

Need of the

Identity Federation in reality

8

Evolution of the web

▪ Web 1.0 Static content Limited users-sites interaction Identity was not portable

▪ Web 2.0 Interactive data Allows users-sites interaction User Centric Identity

▪ Web 3.0 Predicted content Identity of things

9

▪ For an consumer Ability to access the services with minimum effort

▪ For an enterprise Ability to quickly adopt to new business demands Adhere with complex corporate policies of,

▪ password policies▪ strong authentication▪ login policies etc.▪ to comply with regulations

▪ In general: provide seamless user experience for a better productivity without compromising security

IAM Requirements

10

Identity Federation is the

Solution!

11

What “Identity Federation” means

Connecting,a person's digital identity and attributes,

stored across multiple distinct trust domains

12

Elevated Security▪ Identity federation leverages widely adopted standard, secure and mature

protocols (SAML, OpenID and OAuth) ▪ Eliminate maintaining multiple credentials▪ Enables Single Sign-On (SSO)▪ Can introduce Multi-Factor Authentication (MFA)

Benefits of Identity Federation

13

Cost Benefits▪ Introduce standard access control for enterprise apps with minimum effort

with a shortest possible time▪ Eliminates the requirement of implementing proprietary SSO mechanism▪ Secure legacy apps with modern security specification without additional

development effort▪ Adaptation to latest security trends and organizational security

requirements with minimum effort

Benefits of Identity Federation

14

▪ Protocol Agnostic▪ Claim Transformation▪ Multi-option \ Multi-step authentication▪ Trust brokering▪ Home Realm Discovery▪ Adaptive Authentication

Capabilities of an Identity Broker

15

▪ Account Association▪ Multiple Attribute Stores▪ Just In Time Provisioning▪ Manage Identity Relationships▪ Centralized Access Control▪ Centralized Monitoring & Analytics

Capabilities of an Identity Broker

16

Federation Problems&

Patterns

17

Problem 1: Utilize a Single Identity Across Multiple Heterogeneous Service Providers

▪ The business users need to access multiple service providers supporting multiple heterogeneous identity federation protocols.

18

Pattern 1: Identity Federation between Multiple Heterogeneous Identity Federation Protocols

Pros▪ Single Sign On ▪ Separate user authentication from application code▪ Hides user credentials from applications▪ Removes administrative overhead from applications▪ Improves user experience

Cons▪ Introduce a single point where the security of the system can be breached

19

Problem 2: Consuming Multiple Services Across Different Trust Domains

▪ The business users need to utilize services beyond enterprise borders. The cross border interaction typically implies interacting with services residing under a different trust domain. The interaction may need to be done with or without having dependencies with the external trust domain entities.

20

Pattern 2.1: Inter-Domain Token Exchange

▪ Establish a trust relationship between the two Identity Providers residing in each trust domain.

21

Pattern 2.1: Inter-Domain Token Exchange

Pros▪ Flexible in maintaining trust domains▪ Facilitates federated interactions between consumers and services across

trust domains▪ Same model can be extended to address more complex federation

scenarios

Cons▪ Introduces certain level of dependency between the consumer and the

Identity Provider in the other trust domain

22

Pattern 2.2: Intra-Domain Token Exchange

▪ Interact with a service developed in a federated trust domain, without any dependencies to entities in the other trust domain.

23

Pattern 2.2: Intra-Domain Token Exchange

Pros▪ Removes dependencies between consumers and service in different trust

domains▪ Can handle different token claim representations

Cons▪ Adds complexity to the mechanism used to model the trust relationship

with the Identity Provider in the other trust domain▪ Makes the services to accept messages that are not issued by the Identity

Provider that they trusts

24

Problem 3: Identity Silos and Spaghetti Identity

▪ Localized groups of service providers operating in different protocols Introduces difficulties when it requires interoperability between the service provider groups

▪ Each service provider has to trust each identity provider▪ Not scalable and hard to manage

25

Spaghetti Identity

Identity Silos

Pattern 3: Identity Bus

Pros▪ Simplicity introducing new trusted domains / service providers▪ Loosely coupled▪ Reduces deployment complexity

Cons▪ Increased latency due to the intermediate bus▪ Single point of failure

26

Problem 4: Need of Dynamic and Fine-Grained Authorization Policies

▪ Organizational policies may require securing services beyond typical authorization mechanisms

▪ Service provider needs to define a complex authorization policy to decide whether a given user is eligible to access a certain resource

27

▪ Federated authorization caters complex authorization requirement▪ XACML can be used to define complex policies and evaluated authorization

requests

28

Pattern 4: Federated Authorization

Pattern 4: Federated Authorization

Pros▪ Authorization implementation is decoupled from the application code base▪ Supports securing services with complex authorization policies▪ Avoid duplication of authorization policies across all the applications

Cons▪ Not widely adapted compared to federated authentication.

29

Problem 5: Lack of Support for Federated Authorization

▪ Even if the authentication is federated, most systems does not support authorization in a federated manner. Hence, the SP requires to persist user information up to a certain degree in order to perform authorization

30

Pattern 5.1: Federated Unidirectional Provisioning

▪ User interaction is directly with the identity provider▪ IdP initiates the outbound provisioning for service providers▪ Service providers receives a bare minimum amount of information.

31

Pattern 5.2: Federated Bidirectional Provisioning

▪ Built on top of unidirectional provisioning▪ User can interact directly with either service provider or the identity

provider▪ Service provider or identity provider initiates outbound provisioning

32

Q&A

33

What next?

34

OPEN TECHNOLOGY FOR YOUR AGILE DIGITAL BUSINESS

THANK YOU

35