Shibboleth (software)

Last updated
Shibboleth
Type Single sign-on system
License Apache 2.0
Website 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.

Contents

The Shibboleth Internet2 middleware initiative created an architecture and 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 providers (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 identifying passphrase used in the Bible (Judges 12:4–6) 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 infrastructures. 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. [1] 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. [2] 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? ]

Architecture

Shibboleth is a web-based technology that implements the 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, [3] architectural document, [4] and conformance document [5] that build on top of the SAML 1.1 specifications.

Shibboleth 1.3

In the canonical use case:

  1. A user first accesses a resource hosted by a web server (the service provider) that has Shibboleth content protection enabled.
  2. 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.
  3. 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.
  4. The user authenticates to an access control mechanism external to Shibboleth.
  5. 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.
  6. 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.
  7. The IdP sends an attribute assertion containing trusted information about the user to the SP.
  8. 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 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 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.[ citation needed ]

Adoption

Federations have been formed in many countries around the world to build trust structures for the exchange of information using SAML and Shibboleth software. Many major content providers support Shibboleth-based access.

In February 2006, the Joint Information Systems Committee (JISC) of the Higher Education Funding Councils of England, Scotland, Wales and Northern Ireland announced that it would move from the Athens authentication system to an access-management system based on Shibboleth technology. [6] Since then it has updated its position and is endorsing a federated access management solution rather than Shibboleth itself.[ citation needed ]

See also

Related Research Articles

<span class="mw-page-title-main">Single sign-on</span> Authentication scheme

Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.

Identity management (IdM), also known as identity and access management, is a framework of policies and technologies to ensure that the right users have the appropriate access to technology resources. IdM systems fall under the overarching umbrellas of IT security and data management. Identity and access management systems not only identify, authenticate, and control access for individuals who will be utilizing IT resources but also the hardware and applications employees need to access.

<span class="mw-page-title-main">Liberty Alliance</span> Computer trade group

The Liberty Alliance Project was an organization formed in September 2001 to establish standards, guidelines and best practices for identity management in computer systems. It grew to more than 150 organizations, including technology vendors, consumer-facing companies, educational organizations and governments. It released frameworks for federation, identity assurance, an Identity Governance Framework, and Identity Web Services.

Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions. SAML is also:

The Central Authentication Service (CAS) is a single sign-on protocol for the web. Its purpose is to permit a user to access multiple applications while providing their credentials only once. It also allows web applications to authenticate users without gaining access to a user's security credentials, such as a password. The name CAS also refers to a software package that implements this protocol.

A federated identity in information technology is the means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems.

<span class="mw-page-title-main">OpenID</span> Open and decentralized authentication protocol standard

OpenID is an open standard and decentralized authentication protocol promoted by the non-profit OpenID Foundation. It allows users to be authenticated by co-operating sites using a third-party identity provider (IDP) service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log in to multiple unrelated websites without having to have a separate identity and password for each. Users create accounts by selecting an OpenID identity provider, and then use those accounts to sign on to any website that accepts OpenID authentication. Several large organizations either issue or accept OpenIDs on their websites.

<span class="mw-page-title-main">Windows CardSpace</span> Discontinued identity selector app by Microsoft

Windows CardSpace is a discontinued identity selector app by Microsoft. It stores references to digital identities of the users, presenting them as visual information cards. CardSpace provides a consistent UI designed to help people to easily and securely use these identities in applications and web sites where they are accepted. Resistance to phishing attacks and adherence to Kim Cameron's "7 Laws of Identity" were goals in its design.

Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between security domains. SAML is a product of the OASIS (organization) Security Services Technical Committee.

Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML standard for exchanging authentication and authorization identities between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between a SAML authority, named an Identity Provider, and a SAML consumer, named a Service Provider. SAML 2.0 enables web-based, cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user. SAML 2.0 was ratified as an OASIS Standard in March 2005, replacing SAML 1.1. The critical aspects of SAML 2.0 are covered in detail in the official documents SAMLCore, SAMLBind, SAMLProf, and SAMLMeta.

PERMIS is a sophisticated policy-based authorization system that implements an enhanced version of the U.S. National Institute of Standards and Technology (NIST) standard Role-Based Access Control (RBAC) model. PERMIS supports the distributed assignment of both roles and attributes to users by multiple distributed attribute authorities, unlike the NIST model which assumes the centralised assignment of roles to users. PERMIS provides a cryptographically secure privilege management infrastructure (PMI) using public key encryption technologies and X.509 Attribute certificates to maintain users' attributes. PERMIS does not provide any authentication mechanism, but leaves it up to the application to determine what to use. PERMIS's strength comes from its ability to be integrated into virtually any application and any authentication scheme like Shibboleth (Internet2), Kerberos, username/passwords, Grid proxy certificates and Public Key Infrastructure (PKI).

WS-Security Policy is a web services specification, created by IBM and 12 co-authors, that has become an OASIS standard as of version 1.2. It extends the fundamental security protocols specified by the WS-Security, WS-Trust and WS-Secure Conversation by offering mechanisms to represent the capabilities and requirements of web services as policies. Security policy assertions are based on the WS-Policy framework.

OAuth is an open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This mechanism is used by companies such as Amazon, Google, Meta Platforms, Microsoft, and Twitter to permit users to share information about their accounts with third-party applications or websites.

<span class="mw-page-title-main">Information card</span> Personal digital identity for online use

An information card is a personal digital identity that people can use online, and the key component of an identity metasystem. Visually, each i-card has a card-shaped picture and a card name associated with it that enable people to organize their digital identities and to easily select one they want to use for any given interaction. The information card metaphor has been implemented by identity selectors like Windows CardSpace, DigitalMe or Higgins Identity Selector.

Active Directory Federation Services (ADFS), a software component developed by Microsoft, can run on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access-control authorization model to maintain application security and to implement federated identity. Claims-based authentication involves authenticating a user based on a set of claims about that user's identity contained in a trusted token. Such a token is often issued and signed by an entity that is able to authenticate the user by other means, and that is trusted by the entity doing the claims-based authentication. It is part of the Active Directory Services. Microsoft advises using Entra ID and Azure AD Connect in place of ADFS in most cases.

An identity provider is a system entity that creates, maintains, and manages identity information for principals and also provides authentication services to relying applications within a federation or distributed network. Identity providers offer user authentication as a service. Relying party applications, such as web applications, outsource the user authentication step to a trusted identity provider. Such a relying party application is said to be federated, that is, it consumes federated identity.

Security Assertion Markup Language (SAML) is a set of specifications that encompasses the XML-format for security tokens containing assertions to pass information about a user and protocols and profiles to implement authentication and authorization scenarios. This article has a focus on software and services in the category of identity management infrastructure, which enable building Web-SSO solutions using the SAML protocol in an interoperable fashion. Software and services that are only SAML-enabled do not go here.

The SAML metadata standard belongs to the family of XML-based standards known as the Security Assertion Markup Language (SAML) published by OASIS in 2005. A SAML metadata document describes a SAML deployment such as a SAML identity provider or a SAML service provider. Deployments share metadata to establish a baseline of trust and interoperability.

A SAML identity provider is a system entity that issues authentication assertions in conjunction with a single sign-on (SSO) profile of the Security Assertion Markup Language (SAML).

STIR/SHAKEN, or SHAKEN/STIR, is a suite of protocols and procedures intended to combat caller ID spoofing on public telephone networks. Caller ID spoofing is used by robocallers to mask their identity or to make it appear the call is from a legitimate source, often a nearby phone number with the same area code and exchange, or from well-known agencies like the Internal Revenue Service or Ontario Provincial Police. This sort of spoofing is common for calls originating from voice-over-IP (VoIP) systems, which can be located anywhere in the world.

References

  1. Pollack, Michelle (2003-07-01). "I2-News: Internet2 Releases Privacy-Preserving Web Authorizing Software" (Mailing list). Archived from the original on 2012-12-13. Retrieved 2007-11-28.
  2. "Shibboleth 2.0 Available".
  3. Scavo, Tom; Cantor, Scott (2005-06-08). "Shibboleth Architecture: Technical Overview (Document ID: draft-mace-shibboleth-tech-overview-02)" (PDF). Archived from the original on 2012-03-14. Retrieved 2017-10-02.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  4. "Shibboleth Architecture: Protocols and Profiles" (PDF). 2005-09-10. Retrieved 2017-08-24.
  5. Cantor, Scott; Morgan, RL "Bob"; Scavo, Tom (2005-09-10). "Shibboleth Architecture: Conformance Requirements" (PDF). Retrieved 2017-08-24.
  6. "JISC announces the development of a new access-management system for the UK". Joint Information Systems Committee . Retrieved 2006-07-19.