Federated Identity Providers
Federated identity providers offer services that enable users in a corporate enterprise environment to use a single digital identity to access applications and services that they have access rights to, regardless of which security domain the application or service resides in. This requires a trust relationship between the enterprise network and the CSP; that however should be explicitly stated in any SLAs between the corporation and the identity provider.
Note:
This document is part of a collection of documents that comprise the Reference Architecture for Private Cloud document set. The Reference Architecture for Private Cloud documentation is a community collaboration project. Please feel free to edit this document to improve its quality. If you would like to be recognized for your work on improving this article, please include your name and any contact information you wish to share at the bottom of this page.
In a federated security model, authentication can be performed by a Security Token Service (STS), and the STS can issue security tokens carrying claims that assert the identity of the authenticated user and the user’s access rights. Federation allows users to authenticate in their own security domain while being granted access to applications and services that belong to another security domain—provided the security domains have an established trust relationship.
This approach removes the need to provision and manage duplicate accounts for a single user, and enables single sign-on (SSO) scenarios. Claims-based access is central to a federated security model whereby applications and services authorize access to features and functionality based on claims from issuers (the STS) in trusted security domains. Claims can contain information about the user, roles or permissions, and this makes for a very flexible authorization model. Together, federated security and claims-based access enable a range of integration and authorization scenarios across applications, departments and partners in a wider ecosystem.
Though federation may require a significant effort to set up, after that work is done it can provide a platform for simpler user identity management across all aspects of the datacenter. For example, it may be possible to authenticate users in the Private Cloud against private network domain controllers and flow the authenticated identity’s request to services hosted in the Public Cloud. You would establish a trust relationship with the Public Cloud CSP that hosts the services that you use.
Some of the questions you should ask when investigating federated identity providers included:
- What types of access control technologies does the provider support? This is important when deciding to migrate to claims-based security.
- How much effort is required to integrate existing systems with the provider’s system?
- Can synchronization between the Public and Private Cloud identity systems be automated?
The strengths of a federated identity approach are that it readily enables organizations to:
- Integrate cloud security with their existing enterprise security.
- Enable employees to use one set of credentials to access services in the Private and Public cloud.
- Build on their existing security infrastructure in the future because the security systems are currently compatible and support claims-based security for future application development
REFERENCES:
Federated Identity and Privilege Management
Federated Identity and Healthcare
Windows Azure AppFabric Access Control Service (ACS)
ACKNOWLEDGEMENTS LIST:
If you edit this page and would like acknowledgement of your participation in the v1 version of this document set, please include your name below:
[Enter your name here and include any contact information you would like to share]