Shibboleth (informatica)

Il logo di Shibboleth.

Shibboleth è un sistema di single sign-on (login) per reti informatiche. Consente di autenticarsi su sistemi differenti, permettendo di effettuare il login su reti di organizzazioni o istituzioni diverse, utilizzando una sola identità. Spesso le federazioni sono università o organizzazioni di servizi pubblici.

Shibboleth è stato sviluppato dal consorzio no-profit Internet2, che ha creato un'architettura e un'implementazione open source per l’identity management e l'autenticazione con identità federata. L'infrastruttura è basata sullo standard aperto Security Assertion Markup Language (SAML). L'identità federata permette di condividere le informazioni sugli utenti tra sistemi e organizzazioni diversi all'interno di una federazione. Questo permette di effettuare single sign-on tra sistemi diversi ed elimina la necessità di conservare nomi utente e password da parte dei singoli sistemi. Gli identity provider (IdP) forniscono le informazioni sull'utente, mentre i service provider (SP) utilizzano le informazioni e danno accesso ai contenuti protetti.

Shibboleth è open source ed è rilasciato con licenza Apache 2. Molte estensioni sono state fornite da altri gruppi.

Storia

Storicamente il progetto Shibboleth nasce da Internet2, consorzio ben conosciuto nelle comunità open-source. Oggi il progetto è gestito dal Shibboleth Consortium[1]. I due più popolari software gestiti dal Shibboleth Consortium sono Shibboleth Identity Provider e Shibboleth Service Provider, i quali sono implementazioni di Security Assertion Markup Language (SAML).

Il progetto Shibboleth è stato avviato nel 2000 con lo scopo di facilitare la condivisione di risorse tra organizzazioni aventi infrastrutture di autenticazioni e autorizzazioni incompatibili. Prima di sviluppare software hanno studiato l'architettura necessaria per più di un anno. Dopo una versione alfa, due beta e due rilasci di versioni minori, Shibboleth IdP 1.0 è stato pubblicato il 1º giugno 2003[2], seguito da Shibboleth IdP 1.3 pubblicato il 26 agosto 2005.

La versione 2.0 di Shibboleth software è stata distribuita il giorno 19 marzo 2008[3] e portava con sé sia IdP che SP, ma - cosa più importante - supportava SAML v2.0.

Storicamente Shibboleth e il protocollo SAML sono stati sviluppati nello stesso periodo di tempo. All'inizio, Shibboleth era basato su SAML, ma dove SAML mancava, Shibboleth improvvisava. Essenzialmente, gli sviluppatori di Shibboleth implementarono delle funzionalità che compensavano quelle mancanti in SAML 1.1. Alcune di tali funzionalità sono poi state incorporate in SAML 2.0 e, in questo senso, Shibboleth ha contribuito allo sviluppo del protocollo SAML.

Forse la caratteristica più importante è stata il protocollo Shibboleth AuthnRequest. Poiché il protocollo SAML V1.1 era intrinsecamente un protocollo IdP-first, Shibboleth ha inventato un semplice protocollo di richiesta di autenticazione basato su HTTP che ha trasformato SAML V1.1 in un protocollo SP-first. Questo protocollo è stato implementato per la prima volta in Shibboleth IdP 1.0 e successivamente rifinito in Shibboleth IdP 1.3.

Basandosi su quel primo lavoro, Liberty Alliance ha introdotto un protocollo AuthnRequest completamente ampliato nel Liberty Identity Federation Framework. Alla fine Liberty ID-FF 1.2 ha aderito a OASIS, che ha costituito la base per lo standard OASIS SAML V2.0.

Architettura

Shibboleth è una tecnologia basata sul web che implementa i profili push HTTP/POST, artefatti e attributi di SAML, inclusi i componenti Identity Provider (IdP) e Service Provider (SP). Shibboleth 1.3 ha una sua panoramica tecnica,[4] documento architettonico,[5] e documento di conformità[6] che si basano sulle specifiche SAML 1.1.

Shibboleth 1.3

Nel caso d'uso canonico:

  1. Un utente accede per la prima volta a una risorsa ospitata da un server Web (il fornitore di servizi) con la protezione del contenuto abilitata tramite Shibboleth.
  2. Il SP crea una richiesta di autenticazione proprietaria che viene passata attraverso il browser utilizzando query string nell'URL per fornire l'entityID SAML del richiedente, l'Assertion Consumer Location e facoltativamente la pagina finale da restituire all'utente.
  3. L'utente viene reindirizzato al proprio servizio IdP o ad un servizio WAYF (Where Are You From), dove può selezionare l'IdP principale per un ulteriore reindirizzamento.
  4. L'utente si autentica su un meccanismo di controllo degli accessi esterno a Shibboleth.
  5. Shibboleth genera un'asserzione di autenticazione SAML 1.1 con un "handle" temporaneo contenuto al suo interno. Questo handle consente all'IdP di riconoscere una richiesta relativa ad un particolare utente (browser) come corrispondente ad un utente precedentemente autenticato.
  6. I dati di autenticazione dell'utente vengono inviati al Assertion Consumer Service del SP. Il SP consuma l'asserzione e invia un'AttributeQuery al servizio IdP per gli attributi relativi a quell'utente, che possono includere o meno l'identità dell'utente.
  7. L'IdP invia al SP un'Attribute Assertion contenente informazioni attendibili sull'utente.
  8. Il SP, a quel punto, può sia fare una decisione di controllo di accesso, che fornire le informazioni alle applicazioni per permettere loro di prendere tali decisioni.

Shibboleth supporta una serie di variazioni su questo caso base, inclusi i flussi in stile portale in cui l'IdP elimina un'asserzione indesiderata da consegnare nell'accesso iniziale al SP, e l'avvio "lazy" della sessione, che consente a un'applicazione di attivare la protezione del contenuto tramite un metodo a sua scelta a richiesta.

Shibboleth 1.3 e precedenti non forniscono un meccanismo di autenticazione incorporato, ma qualsiasi meccanismo di autenticazione basato sul web può essere utilizzato per fornire a Shibboleth i dati dell'utente. I sistemi più comuni per questo scopo sono Central Authentication Service (CAS) o Pubcookie. Possono essere utilizzate anche le funzioni di autenticazione/SSO del container Java in cui viene eseguito l'IdP (ad esempio, Tomcat).

Shibboleth 2.0

Shibboleth 2.0 si basa sugli standard di SAML 2.0. L'IdP di Shibboleth 2.0 deve eseguire un'ulteriore elaborazione per supportare le richieste di autenticazione passive e forzate in SAML 2.0. Il SP può richiedere uno specifico metodo di autenticazione dall'IdP. Shibboleth 2.0 supporta capacità di crittografia aggiuntive e imposta una durata di sessione predefinita di 30 minuti.

Attributi

Il controllo degli accessi di Shibboleth viene eseguito associando gli attributi forniti dagli IdP alle regole definite dagli SP. Un attributo è qualsiasi atomo di informazioni su un utente, come "membro di questa comunità", "Alice Smith" o "concesso in licenza con contratto A". L'identità dell'utente è considerata un attributo e viene trasmessa solo se esplicitamente richiesta, il che preserva la privacy dell'utente. Gli attributi possono essere scritti in Java o estratti da directory e database. Gli attributi dello standard X.520 sono più comunemente utilizzati, ma possono essere definiti arbitrariamente nuovi attributi purché siano compresi e interpretati in modo simile da IdP e SP in una transazione.

Fiducia

La fiducia tra i domini è implementata utilizzando la crittografia a chiave pubblica (spesso semplicemente certificati server SSL) e metadati che descrivono i provider. L'uso delle informazioni trasmesse è controllato tramite accordi. Le federazioni vengono spesso utilizzate per semplificare queste relazioni aggregando un numero elevato di providers che accettano di utilizzare regole e contratti comuni.

Adozione

Le federazioni si sono formate in molti paesi in tutto il mondo per costruire strutture di fiducia per lo scambio di informazioni usando il software SAML e Shibboleth. Molti dei principali fornitori di contenuti supportano l'accesso basato su Shibboleth.

Note

  1. ^ Sito ufficiale Shibboleth Consortium, su shibboleth.net.
  2. ^ Michelle Pollack, I2-News: Internet2 Releases Privacy-Preserving Web Authorizing Software, su mail.internet2.edu, 1º luglio 2003. URL consultato il 28 novembre 2007 (archiviato dall'url originale il 13 dicembre 2012).
  3. ^ Shibboleth 2.0 Available, su lists.internet2.edu.
  4. ^ Tom Scavo e Scott Cantor, Shibboleth Architecture: Technical Overview (Document ID: draft-mace-shibboleth-tech-overview-02) (PDF), su shibboleth.internet2.edu, 8 giugno 2005. URL consultato il 2 ottobre 2017 (archiviato dall'url originale il 14 marzo 2012).
  5. ^ Shibboleth Architecture: Protocols and Profiles (PDF), su wiki.shibboleth.net, 10 settembre 2005. URL consultato il 24 agosto 2017.
  6. ^ Scott Cantor, RL "Bob" Morgan e Tom Scavo, Shibboleth Architecture: Conformance Requirements (PDF), su wiki.shibboleth.net, 10 settembre 2005. URL consultato il 24 agosto 2017.

Collegamenti esterni

  Portale Sicurezza informatica: accedi alle voci di Wikipedia che trattano di sicurezza informatica