The rapid growth of organizations, ever changing company policies, mergers and acquisitions often lead to the need for complex identity solutions that require integration with multiple heterogeneous systems. This makes traditional centralized identity management systems no longer viable.
Identity federation is now adopted as a solution for such complex systems. It allows you to link multiple identities that belong to different trust domains by means of a common set of policies, practices and protocols.
Join Darshana and Omindu in this webinar as they explore
The challenges of introducing identity federation with use cases
How to leverage identity federation patterns to overcome these challenges
3. 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
5. ▪ 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
7. Agenda
▪ Need of the Identity Federation in reality
▪ Identity Federation is the solution!
▪ Capabilities of an Identity Broker
▪ Federation Problems & Patterns
▪ Q&A
7
9. 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
10. ▪ 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
12. What “Identity Federation” means
Connecting,
a person's digital identity and attributes,
stored across multiple distinct trust domains
12
13. 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
14. 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
15. ▪ Protocol Agnostic
▪ Claim Transformation
▪ Multi-option Multi-step authentication
▪ Trust brokering
▪ Home Realm Discovery
▪ Adaptive Authentication
Capabilities of an Identity Broker
15
16. ▪ Account Association
▪ Multiple Attribute Stores
▪ Just In Time Provisioning
▪ Manage Identity Relationships
▪ Centralized Access Control
▪ Centralized Monitoring & Analytics
Capabilities of an Identity Broker
16
18. 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
19. 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
20. 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
21. Pattern 2.1: Inter-Domain Token Exchange
▪ Establish a trust relationship between the two Identity Providers residing in each trust
domain.
21
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. ▪ Federated authorization caters complex authorization requirement
▪ XACML can be used to define complex policies and evaluated authorization
requests
28
Pattern 4: Federated Authorization
29. 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
30. 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
31. 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
32. 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