Real Basic Description
SAML—Security Assertion Markup Language—(pronounced like camel) is an authentication system where the username, password, and info are stored/accessed on/through a centralized server (identity provider) who’s job is to be the central location for authentication. External services (service providers) configured with the identity provider send authentication requests and receive a token once a user is has authenticated. The token contains a user identifier (such as a username) and some optional user info but no passwords. The token exchange is possible because of a certificate exchange between the authentication source and the service during setup and optionally during a config sync (metadata sync). All this is done over HTTPS with a bunch of HTTP redirects that GET or POST base64 encoded XML (text).
SAML uses certificate signatures to validate communication with the option encrypting the username (principal/NameID field) or everything.
SAML – Security Assertion Markup Language. Currently on version 2.0.
Shibboleth – Implements SAML but extends it on a few things. Also a hosted provider.
ADFS – Active Directory Federated Services – Somewhat implements SAML in its own Microsofty, butchering kind of way. Kinda like AD is LDAP, sorta. Really rigid and not very configurable.
SimpleSAMLphp – A php based web service that is flexible and works with SAML, Shibboleth, ADFS, and many others. Has plugins and other useful things. Very configurable.
Actual SAML Terms
IdP – Identity Provider – This is the service/place that contains the authority on identities. So Joe Schmoe’s username and password are stored/accessed here. Identities are provided from AD, LDAP, Database, htpassword, text file, or whatever.
SP – Service Provider – This is service/place provides a “service” that does not store username and password info. The SP may store username and whatever attributes are passed via SAML. A service provider could be a content management system (CMS), learning management system (LMS), hosted software, etc. basically anything that is web based and has user profiles.
Metadata – A XML (text) file with all the info about the IdP or SP (info about the SAML service).
Principal – Basically the user or username. See NameID.
Assertions – Extra info on the user. See Attributes.
SAML XML/NItty-Gritty Terms
Entity ID – The unique identifier of the SAML server (IdP or SP). This can be a string or URL as long as it’s a unique name.
NameID – The Username or whatever identifies the user (could be an email address). This is configurable. What ever is the UNIQUE identifier for the user and is almost always the username.
NameID format – The format of the NameID.
Attributes – Extra info on a principal/NameID such as email, first and last name, display name, etc. What attributes are sent is configurable on the IdP side and what attributes are received/processed is configurable on the SP side.
AuthNRequest – A request for authentication from the SP that goes to the IdP. Only for SP initiated setups.
ACS – Assertion Consumer Service – The URL where after a successful authentication at the IdP returns data to (such as NameID and attributes) via HTTP POST, GET, or artifact.
SLS – Single Logout Service – The URL where after a logout at the IdP (weather IdP or SP initiated) the SP is notified of the logout. Also accessed via HTTP POST, GET, or artifact.
Binding – The protocol for binding, i.e. do we use GET POST or artifact to send the XML data.
SP initiated login – The SP initiates the SAML process by redirecting (sending an AuthNRequest) to the IdP for login.
IdP initiated login – The IdP initiates the SAML process by logging in the user and then redirecting to the SP. The IdP can sometimes provide a “portal” for authenticated users to select whatever SP they want to use (hyperlink to SP that in turns completes the SAML process with whatever SP is chosen).