During this week I ‘ve been working with federated identity a very interesting topic that every day sounds more and more. This post is the first part of a quickstart I plan to write to help beginners to understand the stack of protocols involved in the solution to this common problem and in particular to Microsoft’s solution for it: codename “Geneva”.
Let’s start by getting familiar with some vocabulary:
- Security token: it is a serialized set of claims that in most of the cases is digitally signed by an issuing authority.
- Issuing authority: any entity you trust.
- Security Token Service (STS): is a software component (exposed by an issuing authority) applications trust for authetication.
- Relaying party (RP): is an aplication that trust in the STS.
- Claim: information about the user contained in a security token and required by a application (RP app.). In some point claims are analogous to attributes in the enterprise directory world.
- identity provider STS (IP STS): is an STS capable of authenticate users, determining user identity tipically by validating his credentials (username & password).
- Relaying party STS (RP STS): is an STS that relies in others STS to authenticate users and has the ability to generate the claims required by the relaying party application.
What is Geneva?
- Geneva server (ADFS)
- Windows Cardspace Geneva (CardSpace)
- Geneva framework (Windows Identity Foundation)
- WS-Security: is a protocol that define some extension to SOAP that can be used when building secure Web services to implement message content integrity and confidentiality. (see ws-security specification)
- WS-Trust: is an extension to WS-Security that defines methods for issuing, renewing, and validating security tokens and ways to establish assess the presence of, and broker trust relationships. It is used by STSs to expose endpoints. This video by Vittorio Bertocci explains this protocol in a very clear way, or you can also read the ws-trust specification.
- WS-Policy: provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. In out context it is used is used by RP app/service to expose the required policy to be invoked. (see ws-policy specification)
- SAML: is an XML-based standard for exchanging authentication and authorization data in the kind of tokens. Our tokens are expressed with SAML.
- WS-Federation: is based on WS-Trust and provides some extentions interesting extension that amogn other things, define how to work with passive relaying parties like web browsers. This paper by Microsoft and IBM is a very good introduction to this protocol and the whole flow of messages in the authentication scenario.