Editing Shibboleth (software)

{{Short description|Internet identity system}}
{{outdated|version 3.0|date=April 2019}}
{{Infobox software
| name = Shibboleth
| logo = File:Shibboleth logo.png
| caption = 
| developer = 
| released = 
| latest release version = 
| latest release date = 
| programming language = 
| operating system = 
| genre = [[Single sign-on]] system
| license = [[Apache License|Apache 2.0]]
| website = {{URL|https://www.shibboleth.net/}}
}}
'''Shibboleth''' is a [[single sign-on]] log-in system for computer networks and the [[Internet]]. It allows people to sign in using just one identity to various systems run by federations of different organizations or institutions. The federations are often universities or public service organizations.

The Shibboleth [[Internet2]] [[middleware]] initiative created an [[Information technology architecture|architecture]] and [[open-source model|open-source]] implementation for [[identity management]] and [[federated identity]]-based [[authentication]] and [[authorization]] (or [[access control]]) infrastructure based on [[Security Assertion Markup Language]] (SAML). Federated identity allows the sharing of information about users from one security domain to the other organizations in a federation. This allows for cross-domain single sign-on and removes the need for content providers to maintain usernames and passwords. [[Identity provider]]s (IdPs) supply user information, while service providers (SPs) consume this information and give access to secure content.

==History==
The Shibboleth project grew out of Internet2. Today, the project is managed by the Shibboleth Consortium. Two of the most popular software components managed by the Shibboleth Consortium are the Shibboleth Identity Provider and the Shibboleth Service Provider, both of which are implementations of [[SAML]].

The project was named after an [[Shibboleth|identifying passphrase]] used in the [[Bible]] ([[Book of Judges|Judges]] {{bibleverse-nb|Judges|12:4-6|NET}}) because [[Ephraimites]] were not able to pronounce "sh".

The Shibboleth project was started in 2000 to facilitate the sharing of resources between organizations with incompatible [[Authentication and authorization infrastructure|authentication and authorization infrastructures]]. [[Software architecture|Architectural work]] was performed for over a year prior to any software development. After development and testing, Shibboleth IdP 1.0 was released in July 2003.<ref>{{cite mailing list |url=https://mail.internet2.edu/wws/arc/i2-news/2003-07/msg00000.html |last=Pollack |first=Michelle |title=I2-News: Internet2 Releases Privacy-Preserving Web Authorizing Software |date=2003-07-01 |accessdate=2007-11-28 |archive-date=2012-12-13 |archive-url=https://archive.today/20121213000159/https://mail.internet2.edu/wws/arc/i2-news/2003-07/msg00000.html |url-status=dead }}</ref> This was followed by the release of Shibboleth IdP 1.3 in August 2005.

Version 2.0 of the Shibboleth software was a major upgrade released in March 2008.<ref>{{cite web |url=https://lists.internet2.edu/sympa/arc/shibboleth-users/2008-03/msg00289.html |title=Shibboleth 2.0 Available}}</ref> It included both IdP and SP components, but, more importantly, Shibboleth 2.0 supported SAML 2.0.

The Shibboleth and SAML protocols were developed during the same timeframe. From the beginning, Shibboleth was based on SAML, but, where SAML was found lacking, Shibboleth improvised, and the Shibboleth developers implemented features that compensated for missing features in [[SAML 1.1]]. Some of these features were later incorporated into [[SAML 2.0]], and, in that sense, Shibboleth contributed to the evolution of the SAML protocol.

Perhaps the most important contributed feature was the legacy Shibboleth AuthnRequest protocol. Since the SAML 1.1 protocol was inherently an IdP-first protocol, Shibboleth invented a simple HTTP-based authentication request protocol that turned SAML 1.1 into an SP-first protocol. This protocol was first implemented in Shibboleth IdP 1.0 and later refined in Shibboleth IdP 1.3.

Building on that early work, the [[Liberty Alliance]] introduced a fully expanded AuthnRequest protocol into the Liberty Identity Federation Framework. Eventually, Liberty ID-FF 1.2 was contributed to OASIS, which formed the basis for the OASIS SAML 2.0 Standard.{{importance inline|date=January 2019}}

==Architecture==
Shibboleth is a web-based technology that implements the {{sic|hide=y|HTTP/POST}} artifact and attribute push profiles of [[SAML]], including both Identity Provider (IdP) and Service Provider (SP) components. Shibboleth 1.3 has its own technical overview,<ref>{{cite web |url=http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-overview-latest.pdf |title=Shibboleth Architecture: Technical Overview (Document ID: draft-mace-shibboleth-tech-overview-02) |date=2005-06-08 |accessdate=2017-10-02 |author1=Scavo, Tom |author2=Cantor, Scott |url-status=bot: unknown |archiveurl=https://web.archive.org/web/20120314082144/http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-overview-latest.pdf |archivedate=2012-03-14 }}</ref> architectural document,<ref>{{cite web |url=https://wiki.shibboleth.net/confluence/download/attachments/2162702/internet2-mace-shibboleth-arch-protocols-200509.pdf |title=Shibboleth Architecture: Protocols and Profiles |date=2005-09-10 |accessdate=2017-08-24}}</ref> and conformance document<ref>{{cite web |url=https://wiki.shibboleth.net/confluence/download/attachments/2162702/internet2-mace-shibboleth-arch-conformance-200509.pdf |title=Shibboleth Architecture: Conformance Requirements |date=2005-09-10 |accessdate=2017-08-24 |author1=Cantor, Scott |author2=Morgan, RL "Bob" |author3=Scavo, Tom}}</ref> that build on top of the SAML 1.1 specifications.

===Shibboleth 1.3===
In the canonical use case:

# A user first accesses a resource hosted by a web server (the service provider) that has Shibboleth content protection enabled.
# The SP crafts a proprietary authentication request that is passed through the browser using URL query parameters to supply the requester's SAML entityID, the assertion consumption location, and optionally the end page to return the user to.
# The user is redirected to either their home IdP or a WAYF (Where Are You From) service, where they select their home IdP for further redirection.
# The user authenticates to an access control mechanism external to Shibboleth.
# Shibboleth generates a SAML 1.1 authentication assertion with a temporary "handle" contained within it. This handle allows the IdP to recognize a request about a particular browser user as corresponding to the principal that authenticated earlier.
# The user is POSTed to the assertion consumer service of the SP. The SP consumes the assertion and issues an AttributeQuery to the IdP's attribute service for attributes about that user, which may or may not include the user's identity.
# The IdP sends an attribute assertion containing trusted information about the user to the SP.
# The SP either makes an access control decision based on the attributes or supplies information to applications to make decisions themselves.

Shibboleth supports a number of variations on this base case, including portal-style flows whereby the IdP mints an unsolicited assertion to be delivered in the initial access to the SP, and lazy session initiation, which allows an application to trigger content protection through a method of its choice as required.

Shibboleth 1.3 and earlier do not provide a built-in [[authentication]] mechanism, but any Web-based authentication mechanism can be used to supply user data for Shibboleth to use. Common systems for this purpose include [[Central Authentication Service|CAS]] or [[Pubcookie]]. The authentication and single-sign-on features of the Java container in which the IdP runs (Tomcat, for example) can also be used.

===Shibboleth 2.0===
Shibboleth 2.0 builds on [[SAML 2.0]] standards. The IdP in Shibboleth 2.0 has to do additional processing in order to support passive and forced authentication requests in SAML 2.0. The SP can request a specific method of authentication from the IdP. Shibboleth 2.0 supports additional encryption capacity.

==Attributes==
Shibboleth's access control is performed by matching attributes supplied by IdPs against rules defined by SPs. An attribute is any piece of information about a user, such as "member of this community", "Alice Smith", or "licensed under contract A". User identity is considered an attribute, and is only passed when explicitly required, which preserves user privacy. Attributes can be written in Java or pulled from directories and databases. Standard [[X.520]] attributes are most commonly used, but new attributes can be arbitrarily defined as long as they are understood and interpreted similarly by the IdP and SP in a transaction.

==Trust==
Trust between domains is implemented using public key cryptography (often simply [[Transport Layer Security|TLS]] server certificates) and metadata that describes providers. The use of information passed is controlled through agreements. Federations are often used to simplify these relationships by aggregating large numbers of providers that agree to use common rules and contracts.

==Development==
Shibboleth is open-source and provided under the Apache 2 license. Many extensions have been contributed by other groups.{{cn|date=February 2024}}

==See also==
* [[OpenAthens]]

==References==
{{reflist}}

==External links==
* {{official website|https://www.shibboleth.net/}}

[[Category:Federated identity]]
[[Category:Identity management initiative]]