Federated Identity Concepts and Patterns
Last week I’ve read an excellent set of articles that were published in the Architecture Journal #16 (Identity and Access), and deeply caught my attention the way in which the authors expose in a really simple way most of the concepts you need to have in handy to face this new era of security.
In order to internalize most of the concepts, I’ve made a summary of the articles I’ve read so far, so I can get the big picture again when my memory needs so; and now I’m sharing this with you. Remember to read the full article to get into more detail!
The Evolving Role of Identity (by Fernando Gebara Filho)
(Source: http://msdn.microsoft.com/en-us/architecture/cc837112.aspx)
Phases of Identity during the last years
- Punched Cards (UserName and Password in the card)
Reason to Evolve: Low Secure
- Workgroups (each workgroup member responsible for security checking)
Reason to Evolve: Not integrated in the network
- Workgroups with network credentials (identity database replicated among all workgroup members)
Reason to Evolve: Inconsistencies from replication + heavy payload
- Network Domain (all network members managed by a central credential database)
Reason to Evolve: Model did not support trust relation between domains under different technologies
- Identity Federation Systems (cross platform, standardized set of protocols to transmit identities among loosely coupled domains)
Federated Identity: Patterns in a Service oriented World (by Jesus Rodriguez and Joe Klug)
(Source: http://msdn.microsoft.com/en-us/architecture/cc836393.aspx)
Principles of Web Service Federation
STS: Isolated service that removes the dependencies between company services and the authentication mechanism
- Provides ClaimSets: Assertions about the consumer’s identity (name, age, email)
- Issue Security Tokens
- Services and IP/STS are part of the same Trust Domain.
- Consumer then uses tokens issued by STS to consume the services.
- Service authenticate consumer using both Tokens and claimsSets.
Initial Federation Challenge (The problem that Federation comes in to solve)
How to communicate the Consumer and the Service if they live in different Trust Domains?
Patterns
Inter-Domain Token Exchange
Context:
- The Consumer belongs to a different Trust Domain (A) than the Services (Federated Trust domain B) he wants to consume.
- The service only allows calls to valid tokens issued by the IP of its Trust Domain (IP/STS B).
- Consumer can only authenticate through IP/STS A, but the Service has not knowledge about that authentication mechanism
- We need to find a way in which the Service can understand the Consumers credentials.
Characteristics (Forces):
- Multiple Identity Providers: Your company needs to maintain different multiple trust domains for scalabilty and management reasons (IP/STS A and IP/STS B may issue tokens in different format)
- Trust Boundaries: Service only accepts tokens issued by the IP/STS of its Trust Domain.
Solution:
- Provide a Trust relationship between the two identities. This way IP/STS B will trust the security tokens issued by IP/STS A.
- Customer will communicate with IP/STS A telling that wants to access to resources on Trust Domain B.
- IP/STS A will issue a set of tokens and identity claims that IP/STS B will understand and allow the Consumer access to the Service.
Pros:
- Keeps Trusts Domains isolated
- Extensible to more complex federated scenarios
Cons:
- Generates certain dependencies between the Consumer and the IP/STS B
- If IP/STS B issue tokens as certificates the Consumer will have to implement some logic to handle them (see Intra-Domain Token Exchange pattern to a solution to this drawback).
Intra-Domain Token Exchange
Context:
- Similar to Intra-Domain but avoiding dependencies between the Customer and the IP/STS B
Characteristics (Forces):
- All the ones from the previous scenario.
- Different token claims representation: IP/STS B issue tokens that can’t be handed by the Consumer application (cant’ change the consumer logic to implement the handing)
Solution:
- The Consumer presents the token acquired in the IP/STS A directly to the Service in the Trust Domain B.
- Service implements some sort of interceptor to forward the claims and tokens to IP/STS B.
- IP/STS B will use the authentication mechanism of the trust relationship to validate the tokens.
Pros:
- Removes dependencies between Consumers and IP/STS from other Trust Relationships.
- Suitable for very secure scenarios where the Consumer should not hand security tokens issued by IP/STS in the other trust domain. (For ex: Banking)
Cons:
- Introduces extra complexity while developing the authentication mechanism for the trust relationship
Third-party Trust Establisher
Context:
- Trust relationships between IP/STSs bring tightly couple interactions
- We need an approach that does not alter the natural behavior of the IP/STSs
Characteristics (Forces):
- Policy Change Frequently: Policies that regulates the identities with the Consumer changes frequently. Those changes can influence the policies of the other IP/STS (IP/STS A decides that now on the claims issued to users should exclude the bank account; however IP/STS B still needs this claim to authenticate)
- Different Token-Claims representation: Similar to the previous pattern
- Loosely Coupling IP/STSs: One IP/STS should not have knowledge of the authentication mechanism of the other IP/STS
Solution:
- Establish a trust relationship using a third party (IP/STS C) to act as a bridge between both trust domains
- Consumer will request a token to IP/STS A
- IP/STS A will contact IP/STS C that will issue a token that IP/STS B will understand
Pros:
- No dependencies between IP/STSs in terms of authentication mechanism
Cons:
- The third party is a new component that must be versioned and maintained
Pseudonym Claim Service
Context:
- Some scenarios require keeping the real identity of the caller hidden while calling a Service in a different Trust Domain. (identity not propagated across domains)
- Identity Mapping is needed within the Consumer trust domain
Characteristics (Forces):
- Identity Protection: Protect the identity across different Trust Domains.
- Identity Mapping: Trust Domains may represent identities and attributes differently. This is a mechanism that translates identities from one trust domain, to be understood by the other trust domain.
- Identity Collision: The identity of Services within a IP/STS can collide with other identities in a federated Trust Domain.
Solution:
- Implement a Pseudonym Claim Service to map the real identities to pseudonyms.
- These pseudonyms will be the identities that the Consumer will use to call the Service.
- The IP/STS B will generate the claims and security tokens based on those pseudonyms identities.
- Then the identity flow goes on as usual, using any of the patterns seen before.
Pros:
- Preserves the real identity across Trust Domains.
- Given that the aliases are applied to the initial claim set, the identity mapping process can be executed against the aliases with no impact to the process.
Cons:
- Pseudonym Claim Service is another component you need to maintain (including the pseudonyms mapping database)
Attribute Claim Service
Context:
- Sometimes the federation procedures require extra information than the one generated in an IP/STS (IP/STS B requires more claims than the ones IP/STS A is issuing to the Consumer)
- This may not mean that IP/STS A do not have that information, but due to privacy policies cannot issue them directly to the Consumer.
- IP/STS B may need for example email claims that are not part of the original claimset generated by IP/STS A.
Characteristics (Forces):
- Privacy: Based on privacy requirements, only a subset of the Consumer claims is issued as part of the identity information issued by the IP/STS (A). The Consumer cannot handle certain claims that may be considered delicate by the issuer entity.
Solution:
- The remaining Consumer claims (needed by the other IP/STS (B)) may be accessible to security entities such as IP/STSs , but should not be propagated to the consumer applications.
- The attributes needed for identity federation can be exposed through an Attributes Claim Service, which can be invoked from any security entity (Service or IP/STS depending on the pattern chosen).
- In order to complete the federation process, IP/STS B may need some extra claims that are not present in the original security token, so a service call is made to the Attribute Claim Service (ACS).
- IP/STS B would obtain these claims presenting to the ACS the original claims issued by IP/STS A to the Consumer, and its own security identity.
- The trust relationship between IP/STSs allows IP/STS B to communicate with the ACS.
Pros:
- Preserves privacy within a Trust Domain, and avoids changing the privacy requirements just to access a different Trust Domain.
- This pattern can be applied in different topologies, and can be combined with pseudonym service pattern.
Cons:
- ACS is another component you need to maintain (including authentication mechanism with other IP/STS that invoke it)
Defederation
Context:
- Sometimes you may want to eliminate the relationship that exists between entities within a Federated Solution (Identity Providers, Services, and Consumers). For ex, remove the association between the Consumer’s principal accounts with the IP/STS B; this will result in the impossibility for the Consumer to invoke the Services in the other Trust Domain.
- The governance and management of entities involved in the Federation is absolutely vital to the correct functioning of the model.
Characteristics (Forces):
- Defederating Services: When a Service is removed from the federation, we need a mechanism to dynamically update the IP/STS and other services in the federation Trust Domains that have a relationship with that Service.
- Defederating Consumers: Notify the IPs that the claims from that Consumer are not longer valid.
- Updating Policies: When the security policy of a service changes, we need a mechanism for propagating those changes to the federated IP/STSs.
Solution:
- Provide the entities involved in a federation with a publish/subscribe “defederation protocol†that can be used as a mechanism for Defederating entities.
- For instance, when a Service is removed from the federation, a “Defederated Service†message is sent to the IP/STS of its Trust Domain, and from there propagated to the other IP/STS and services involved in the federation.
Pros:
- Helps to enforce the security and trust boundaries consistently.
Cons:
- Complexity in implementation
Is worth to make clear that all the merit goes to the authors of these articles; thank you guys for making me understand.
