Shibboleth is a standards based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.
The Shibboleth software implements widely used federated identity standards, principally the OASIS Security Assertion Markup Language (SAML), to provide a federated single sign-on and attribute exchange framework. A user authenticates with his or her organizational credentials, and the organization (or identity provider) passes the minimal identity information necessary to the service provider to enable an authorization decision. Shibboleth also provides extended privacy functionality allowing a user and their home site to control the attributes released to each application.
How Shibboleth Works:
At its core Shibboleth works the same as every other web-based Single Sign-on (SSO) system. What distinguishes Shibboleth from other products in this field is its adherence to standards and its ability to provide SSO support to services outside of a user’s organization while still protecting their privacy.
The main elements of a web-based SSO system are:
Web Browser – represents the user within the SSO process
Resource – contains restricted access content that the user wants
Identity Provider (IdP) – authenticates the user
Service Provider (SP) – performs the SSO process for the resource
Single Sign-on Steps
The user starts by attempting to access a protected resource over the web and is redirected to the Service Provider (SP) in order to start the SSO process.
The SP chooses which Identity Provider (IdP) must be queried in order to authenticate the user by the means of a discovery service known as WAYF (Where Are You From): in this way, is WAYF the one that takes in account user’s request, sending it to its IdP.
The IdP queries internal Directory Service (LDAP or AD) to see if user exists, signs and gets back to SP user’s DS attributes (attributes to be released are stored into a configuration file in IdP core) as SAML assertion
Finally the SP unpacks and decodes the SAML assertion received from user’s IdP and checks whether user’s attributes, as released from his IdP, are the ones requested in order to access the protected resource or not and allows or refuses access to the requested resource.
For every need, question, info and details about IDEM service and/or Shibboleth , please call Dr. Stefano Manfredda on phone (0706755020) or send an e-mail to idem-helpATunica.it