English version

Federativní správa identit dovoluje výměnu informací o uživatelích mezi různými organizacemi na základě dohodě o vzájemné důvěře. Hlavními prvky federace jsou:

• správce identit (identity providers) – uchovávají identity uživatelů, provádí autentizaci a poskytují data uživatelů formou atributů
• poskytovatelé služeb (service providers) – nabízí služby nebo zdroje určené uživatelům

Shibboleth je projekt organizace Internet2, který implementuje federativní infrastrukturu založenou na SAML (Security Assertion Markup Language) – XML standard určen k výměně autentizačních a autorizačních dat. Shibboleth v současné době podporuje pouze web aplikace (přístupné skrz webovský prohlížeč), neboť využívá některé specifické rysy HTTP protokolu.

Když se nepřihlášený uživatel pokusí přistoupit k aplikaci ve správě Shibboleth Service Provider, je přesměrován k identity provideru jeho vlastní organizace k příhlášení. Po úspěšné autentizaci je uživatel přesměrován zpět k service provideru, který pak dovolí uživateli přistoupit k aplikaci. Při tom service provider obvykle žádá identity providera o některé atributy daného uživatele.

Shibboleth Service Provider je implementován jako modul do web serveru (Apache, IIS) a daemon, který běží samostatně. Hlavní funkcionalita je soustředěná v daemonu, zatímco modul zachytává HTTP dotazy a slouží jako rozhraní mezi web serverem a daemonem. Na základě konfigurace, která se podobá konfigurace BasicAuth v Apache, modul chrání určité adresáře nebo lokace. Pro přístup k těmto adresářům je potřeba splnit zadané podmínky (autentizace, autorizace na základě atributů).

Poté modul předává chráněné aplikaci informace o identitě přistupujícího uživatele, příslušné atributy a také další informace, například z jakého identity provideru pochází uživatel, jakou metodou ze autentizoval apod.

Shibboleth infrastrukturu lze chápat jako aplikační vrstvu mezi uživatelem a aplikaci. Aplikace se nemusí zabývat autentizací, dostává potřebné informace z infrastruktury. Tím se vývoj aplikací podporující Shibboleth značně usnadňuje.

Shibboleth Service Provider poskytuje chráněné aplikaci uživatelské atributy formou dodatečně nastavených HTTP hlaviček. Atributy určené k zpracování se nastavují v tzv. AAP (Attribute Acceptance Policy) konfiguračním souboru, obvykle je to AAP.xml v konfiguračním adresáři. Typické nastavení atributu vypadá takto:

<AttributeRule Name="urn:mace:dir:attribute-def:mail" 
               Header="Shib-InetOrgPerson-mail"
               Alias="email">
 
    <AnySite>
      <AnyValue/>
    </AnySite>
</AttributeRule>

• Name je název atributu
• Header je název HTTP hlavičky, kam se uloží hodnota atributu pro další zpracování
• Alias je zkrácený název atributu, který lze použít v konfiguraci Apache (viz dále)

Zároveň je možné pomocí elementů SiteRule a Value omezit použití atributu jen pro určité identity providery nebo konkrétní hodnoty (podrobnosti na stránkách Shibboleth Wiki). Atributy, které nejsou definovány v AAP.xml nebo nesplňují kriteria, jsou ignorovány.

Aplikace pak může přistupovat k určeným atributům tím, že přečte příslušné HTTP hlavičky. Apache ale pro větší pohodlí nastavuje hodnoty hlaviček jako proměnné prostředí a tím umožňuje snadný přístup z prostředí většiny programovacích jazyků (PHP, Perl, C/C++, Java, …). Například, atribut, jehož konfigurace je uvedena výše, lze v PHP přečíst následujícím způsobem:

<?php
$email = $_SERVER['HTTP_SHIB_INETORGPERSON_MAIL'];
?>

Navíc, Shibboleth může aplikaci poskytnout i původní SAML zprávu, asociovanou s aktuálním dotazem. K tomu je potřeba nastavit atribut exportAssertion pro příslušnou lokaci v hlavním konfiguračním souboru (shibboleth.xml):

<Host name="sp.example.org" requireSession="true" exportAssertion="true"/>

SAML zpráva se pak uloží do hlavičky Shib-Attributes zakódovaná do base64 (proměnná prostředí HTTP_SHIB_ATTRIBUTES). V případě delší zprávy se může stát, že se base64 řetězec nevejde do výchozí délky hlavičky pro daný web server. Naštěstí, nové verze Apache stejně jako IIS podporují direktivy, kterým lze tuto hodnotu změnit (například pro Apache je to direktiva LimitRequestFieldSize).

V Shibboleth infrastruktuře samotný proces autentizace neodhalí identitu uživatele. Service provider vydá požadavek k autentizaci, identity provider pak v případě úspěšné autentizace pošle zpět pozitivní odpověď, ale nemusí poskytnout žádné informace ohledně identity uživatele. Znamená to, že identity provider nemusí poskytovat citlivé informace aplikacím, které to nepotřebují. Nicméně, většina aplikací potřebuje pracovat s nějakými identitami, aby mohla rozpoznávat jednotlivé uživatele, ukládat jejich nastavení, nastavovat role a přístupová práva.

Taková identita může být založena na uživatelským atributu. Běžně je to atribut eduPersonPrincipalName, ale může to být jakýkoliv jiný. Obvykle se tento identifikační atribut mapuje na proměnnou prostředí REMOTE_USER, například:

<AttributeRule Name="urn:mace:dir:attribute-def:eduPersonPrincipalName" 
               Scoped="true" 
               Header="REMOTE_USER" 
               Alias="scoped_user">
 
    <AnySite>
        <Value Type="regexp">^[^@]+$</Value>
    </AnySite>
</AttributeRule>

Vlastnost Scope stanovuje, že k hodnotě atributu se připojí údaj o původu uživateli – jakási doména, asociována s identity providerem uživatele. Například, uživatel „joe“ pocházející z identity provideru s doménou „example.org“ bude mít proměnnou REMOTE_USER nastavenou jako „joe@example.org“. Cílem je zachovat unikátnost uživatelských identit napříč federace.

V případě, že je proměnná REMOTE_USER správně nastavena, autentizaci můžeme provést například takto:

<?php
$identity = null;
if (isset($_SERVER['REMOTE_USER']) && !empty($_SERVER['REMOTE_USER'])) {
  $identity = $_SERVER['REMOTE_USER'];
}
else {
  // Error, identity attribute is missing
}
?>

Zatímco autentizaci obstarává identity provider, autorizaci musí zajistit service provider. Autorizační rozhodnutí provádí service provider na základě výsledku autentizace a dále na základě uživatelských atributů v případě úspěšné autentizace. Samotná aplikace pak může disponovat vlastními mechanismy autorizace.

Nejjednodušší způsob je definovat práva přístupu pomocí příslušných direktiv přímo v konfiguraci web serveru. V Apache se tyto direktivy můžou definovat pro následující sekce – File, Directory, Location a to, jak v centrální konfigurace, tak i ve zvláštním .htaccess souboru, umístěném v chráněném adresáři. Používá se standardní direktiva známá z BasicAuth:

Require entity-name value [value] ...

V tomto případě pole entity-name odpovídá položce Alias u nastavení atributu v AAP.xml. Například, následující direktivy omezují přístup pouze pro zaměstnance:

<Directory /secure>
    AuthType shibboleth
    ShibRequireSession On
    Require affiliation student staff
</Directory>

Je možné definovat více Require direktiv pro danou lokaci. Pokud není zároveň nastavena direktiva ShibRequireAll, stačí, aby uživatel splňoval pouze jednu z podmínek, aby získal přístup k zdroji.

Výhoda autorizace definované v Apache je v jednoduchosti – používá se standardní konfigurační prostředí Apache. Tento způsob konfigurace ale není dostatečně flexibilní pro definici složitějších pravidel. K tomu je potřeba použít nativní konfigurační prostředí Shibboleth založené na XML. Syntaxe podporuje vnořené logické výrazy s operátory AND, OR a NOT. Tuto konfiguraci je možné definovat přímo v hlavním konfiguračním souboru shibboleth.xml nebo uložit do zvláštního souboru.

Příklad konfigurace v shibboleth.xml:

<RequestMapProvider 
  type="edu.internet2.middleware.shibboleth.sp.provider.NativeRequestMapProvider">
<RequestMap applicationId="default">
 
<Host name="sp.example.org">
  <Path name="secure" authType="shibboleth" requireSession="true">
    <AccessControl>
      <AND>
        <OR>
          <Rule require="affiliation">member@example.org</Rule>
          <Rule require="affiliation">member@otherexample.org</Rule>
        </OR>
        <Rule require="entitlement">urn:mace:example.org:exampleEntitlement</Rule>
      </AND>
    </AccessControl>
  </Path>
</Host>
 
</RequestMap>
</RequestMapProvider>

V případě použití zvláštního souboru, místo definic logických výrazu umístíme element AccessControlProvider obsahující odkaz na externí soubor:

<Host name="sp.example.org">
  <Path name="secure" authType="shibboleth" requireSession="true">
 
    <AccessControlProvider 
      uri="/var/www/secure/.shibacl.xml" 
      type="edu.internet2.middleware.shibboleth.sp.provider.XMLAccessControl"/>
 
  </Path>
</Host>

Obsah externího souboru .shibacl.xml:

<?xml version="1.0" encoding="UTF-8"?>
<AccessControl xmlns="urn:mace:shibboleth:target:config:1.0">
  <AND>
    <OR>
      <Rule require="affiliation">member@example.org</Rule>
      <Rule require="affiliation">member@otherexample.org</Rule>
    </OR>
    <Rule require="entitlement">urn:mace:example.org:exampleEntitlement</Rule>
  </AND>
</AccessControl>

Podrobné informace lze získat na stránkách Shibboleth Wiki.

V mnoha případech je potřeba, aby byla autorizace zabudovaná přímo v aplikaci. Hodnoty atributů jsou přístupné z proměnných prostředí, aplikace je přečte a na základě jejich hodnot provede autorizační rozhodnutí. Například lze nastavit roli uživatele na základě atributu affiliation:

<?php
if ($_SERVER['HTTP_SHIB_EP_AFFILIATION'] == 'member@example.org') {
  $userRole = 'member';
}
?>

Složitější aplikace definují vlastní přístupová práva vázané na identitu uživatele. Vzhledem k tomu, že jsou tyto přístupová práva relevantní jen pro danou aplikaci, jsou uloženy lokálně a jsou nezávislá na infrastruktuře Shibboleth. Infrastruktura pouze poskytne identitu uživatele, aplikace k této identitě asociuje přístupová práva.

Typicky to může byt diskusní fórum, kde se vyskytují různé role (administrátor, moderátor, uživatel), definují se uživatelské skupiny, které mají různá práva na čtení a zápis pro různé sekce fóra. Tyto relace jsou uloženy lokálně. Není vhodné a často je i nemožné tyto vztahy ukládat globálně. Ovšem, na základě globálních atributů získaných z Shibboleth infrastruktury lze uživateli přiřadit lokální roli nebo skupinu.

Při úspěšné autentizaci, na straně service provideru vzniká session. Uživateli je pak dovoleno přistupovat k aplikaci po dobu trvání této session. Po ukončení její platnosti service provider pošle identity provideru nový požadavek o autentizaci (AuthN request). Samotný identity provider uchovává tzv. login session v asociaci s daném uživateli. Tato session vzniká při úspěšné autentizaci uživatele a po dobu její trvání nemusí zadávat uživatel svoje přihlašovací údaje při požadavcích o autentizaci ze strany service provideru. Obě tyto sessions mají omezenou životnost, kterou lze nastavit v konfiguraci v závislosti na politiky pro danou síť a na potřebách aplikací.

V případě aplikací nebo zdrojů, kde je přihlášení vždy povinné, je vhodné vyžadovat vytvoření session při každém dotazu. V konfiguraci Apache lze použít direktivu ShibRequireSession, například:

<Directory /secure>
  AuthType shibboleth
  ShibRequireSession On
  ...
</Directory>

Rozhodnutí o tom, jak nakládat se sessions, lze provádět i přímo v konfiguraci Shibboleth:

<Directory /secure>
  AuthType shibboleth
  Require shibboleth
  ...
</Directory>

V shibboleth.xml pak můžeme nastavit atribut requireSession pro příslušný <Path> element:

<Host name="sp.example.org">
  <Path name="secure" authType="shibboleth" requireSession="true">
    ...
  </Path>
</Host>

V případě, že vytvoření session nebude povinné (requireSession=“false“), nespustí autentizační proces, neproběhne stažení uživatelských atributů a nenastaví se příslušné proměnné prostředí. Vznik session je potřeba iniciovat „manuálně“.

Velká část aplikací, které vyžadují autentizaci, dovolují také omezený anonymní přístup. Uživatelé navštíví dané stránky a případně se můžou přihlásit, aby se dostali k chráněnému obsahu. V takových případech je vhodnější iniciovat session až když je to potřeba. U Shibbolethu se této funkcionalitě říká „lazy sessions“.

K tomu je potřeba vypnout požadavek na vytvoření session (viz předchozí sekci). Pro „manuální“ vytvoření session (obvyklé když uživatel klikne na přihlašovací tlačítko) je potřeba využít komponentu Shibboleth SessionInitiator. Místo implementaci speciálního aplikačního rozhraní pro přístup k této komponentě, Shibboleth používá virtuální URL. Přístup k tomuto URL spouští proces tvorby session (autentizace, výměna atributů atd.). Právě k tomuto URL je potřeba přesměrovat uživatele poté co klikne na přihlašovací tlačítko. Hodnota URL závisí na konfiguraci.

Příklad virtuálního URL:

/Shibboleth.sso/WAYF/myFed?target=https://sp.example.org/

První část URL /Shibboleth.sso odpovídá hodnotě atributu handleURL v elementu <Sessions> v shibboleth.xml:

<Sessions lifetime="7200" timeout="3600" 
          checkAddress="true" consistentAddress="true"
          handlerURL="/Shibboleth.sso" handlerSSL="true" 
          idpHistory="true" idpHistoryDays="7"
          cookieProps="; path=/; secure">
 
  ...
</Sessions>

Druhá část - /WAYF/myFed – je definována pomocí atributu Location v elementu <SessionInitiator> v shibboleth.xml:

<SessionInitiator
    isDefault="true" id="myfed" 
    Location="/WAYF/myFed"
    Binding="urn:mace:shibboleth:sp:1.3:SessionInit"
    wayfURL="https://www.myfed.org/wayf/"
    wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/>

Hodnota parametru target je URL, kam se provede přesměrování po úspěšné autentizaci.

„Lazy sessions“ se od normálních sessions nijak neliší, nicméně je důležité, aby aplikace detekovaly jejich expiraci a podnikaly vhodná opatření – například iniciovat novou session anebo označit uživatele za anonymního.

Spoléhat výhradně na session v Shibbolethu má jisté nevýhody. Životnost je omezena v konfiguraci shibboleth.xml, což může být nevhodné pro některé aplikace, zvláště pro ty, co implementují vlastní session management. Například, pro uživatele používající danou aplikaci často může být obtěžující přihlašovat se každou chvíli znovu. Další problém může nastat, pokud session vyprší v okamžiku vyplňování formuláře. Po odeslání formulaře je uživatel přesměrován k identity provideru a obsah je ztracen.

Na druhou stranu, prodloužení životnosti session také není ideální řešení, problémy budou vznikat stále, i když se budou projevovat méně často. Optimálním řešením je spravovat sessions na úrovni aplikace, ale zároveň využívat Shibboleth infrastrukturu pro autentizaci a výměnu atributů. Lze to dosáhnout tím, že pod pod zabezpečení Shibbolethu umístíme pouze přihlašovací stránku aplikace. V případě potřeby autentizace (uživatel klikne na přihlašovací tlačítko) aplikace přesměruje uživatele na přihlašovací stránku, která je chráněna Shibbolethem a tudíž vyžaduje platnou Shibboleth session. Tudíž proběhne standardní proces tvorby session – přesměrování, autentizace, žádost o atributy, návrat. Aplikace pak na základě toho vytvoří vlastní session, do které případně uloží získane uživatelské atributy a uživatele přesměruje zpět.

Například, pokud je aplikace umístěna na adrese http://www.example.org/app/, přihlašovací stránka může mít adresu http://www.example.org/app/login/. Pro cestu /app/login/ nastavíme v příslušné sekci Location v konfiguraci Apache, že vyžaduje Shibboleth session:

<Location /app/login/>
  AuthType shibboleth
  ShibRequireSession On
  ...
</Location>

V adresáři /app/login/ pak umístíme skript index.php, který se postará o přihlášení uživatele na základě dat z Shibboleth infrastruktury:

<?php
// first we need to check if the authentication process has been triggered
if (isset($_SERVER['HTTP_SHIB_IDENTITY_PROVIDER'])) {
 
  // then we check for username
  if (isset($_SERVER['REMOTE_USER'])) {
    // if present, we save the username into the session
    $SESSION['user']['username'] = $_SERVER['REMOTE_USER'];
    // ... as well as some other attributes
    $SESSION['user']['email'] = $_SERVER['HTTP_SHIB_INETORGPERSON_MAIL'];
    $SESSION['user']['name'] = $_SERVER['HTTP_SHIB_PERSON_COMMONNAME'];
    // ...
 
    // perform redirect back to the application
    header('Location: http://www.example.org/app/');
  }
  else {
    // handle error - username not found
  }
 
}
else {
  // handle error - no shibboleth session
}
?>

Aplikace pak rozpozná autentizovaného uživatele podle toho, že má nastavené uživatelské jméno ($SESSION['user']['username']). Neautentizovaným uživatelům může aplikace nabídnout přihlašovací tlačítko nebo rovnou přesměrovávat na přihlašovací stránku:

<?php
session_start();
 
// check if authenticated
if (!isset($_SESSION['user']['username'])) {
  // redirect the user to perform login
  header('Location: http://www.example.org/app/login/');
}
?>

Při použití automatických přesměrování je obzvlášť důležité vhodně ošetřovat chybové stavy, které můžou vzniknout v přihlašovacím skriptu, aby nevznikaly nekonečné smyčky mezi přihlašovací stránkou a aplikaci.

V případě výskytu chyby během zpracování dotazu Shibbolethem se zobrazí stránka s chybovou hláškou. Shibboleth tuto stránku vytváří pomocí šablon, které jsou umístěné nejčastějí v konfiguračním adresáři (v závislosti na nastavení). Bylo by vhodné, přizpůsobit tyto šablony vzhledu a potřebám aplikace, například – přidat logo aplikace, kontaktní informace, odkazy na nápovědu atd.

Nastavení šablon lze změnit v shibboleth.xml:

<Errors session="/etc/shibboleth/sessionError.html"
        metadata="/etc/shibboleth/metadataError.html"
        rm="/etc/shibboleth/rmError.html"
        access="/etc/shibboleth/accessError.html"
        ssl="/etc/shibboleth/sslError.html"
        supportContact="root@localhost"
        logoLocation="/shibboleth-sp/logo.jpg"
        styleSheet="/shibboleth-sp/main.css" />

Pro různé typy chyb existují různé šablony. V šablonách je možné použít jednoduché skriptování formou speciálních tagů:

<shibmlp tag-name>

Za řetězec tag-name je možné dosadit nazev atributu z elementu <Errors> v shibboleth.xml, například:

<shibmlp supportContact>

Shibboleth pak ve výsledné stránce nahradí tento tag hodnotou atributu supportContact – root@localhost.

Navíc, je možné použít i některé speciální řetězce:

• requestURL – URL dotazu
• errorType – typ chyby
• errorText – chybové hlášení
• errorDesc – podrobnější popis chyby, určen uživateli
• originContactName – jméno správce identity provideru
• originContactEmail – email správce identity provideru
• originErrorURL – adresa stránky identity provideru poskytující uživatelskou podporu v případě chyb

Je také možné použít jednoduché podmíněné příkazy v závislosti na existenci specifickýho tagu:

<shibmlpif tag-name> arbitrary markup </shibmlpif>
<shibmlpifnot tag-name> arbitrary markup </shibmlpifnot>

V současné době Shibboleth nenabízí možnost globálního odhlášení. Je možné provádět pouze lokální odhlášení (v kontextu service providera), ale dokud je tzv. login session na straně identity providera aktivní, je možné opětovně vstoupit do aplikace bez nutnosti zadávat přihlašovací údaje.

Nicméně, v některých případech zvláště za použití „lazy sessions“ můžé být vhodné implementovat lokální odhlášení. Samotné lokální odhlášení představuje ve své podstatě smazání cookie, která identifikuje Shibboleth session. Pro ulehčení nabízí Shibboleth k tomu úkonu opět virtuální URL, které lze nastavit v konfiguraci a po jehož navštívení je potřebná cookie smazaná a příslušná session zrušená. Virtuální logout URL lze nastavit v elementu <md:SingleLogoutService> v příslušném <Sessions> elementu v shibboleth.xml (výchozí nastavení je /Logout):

<Sessions lifetime="7200" timeout="3600" checkAddress="true" 
          consistentAddress="true" handlerURL="/Shibboleth.sso" 
          handlerSSL="true" idpHistory="true" idpHistoryDays="7"
          cookieProps="; path=/; secure">
 
  <!- ... ->
 
  <md:SingleLogoutService Location="/Logout" 
                          Binding="urn:mace:shibboleth:sp:1.3:Logout"/>
 
</Sessions>

Je-li adresa serveru www.example.org, výsledné „odhlašovací“ URL je pak:

http://www.example.org/Shibboleth.sso/Logout

Jako jediný způsob, jak provést globální odhlášení, zatím zůstává ukončení běhu webovského prohlížeče, čímž se vymažou všechny cookies, identifikujici jednotlivé sessions. Funkcionalita globálního odhlášení bude s největší pravděpodobnosti implementována v nové verzi Shibboleth – 2.x.

Zatímco vývoj nových aplikací s podporou Shibboleth je relativně snadný a přímočarý, adaptace existujících programů může být více či méně problematická v závislosti na složitosti, struktury a uspořádání kódu. Na základě zkušeností ale lze tvrdit, že převážná většina existujících web aplikací je možné přizpůsobit bez větších problémů. Platí to především pro aplikace s otevřeným kódem. Adaptace proprietárních aplikací může být komplikovaná, i když i pro tyto případy lze často najít kompromisní řešení.

Aplikace podporující Shibboleth neprovádí autentizaci, ale pouze přebírají informace z proměnných prostředí. Identita uživatele je obvykle uložena v proměnné REMOTE_USER, ale nemusí tomu tak být, lze použít libovolnou proměnnou (viz nastavení atributů v AAP.xml). Tudíž, abychom implementovali Shibboleth autentizaci, je potřeba nahradit nativní autentizaci dané aplikaci kódem, který nastaví identitu uživatele na základě proměnných prostředí nastavených Shibbolethem. Je také důležité vhodně zvolit atribut (poskytnutý identity providerem), který se stane zdrojem pro identitu uživatele. Často je tento atribut v rámci federaci pevně daný na základě politiky federace. Jako zdroj identity lze použít například - eduPersonPrincipalName, eduPersonTargetedId nebo také email.

Některé aplikace podporují více způsobů autentizace (autentizačních back-endů). Většinou to znaméná, že aplikace implementuje jednotné autentizační rozhraní, na které navazují různé autentizační adaptery. Adaptace podobných aplikací je velmi snadná, jelikož stačí implementovat podporu Shibboleth jako další z adapterů.

Nejčastěji autentizace uživatele spočívá v odesláním přihlašovacích údajů (obvykle uživatelské jméno a heslo) na speciální přihlašovací stránce. Při autentizaci pomocí Shibboleth není třeba uživatelského vstupu. V tomto směru je to podobné „basic“ autentizaci v Apache. Aplikace podporující „basic“ autentizaci jednoduše kontrolují hodnotu proměnné REMOTE_USER a obvykle neimplementují vlastní správu uživatelů (například DokuWiki). Tyto aplikace lze snadno přizpůsobit pro Shibboleth autentizaci.

Řada aplikací implementuje vlastní správu uživatelů a jejich atributů, definuje uživatelské skupiny a role, přiřazuje práva apod. K tomu často implementují související funkce jako například – automatická registrace uživatelů, možnost editace vlastního profilu, možnost znovu získat zapomenuté heslo atd. V aplikaci podporující Shibboleth většina těchto funkcí se stává irelevantní a měla by být vyřazena s tím, že vnitřní vazby a vztahy mezi uživateli a jejich atributy (skupiny, role, práva) by měly být naopak zachovány.

Pro takovou aplikaci je stále potřeba vytvářet uživatele i lokálně, přestože autentizaci a uživatelské atributy poskytuje Shibboleth infrastruktura. Uživatele může vytvářet administrátor ručně, ale lepší je vytvářet lokální uživatelské účty automaticky v okamžiku prvního přihlášení uživatelů. Pravděpodobně bude potřeba při tom nastavit některé z lokálních atributů (jméno, email, …) na základě atributů získaných z Shibboleth infrastruktury (poskytuje-li je). Většinou bude vhodné zabránit uživatelům v přímé editaci těchto atributů. Aby byly tyto atributy stále aktuální, je potřeba obnovovat jejich hodnoty v lokální databázi při každém přihlášení uživatele.

V některých případech je možné postavit autorizaci přímo na atributech získaných z Shibboleth infrastruktury. Většinou jde o jednoduché přiřazení rolí či skupin. Například na základě hodnoty atributu eduPersonAffiliation, která může nabývat hodnot jako student, staff, faculty a další, je možné přiřadit studentům, učitelům a zaměstnancům různá práva.

Vývoj aplikací s podporou Shibboleth je relativně snadné. K tomu jsou ale potřeba jisté znalosti ohledně Shibboleth infrastruktury jako celek a speciálně ohledně způsobu jakým Shibboleth Service Provider zpracovává příchozí dotazy. Na druhou stranu, v případě adaptace existujících aplikací je potřeba dobře pochopit její vnitřní logiku a způsob, jakým řeší procesy jako autentizace, autorizace a správu uživatelů.

Shibboleth je pravděpodobně nejrozšířenější federativní infrastruktura. Už celá řada aplikací a služeb na webu ji podporuje. Aktuální seznam je k dispozici na stránkách Shibboleth Wiki.

• Novakov I., Integrating applications with Shibboleth Service Provider
• Shibboleth project - Internet2 Middleware
• Shibboleth - Internet2 Wiki
• SWITCHaai
• czTestFed - Czech testbed federation homepage