Upload
wso2-inc
View
343
Download
0
Embed Size (px)
Citation preview
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