Date post: | 16-Apr-2017 |
Category: |
Technology |
Upload: | wso2-inc |
View: | 299 times |
Download: | 1 times |
For whom?● Looking to learn about Identity and Access Management Patterns to
solve real world business problems.● Some experience with Identity and Access Management
Technologies. E.g. Directories, SAML2, OAuth2 which are some of the most commonly used data standards / protocols for transporting Identity and Access Management data.
● Main focus is on Identity and Access Management Patterns.○ NOT Network Security○ NOT OS Security
2
Problem● Users to the system can come from multiple sources● A single user’s attributes can come from multiple sources● User credentials and attributes can come from separate sources
Solution● Mount multiple user stores for
user management and make the number and type of user stores transparent to the application
● Connect the credential stores and identity stores to the system and provide a unified view of the user's’ identity hiding away the complexity in aggregating those data
4
ProblemUsers will work with multiple applications in an enterprise. They will have to use specific credentials for each.
● Disjointed User Experience● Complicated user and account management● Security Threats
SolutionDelegate authentication to a trusted identity provider - Brokered Identity
6
Benefits● Single Sign On● Separate user authentication from application code ● Hides user credentials from applications● Removes administrative overhead from applications● Improves user experience
Limitations● Authentication can be a single point of failure.● Introduce a single point where the security of the entire system can
be breached
7
ProblemUsers will use applications across enterprise borders and cloud.
SolutionMultiple trust domains with multiple Identity Providers.Federated authentication based on the trust relationship
9
Benefits● Single Sign On● No need of managing accounts in the on premise userstore● Reduce administration overhead
LimitationsSecurity of the system can be compromised if any of the Identity Provider that your Identity Provider trusts are breached.
10
ProblemA consumer who is living in a trust domain needs to interact with a service that is developed in a federated trust domain
SolutionEstablish a trust relationship between the two Identity Providers residing in each trust domain.
IdP-A IdP-B
Consumer Service
Trust
Trust
Trust
Trust Domain A Trust Domain B
12
Benefits● 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
LimitationsIntroduces certain level of dependency between the consumer and the Identity Provider in the other trust domain
13
ProblemA consumer who is living in a trust domain needs to interact with a service that is developed in a federated trust domain, without any dependencies to entities in the other trust domain
SolutionConsumer presents the token to the service in the other trust domain.Service will validate the token with its Identity Provider.
IdP-A IdP-B
Consumer Service
TrustTrust
Trust
Trust Domain A Trust Domain B
15
Benefits● Removes dependencies between consumers and service in different
trust domains● Can handle different token claim representations
Limitations● 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
16
ProblemCreation of trust between Identity Providers can be complex. Ex: Cannot establish direct trust relationship as some identity information cannot be shared with partner company.
SolutionEstablish the trust relationship with a third party Identity Provider, that act as a bridge between other Identity Providers
IdP-A IdP-B
Consumer Service
Trust
Trust
Trust
Trust Domain ATrust Domain BIdP-C
Trust Trust
18
BenefitsIsolates the complexities of the federated environment from different trust domains
LimitationsIntroduces a new component that needs to maintained
19
Problem● Increasing no of Service Providers and Identity Providers
● Each Service Provider has to trust Each Identity Provider Not scalableHard to manage
Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2.html
Spaghetti
21
Problem● Multiple Identity Federation Protocols
SAML, OpenID Connect, WS-Federation etc.
● But federation systems relies on only one protocol Ex:
Silo of SAML FederationSilo of OpenID Connect Federation
Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2.html
Federation Silos
24
Benefits● Single Sign On across heterogeneous protocols● Identity federation between Service Providers and Identity Providers
with heterogeneous federation protocols● Scalability
Limitations● Authentication can be a single point of failure.● Introduce a single point where the security of the entire system can
be breached
26
ProblemService Providers may not be able to understand claims or roles of the subject, in the format issued by Identity Providers and vise versa.
SolutionConvert incoming claims to the expected format
Benefits● Process claims in a single point reducing the complexity of enforcing
brokered trust● Can be used with legacy systems
28
ProblemDigital identity fraud is still on the riseNeeds “strong” user authentication
SolutionUse two or more authentication factors● Something known to only the user (Knowledge based)
password, shared secret, PIN● Something held only by the user (Possession based)
security token, smart card, mobile device● Something inherent only to the user (Biometric)
facial recognition, fingerprint, voice recognition
30
ProblemMultiple domains essentially isolated due to lack of mutual inbound or outbound trust relationships.Service Providers opt for different login options
SolutionMultiple login options are presented to the user as per the Service Provider application.
32
ProblemNeeds “strong” user authentication, if and only if there is an actual risk.
SolutionProvide additional authentication steps, if and only if the risk profile (derived from a matrix of variables) is high.Enhance user experience
34
36
MAC vs. DAC
● Mandatory Access Control (MAC)○ Centralized security policy○ Users do not have the ability to override the policy
● Discretionary Access Control (DAC)○ Governs the ability of subjects to access objects○ Allows users the ability to make policy decisions and/or assign
security attributes.○ The traditional Unix system of users, groups, and read-write-
execute permissions is an example of DAC.
37
Access Control Patterns
● Access Matrix / Access Control Table / Access Control List● Role Based Access Control (RBAC)● Group Based Access Control● Claim Based Access Control● Policy Based● Hierarchical Authorization
○ Hierarchical Tenants○ Hierarchical Groups/Roles○ Hierarchical Resources
● Multilevel Access Control
ProblemConsumers need to access back-end APIs on behalf of the logged in user.
42
SolutionShould adhere to some access delegation protocolEx: OAuth
Exchange the authentication token to some access tokenSAML token, JSON Web Token (JWT)
Requirements● Transient Name IDs● Persistent Name IDs● Identity Protection● Identity Mapping● Identity Collision
51
53
ProblemSecuring a n-tier application● Securing only the top most layer● Expansion in the number and kinds of users● Heterogeneous devices● Unlimited connections● Who should be allowed to access the data?● Cannot protect from an attack originating from the local area
network within the company.● Who has already accessed the data?
Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2.html
54
Solution 1Impersonation and Delegation
● Delegation is the process of allowing another party to act on behalf of an identity.
● This process bestows upon a party the rights and privileges of another party to perform a set of tasks.
● Impersonation can be viewed as the most relaxed form of delegation, such that one identity is assigned the complete set of permissions of the impersonated identity.
55
Solution 2Trusted Subsystem● Trusted subsystem model implies that application services are trusted
to perform a specific set of application tasks.● Frequently, downstream services need to make application
authorization decisions.● To do so, the service must know the identity of the end user.● While the ability to flow the identity of the end user is an inherent
property of the delegation model, it is not so for the trusted subsystem model and special efforts must be made to include this feature.
Source : https://msdn.microsoft.com/en-us/library/aa905320.aspx#trstsubsysdes_topic6
56
Solution 2 Contd.Trusted Subsystem● Authenticate and verify the identity of the upstream or downstream
service they are communicating with.● Decide if the identified service is a trusted subsystem for a specific set
of application functions, including propagating identity claims.● Protect the integrity of the data being communicated between trusted
subsystem and downstream services. Besides application data and application plumbing data, such as the identity claims of the original user, must also be protected so that no man-in-the-middle can modify the identity information that is in transit.
57
Solution 2 Contd.Trusted Subsystem - Identity Flows
● Trusted subsystem generated identity tokens / Self-issued○ When downstream services trust the trusted subsystem to assert the
original caller's identity, without requiring additional evidence from other parties.
● Third party generated identity tokens / Self-contained○ When the downstream services trust the trusted subsystem to assert
claims regarding the original caller in conjunction with third party evidence that satisfies an additional set of security requirements.
● User self-signed tokens○ When the trusted subsystem is authorized to perform a set of
application functions and when there must be evidence from the original caller that the caller initiated the request.
● Identity/Credential Mapping○ Special function of the trusted subsystem role, where the goal is to
transform an identity to another related identity for the purpose of gaining access to downstream resources that only recognize the transformed identity.
61
Audit InterceptorRequirement● Log security incidents to trace system abuse:
○ Failed login attempts○ Unauthorized access attempts to services
Solution● All messages flow through the a gateway of the system.● Necessary auditing is done by the logging at the gateway.
62
Data Origin AuthenticationRequirement● Non-repudiation
Solution● Digital Signature
Data ConfidentialityRequirementProtect sensitive personal data during transmission from:● Tampering● unauthorized access
Solution● Digital Encryption
63
Message ScreeningRequirementMitigate damages to the system from messages with malicious content● SQL injection● X-Doc attacks
Solution● XML Schema validation.● Regular expression validation to avoid SQL injections contained in
strings.● An application of Perimeter Security
64
Replay Mitigation/DoS SafetyRequirementPrevent denial of service attacks caused by replaying valid messages.
Solution● Apply throttling rules at the entry point.● Validate message freshness by WS-Security mechanisms
(Timestamp/Nonce).● An application of Perimeter Security.
65
Exception Shielding
RequirementAvoid exposing sensitive data through exceptions.● Legacy application code might throw exceptions containing sensitive
information.● Need to filter those exceptions when system is exposed to external
parties.
Solution● Sanitize unsafe exception data by replacing it with non-harmful
exception message and give the right level of detail to the user.
66
References[1] https://msdn.microsoft.com/en-us/library/[2] http://soapatterns.org/[3] https://medium.facilelogin.com/thirty-solution-patterns-with-the-wso2-identity-server-16f9fd0c0389#.1f3slrjnt[4] http://wso2.com/library/blog-post/2014/10/blog-post-identity-anti-patterns-federation-silos-and-spaghetti-identity/[5] http://wso2.com/library/webinars/identity-server/[6] M. Schumacher, E. Fernandez-Buglioni and D. Hybertson, Security Patterns: Integrating Security and Systems Engineering. 2005.