Some sort of unique key that is used by the service- and identity provider to refer to a user session or transaction. If a user visits a service provider who can not recognize the user, the SP will redirect the user to the identity provider, who will, after authentication,
send the user back to the SP. In the redirect URL a little message (the artifact) is included which the SP uses to query the IDP for the users identity by sending the artifact as the key. The description is already an introduction to “profiles” – in this case the browser artifact profile.
SAML stands for Security Assertion Markup Language. So basically SAML is all about assertions. Assertions are statements about a user, authentication, authorization and/or attributes. These information is used by the service provider to decide whether it will service a user and if so what kind of service the user will get.
Although this description sounds simple, there is a lot to do do assure that such statements are in a way that other parties interpret it correctly. Another proof of how difficult communication is …
Since there are different ways assertions can take from A to B there is a need to describe the ways that are allowed. For example the identity provider can send the user back to the service provider by supplying a HTTP-POST request directed to the service provider and putting the assertion into the POST payload. This is exactly what is meant by HTTP-POST Binding.
Another Binding is the Artifact Binding. The assertion is not transferred immediately. The identity provider sends the user back to the service provider with a reference ( so called artifact ). The service provider then goes back directly to the identity provider and asks for the assertion matching the reference. This is what is called the Artifact Binding. The artifact is normally exchanged as a parameter in a HTTP GET request. The artifact is resolved by a direct SOAP call between the Service Provider and the Identity Provider.
COT or Circle of Trust
A group of service provider who trust one or more identity providers. If a user visits a service provider, the service provides queries the identity provider for assert the user’s identity and possibly other statements about the user.
In practice forming of such a trust relationship across company boundaries involves a lot of legal work and contracts. SSOCircle is making this part very easy.
Hub and Spoke Model
Traditional model used in a transport e.g. aviation. One central hub that is connected to many spokes. For example if you fly from Germany to Denver by US Airways you need to fly from Frankfurt to a Hub (in my case Pittsburgh) because there is no direct connection from Frankfurt to Denver ( at least if you fly USAir )
In the federation field a hub would be the Identity Provider ( e.g. idp.ssocircle.com ) and the spokes would be the service provider that trust ssocircle. If a user visits service provider A and afterwards visits service provider B, the user has to “fly” via ssocircle ( fly over means: will be redirected spoken in “browser language” )
IDP or Identity Provider
Someone who asserts your identity to others. Normally you would register at an IDP, the IDP verifies your identity and provides you with a password, certificate or something else.
For example you register with idp.ssocircle.com and specify a password and userid. The registration will need to be confirmed by sending an email to the address in order to confirm that the email address belongs to you. After successful registration you are able to authenticate to idp.ssocircle.com and SSOCircle will assert your authentication to any Service Provider who joined the SSOCircle of trust.
Classically Metadata is defined as data or information about data. At SAML there is metadata about the identity provider and metadata about the service provider. This information about data is the information that is necessary for one party to contact the other. Basically it is address information: hostnames, ports, URI and some exchange specifics like “I wish the information being signed” etc.
SSO Profiles define how single sign on can be achieved. There are different profiles for different clients: browser ( Web Browser SSO Profile ) and other client devices ( Enhanced client profile ). Single Logout Profile and Name Identifier Management complement the life cycle.
The Web Browser SSO Profile defines the messages that are exchanged between the service provider and the identity provider in order to allow the service provider to decide whether it grants the user access to the service or not. The decision is made based on assertions the service provider receives from the identity provider. In the assertion the identity provider states that the user has already authenticated. Naming identifier might be exchanged so that the service provider is able to correlate the name identifier with a local user or group. For a implemention of the scenario a specific Binding is used.
SAML or Security Assertion Markup Language
Specified by the OASIS Security Services Technical Committee (SSTC) is a standard to construct, exchange and interpret statements between an identity provider and a service provider. We described some more details in SAML 2 at SSOCircle.
SP or Service Provider
Someone who provides a “service” to a user. If the SP has joined a Circle of Trust, the SP trusts authentication assertions the Identity Provider will give about a user.
The benefit a user gains, if his SP joined a Circle of Trust, is that he only needs to sign once to the IDP and the SP can recognize
the identity automatically without reentering the users credentials.
Fortunately with federation the IDP is not a single point of failure for the SP. If the user is not logged in at the IDP (because the user doesn’t wanted to or if the IDP is down, he will be able to
login locally at the SP – ok he needs to reenter his/her user and password.