Understanding Shibboleth and SAML is much easier after learning some terminology. A successful deployment of Shibboleth involves two critical software components:
Identity Provider (IdP)
This is the server that handles authentication of users. McMaster University has deployed a load-balanced SAML Identity Provider (IdP) and it also has a test environment that mirrors the settings of the live IdP. Only one live IdP is needed per campus.
Identity Provider Information for all locally based Service Providers (SPs):
Metadata: IdP-only metadata
SSL certificate: idp.crt
Metadata: IdP-only metadata
SSL certificate: idp-t.crt
Production: URL = https://sso.mcmaster.ca/idp/logout
Test: URL = https://tsso.mcmaster.ca/idp/logout
Identity Provider Information for InCommon Service Providers:
InCommon Service Providers must use urn:mace:incommon:mcmaster.ca for McMaster University’s IdP entityID.
All other InCommon metadata should be downloaded directly from InCommon.
Service Provider (SP)
An IdP is useless without Service Providers. Service Providers are web applications, resources, or other services which require authentication. The Shibboleth SP software allows most web servers (namely Apache and IIS) to integrate with an IdP or a number of IdPs.
The SP software consists of several components:
ISAPI Filter – This is only used for IIS deployments. It intercepts requests to IIS and redirects users to an IdP or WAYF. After the user authenticates it also handles the callback which tells your SP that the user has authenticated. During handling of this callback the ISAPI Filter collects attributes which describe the authenticated user. The filter is configured through the shibboleth2.xml config file.
Apache Module – This is only used for Apache deployments. It is essentially the same as the ISAPI Filter but for the Apache web server. In addition to shibboleth2.xml, some configuration is required via httpd.conf.
Shibd – This is a service (Windows) or daemon (UNIX) which handles attributes request queries from the SP to the IdP. Shibboleth attribute requests are part of the SAML standard and are made via a back channel SOAP call to the IdP (usually on port 8443). In order to receive user attributes, this service must be running.
Attribute Acceptance Policy – This policy dictates which attributes the SP wants and which IdPs are authorized to provide them. It may also define specific formats that the values must match. In addition, the AAP determines what HTTP headers will be used for mapping attributes that are supplied by the IdPs. There are two files that combine together for this functionality, the attribute-map.xml and attribute-policy.xml.
For an in-depth explanation of how to deploy and configure your SP follow this link
If an SP partner application wants to kill its login session, a call to the URL in this fashion should suffice:
The above action will ensure that the Shibboleth session in the browser is closed so long as the logout action is successful and the SP is configured correctly. The Shibboleth logout URL removes Shibboleth cookies in the browser then redirects to the logout URL specified in the above call. Other browser sessions with other SPs are potentially unaffected by this action which therefore does not guarantee a global SSO logout but rather effects (1) Shibboleth SSO session terminations for the browser and (2) termination of the browser session for the application whose SP is invoking the call.