AAI Oldalak
OpenSSO
OpenSSO
OpenSSO telepítése
Az OpenSSO szerver letölthető a projekt oldaláról . Telepítéshez servlet-api támogató alkalmazásszerver szükséges. (Tomcat-et nem ajánlják a futtatásra, inkább érdemes nagyobb alkalmazásszervereken futtatni, pl. Glassfish vagy Oracle AS)
Az alkalmazásszerver konfigurációjában a Heap size-ot 1G méretűre kell állítani (-Xmx1G), különben a telepítés hibát dob. Valamint érdemes a JVM hotspotot -server módban futtatni. (/path/to/glassfish/domains/domain/config/domain.xml)
Glassfish V2UR1 alatt így zajlik a telepítés:
$ /path/to/asadmin deploy --name opensso --contextroot opensso /path/to/opensso.war
Ezután webes felületen történik a konfigurálás: meg kell adni az admin felhasználó nevét, jelszavát, a konfigurációs címtár paramétereit (érdemes a beágyazott címtárat használni), a felhasználókat tároló címtár paramétereit (host, port, admin bind paraméterek és DIT gyökér).
Sikeres telepítés esetén a webes felületen állíthatjuk be ízlésünk szerint a kért szolgáltatásokat.
Realm-ek
Az OpenSSO egyszerre képes több szervezetet kiszolgálni, ezeknek a konfigurációját külön-külön 'realm'-ekben kezeli. Minden realmhez megadhatóak az authentikációs modulok, a felhasználói adatokat tartalmazó címtár elérésének paraméterei, egyedileg szerkeszthetők a hozzáférési szabályok, és a federációs konfiguráció is teljesen külön van minden szervezetnél.
Hosztolt IDP beállítása
Legegyszerűbben a nyitóoldalon elhelyezett gyorslinkekkel hozhatunk létre új IDP-t ('Create hosted Identity Provider'). Ekkor meg kell adni a realm-et, és hogy melyik Circle-of-trust részévé kívánjuk tenni az IDP-t. Ha még nem hoztunk létre COT-ot, akkor azt megtehetjük itt.
Ezután a 'Federation' fül alatt találjuk az összes beállítási paramétert. A hosztolt IDP minden beállítását elvégezhetjük adminfelületről: aláíró és titkosító kulcsok (ezeket keystore-ból veszi, amit a keytool parancssal menedzselhetünk parancssorból), támogatott NameID formátumok, attríbutum mappelés akár saját osztállyal, és persze a támogatott SAML2 bindingok - Redirect, POST, Artifact - paraméterei.
A beállított metaadatok XML formátumban a http://host:port/opensso/saml2/jsp/exportmetadata.jsp URL-en lesznek elérhetőek. (az exportmetadata.jsp a következő paramétereket tudja fogadni: realm, entityID)
Amennyiben digitálisan aláírt metaadatra van szükségünk, azt az adminkonzolból tudjuk csak exportálni, illetve ezen patch segítségével az exportmetadata.jsp -ből is a signMetadata=true paraméter megadásával ( https://opensso.dev.java.net/issues/show_bug.cgi?id=2680 )
Új SP hozzáadása
Szintén a taszkok között található link új távoli SP hozzáadására ('Register remote Service Provider'). Itt a SAML2 metaadat URL-jét kell megadni, vagy feltölteni azt. Ezen kívül egy listában megadható, hogy milyen attribútum-leképzést igényel az SP. Természetesen az SP-t is hozzá kell adni egy COT-hoz.
Miután felvettük az SP-t, néhány attribútumot a Federation fülön átállíthatunk utólag is.
Interoperabilitás
OpenSSO IdP - Shibboleth2 SP
OpenSSO SP - Shibboleth2 IdP
OpenSSO IdP - SimpleSAMLphp SAML2 SP
Problémák
Hibás metaadat hozzáadása (vannak hibák, amiket az import parancs nem vesz észre) után a hozzáadott entity-t nem lehet törölni sem, ilyenkor a teljes federation fül működésképtelenné válik. Megoldás: újraindítás és a famadm delete-entity parancs használata. Ha ez sem megy, akkor a konfigurációs címtárból ki kell törölni az entity-t.
Az SP metaadatának tartalmazni kell a NameID attribútumot, az IDP anélkül nem képes a federációra. Ezt a ManageNameIDService után, és az AssertionConsumerService elé kell beírni, pl. így
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
OpenSSO IdP - Shibboleth2 SP
Cél
http://maszat.sch.bme.hu -n futó OpenSSO-n IdP létrehozása, és a https://sandbox.aai.niif.hu/shibboleth alatt futó Shibboleth 2 SP-vel való federáció.
OpenSSO IdP létrehozása
lásd: OpenSSO
Cél Realm: /niif-teszt
IDP entityID: https://idp.sch.bme.hu/niif-teszt
Legalább a "signing certificate alias" -t állítsuk be
A /opensso/famadm.jsp -> export-entity parancssal tudjuk XML-ként exportálni az létrehozott IDP metaadatát. (Vagy, a /opensso/saml2/jsp/exportmetadata.jsp?entityID= https://idp.sch.bme.hu/niif-teszt&realm=/niif-teszt URL-ről közvetlenül elérhetjük).
Shibboleth 2 SP beállítása
/etc/shibboleth/shibboleth2.xml:
...
...
...
Shibboleth SP Metadata importálása OpenSSO-ba
A lementett XML-ből töröljük ki az node-ot, mivel a parszolás során hibaüzenetet dob, ami a teljes SAML2Meta konfigurációt megfekteti.
ERROR: SAML2MetaManager.getEntityDescriptor
javax.xml.bind.UnmarshalException: Unexpected end of element {urn:oasis:names:tc:SAML:2.0:metadata}:Extensions
...
Ha ez a hiba előjön, akkor a konfigurációs címtárból kell törölni az entity-t, ugyanis ilyenkor teljesen használhatatlan lesz a felület (ez egy bug sajnos)
$ ldapmodify ...
dn: ou=,ou=default,ou=OrganizationConfig,ou=1.0,ou=sunFMSAML2MetadataService,ou=services,
o=,ou=services,
changetype: delete
A problémát az okozza, hogy amikor a metadata xml-t beolvassa a SAX parszer, akkor JAXB-vel mappeli java objektumokra, és ezt marshallolja ki a konfigurációs store-ba. Viszont az Extensions belseje egy teljesen
külön névtér és külön séma, ezért arra nincsenek generált osztályok. Ezt úgy veszi a JAXB, hogy egy -t ír ki, ami viszont unmarshal időben nem felel meg már a sémának (ugyanis xsd szerint ott legalább egy elemnek lennie kell).
Egyelőre azt a megoldást javasolták, hogy kézzel szedjem ki az -t, aminek továbbra sem örülök az xml aláírás és a kézi hegesztés miatt. Idővel egy olyan javítást fognak készíteni, amivel user osztálykönyvtárat meg lehet adni az opensso-nak, hogy a metaadat bizonyos részeit (pl. extensions belseje) arra mappelje le. Illetve
tettem egy olyan javaslatot, hogy ilyen esetben amikor kinullozza a node belsejét a JAXB, akkor a teljes node-ot töröljék, így legalább az xml valid marad. Talán azt is javítják, hogy ilyenkor a teljes metaadat rész összeomlik és semmilyen műveletet nem lehet végezni. ( https://opensso.dev.java.net/issues/show_bug.cgi?id=2736 )
A ManageNameIDService ill. AssertionConsumerService közé írjuk be a következő node-okat:
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Ha nem adunk meg NameIDFormat -ot, akkor az OpenSSO IdP vissza fogja utasítani a kérést. Megj. https://opensso.dev.java.net/issues/show_bug.cgi?id=2172 hosszútávon ezt a viselkedést valószínű megváltoztatják.
Ezt a metaadatot a Federation fül Entities -> Import Entity parancssal tudjuk importálni. Itt ki kell választani a /niif-teszt realm-et, és feltölteni az XML-t (vagy megadni az URL-jét). Ezután felül a Circle of Trust-nál hozzá tudjuk már adni a SAML2 SP-t.
Ha mindezt végigcsináltuk, máris működik minden.
Problémák
Ha Shibboleth2 SP-ben külön application-be tesszük a metaadatot, akkor nem találja meg a SAML Response issuer-alapján.
Az OpenSSO nem jelzi a saml attribútum névformátumát ( ). A Shibboleth pedig csak az urn:oasis:names:tc:SAML:2.0:attrname-format:uri típusú nevet fogadja el.
Emiatt a következő probléma adódik:
shibd.log:
2008-05-14 18:33:25 INFO Shibboleth.AttributeExtractor : creating mapping for Attribute urn:mace:dir:attribute-def:mail
...
hege@*********
...
2008-05-14 18:33:31 INFO Shibboleth.AttributeExtractor [1]: skipping unmapped SAML 2.0 Attribute
with Name: urn:mace:dir:attribute-def:mail, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:unspecifiedd
Itt egy patch OpenSSO-hoz ami megoldja a problémát: https://opensso.dev.java.net/issues/show_bug.cgi?id=2775
Ezen patch használatával a következő módon kell megadni az IDP attribútum mappelést az IDP > Attribute Processing fülön:
# [NameFormat|]SAMLAttributeName=LocalAttributeName
urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:mail=mail
OpenSSO IdP - SimpleSAMLphp SAML2 SP
Cél
OpenSSO hosztolt IdP és SimpleSAMLphp SP összekapcsolása a SAML2 protokoll segítségével.
SimpleSAMLphp telepítése
[[ http://rnd.feide.no/content/installing-simplesamlphp ]]
Konfigurációs paraméterek (config/config.php)
A következő paramétereket érdemes beállítani kezdésképp:
secretsalt: egy titkos 32 bájtos véletlenszám, amit a titkosításhoz használni fog a simplesamlphp
technicalcontact_name,email: az üzemeltető technikai kapcsolattartója
logging_handler: file / syslog
debug: bekapcsolva minden saml kérés és válasz megjelenik a webes felületen (kényelmes!)
enable.saml20-sp, enable.saml20-idp, enable.shib13-sp, enable.shib13-idp
default-saml20-idp: Discovery Service megkerülése és fix IdP választása
IdP metaadat beállítása
metadata/saml20-idp-remote.php:
'https://idp.sch.bme.hu/niif-teszt' => array(
'name' => 'NIIF Test at idp.sch.bme.hu',
'description' => 'Log in via idp.sch.bme.hu',
'SingleSignOnService' => 'http://maszat.sch.bme.hu:58080/opensso/SSORedirect/metaAlias/niif-teszt/idp',
'SingleLogoutService' => 'http://maszat.sch.bme.hu:58080/opensso/IDPSloRedirect/metaAlias/niif-teszt/idp',
'base64attributes' => false,
'request.signing' => false,
'certificate' => "maszat-idp.crt",
'certFingerprint' => "DE:F1:8D:BE:D5:47:CD:F3:D5:2B:62:7F:41:63:7C:44:30:45:FE:33",
'saml2.relaxvalidation' => array('noattributestatement')
)
A cert könyvtárba mentsük le a maszat-idp.crt-t (például a maszat idp metaadatból kimásolva).
A fenti konfiguráció HTTP/Redirect bindingot használ a SAML Requestre, a választ pedig HTTP/Post-on keresztül kapja. Fontos, hogy a base64attributes ki legyen kapcsolva, ugyanis az OpenSSO IdP nem kódolja base64-be az attribútumokat a SAML Response-ban.
SP metaadat beállítása
metadata/saml20-sp-hosted.php:
'https://maszat.sch.bme.hu/simplesamlphp/sp/niif-teszt' => array(
'host' => 'maszat.sch.bme.hu',
/*'privatekey' => 'server.pem',
'certificate' => 'server.crt',
'request.signing' => true,*/
'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
)
Ezután a /simplesamlphp/saml2/sp/metadata.php?output=xml URL-en keresztül tudjuk elérni az SP metaadatot. Fontos, hogy ebben a generált metaadatban nem tükröződik pl. a signing certificate és a NameIDFormat beállítás, ezért ezeket kézzel kell beleszerkeszteni.
Miután kijavítgattuk a metaadat fájlt, az OpenSSO adminfelület Federation -> Import Entity parancsával tudjuk importálni a megfelelő Realm-be. Importálás után a Circle of Trust konfigurációhoz is hozzá kell adni a SimpleSAMLphp SP-t.
Problémák
Nincsenek :)
Drupal
Drupal telepítés
A Drupal aktuális verzióját az alábbi link segítségével lehet letölteni: https://ftp.drupal.org/files/projects/drupal-8.7.7.tar.gz
A letöltött tar.gz állományt tömörítsük ki a saját gépünkön. Miután a kitömörítettük, a mappa tartalmát feltölthetjük a tárhelyünkre.
A PWS-en található tárhelyünkhöz a SFTP segítségével tudunk kapcsolódni.
Windows operációs rendszer esetén pl. :WinSCP - https://winscp.net/eng/download.php
Szükséges adatok:
SFTP host: ftp.pws.niif.hu
SFTP user: < felhasználói név >
SFTP password: < jelszó >
A csatlakozás során fogadjuk el, a kiszolgáló kulcsának hozzáadását a gyorsítótárhoz.
Amennyiben sikeresen csatlakoztunk az alábbi mappa szerkezetet láthatjuk:
A korábban letöltött és kicsomagolt Drupal fájlokat másoljuk fel a www könyvtárba.
Miután feltöltésre kerültek a fájlok a domain név beírása után az alábbi oldalnak kell megjelennie:
Válasszuk ki az English opciót majd kattintsunk a Save and continue opcióra.
Válasszuk ki a Standard opciót.
Megjegyzés: Ha a követelmények ellenőrzése során azt a hibát kapjuk vissza, hogy a settings.php nem létezik.
Az alábbi fájlt nevezzük át: /protected/www/sites/default/default.settings.php -> settings.php -ra.
(Az átnevezés előtt ajánlott egy másolat készítése a default.setting.php fájlról)
A folytatáshoz görgessünk le az oldal aljára és kattintsunk a try again szövegre. A hibajelzés eltűnt, maradt egy Waring-ra felhívó szöveg. Ezt figyelmen kívül hagyhatjuk, görgessünk le ismét az oldal aljára és kattintsunk a continue anyway szövegre.
A következő lépésnél az adatbázis beállítása következik
A Database type-nál válasszuk ki a MySQL, MariaDB, Percona Server, or equivalent lehetőséget.
Töltsük ki az adatok.
Az adatbázis szerver az elérését az Advanced options-ra kattintva tudjuk megtenni.
További beállítások elvégzésére is lehetőségünk van.
A table name prefixet nem muszáj kitölteni.
Ha ezekkel meg vagyunk kattintsunk a Save and continue gombra.
Elkezdődik a Drupal telepítése.
Utolsó lépésként jön az oldal beállítása. Itt tudjuk megadni az oldalunk nevét, email címet, adminisztrátor név jelszó, régió beállítás.
Ha megvagyunk akkor Save and continue gombra kattintunk.
Egy kis várakozás után az oldalunk telepítése elkészül.
Telepítés után:
Állapot jelentésnél az alábbi hibákkal találkozhatunk:
http://sajtdomain/admin/reports/status
a) A settings.php olvasható/írható
Megoldás:
A /protected/www/sites/default/settings.php jogosultságát módosítsuk 0444-re,
A default mappa jogosultságát módosítsuk 0555-re.
b) A trusted_host_patterns beállítás nincs még megadva a settings.php fájlban (Ez a hiba az oldal működését nem befolyásolja, csak állandó hibaként jelenik meg a státusznál)
Megoldás:
A /protected/www/sites/default/settings.php fájlban megkeressük a trusted_host pattern részt (kb. 721. sor) majd az ide vonatkozó részt kijelöljük és átmásoljuk a fájl végére.
Ha ezzel végeztünk akkor kikommentezzük és a példában szereplő adatokat kicseréljük a mi domain címünkre, majd az egészet másoljuk a fájl végére.
DrupalShibboleth
Elgondolás
A Drupal saját maga szereti kezelni a felhasználóit - adatbázisban -, de az azonosítás moduláris. A felhasználó beállításai a Drupal saját adatbázisában vannak, a Shibboleth modul csak a felhasználó azonosítóját adja meg.
Felhasználó létrehozása
Az IdP-nek azonosítania kell tudnia a felhasználót, tehát valamilyen központi adatbázisban léteznie kell.
Ha egy olyan felhasználó jelentkezik be a Drupalba, aki még korábban nem jelentkezett be (pontosabban ha a Shibboleth-en keresztül megkapott azonosító még nem létezik), akkor a modul létrehoz egy új Drupal felhasználót. A felhasználó jelszava egy olyan véletlenszerűen generált megfelelően hosszú karakter sorozat, amely egyaránt tartalmazhat kis- és nagybetűket, valamint számokat. Alapesetben a felhasználó számára a jelszó változtatása tiltott, így a hagyományos úton (felhasználó név/ jelszó párossal) nem tud. A későbbiekben a jelszó változtatásának joga azonban egyénileg, vagy csortosan kiosztható ezzel engedélyezve a két authentikáció párhuzamos használatát. Néhány felhasználói beállítás kezdeti értéke származhat a Shibboleth-től kapott attribútumokból:
teljes név
email cím
(Ez utóbb funkciót az implementáció nem tartalmazza, ugyanis a különböző Shibboleth beállításoknak megfelelően rendszerenként más információk állnak rendelkezésre. Ennek kezelése a modul jövőbeli fejlesztései közé tartozik.)
A felhasználói attribútumok változtatása az IdP-ben nem terjed át a Drupalra (leszámítva természetesen a felhasználói azonosítót), az Drupalban található attribútumok megváltoztathatók, ha ezt az oldal konfigurációja megengedi.
Az újonnan létrejött felhasználó alap jogosultságokkal rendelkezik, ezután az adminisztrátor további jogokat biztosíthat számára.
Felhasználó törlése
A felhasználót a központi adatbázisból kell törölni, ezáltal megszűnik a hozzáférése a Drupalhoz. A Drupal azonosítója és beállításai azonban megmaradnak, ami az alábbi következményekkel jár (Vigyázat! Ha korábban egedélyeztük számára a jelszavas belépést, akkor azt külön le kell tiltani!):
ha újra kiosztják a felhasználó azonosítóját, akkor a régi beállítások lesznek érvényesek
lehetséges privát üzenetet küldeni a felhasználó email címére
a törölt felhasználó mindaddig be tud lépni, amíg a Drupal által használt cookie érvényes, ezért célszerű memóriában tárolt cookie-kat használni (ld.: Drupal modul konfiguráció )
A fenti problémákat csak úgy lehet megoldani, ha egy alkalmazás a törölt felhasználók státuszát inaktiválja a Drupalban (és a hasonló elven felépülő többi rendszerben is).
Shibboleth konfiguráció
Be kell állítani a RequestMap-et az adott virtuális szerver adott könyvtárára, majd az Apache-nak a megfelelelő Directory vagy Location blokkjában be kell kapcsolni a Shibboleth azonosítást .
Info Lazy sessiont kell beállítani akkor, ha azt szeretnénk, hogy • anonymous módon hozzáférhető legyen a Drupal (pl. csak olvasásra) • az adminisztrátor be tudjon jelentkezni jelszóval.
Bővebben lásd: Required Session
Drupal Shibboleth modul
Amennyiben lehetővé szeretnéd tenni, hogy a rendszered felhasználói Shibboleth-en keresztül is azonosíthassák magukat, nem kell mást tenned, mint hogy a meglévő Drupal rendszeredhöz hozzáadjad a Drupal Shibboleth modul-t (shib_auth).
A Drupal Shibboleth modul angol nyelvű dokumentációja itt található
Figyelem A szócikk további része lehetséges, hogy elavult, az angol nyelvű dokumentáció az érvényes!
Telepítés
Telepítsd a userprotect modult
Töltsd le a rendszerünknek megfelelő verzióhoz tartozó userprotect modult a project honlapjáról !
Kövesd a modullal együtt érkező README.txt utasításait a telepítéshez!
Telepítsd a shib_auth modult
Töltsd le a rendszerünknek megfelelő verzióhoz tartozó shib_auth modult a project honlapjáról !
Másold be a tömörítve érkező fájlokat a rendszered modules/shib_auth könyvtárába. (Ez elsősorban a /modules/shib_auth útvonalon érhető el, azonban néha - főként multisite alkalmazások esetén - ettől eltérő is lehet.)
A portál adminisztrációs felületén keresztül (Administer/Site Building/Modules) engedélyezd a shib_auth modult! Amennyiben ezt a rendszer nem egedélyezné, bizonyosodj meg róla, hogy a Drupal verziójához tartozó modult töltötted-e le, valamint hogy a függőségként szereplő modulok be vannak-e már kapcsolva!
Konfiguráció
A modul telepítője elvégezi a szükséges beállítások és módosítások többségét, így neked már nincs sok tennivalód. Az egyetlen elengedhetetlen beállítás a modul (Administer/User management/Shibboleth authentication module settings útvonalon elérhető) adminisztrációs oldalán található, ahol megadható a a WAYF localhost -ra mutató útvonala. (például: /Shibboleth.sso/WAYF/NIIF-WAYF )
Ajánlott a settings.php-ben (pl.: /sites/default/settings.php) a cookie-k élettartamát 0-ra csökkenteni. ini_set('session.cookie_lifetime', 0);
Használat
A modul működése automatikus. A felhasználók a modul által létrehozott block-ban található url-re kattintva ( lazy-session ) vagy automatikusabn, az oldal betöltése közben ( required session ) authentikálják magukat a hozzájuk tartozó, a szerver által megbízhatónak tartott IdP-nél. A rendszer a apache modul által kapott információk alapján, az első bejelentkezés során létrehoz egy, a felhasználóhoz tartozó Drupal accountot, amihez egy véletlenszerű jelszót társít. Mivel a felhasználó ezt nem ismeri, így ezzel nem, kizárólag Shibboleth-es azonosítás segítségével tud belépni.
Info Amennyiben engedélyezni szeretnéd egy felhasználónak vagy csoportnak a Shibboleth-es belépésen túl a jelszavas azonosítást IS , nincs más dolgod, mint: • a felhasználónak, vagy csoportnak a jogosultságokat kezelő oldalon engedélyezni a jelszavának átállítását • majd ezt követően:
• beállítani neki egy jelszót és ezt közölni vele, vagy
• rávenni, hogy egy Shibboleth-es belépést követően adjon meg magának egy jelszót.
Admin felhasználó bejelentkezése
Érdemes egy, a Shibboleth-től elkülönítve kezelt adminisztrátort is létrehoznod (például a telepítés során), hogy a rendszer az IdP-től függetlenül is használható maradjon, vagy hogy például szükség esetén magát a shib_auth modult is el lehessen távolítani.
Mivel a modul kikapcsolja a főoldalon megjelenő user login blokkot, így azon keresztül nem lehetséges a username/password alapú belépés. (Ez a blokk opcionálisan visszakapcsolható.) Ahhoz hogy mégis be tudj lépni töltsd be a /?q=user oldalt anélkül, hogy Shibboleth-en keresztül authentikáltad volna magad.
Required session
Lehetőség van arra is, hogy a felhasználók Shibboleth-en keresztüli authentikációját kötelezően megköveteld az oldal valamennyi megtekintése előtt. Ebben az esetben azonban nem lehetséges a nem shib_auth-on keresztüli belépés, így amíg ez a kényszer fenn áll, nem megoldható, hogy adminisztrátorként lépj be.
DrupalShibbolethReadmeDev
Drupal shib_auth module enables Shibboleth authentication for Drupal CMS .
Installation and bootstrapping
Warning
The following documentation assumes that
• You understand how Shibboleth works
• You have successfully installed and configured Shibboleth SP on your host running Drupal.
Installing the module
Download module source for your Drupal version from the project page .
Uncompress archive to the modules/ directory
Enable module at Administer -> Site building -> Modules
Compatibility
The module assumes that you use Shibboleth SP 2.x. It's possible to use the module with Shibboleth SP 1.3, but that version is not supported anymore.
Upgrading the module
Figyelem
If you upgrade from 3.x (or previous versions) to 4.x, you must update the database . After overwriting the files in the modules/ directory, open up YOUR_DRUPAL_INSTALLATION/update.php in your browser and run update for the shib_auth module. This is required to let your user info persist.
The upgrade script makes slight changes to the database. You only need to run this script once, however running it several times does no harm to your installation apart from showing some SQL errors.
Note
although the upgrade script was designed to be robust, please back up your database before upgrading.
Moving from Drupal 6 to Drupal 7
To migrate your working installation to D7, first you must update your module to the latest 4.x version. After that, you can perform the Drupal update.
Get it running
Configuring Shibboleth
You should be familiar with protecting resources with Shibboleth before using this module. (See Shibboleth Wiki for comprehensive information) Please check that Shibboleth authentication is working for the location of your Drupal installation and all the necessary attributes are exported to the headers. You can enable DEBUG mode to dump the whole $_SERVER array. If you can see Shibboleth attributes there, you're fine.
In Shibboleth there are two modes for protecting resources:
Lazy Sessions : session is only initiated if an application redirects user to the SessionInitiator URL. In this module, it is done by clicking the "Login with Shibboleth" link. Anonymous access is possible as well as using other authentication methods. This is what you want to use for a CMS that contains public information .
Detailed description of lazy sessions in Hungarian.
"Strict" Sessions (normal sessions): users can only access Drupal content if they have a valid Shibboleth session. In this case, no anonymous access can be granted (not even read-only) and you can not use any auxiliary authentication methods. Most of the advanced features don't work with strict sessions. You should not use this unless you want to protect all the information in the CMS from viewing.
Note
after enabling "strict" sessions, you won't be able to login with admin user. Read on further how to give your own user administrator rights.
Example Shibboleth configuration
Note
this example uses lazy sessions.
/etc/shibboleth/shibboleth2.xml snippet :
Apache config file snippet (ie. /etc/apache2/sites-enabled/your.host.name , or you can even use .htaccess without the tags):
AuthType Shibboleth
ShibRequireSession Off
ShibUseHeaders On
require shibboleth
DEBUG mode
If you enable DEBUG mode on the module configuration interface, you can dump the $_SERVER , $_SESSION arrays and additionally the $user object, if the user is logged in. This mode shows you all the available attributes and helps you diagnosing possible Shibboleth attribute problems.
Keep in mind that some users might have a specific attribute while others don't.
Debug path prefix
Leave it empty, if you want to display debug information on every page. Enter the string user/ (mind the trailing slash!) for displaying DEBUG messages only on paths below user/*
Adding a prefix is useful, if you want to enable debugging on an online drupal installation without littering all of the pages with the debugging information. You can set it to a non-existent node as well, in this case, the information will be displayed over the built-in 404 page.
Setting Shibboleth parameters for the module
Handler settings
If you are using lazy sessions, you have to define the Shibboleth SessionInitiator to which the user should be directed when she clicks on "Login with Shibboleth". The SessionInitiator can be called on a special URL which depends on your Shibboleth configuration.
If your /etc/shibboleth/shibboleth2.xml is something like this:
Then your
Login URL is: http(s?)://your_fully_qualified_domain_name/Shibboleth.sso/Login
Logout URL is: http(s?)://your_fully_qualified_domain_name/Shibboleth.sso/Logout
Note
Most common errors are (please check Shibboleth documentation):
• using http when your Shibboleth SP is configured for https only (either by Apache settings or the handlerSSL parameter)
• you want to use another SessionInitiator (for example with Discovery Service), such as /DS
Attribute settings
Specify here the $_SERVER headers to look up the user's username and e-mail address. Please check DEBUG mode to look for the available headers. If you can not find the desired attribute, then something is wrong with your IdP-SP attribute release flow.
Both fields can have the same value, if you wish.
Redirecting authenticated users to HTTPS
It's a common problem if Shibboleth SP is configured on HTTPS only ( handlerSSL="true" ), while the site also works on plain HTTP. By using Force HTTPS on login feature, you can redirect your users to HTTPS at login time. This way you can have your anonymous users view your site unencrypted (which saves some CPU cycles), but once they login, they get redirected to HTTPS (which is the only secure use of Shibboleth SP).
Note
If you don't see Shibboleth attributes in DEBUG although you have double checked that you have set AuthType shibboleth , require shibboleth in your .htaccess file, you most probably need to turn this feature on.
Understanding features
Automatic user creation
Drupal CMS requires all users to be in its internal SQL database. If the module detects that no user exists in the database with the received Shibboleth user identifier, it creates a new (Drupal) user.
Drupal needs 3 pieces of information to create a new user:
username
e-mail address
password
The module by default uses the username and e-mail address taken from the $_SERVER headers, see [Attribute settings](#bkmrk-attribute settings) right above. On new user creation a random password is generated. This can be overwritten by the user unless you disallow it by the userprotect module.
Note
if the user overwrites the password, she can log in with her username and the new password.
Using custom values
You may want to let your users to define their own Drupal usernames and e-mail addresses other than what was received from the IdP. If either User-defined usernames or User-defined e-mail addresses option is set, new users are presented a form to enter data at the first logon.
Info
• The module ensures that neither values are in use by existing users.
• If you enable and later disable the options, the two behave differently. On subsequent logons:
• the user-defined username is preserved
• e-mail address gets rewritten (or the user gets a fatal error if the IdP does not provide the data)
• Even if you enable user-defined usernames, the IdP must send a unique identifier which must be in the server variable defined for username. This feature just enables you to use opaque identifiers such as eduPersonTargetedId
• User-defined e-mail addresses are not verified, only well-formedness is checked
Working with federated identifiers
If you enable the option User-defined usernames in the module configuration, every new user is presented a form to specify a Drupal username. This way you can work with opaque (federated) identifiers such as eduPersonTargetedId , as long as it appears in the $_SERVER variable holding the username. The only limitation is that the federated identifier cannot be longer than 255 characters, however it can contain characters otherwise not allowed in Drupal account names (such as exclamation mark, etc).
Disallowing password change
If you don't want to let your users to change passwords and log in with it, you may want to disallow password change.
Install Drupal User Protect module
At Administer -> User management -> User Protect -> Protected roles tab check password for the authenticated user role.
At Administer -> Permissions -> userprotect module: uncheck change own password for authenticated user
Log in with a normal account, go to "My account" -> Edit. You shouldn't see the possibility for changing password; except for the case when the user has user administrator rights.
Administering Drupal with strict sessions
If you use strict sessions, you can not log in with a password. You need to grant your own user administrator rights to administer the CMS.
Enable Shibboleth protection
Login with your own user credentials, so that your Drupal user profile is created
Disable Shibboleth protection
Login as 'admin', grant your own user 'Administrator' rights.
Enable Shibboleth protection
Login with your own credentials, you should have 'Administrator' rights now.
Pre-creating users
Versions before 4.0 allowed pre-creating users without any tweaks; if the username matched, the user was logged in.
Since 4.0 the module only logs in users who exist in {shib_authmap} and the update script only takes care of users tagged with 'shib_auth' in {authmap} . When there is no mapping in the {shib_authmap} , a new user is attempted to be created, which fails because of the mail being duplicated. So what was accidentally working with pre-created users, do not work anymore with 4.0.
To pre-create users, you should first create the Drupal users in your preferred way (either by using the administration interface or by direct SQL query), and then you MUST manually run the following three queries :
INSERT INTO shib_authmap (uid, targeted_id)
SELECT uid, name
FROM users
WHERE uid > 1 AND (uid) NOT IN
(SELECT uid
FROM shib_authmap);
INSERT INTO authmap (uid, authname)
SELECT uid, targeted_id
FROM shib_authmap
WHERE (uid) NOT IN
(SELECT uid
FROM authmap);
UPDATE authmap SET module = 'shib_auth'
WHERE (uid) IN
(SELECT uid
FROM shib_authmap);
Note
These queries add all your existing users to shib_authmap with their usernames and make sure that your authmap table contains all of the user entries. You should optimize these queries if you have a large number of users.
Figyelem
You should repeat these queries each time after you add pre-created users.
Role assignment
It's possible to assign roles to users based on their Shibboleth attributes.
An assignment rule is made of three parameters:
$_SERVER header name: name of the Shibboleth-derived attribute
Value regexp : regexp applied to (all) the value(s) of the Shibboleth-derived attribute
Role(s) : checklist of roles to be assigned to the matching users
Dynamic rules (default)
Dynamic rules add roles to the user, but do not save them to the user's profile . This means that
the roles assigned by dynamic rules are NOT displayed on the user page , even though the permissions assigned to the role are in effect
the roles assigned by dynamic rules are automatically revoked if the Shibboleth attributes change (ie. eduPersonAffiliation changes from student to alum ),
thus if the user logs in by other means than Shibboleth, the rule will not be triggered, so the roles will not be assigned.
Additional roles can be assigned statically to the user (as an individual) by the administrator as normally. Every logged in user gets the role Authenticated user automatically.
Sticky rules
On the other hand, sticky rules do save the roles to the user's profile . Thus
the roles assigned by sticky rules are displayed on the user page,
the roles are not revoked automatically by the module,
the roles will be in effect regardless of the login procedure.
User profile mapping
From the 7.x-4.2 version (D6 is not supported) it is possible to define a mapping between Shibboleth attributes and Drupal Fields. You must have the Field UI and the Shibboleth profile fields modules enabled to use this functionality. Unlike other features of the module, this mapping is configured together with the field definition.
Go to Administration » Configuration » People » Account settings » Manage fields ( admin/config/people/accounts/fields ) and create a new field or edit an existing one. The Shibboleth mapping is available on the Field Edit form and can be used in three ways:
Disabled : no mapping (this is the default);
Initial value from Shibboleth, later editable by User : the value of the mapping is only assigned to the field if the field has no values;
Always update value on User login, not editable by User : the field is updated on every login.
You can use the values of the server variables by referring to them with square brackets like [sn] . You can reference multiple server variables in one mapping. Anything that is not matched to a server variable will be treated as string and copied to the value of the field. The server variable match is case insensitive.
As an example, consider the user's request containing the following server variables (regardless of being set by Shibboleth or by something else):
[givenName] -> John
[sn] -> Doe
[email] -> jdoe@example.com
The following mappings would produce the results as indicated:
[sn], [givenName] <[email]> Doe, John jdoe@example.com
[firstName] [sn] [firstname] Doe (note the mistaken header name)
Account linking
There might be cases when you have a number of existing users and you want them to (optionally) log in through the federation. If you enable account linking , a user can add her SSO login to her existing Drupal account. The process of adding an SSO login -> Drupal account association is the following (all steps are performed by the user):
Login to Drupal (with username/password)
Go to My account -> Edit
Click on Link this account to Shibboleth!
Authenticate with your IdP
From this point the user can choose to login either with Shibboleth or with username/password. This feature can also be useful for users switching home organizations.
Info
• One Drupal account can be linked to more than one federated unique identifier, however
• One federated identifier can only be linked to a single Drupal account
• Nobody can link to admin or Anonymous user
• If the administrator disables this feature, no new associations can be stored. Existing associations remain in effect.
• On a new user logon, the one cannot choose the Drupal username of another user (when user-defined usernames is active). For account linking, the user must be already logged in.
• Currently account linking link is not displayed if the user has been logged in using Shibboleth. If you want to support users with multiple federated identities, please file a feature request.
Figyelem
Dynamic roles are roles based on server variables, not users. These may well be different on username/password logon and Shibboleth logon.
Logging out
Session expiry
Enable the option " Destroy Drupal session when the Shibboleth session expires ", if you want to force logout the users without a valid Shibboleth session. (This only applies to lazy sessions, otherwise it is the webserver what ensures that you have a valid session.)
Info
Keep in mind if you leave this option off:
• if the Shibboleth session is lost, assigned dynamic roles are lost, too
• Shibboleth session might get lost if you use a clustered SP without a central session cache
• Never ever leave this option off if you want support Single Logout . Otherwise the user will remain logged in to Drupal even after doing single (global) logout.
URL to redirect to after logout
Define an URL here, where you want the user to be navigated after logout. The URL can be absolute or relative to the server base url. The relative paths will be automatically extended with the site base URL.
SAML2 Logout
At the moment, Shibboleth2 SP supports SAML2 logout while the Shibboleth2 IdP does not. It has a consequence that (if you have a standard Shibboleth2
installation), you will get a Shibboleth error message on logout, like this:
Global Logout
Status of Global Logout: Identity provider does not support SAML 2 Single Logout protocol.
You can avoid this message by commenting out SAML2 global logout initiator from /Logout handler in /etc/shibboleth/shibboleth2.xml :
User consent
In certain scenarios you are only allowed to store personal data if the user accepted some kind of legal agreement such as the Terms of Use or the Privacy Policy.
When a new user arrives, she gets a screen with a link to the legal document and a checkbox. This page also contains the user's name and the e-mail address. Personal data required for login are stored only if the user accepts the agreement. If it's allowed by the administrator, the user might set custom values for those attributes.
If the document changes, the administrator might increment the version. This case all users are forced to accept the new version of the agreement before logging in.
Note
Version matching is an exact match, so the user must accept exactly the same version what was specified by the administrator
Personal data handled by the module
username
user's e-mail address
user's targeted identifier(s) (what is sent by the IdP, if different from username), along with a mapping to the Drupal username
Identity Provider(s) that identified the user
random password (this might not be considered personal data)
time of the registration
Advanced SAML2 features
SAML2 defines several properties of the authentication request message which may affect the authentication performed by the IdP.
Warning
Be careful when using these options.
IdPs that do not support these features might signal an error instead of performing any kind of authentication of the user. Or might show errors after authenticating the user. Some kind of authentication handlers (ie. HTTP Basic Auth) will never work even if the IdP software is capable of handling these properties.
isPassive
If isPassive is set, then the user is redirected to the IdP or to the Discovery Service in advance, but neither of them are allowed to take over the control of the user interface (such as performing any visible authentication). If authentication (or IdP selection) can not be performed silently, an error is returned, which is then handled by the module.
By using this option, you can auto-login users who are already logged in to the IdP even if you are using lazy sessions. If auto-login can not be performed, the user returns to Drupal unauthenticated without seeing any error message.
Figyelem
You need to instruct Shibboleth to redirect errors back to Drupal to handle passive authentication failures. This is done by setting redirectErrors parameter in the RequestMap. See Shibboleth wiki for details.
IMPORTANT : current implementation does not handle any errors except for NoPassive error. This means, that on every possible Shibboleth SP error you will get an unauthenticated Drupal page instead of a Shibboleth error page.
Note
this feature requires JavaScript.
forceAuthn
This feature requires reauthentication of the user at the IdP even if she is having an SSO session there. Just like isPassive, it's not generally supported by authentication handlers.
In general, you should never mix isPassive and forceAuthn . The standard states that in this case, the IdP must reauthenticate the user without visibly taking control of the user interface. It's up to you, how you interpret it...
Non-implemented features
There are several other SAML features which are not yet implemented, because there seems to be very little practical interest for them. Please file a feature request if you really need them, but before doing so, please, spend a little time on thinking how things should really work.
AuthnContextClass : the SP can request some specific authentication context from the IdP.
NameID management : the IdP can request to change the user's NameID (targeted identifier) or to remove it.
Logout notification : this is a Shibboleth2 feature, not a SAML one. You generally do not need this, because you can terminate the Drupal session on Shibboleth session expiry. This workaround has the disadvantage that the module will not be notified at the time when the user was logged out, only on the next page refresh.
Change log
Version 3.0 -> 3.1
If you need documentation for 3.0, please use the previous version of the documentation
Release notes
Version 4.0
Bug fixes
The module now works with caching enabled
Code refactoring
New features
Allow specifying Drupal username, thus support opaque identifiers
Support for sticky rules (roles saved permanently to the users' profile)
Basic support for account linking
Basic support for getting user consent on personal data
Support for isPassive and forceAuthn session initiation
Support for redirecting users to HTTPS on login
Drupal Shibboleth module
Drupal shib_auth module enables Shibboleth authentication for Drupal CMS .
Warning This document is written for module version 3.3-x. Please consult the Change log for the revisions of this document for the previous releases. For documentation about the more recent 4.x version, please read DrupalShibbolethReadmeDev .
Warning The following documentation assumes that: • You understand how Shibboleth works • You have successfully installed and configured Shibboleth SP on your host running Drupal.
Installation
Download module source for your Drupal version from the project page .
Uncompress archive to the modules/ directory
Enable module at Administer -> Site building -> Modules
Compatibility
Module is being developed for Drupal 6.x. We have stopped backporting new features to the 5.x branch and Drupal 7 is not yet supported as long as it isn't the stable branch. If you want to contribute to development or porting, please contact aai AT niif DOT hu !
Both Shibboleth 1.3 and Shibboleth 2.x are supported, although some features might require Shibboleth 2.x.
Upgrading module
If you are upgrading from the same major version, you only need to overwrite the files within your modules/shib_auth directory, then run update.php .
Configuration
Configuring Shibboleth
You should be familiar with protecting resources with Shibboleth before using this module. (See Shibboleth Wiki ) Please check that Shibboleth authentication is working for that location and all the necessary attributes are exported to the headers. You can enable DEBUG mode to dump the whole $_SERVER array. If you can see Shibboleth attributes there, you're fine.
In Shibboleth there are two modes for protecting resources:
Lazy Sessions : session is only initiated if an application redirects user to the SessionInitiator URL. In this module, it is done by clicking the "Login with Shibboleth" link. Anonymous access is possible as well as using other authentication methods.
Detailed description of lazy sessions in Hungarian.
"Strict" Sessions (normal sessions): users can only access Drupal content if they have a valid Shibboleth session. This case, no anonymous access can be granted (not even read-only) and you can not use any auxiliary authentication methods.
Warning If you decide to use lazy sessions and you don't want your users to be able to log in with a password, you have to disable changing passwords .
Example Shibboleth configuration
Note: this example uses lazy sessions. Configuration for Shibboleth 1.3 is quite similar.
/etc/shibboleth/shibboleth2.xml snippet :
Apache config file snippet (ie. /etc/apache2/sites-enabled/your.host.name , or you can even use .htaccess without the tags):
AuthType Shibboleth
ShibRequireSession Off
# the following single line is only valid for Shib2
ShibUseHeaders On
require shibboleth
Figyelem You MUST use ShibUseHeaders On if you use Shibboleth2 with mod_rewrite . mod_rewrite prefixes CGI environment variables with REDIRECT_ , so you have to instruct Shibboleth2 to use headers instead. Shibboleth 1.3 always uses headers, therefore the ShibUseHeaders directive is invalid with Shibboleth 1.3.
DEBUG mode
If you enable DEBUG mode on the module configuration interface, you can dump the whole $_SERVER array. This shows you all the available attributes and helps you diagnosing possible Shibboleth attribute problems. * Keep in mind that some users might have a specific attribute while others don't.
Debug path prefix
Leave it empty, if you want to display debug information on every page. For example use user/ for display DEBUG messages on paths user/*
Adding a prefix is useful, if you want to enable debugging on an online drupal installation without littering all of the pages with the debugging information. Can be set to a non-existent node as well, in this case, the information will be displayed over the built-in 404 page.
Setting Shibboleth parameters for the module
Handler settings
If you are using lazy sessions, you have to define the Shibboleth SessionInitiator to which the user should be directed when she clicks on "Login with Shibboleth". SessionInitiator URL is constituted of the following:
protocol scheme ( http:// or https:// )
host name
Shibboleth handler URL (usually: /Shibboleth.sso )
'location' part of the SessionInitiator definition
/etc/shibboleth/shibboleth2.xml snippet :
For this example, you should have:
/Shibboleth.sso for Handler URL
HTTPS or HTTP for scheme , depending on whether you are using SSL or not
/Login for WAYF location
Attribute settings
Specify here the $_SERVER headers to look up the user's username and e-mail address. Please check DEBUG mode to look for the available headers. If you can not find the desired attribute, then something is wrong with your IdP-SP attribute release flow.
Both fields can have the same value, if you wish.
Using custom e-mail address
Require and use only Shibboleth-provided e-mail address (default): with this option set, Drupal e-mail address is rewritten with the Shibboleth-provided one on each login. This means that your users can only use the e-mail address which is provided by the IdP. The IdP is required to send the e-mail address attribute otherwise the user gets a fatal error.
Ask for missing e-mail address : let the user modify her own e-mail address by editing her Drupal account. If the IdP provides an e-mail address, then that value will be the default, otherwise the user is asked to specify her e-mail address.
Logging out
Session expiry
Enable the option " Destroy Drupal session when the Shibboleth session expires ", if you want to force logout the users without a valid Shibboleth session. (This only applies to lazy sessions, otherwise you are always having a Shibboleth session.)
Info Keep in mind if you leave this option off: • If the Shibboleth session is lost, all the Shibboleth-derived attributes disappear, therefore the user loses the assigned Shibboleth roles
• On the other hand, the roles assigned to the Drupal account of the user persist as long as the Drupal session is valid • Shibboleth session might get lost if you use a clustered SP without a central session cache
URL to redirect to after logout
Define an URL here, where you want the user to be navigated after logout. The URL can be absolute or relative to the server base url. The relative paths will be automatically extended with the site base URL.
SAML2 Logout
At the moment, Shibboleth2 SP supports SAML2 logout while the Shibboleth2 IdP does not. It has a consequence that (if you have a standard Shibboleth2 installation), you will get a Shibboleth error message on logout, like this:
Global Logout
Status of Global Logout: Identity provider does not support SAML 2 Single Logout protocol.
You can avoid this message by commenting out SAML2 global logout initiator from /Logout handler in /etc/shibboleth/shibboleth2.xml :
Automatic role assignment
It's possible to assign roles to users based on their Shibboleth attributes.
An assignment rule is made of three parameters:
$_SERVER header name: name of the Shibboleth-derived attribute
Value regexp : regexp applied to (all) the value(s) of the Shibboleth-derived attribute
Role(s) : checklist of roles to be assigned for the matching users
All these rules are evaluated at module initiation time. That means that revoking/adding a Shibboleth attribute rule will take effect immediately on next page refresh. The same applies when the set of headers is happened to be changed.
Additional roles can be assigned statically to the user (as an individual) by the administrator as normally.
Figyelem Dynamic roles are not visible on the role administration page and on the user page. These roles are evaluated dynamically and are not saved to the database.
Using module
Automatic user creation
Drupal CMS requires all users to be in its internal SQL database. If the module detects that no user exists in the database with the received Shibboleth user identifier, it creates a new (Drupal) user.
Disallowing password change
There is no way for the module to detect if a user has been deleted from Shibboleth. This simple fact has a number of consequences.
When a user is first logged in, a Drupal account is automatically created for her. Because Drupal requires a password, a random string is generated for password. Normally the user doesn't need it.
Now suppose that your user is about to leave your institution. If she is malicious enough, she can go to the password change form, reset her password to a known one, and even after she is deleted from the IdP, she still can log in to your precious resource with the (now known) password. (Note that it is only achievable with lazy sessions!).
Therefore, if your requirements are such that only Shibboleth-authenticated users can log in, YOU MUST DISABLE PASSWORD CHANGE for users.
Steps for disallowing your users to change their passwords:
Install Drupal User Protect module
At Administer -> User management -> User Protect -> Protected roles tab check password for the authenticated user role.
At Administer -> Permissions -> userprotect module: uncheck change own password for authenticated user
Log in with a normal account, go to "My account" -> Edit. You shouldn't see the possibility for changing password; except for the case when the user has user administrator rights.
Administrator / password login
If you are using lazy sessions, you can still login with password. If you disabled the username/password login block, append the following to your normal Drupal URL: /?q=user
Administering Drupal with strict sessions
If you use strict sessions, you can not log in with a password. It's quite tricky to circumvent it:
Enable Shibboleth protection
Login with your own user credentials, so that your Drupal user profile is created
Disable Shibboleth protection
Login as 'admin', grant your own user 'Administrator' rights.
Enable Shibboleth protection
Login with your own credentials, you should have 'Administrator' rights now.
Change log
Version 3.2 -> 3.3
Module update problem was fixed. From now on one should run update.php on updates. Previous version
Version 3.1 -> 3.2
The module now works with caching, but requires disabling and re-enabling. Previous version
Version 3.0 -> 3.1
If you need documentation for 3.0, please use the previous version of the documentation
Döntési táblázat
Döntési módok
Aktív többségi döntés: Tagok Tanácsának 50% + 1 döntése
Gyorsított döntés
cél: gyorsított eljárás
olyan esetekre, ahol a tagok beleegyezése feltételezhető
a döntés körülményeit a Föderációs Operátor már alaposan megvizsgálta
3 munkanapon belül ha nincs tiltakozó tag, jóváhagyásnak minősül
ha van tiltakozó tag, aktív többségi döntés, vagy a Föderációs Operátor visszavonja az indítványt
Regisztrációs folyamat
Döntési folyamat
Kérelem forma
Csatolt dokumentáció
Döntés módja
Döntés eredménye
Új Tag felvétele
Szerződés, szándéknyilatkozat
Aktív többségi döntés
Szerződés aláírása Felvétel T.T. -ba
Tag (új) IdP
RR
Adatkezelési folyamatok dokumentálása Adatkezelési nyilatkozat
Gyorsított eljárás
Jóváhagyás az RR-ben
Tag (új) SP
RR
Adatkezelési nyilatkozat
Gyorsított eljárás
Jóváhagyás az RR-ben
Új Partner felvétele
Szerződés, szándéknyilatkozat
Aktív többségi döntés
Szerződés aláírása Jóváhagyás az RR-ben
Partner új SP
RR
Adatkezelési nyilatkozat
Gyorsított eljárás
Jóváhagyás az RR-ben
Döntési jogok
Döntési jog
Intézményi döntés, Tagok tájékoztatása
Föderációs operátor döntése, Tagok tájékoztatása
Föderációs operátor mint szolgáltató döntése
Gyorsított eljárás
Tagok Tanácsának döntése
Műszaki dokumentumok megváltoztatása Attribútum specifikáció Metadata specifikáció Műszaki követelmények és ajánlások
X
Policy dokumentumok bármilyen megváltoztatása Szószedet Alapelvek
X
Csatlakozás nemzetközi szervezetekhez és együttműködésekhez
X
Azonosítási szolgáltatás (Identity Management) kiszervezése
X
Metadata módosítása
X ( jóváhagyás )
Szolgáltatási díj bevezetése / megváltoztatása
X ( Tagok új szerződést kötnek )
Egyedi díjkedvezmények megállapításának joga
X
Bevételek felhasználása
X
Szerződés rendes felmondása
X
X
Súlyos szerződésszegés miatti rendkívüli felmondás
X
X
Föderáció megszüntetése
X
Tagok Tanácsak saját eljárási szabályainak elfogadása, módosítása
X
RelyingParty
A Shibboleth terminológiában a RelyingParty kifejezés jelenti a "másik fele(ke)t". Egy RelyingParty vonatkozhat egyetlen SP-re vagy IdP-re, illetve egy teljes föderációra is.
Mind az SP-nél, mind az IdP-nél meg lehet adni, hogy különböző RelyingParty-ra vonatkozóan más azonosító kulcsokat és más providerId -t használjon.
Annak eldöntése, hogy a másik félre melyik RelyingParty konfiguráció vonatkozik így dől el:
Ha a másik fél providerId -je megegyezik a RelyingParty nevével, akkor az vonatkozik rá
Keresés indul a rendelkezésre álló föderációs metadata állományokban. Amennyiben valamelyikben megtalálható a másik fél providerId -je, akkor a föderáció URI-jának megfelelő RelyingParty vonatkozik rá, amennyiben az létezik
Ha nem található megfelelő RelyingParty konfiguráció, akkor az alapértelmezett RelyingParty konfiguráció vonatkozik a másik félre.
Lásd még:
Shibboleth IdP konfiguráció
IdPRelyingConfig (Shibbleth Wiki)
[[Shibboleth_SP_konfigurációja]]
SPRelyingConfig (Shibbleth Wiki)
AAI
Meghatározások
Föderáció
Pont-pont bizalmi kapcsolati modell
Metadata
Föderációs modellek
Home Location Service
Shibboleth
Hogy kezdjem?
Föderációs alapinfrastruktúrák (IdP-k, SP-k)
Tapasztalatok alapján IdP esetén egyszerűsége miatt talán jobb választás a simpleSAMLphp, SP esetén Shibboleth ill. simpleSAMLphp egyaránt megfelelő választás mind beállítási, mind üzemeltetési szempontból.
Shibboleth IdP: Telepítés, beállítás , Egyéb leírások , Shibboleth 2 IdP leírások
Shibboleth SP: Kezdőlépések , Egyéb leírások
simpleSAMLphp IdP és SP: Kezdőlépések , SimpleSAMLphp 2
Microsoft Azure AD hitelesítési forrás simpleSAMLphp-ben
Melyik IdP-t válasszam?
HREF/eduID föderációhoz kapcsolódó tudnivalók
HREF Key Rollover 2020 : Új metaadat aláírókulcs a HREF föderációban
HREF Key Rollover 2020 English : New metadata signing certificate
HREFContract : A föderációhoz kapcsolódó dokumentációk gyűjtőlapja
HREF_attribútum_specifikáció : A föderációban használható attribútumok specifikációja
HREF_metadata_specifikáció : A föderációban használt metadata specifikációja
Resource Registry : A föderáció adminisztrációs felületének leírása
JoiningEduGAIN : Tudnivalók az eduGAIN csatlakozással kapcsolatban
MDX : Igény szerinti metaadat-kiszolgálás
Sirtfi : Föderációs és föderációközi együttműködéshez kapcsolódó incidenskezelés keretei
URN : Magyar NREN-nél használt speciális azonosítók tára
URN_SCHAC : eduID.hu föderációban használt speciális azonosítók tára
További föderációs megoldások
DiscoveryService : Shibboleth 2.0 SAML-kompatibilis Discovery Service
OpenSSO : Nehézsúlyú Java hozzáférés-szabályozást és federációt megvalósító rendszer
OpenID : Széles körben támogatott, de nem SAML-alapú federációt megvalósító rendszer
GoogleAuth : Google, mint OpenID szabványú IdP
mod_mellon : SP megoldás apache modulban. A SAML2 motort a Lasso valósítja meg. 1
oiosaml.java : Java SP megoldás, amit a Dán állam is használ. 2
UApprove : Shibboleth 2.1.x IdP-hez illeszthető "consent-modul" beállításának leírása
Shibboleth troubleshooting : Shibboleth hibaelhárítás
Shibboleth Service Provider (SP) és Docker : Shibboleth és Docker összehangolása
Kiegészítő tudnivalók
Szolgáltatási IP tartományok
Alkalmazások illesztése : Néhány alkalmazás Shibboleth-illesztésének leírása
Interoperabilitás mátrix : Shibboleth, OpenSSO, simpleSAMLphp együttműködési mátrix
Eszközök : Hasznos eszközök föderációk üzemeltetéséhez, használatához
Intézmény átnevezés : megfontolandó szempontok
Tanúsítványok a föderációban
Test HEXAA (or any SAML AA) from command line
Hogyan teszteljünk eduID IdP-t vagy SP-t?
Erasmus+ és ESI információk
Publikációk
Azure AD használata azonosítási forrásként
Lazy Session
Általában a Shibboleth SP Apache modul csak akkor enged hozzáférést az erőforráshoz (oldalhoz), ha sikerült autentikálnia és autorizálnia a felhasználót (azaz shibboleth session-t létrehozni).
Elképzelhető azonban olyan alkalmazás is, amely azonosítatlan (anonymous) felhasználók számára is szolgáltat információkat. Ez a wiki is ezen az elven épül fel: bárki olvashatja, de csak bejelentkezett felhasználók szerkeszthetik.
A lazy session csak a Shibboleth szempontjából "lusta"; a modul csak akkor hoz létre Shibboleth session-t, ha az alkalmazás erre kifejezetten utasítja. Ez azzal jár, hogy:
az alkalmazásnak tudnia kell, hogy mikor van érvényes Shibboleth session
az alkalmazás felhasználói interfészén el kell helyezni egy olyan elemet (linket), melynek segítségével a session létrehozható
magyarul: csak Shibboleth-et "beszélő" alkalmazások védhetők lazy session-nel .
Lazy session az alkalmazás szemszögéből
Session érvényességének ellenőrzése
Az alkalmazás a Shibboleth attribútumok vizsgálatával győződhet meg arról, hogy létezik-e Session. Célszerű olyan attribútumot választani, amely minden session létrehozáskor biztosan létrejön, ilyen például a _SERVER tömbből kinyerhető Shib-Application-ID (Shibboleth 1.3 esetén: HTTP_SHIB_APPLICATION_ID ) header. Ha ez létezik, akkor biztosan van session.
Session létrehozás
Mivel a webszerveren futó alkalmazás és a Shibboleth webszerver modul közvetlenül nem tud kommunikálni, ezért szükséges, hogy a felhasználót valahogyan egy megfelelő URL-re (a SessionInitiator URL-jére). Ez az URL általában így áll össze:
metódus: http:// vagy https://
hostnév
Shibboleth SP modul elérhetősége (általában: /Shibboleth.sso )
SessionInitiator "location"-je, pl. /WAYF/HREF
Milyen jó is lenne, ha a default session initiator akkor is menne, ha nem adunk meg location-t. De sajnos jelenleg nem ez a helyzet.
?target= + az az URL, amelyre a Shibboleth session létrehozás után szeretnénk, hogy a felhasználónk kerüljön. Általában az éppen aktuális Request URI-t szoktuk használni.
Példa URL:
https://dev.aai.niif.hu/Shibboleth.sso/WAYF/NIIF-WAYF?target=https://dev.aai.niif.hu/drupal/shiblazy.php
Request headerek megbízhatósága, lazy session biztonság
A Shibboleth modul gondoskodik arról, hogy kiszűrje a HTTP_SHIB_ kezdetű header elemeket, mivel azokat csak ez a modul állíthatja be. Bárki más is állítaná be, az visszaélést jelentene (header spoofing). A header spoofing elleni védelem lazy session esetén is működik, függetlenül attól, hogy létrejött-e a Shibboleth session. Ez azt jelenti, hogy nem lehet létező "sessiont hazudni", mivel a HTTP_SHIB_IDENTITY_PROVIDER header védett.
Természetesen a spoofing védelem csak akkor működik, ha
a Shibbleth webszerver modul (mod_shib) be van töltve ÉS
az adott Directoryra vagy Location-re be van konfigurálva, hogy hallgasson
A _SERVER tömb elemeit csak webszerver modulok tölthetik fel, ezért az ebből kivett értékek többé-kevésbé megbízhatóak header spoofing védelem nélkül is (megbízhatóságuk megegyezik a webszerver megbízhatóságával). Problémát okoz azonban, ha ezeket az elemeket összekeverjük a requestből kinyerhető értékekkel (pl. PHP-ban a register_globals használatával). Ez amúgy is kerülendő eljárás, lazy session-ök esetén pedig egyenesen öngyilkosság!
AAI és Shibboleth 2007.11.07
Elhangzott a 2007-es HBONE Workshopon
Letöltés
OpenOffice formátum
PDF formátum
ArpFilterProposal
ArpFilter before the profile servlet - support for other authentication modules
ArpFilter and ArpViewer works great, but there is one big problem with ArpFilter: it only supports REMOTE_USER -based authentication. Shibboleth2 IdP comes with username and password module, which can be extended to use with any JAAS-compliant Login module. Unfortunately, current ArpFilter design can not work with this module.
So I made some research to find out how to bring ArpFilter and Shibboleth IdP's internal authentication modules together. My motivation was to support the shipped UserPassword authentication and many of the features that Shibboleth IdP has (forceAuthn, isPassive).
I found out that ArpFilter only depends on Shibboleth's LoginContext. This LoginContext is created by the profile handler code and interpreted by the authentication engine (and authentication modules) - then, after authentication succeeds, the profile handler processes the LoginContext and issues the response to the SP that requested it.
So my idea is simple: why ArpFilter is put before the authentication servlets instead of the profile handler servlet?
I got ArpFilter work before the profile servlet, but not quite sure whether my solution works in all use cases where it should do. I have tested it with SAML2 requests and UserPassword authentication and it seemed to work. Even the PreviousSession authentication handler did with no additional need of PreviousSessionServlet.
Of course I made some modifications to the original ArpFilter code, but not too much. Basically, it just looks for LoginContext and makes sure the profile servlet gets the LoginContext, even if ArpFilter is called.
The code logic is the following:
Ensure that the request is made to the profile servlet.
Try to get LoginContext from session.
If LoginContext is found in the session, transfer it back to the request scope and remove it from the session.
Try to get LoginContext from request scope.
If no LoginContext found, proceed to the profile servlet and exit.
Else process the request as usual, and find username in the IdP session.
In the case when ArpFilter decides to hand over the control to the ArpViewer application, save the LoginContext back to Session.
I needed one more little modification to web.xml: remove filters from /Authn/ servlets and put the ArpFilter in front of the ProfileHandlerServlet (and include the 'forward' dispatcher here, because the profile handler servlet gets the second request from the authentication engine with servlet forward - when the authentication is succeeded).
Attribútum feloldás
A felhasználó azonosítása után az IdP még csak a REMOTE_USER változóban megkapott principal azonosítót tudja. A következő lépésben meg kell határozni a felhasználóhoz kapcsolódó attribútumokat. Ezeket az attribútumokat általában valamilyen adatbázisból (LDAP, SQL) kell lekérdezni, de lehetséges konstans, ill. származtatott attribútumokat is használni.
Fontos megjegyezni, hogy az attribútumok csak akkor adódnak át az SP-knek, ha ez az Attribute Release Policy -ban engedélyezve van. Természetesen fel nem oldott attribútumokat nem lehet átadni.
Az attribútum feloldást az IdP konfiguráció IdPConfig elemének resolverConfig attribútumában megadott XML állományban konfigurálhatjuk. Ez általában a resolver.xml vagy resolver.ldap.xml névre hallgat
Működő példa konfiguráció
o=niifi,o=niif,c=hu
Attribútum feloldás menete
Az attribútum feloldás abból áll, hogy attribútum definícióhoz adat(bázis) konnektorokat rendelünk. Az adat konnektor feladata az attribútum értékének meghatározása, pl. külső adatforrásokból. Az attribútum definíció azt adja meg, hogy miként kell az értéket a Shibboleth által használt SAML assertionbe tenni.
Adatok kinyerése (DataConnector)
Minden adatforrás rendelkezik egy id mezővel, amelynek az összes adatforrásra nézve egyedinek kell lennie.
JNDIDirectoryDataConnector
Ennek segítségével állíthatjuk be a JNDI LDAP kapcsolat paramétereit. Ezen az interfészen keresztül tetszőleges LDAP v3 interfészt biztosító adatforrás lekérdezhető.
Példa:
Példa beállítások magyarázata (részletes beállítási lehetőségekkel kapcsolatban lásd a Shibboleth Wiki vonatkozó részét !)
Search@filter : az az LDAP filter, amely alapján a REMOTE_USER értékéből megkereshető a felhasználó LDAP entry-je. Ha összetett szűrő szabályt kell mondani, akkor a & jelet & -vel kell eszképelni.
Search/Controls@searchScope : az LDAP lekérdezés scope-ja. Lehetséges értékek:
ONELEVEL_SCOPE
OBJECT_SCOPE (base)
SUBTREE_SCOPE
java.naming.provider.url property : LDAP URL, amely a search base DN-jét is tartalmazza
java.naming.provider.protocol property : itt lehet megadni, hogy SSL-t használjon-e az LDAP kapcsolat kiépítésekor. Ha nem akarunk SSL-t használni, akkor ezt a property-t ne adjuk meg! Lásd még: LDAP kliens SSL
java.naming.security.principal property : az a DN, amellyel a Shibboleth alkalmazás bind-ol az LDAP szerverhez.
java.naming.security.credentials property : az előző DN-hez tartozó jelszó
JDBCDataConnector
E konnektor segítségével tetszőleges JDBC-n keresztül elérhető adatforrásból kinyerhetünk adatokat.
select entitlement from foo where name = ?
A "?" karakterrel hivatkozhatunk a REMOTE_USER változóban kapott principal azonosítóra.
A JDBCDataConnector részletes paraméterezhetőségéről lásd a Shibboleth wiki vonatkozó részét !
StaticDataConnector
Ennek segítségével rendelhetünk statikus adatokat a felhasználókhoz. Legtöbbször akkor használjuk, ha az IdP-nél történt azonosítás tényéből attribútumokat akarunk származtatni.
o=niifi,o=niif,c=hu
Egy StaticDataConnector egyszerre több attribútumot is tud szolgáltatni, ill. egy attribútumnak több értéke is lehet. Bővebben lásd a Shibboleth wiki vonatkozó részét !
Attribútumok előkészítése (AttributeDefinition)
Az attribútum definíciók arra valók, hogy az adatforrásból származó értéket az átvitelt biztosító SAML szabványnak, illetve az attribútumot fogadó SP-nek megfelelő formátumba konvertálják. Ezért minden attribútum definíciónál meg lehet adni függőséget, amelyből az attribútum értéke származik. A függőségnek két fajtája van:
DataConnectorDependency : az attribútum értéke egy már definiált adatforrásból származik.
AttributeDependency : az attribútum értéke egy másik (feloldott) attribútum értékéből származik
Mindkét függőség megadásakor a requires XML attribútummal hivatkozhatunk a DataConnector vagy az AttributeDefinition id -jére. Ebből következik az is, hogy minden attribútum definíciónak egyedi id mezője kell, hogy legyen.
SimpleAttributeDefinition
Ezzel a pluginnal egyszerű műveleteket végezhetünk az adatforrásokból származó értékeken (vagy akár átalakítás nélkül is továbbíthatjuk). Az alábbi attribútumokkal rendelkezik:
id : ezzel lehet rá függőségekben hivatkozni, ill. az attribútum forrásának megállapításához is felhasználható. Az Assertion -ben ennek az értéke szerepel attribútum névként.
sourceName : ezzel lehet explicit módon meghatározni a forrás nevét
smartScope : ha az érték nem scope-olt (azaz nem valami@valahol formátumú), akkor az attribútum scope-ja a smartScope lesz, ellenkező esetben a scope értéke a "@ utáni rész" lesz (pl.: valahol ).
(Leegyszerűsítve) egy Assertion -ben egy attribútum így adható meg: attribútum név + scope + érték(ek)
allowEmpty : ez a boolean paraméter adja meg, hogy az üres érték elfogadható-e. Alapértelmezett értéke false , azaz ha nincs érték, akkor az Assertion -be nem kerül bele az attribútum. Ha true , akkor érték nélkül kerül bele.
A sourceName mezőt nem kötelező megadni, mert a forrás attribútum neve megadható az id paraméterben is. A forrás attribútum nevének meghatározása a következő sorrendben történik:
Ha meg van adva a sourceName , akkor az adat konnektortól ezt az attribútumot kapja meg
Ha van olyan - az adat konnektor által nyújtott - attribútum, amely az id mezővel teljesen megegyezik, akkor annak az értékét használja
Egyébként az adat konnektortól az id mezőben megadott paraméter utolsó " : " vagy " / " jel utáni részének megfelelő attribútumot kérdezi le.
Példa 1. : a *
directory* nevű adat konnektortól lekérdezi a "cn" attribútumot, majd ennek értékét az urn:mace:dir:attribute-def:cn attribútumban küldi el a másik félnek.
Példa 2. : a directory nevű adat konnektortól lekérdezi a displayName attribútumot, majd ennek értékét az urn:mace:dir:attribute-def:cn (!) attribútumban küldi el a másik félnek.
Példa 3. : a (már korábban feloldott) urn:mace:dir:attribute-def:uid attribútumot (amennyiben az nem scope-olt) kiegészíti az "niif.hu" scope-pal, és ezt adja át urn:mace:dir:attribute-def:eduPersonPrincipalName néven. Ha viszont az uid értéke pl. valaki@valahol , akkor az átadott érték a valaki lesz, a scope pedig valahol .
Részletes leírást lásd a Shibboleth wiki vonatkozó részében !
CompositeAttributeDefinition
TODO , lásd: https://spaces.internet2.edu/display/SHIB/CompositeAttributeDefinition
RegExpAttributeDefinition
TODO , lásd: https://spaces.internet2.edu/display/SHIB/RegExpAttributeDefinition
ScriptletAttributeDefinition
TODO , lásd: https://spaces.internet2.edu/display/SHIB/ScriptletAttributeDefinition
SAML2PersistentID
TODO , lásd: https://spaces.internet2.edu/display/SHIB/SAML2PersistentIDAttributeDefinition
Tesztelés
A Shibboleth IdP-hez tartozik egy resolvertest névre hallgató program, amellyel ellenőrizhetjük az attribútumok feloldását. Használatához először be kell állítani a telepítésnek megfelelően az IDP_HOME és a JAVA_HOME változókat.
Példa: /usr/local/shibboleth-idp/bin/resolvertest --resolverxml=file:///etc/shibboleth-idp/resolver.ldap.xml --user=bajnokk
o=niifi,o=niif,c=hu
bajnokk
bajnokk
Forrás
https://spaces.internet2.edu/display/SHIB/NewIdPAttribute
https://spaces.internet2.edu/display/SHIB/IdPAttributeConfig
IdP Operational Requirements
Purpose of this document
This document defines identity management and system operation requirements and recommendations for Identity Providers joining the HREF Federation.
Throughout this document the interpretation of terms MUST , MUST NOT , SHOULD , SHOULD NOT are defined as:
MUST (or SHALL , REQUIRED ): the definition is an absolute requirement of the specification in order to build and keep trust in the federation.
MUST NOT : the definition is an absolute prohibition of the specification
SHOULD (or RECOMMENDED ): there may be valid reasons for ignoring the definition, however, the divergence from the specification MUST be documented
SHOULD NOT (or NOT RECOMMENDED ): there may be valid reasons for the particular behaviour to be acceptable, however, the divergence from the specification MUST be documented
Identity management
The organisation operating the Identity Provider MUST document its privacy policy and make it available to its users.
The organisation MUST define the sources, the maintenance procedures and approximate quality of the data about its users, and supply this documentation to the Federation.
Uniqueness of the usernames MUST be guaranteed.
One individual SHOULD NOT have more than one user accounts.
Role accounts (such as 'director', 'secretary') SHOULD NOT be used.
Use of attributes:
Attribute implementations MUST follow the Attribute Specification.
The Identity Provider MUST implement the following attributes:
eduPersonTargetedID
eduPersonScopedAffiliation
schacHomeOrganizationType
eduPersonPrincipalName
The Identity Provider SHOULD implement the following attributes:
displayName
mail
eduPersonEntitlement
The IdP MUST ensure that eduPersonTargetedID and eduPersonPrincipalName are not re-assignable.
Limitation of test accounts:
all test accounts MUST be identified and documented along with the individual who is responsible for the test account
real transactions MUST NOT be initiated by test accounts
test accounts SHOULD be distinguished with appropriate homeOrganizationType value.
User credentials (i.e. passwords) MUST NOT be transmitted over public network in unencrypted form.
If initial user passwords are distributed, it SHOULD be done through non-electronic form
Changes in the users' affiliation to the institution MUST be populated to the IdP database within 7 days
If the authoritative source of user information is an external database (i.e. student information system), then the above timeframe starts from the time of the change in the primary system.
Students may use 'alum' affiliation after leaving the organisation. Values 'student' or 'member' MUST NOT be used afterwards.
For faculty members and employees, affiliation values 'staff', 'employee', 'faculty' and 'member' MUST be revoked.
Service management
The organisation MUST develop a role responsible for liaison with the Federation Operator.
The organisation operating the Identity Provider MUST provide end-user support for its affiliated users and have them informed about the availability of the support.
The organisation MUST provide the following data to the Federation Operator as anonymous daily statistics about the Identity Provider usage:
number of unique users;
number of transactions initiated to each federation service;
total number of logins.
Operational issues
Any transaction including personal data MUST be logged and log files SHALL be kept for at least 30 days .
The log files above MUST be treated in accordance with the applicable data protection laws.
Cryptographic keys of the Identity Provider MUST be at least 2048 bits long.
Private keys MUST be protected.
In case of a key compromise, the Federation Operator MUST be notified within 24 hours.
Use of self-signed certificates with a long expiration time is RECOMMENDED .
Use of SAML:
The Identity Provider MUST comply with the Interoperable SAML 2.0 Web Browser SSO Deployment Profile ( http://saml2int.org )
It is RECOMMENDED to support SAML2 Web Browser SSO Profile over HTTP Artifact Binding.
It is RECOMMENDED to support SAML2 Single Logout Profile over HTTP Redirect and SOAP Bindings.
All SAML endpoints of the Identity Provider SHALL be protected by HTTPS.
All SAML endpoints of the Identity Provider MUST be under a DNS domain which is possessed by the operating organisation.
All scopes used by the Identity Provider MUST be under a DNS domain which is possessed by the operating organisation.
Openidp
Az openIdP ( open.eduid.hu ) az eduID egy olyan azonosító szervezete, amelybe bárki regisztrálhat, majd a regisztrált azonosító birtokában különböző szolgáltatásokat vehet igénybe.
Felhasználóknak
Ahhoz, hogy regisztrálni tudjon, nincs más teendője, mint az openIdP oldalán a Regisztráció menüpontra kattintani, majd megadni egy érvényes e-mail címet, melyre a rendszer elküldhet egy ellenőrző levelet. A levél elolvasása után az abban szereplő hivatkozásra kattintva nyílik mód a regisztráció befejezésére, a további adatok (vezetéknév, keresztnév) megadására.
Ha elfelejtette jelszavát, és szeretne újat beállítani, úgy adja meg regisztrációkor használt e-mail címét, melyre a rendszer küld egy levelet, benne egy hivatkozással, amelyre ha rákattint, lehetősége lesz új jelszót megadnia.
Ha regisztrált adatain szeretne módosítani, lépjen be az openIdP oldalán, majd az 'Adatok megváltoztatása' menüpont alatt vezesse át a változtatásokat
Ha törölni szeretné az openIdP-ből azonosítóját, úgy belépés után válassza az 'Azonosító törlése a rendszerből' menüpontot, s adatai azonnal törlésre kerül.
Háttér
Az openIdP célja, hogy azok a felhasználók, akiknek még nincs föderatív azonosítójuk, de szeretnének olyan szolgáltatást igénybe venni az eduID-n belülről, amely egyfelől lehetőséget nyújt föderatív azonosításra, másfelől "ismeri" az eduID openIdP-jét, ők egy gyors regisztráció után használhassák az adott szolgáltatást.
Egy azonosítási föderáció a technológia mellett komolyan épít a bizalomra, melynek egyik sarokköve, hogy a szolgáltatók megbíznak az egyes azonosító szervezetek által a felhasználókról kiadott adatokban. Mivel az openIdP-be a felhasználók maguk regisztrálnak, nincs mögöttük egy intézmény, aki ellenőrizte volna az adatokat, és felelne azok hitelességéért, így nem elvárható, hogy az eduID minden szolgáltatása megbízzon, azaz ismerje az openIdP-t. Azoknál a szolgáltatásoknál, ahol erre lehetőség van, ott a szolgáltatás üzemeltetője ezt külön jelzi.
Fontos!
Az openIdP működése teljesen automatikus, funkcionalitásában minimalista, kizárólag a legszükségesebbeket tudja, azt viszont üzembiztosan, ezért az eduID kizárólag az üzemeltetést végzi, további felhasználói támogatás nem biztosít.
Szolgáltatások üzemeltetőinek
Ha szeretné, hogy szolgáltatását az openIdP felhasználói is igénybe vehessék, úgy a következők a teendők.
A fent említett, adatok ellenőrizetlenségéből adódó kockázatok megértése
Az openIdP metaadatának betöltése a szolgáltatás előtt dolgozó SP-be.
Az openIdP az alábbi adatokat tárolja és adja ki egy-egy felhasználóról
eduPersonPrincipalName (scope: @open.eduid.hu)
eduPersonTargetedID
mail
surname
givenName
Elérés a központi Discovery Service-en keresztül
Ha szolgáltatása ismeri az openIdP-t, úgy lehetőség van a központi Discovery Service-t oly módon meghívni, hogy az openIdP megjelenjen, mint választható azonosító szervezet. Ehhez az SP-hez tartozó Discovery Service beállításban módosítani kell az URL-t. Alapból ez az érték , amelyet ki kell egészíteni ily módon:
Adatvédelem
Az openIdP-ben a felhasználókról mindössze az e-mail cím, vezetéknév és keresztnév kerül tárolásra. Ezen adatok valódiságáért a felhasználó felel. Ezeket az adatokat az openIdP kizárólag az eduID-ban résztvevő szolgáltatásoknak adhatja ki.
Common-lib-terms
Meghatározás
A common-lib-terms az eduPersonEntitlement attribútum egy speciális jelentéssel felruházott értéke. A teljes attribútum érték a következő: urn:mace:dir:entitlement:common-lib-terms . Ezen rögzített attribútumérték kiadását az egyes intézményekkel szerződéses viszonyban álló folyóirat-kiadók (pl. Ebscohost, Sciencedirect) várják el, amely érték az intézmény oktatóinak, kutatóinak és hallgatóinak járhat. (Ezek a faculity, staff és student affiliation értékkel bíró felhasználók).
További információ (angolul): http://middleware.internet2.edu/urn-mace/urn-mace-dir-entitlement.html
Technikai útmutató
Az intézményi IdP attribútumszűrőjén egyfelől engedélyezni kell a megadott kiadókhoz tartozó SP-k számára az eduPersonEntitlement attribútum kiadását, másfelől be kell állítani, hogy a megadott affiliation értékkel rendelkező felhasználók megkapják a urn:mace:dir:entitlement:common-lib-terms értéket az eduPersonEntitlement attribútumban.
Shibboleth IdP
Shibboleth IdP-nél az attribute-resolver.xml -ben kell kibővíteni az eduPersonEntitlement definícióját az alábbiak szerint.
simpleSAMLphp
Be kell szúrni az attribútumgeneráló folyamatba egy tetszőleges sorszámmal, amely már ismeri a felhasználóhoz tartozó affiliation értéket.
70 => array(
'class' => 'core:AttributeAlter',
'subject' => 'affiliation',
'pattern' => '/staff|student|faculity/',
'replacement' => 'urn:mace:dir:entitlement:common-lib-terms',
'target' => 'eduPersonEntitlement',
),
Károkozási táblázat
/- X ->
User
IdP
SP
Föderáció
User
Azonosító adatok ellopásával más felhasználó nevében vesz igénybe szolgáltatást
Hamis adatokat ad meg (vagy állíttat be) Az SP rendszerével visszaélve rombolja az IdP presztízsét
Visszaél a szolgáltatással (abuse) Hamis adatok alapján jogosulatlanul vesz igénybe szolgáltatást
Visszaélésekkel (ill. próbálkozásokkal) csökkenti a föderációba vetett bizalmat
IdP
Visszaélés a jelszóval Pontatlan személyes adatok Szükséges jogosultsági attribútumokat (pl. entitlement) nem adja meg Visszaélés a személyes adatokkal Személyes adatok túl tág körének átadása harmadik félnek Azonosító szolgáltatás kiesése miatt a felhasználó nem tud igénybe venni szolgáltatásokat
X
Rossz Identity Management Hamis scope megadása Hamis attribútum-értékek megadása (pl. jogosulatlan hozzáférés biztosítása entitlement segítségével) Hamis adatok megadása az IdP regisztrációjakor Visszaélések vizsgálatakor az együttműködés megtagadása
Hamis adatok megadása az IdP regisztrációjakor Rossz felhasználókezeléssel csökkenti a föderációba vetett bizalmat Visszaélésekkel csökkenti a föderációba vetett bizalmat Megbízhatatlanul üzemeltetett informatikai rendszerrel csökkenti a föderatív azonosításba vetett bizalmat
SP
Kicsalja a felhasználó jelszavát Visszaél az IdP-től megkapott adatokkal Visszaél a felhasználótól közvetlenül megkapott adatokkal
Szükségtelenül igényel adatokat felhasználókról (vö. unsolicited attribute query
) DOS támadás
X
FedOp
A metadata elrontásával, elérhetetlenségével vagy a frissítés elmulasztásával elérhetetlenné teszi a felhasználó számára a szolgáltatásokat. Metaadatok szándékos meghamisítása A Discovery Service helytelen működtetése miatt elérhetetlenné válnak a szolgáltatások
Lásd előbb Intézményen belüli szolgáltatások is elérhetetlenné válhatnak
Lásd előbb
Föderációs szolgálatatások szakszerűtlen vagy rosszindulatú működtetésével rombolják a föderációba vetett bizalmat
ErrorNoStatement
Első tipp: rosszul jár az SP vagy az IdP órája
FedEntitiesLogging
Naplózási szintek
** Shibboleth naplózási szintek:**
NONE: semmi
ERROR: hibaüzenetek (ebben az esetben általában a felhasználó hibát tapasztal)
WARN: figyelmeztetések
INFO: az IdP/SP működésével kapcsolatos információk
DEBUG: hibakereséshez hasznos állapotinformációk (pl. protokoll üzenetek)
TRACE: (nagyjából) minden információ, ami a szoftver rendelkezésére áll
Shibboleth IdP audit naplózás
Az IdP audit logok az alábbi információkat tartalmazzák:
időbélyeg (auditEventTime)
bejövő kérés binding-ja (requestBinding)
bejövő kérés azonosítója (requestId)
távoli fél azonosítója (relyingPartyId)
messageProfileId
assertingPartyId
válasz binding-ja (responseBinding)
válasz azonosítója (responseId)
felhasználó helyi azonosítója (principalName)
azonosítási mód (authNMethod)
kiadott attribútumok neve (releasedAttributeId1,releasedAttributeId2)
IdP-SP közötti azonosító (nameIdentifier)
assertion(ök) azonosítója(i) (assertion1ID,assertion2ID)
Naplózott adatok
IdP
Apache
időbélyeg
IP cím
referer (SP-re utal)
böngészőazonosító
(amennyiben Apache azonosítás van): felhasználó azonosítója
Tomcat
IdP alkalmazás
időbélyeg
Felhasználónév
SP
(INFO): küldött attribútumok neve
Hibaüzenetek:
téves bejelentkezés
működési hiba
SP
Webszerver
Időpont
referer (IdP-re utal) (???)
igénybe vett szolgáltatás elérési útja
(ha állandó azonosítót kap az SP): állandó azonosító
Shibboleth SP
időbélyeg
IdP
IP cím
(INFO): kapott és feldolgozott attribútumok neve
SimpleSAMLphp SP
Discovery Service
SWITCH DS
időbélyeg
IP cím
IdP
SP
A webszerver hasonló adatokat naplózhat (kivéve: IdP választás)
Internet2 DS
SimpleSAMLphp DS
Rotálás
Statisztikák
Scope
A scope egy intézményhez tartozó DNS domain , amely az intézmény birtokában van vagy rendelkezésére áll. Javasolt, de nem kötelező a scope értékét ténylegesen is a DNS-be bejegyezni.
Azaz használható a hallgato.intezmeny.hu scope-ként akkor is, ha ez a név nem feloldható a DNS-ből, feltéve, hogy az intezmeny.hu létezik és az intézményhez tartozik.
A HREF Föderációhoz történő csatlakozáskor a csatlakozó Azonosító Szervezetnek kötelező megadnia legalább egy scope-ot.
A megadott scope-ok megjelennek a metadatában , ez alapján az SP-k ellenőrizhetik, hogy az IdP jogosult-e bizonyos attribútum-értékeket kiadni. Az attribútum specifikáció az alábbi scope-ot használó attribútumokat használja:
eduPersonPrincipalName
eduPersonScopedAffiliation
Célszerű, hogy a felhasználókhoz tartozó scope lehetőleg ne változzon meg. Amennyiben mégis meg kellene változtatni, itt találhatók hasznos információk a domain név változtatásával kapcsolatban .
Tomcat55 to Tomcat6
Tomcat6 telepítés Debianra (Lenny)
Debian testing tárolók beállítása
Mivel az újabb fejlesztések nem kerülnek be debian stable ágába, és a backports ág sem tartalmaz mindent, ezért a testing ágból is be kell emelni néhány csomagot. Az alábbi beállításokkal elérjük, hogy a testing ágból csak külön kérésre települjenek csomagok (természetesen a függőségeikkel együtt).
/etc/apt/sources.list.d/sqeeze.list :
deb http://ftp.hu.debian.org/debian squeeze main
/etc/apt/preferences :
Package: *
Pin: release a=stable
Pin-Priority: 100
Package: *
Pin: release a=testing
Pin-Priority: 50
apt-get update
Telepítés
sudo aptitude -t testing install tomcat6
Konfiguráció
Kapcsoljuk ki a TOMCAT6_SECURITY opciót az init konfigurációban:
sudo vim /etc/default/tomcat6
Engedélyezzük az ajp konnektort (alapértelmezett konfigurációban ki van kommentezve):
sudo vim /etc/tomcat6/server.xml
Konfigurálás Shibboleth IdP-hez
Alkalmazás descriptor
sudo cp /etc/tomcat5.5/Catalina/localhost/idp.xml /etc/tomcat6/Catalina/localhost/
Endorsed library-k
cd /usr/share/tomcat6/
sudo mkdir endorsed
sudo cp -i ~/shibboleth-identityprovider-2.1.4-slo3/endorsed/* endorsed/
Logok, metadata írása
sudo chown -R tomcat6 /var/log/shibboleth-idp/
sudo chown -R tomcat6 /var/run/shibboleth-idp/
Terracotta
sudo chown -R tomcat6 /var/log/terracotta/client/
Tomcat 5.5 eltávolítása
sudo aptitude remove tomcat5.5
sudo update-rc.d -f tomcat5.5 remove
sudo rm -r /etc/init.d/tomcat5.5 /etc/default/tomcat5.5 /etc/tomcat5.5/ /var/lib/tomcat5.5 /usr/share/tomcat5.5
SP Operational Requirements
Purpose of this document
This document defines identity management and system operation requirements and recommendations for Service Providers joining the HREF Federation.
Throughout this document the interpretation of terms MUST , MUST NOT , SHOULD , SHOULD NOT are defined as:
MUST (or SHALL , REQUIRED ): the definition is an absolute requirement of the specification in order to build and keep trust in the federation.
MUST NOT : the definition is an absolute prohibition of the specification
SHOULD (or RECOMMENDED ): there may be valid reasons for ignoring the definition, however, the divergence from the specification MUST be documented
SHOULD NOT (or NOT RECOMMENDED ): there may be valid reasons for the particular behaviour to be acceptable, however, the divergence from the specification MUST be documented
Identity management
The organisation running the Service Provider MUST have a Privacy Policy, and its location MUST be indicated in the Resource Registry.
Service management
The organisation MUST develop a role responsible for liaison with the Federation Operator.
The organisation operating the Service Provider MUST provide end-user support about its service and have its users informed about the availability of the support.
Operational issues
Cryptographic keys of the Service Provider MUST be at least 1024 bits long.
Private keys MUST be protected.
In case of a key compromise, the Federation Operator MUST be notified within 24 hours .
Use of self-signed certificates with a long expiration time is RECOMMENDED .
Use of SAML:
The Service Provider MUST comply with the Interoperable SAML 2.0 Web Browser SSO Deployment Profile ( http://saml2int.org )
It is RECOMMENDED to support SAML2 Single Logout Profile over HTTP Redirect and SOAP Bindings.
All SAML endpoints of the Service Provider SHOULD be protected by HTTPS.
All SAML endpoints of the Service Provider MUST be under a DNS domain which is either possessed by the operating organisation, or the organisation MUST be commissioned by the owner of the domain (according to WHOIS database) in written form for using its domain in eduID.
SessionCreationError
Ha Session creation failure üzenetet kapunk, azt jelenti, hogy a Shibboleth SP-nek - ugyan a webszerver modul aktiválódik - nem sikerült létrehoznia megfelelő session-t. Ennek számos oka lehet, de első körben az SP naplóállományában (általában: /var/log/shibboleth/shibd.log ) kell keresni a hiba okát.
Lehetséges hibák:
Nem fut a shibd
Nem sikerült csatlakozni az IdP-hez. Ennek is több oka lehet:
Hálózati probléma az IdP és az SP között (default portok: 443, 8443)
Az IdP nem válaszol az SP-nek (lásd: 404-es IdP hiba , load balanced IdP környezetben leginkább)
Az IdP tanúsítványa hibás (nem egyezik meg a metadata állományban levővel)
SSL hiba:
error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate , lásd: Shibbleth tanúsítványok
Invalid credential:
Lejárt az SP tanúsítványa (Lásd: Tanúsítvány frissítése )
Nem sikerül hozzáférni a - titkosított - privát kulcshoz
A szócikk vagy fejezet még megírásra vár A felsorolás nem tartalmazza az összes előforduló hibát, kiegészítésre szorul!
Lásd még:
https://spaces.internet2.edu/display/SHIB/BrowserErrors
https://spaces.internet2.edu/display/SHIB/CPPSPCommonErrors
Log4whatever
A Shibboleth korábban a log4cpp library 0.35-ös változatát használta, azonban ebben számos threading és egyéb hiba volt, ami miatt a shibd instabil lett. A Shibboleth fejlesztője kijavította a forrást, azonban az eredeti szoftverbe ez nem került vissza (valószínűleg átmenetileg szünetelt a fejlesztése).
Később a log4cpp fejlesztése újrakezdődött, majd komolyabb változtatások után kijött az 1.0-ás verzió. Ez részben javította a Shibboleth fejlesztő által jelzett hibákat, azonban változott az API. A kezdeti instabilitások miatt Scott Cantor kiadta a 0.35-ös log4cpp forkjaként létrejött log4shib csomagot. Ez teljesen megegyezik a 0.35-össel, csak a Shibboleth használatához feltétlen szükséges hibajavításokat tartalmazza. A fejlesztő nem is tervezi a csomag további fejlesztését, álláspontja szerint a csomagra csak az Internet2 fejlesztésekben van szükség.
A helyzet jelenleg (2008.04.28.) a következő:
Úgy tűnik, a log4cpp 1.0 kijavította a shibd elszállásához vezető hibát
A lenny-ben levő Shibboleth (1.3) Debian csomag már az 1.0-ás log4cpp csomagot használja (liblog4cpp5)
A Shibboleth2 és függőségei (opensaml, xmltooling) hivatalosan vagy a log4cpp 0.35 vagy a log4shib csomagot tudják használni
A gyakorlatban a shibboleth2-sp és az opensaml lefordul az 1.0-ás log4cpp-vel is, de figyelmeztető üzenetet küld, mely szerint a log4cpp problémákat okozhat
Az xmltooling lefordításához szükség van erre a patch-re
Ahhoz, hogy a Shibboleth2 bekerülhessen a Debianba, semmiképpen sem használhatja a log4shib-et.
SLODemo
Warning
For more complete description please go and see how Single Logout is implemented in Shibboleth IdP.
To demonstrate the features we have prepared a demo application . The main purpose of the demo is to test the UI and various error conditions.
Preparing
Metadata (unsigned)
IdP: Based on Adam's Git repository
Info
This version is still unreleased .
You can grab a snapshot from the web-based Git repository by selecting the latest commit and clicking on the snapshot link.
Authentication
There are 100 demo users from demo1..100 , all users have the password 'demo'.
Info
It was necessary to use more than one demo account because IdP sessions mix if two testers (browsers) share the same userid.
So if you face strange results (like trying to log out from SP's you were not logged in), please first try it with another demoXX account to sort out possible IdP session mixing problem.
The IdP uses the UsernamePassword Login Handler. IdP logout is not possible with container-based authentication (like HTTP / X.509 / Kerberos) .
Service Providers
SP1: (Not-so) Old Release
SP software
Shibboleth 2.2.1 (Debian backports)
Front channel logout
supported
Back channel logout
supported
Notes
This was a 2.1 SP which used to report partial logout on backchannel. Now it's working OK.
SP2: Bright Shining Star
SP software
Shibboleth 2.2.1 (Debian SID)
Front channel logout
supported
Back channel logout
supported
Notes
Both front- and back-channel logout should work properly
SP3: The Pretender
SP software
SimpleSAMLphp SAML2 SP
Front channel logout
supported
Back channel logout
not supported
Notes
SimpleSAMLphp does not support back-channel bindings, therefore the metadata does not contain it
SP4: Use The Backdoor, Please!
SP software
Shibboleth 2.2.1 (Debian SID)
Front channel logout
not supported
Back channel logout
supported
Notes
The metadata of this SP does not contain front-channel bindings for logout
SP5: Old Slowhand
SP software
Shibboleth 2.2.1 (Debian backports)
Front channel logout
not working (times out)
Back channel logout
not working (times out)
Notes
Metadata points to a fake logout service that is not answering in time. Actually this is a PHP script that returns a 500 Internal Server Error after 20 seconds of delay, similarly to an overloaded webserver. Actually there is a big difference: usually an overloaded server can not complete TCP connection establishment in time. This test only delays the sending of responses
SP6: Shibboleth Neanderthalensis
SP software
Shib 1.3 (IRL: Shibboleth 2.2.1 Debian backports)
Front channel logout
not supported
Back channel logout
not supported
Notes
The metadata of this SP does not contain any logout services, just like a normal Shib1.3 SP
SP7: Good Guy Speaking Ancient Greek
SP software
Shibboleth 2.2.1 (Debian SID)
Front channel logout
supported
Back channel logout
supported
Notes
This is a 2.x SP but it uses Shibboleth 1.3 SSO protocol. I'd expected a logout failure because of the Shibboleth-specific NameID format, however it turned out to be working.
SP8: Blitzkrieg
SP software
Shibboleth 2.2.1 (Debian SID)
Front channel logout
not working (if timed out)
Back channel logout
not working (if timed out)
Notes
This is a special SP that has a very short session lifetime (30 sec). If you hit the logout button within 30 sec, it should work but it should fail afterwards, because the principal is no longer known to the SP.
SP9: Knight Without Armour
SP software
Shibboleth 2.2.1 (Debian SID)
Front channel logout
supported
Back channel logout
supported
Notes
This SP only supports HTTP for both SSO and SLO. Presumably, it would not work if the SSO was using HTTPS (not checked).
How this demo works
The SLO Demo runs in a separate machine from all the SPs and IdP. So it has no information if the login is succeeded or not, it just hopes, everything goes as expected.
Below is a very brief description of the logout demo.
Selecting SPs
At first the user selects the SPs he/she wants to log in. The order of the login is currently sequential (not sure if it makes any difference).
Redirecting to SPs
all SP sessions are initiated by using 302 Redirect s to the SPs SessionInitiator by specifying only the IdP entityID ( https://sandbox.slotest.aai.niif.hu/idp/shibboleth ).
the simpleSAMLphp login URL is somewhat similar but not the same
the SP initiates the session (the first one gets the user logged into the IdP)
the SP redirects to the homeURL
homeURL redirects back to the redirection point of the demo interface (by some trivial PHP script)
the demo interface starts over with the next SP or displays summary page
Summary page
The (supposedly) logged in SPs are displayed along with their logout urls. Logout opens up in a new window.
Logging out
User clicks on one of the logout URLs.
Start over
On page refresh you can start it over. If you are not asked for password by the IdP, it means that your IdP session was not cleared properly, therefore the logout is failed.
How to get your SP involved
Configure the SP as you wish
Don't forget to set signing="true" or signing="false" , as described in the SLO documentation
Configure the target application (or the page which is served on homeURL) to redirect to [https://www.aai.niif.hu/SLODemo/sloDemoLoginRedirect.php](https://www.aai.niif.hu/SLODemo/sloDemoLoginRedirect.php) .
Send SP details to aai at niif dot hu
Metadata
SessionInitiator URL
Optionally:
Front-channel logout initiator (if there's any)
Back-channel logout initiator (if there's any)
SP software & version
Session handler (attribute viewer) URL
Short description of what to test
A funny name, of course ;)
Configure your SP to trust slotest metadata (this will contain your SP metadata as well).
Please inform us when your test SP is no longer functioning
Setting up a back-channel only LogoutInitiator
See this Jira entry for background. If you have a pre-2.2.1 SP, you should use:
Expected results
SAML2
Single Logout profile is for SAML2 only. Therefore SP6 (Neanderthalensis) will always fail. Note that SP7 (Ancient Greek) actually speaks SAML2 although it initiates SSO with Shibboleth protocol. Therefore you cannot initiate SLO from SP7 but you can participate in SLO.
SP5 (Old Slowhand) will always fail unless the Logout request is initiated by it.
Front-channel, back-channel
The IdP can fallback to back-channel, if the logout is front-channel and the SP software does support only back-channel bindings. Not the other way , because front-channel bindings need the information held in browser cookies. Therefore front-channel SLO will work with SP4 (Backdoor) if initiated by some other SP's, but SP4 can only initiate back-channel SLO (which is not supported by many of the SP's above.)
Unexpected results
TODO
Support NoScript
TODO
NoScript support has been added recently to front-channel logout, thorough testing is still necessary.
The user interface is a bit clumsy, because the daisy-chain of redirects is a no-go and some browsers do not even support frames. Ideas, tips are welcome for making it better.
The main rationale behind supporting NoScript is to make it even possible to use logout with other clients than web browsers. Back-channel is much more convenient for them, though.
Test with Application Notification
TODO
Contribution is welcome!
Try it with various browsers
TODO
Contribution is welcome!
Misc
Publish shibd and IdP logs on a web page (real-time?)
Add IPv6 addresses to the vhosts
Add OpenSSO test SP
EduPersonAffiliation
A kép az eduPersonAffiliation értékeinek egy lehetséges ábrázolása. A pontos meghatározás az intézmények feladata, erre a föderációnak nincsenek szigorúbb megkötései
A student , staff , faculty viszonnyal rendelkezők jellemzően member -ek is.
Kivételek előfordulhatnak, például nem kapnak member viszonyt:
ideiglenes hallgatók (pl. nyári egyetem)
nem aktív hallgatók (pl. passzív féléven, abszolutorium és a diploma átvétele közötti időszakban, stb.)
vendégoktatók
eseti szerződéses munkatársak
E három affiliation tetszőleges kombinációja előfordulhat, például
Oktató és hallgató egyszerre (pl. PhD)
Dolgozik és hallgató (pl. rendszergazda)
Alkalmazott és oktató (pl. rendszergazda, aki kurzusokat is tart)
Az employee -t leginkább belül érdemes használni, jellemzően ők is member-ek
Az öregdiákok és a könyvtári és az egyéb külsős felhasználók jellemzően nem member-ek
IsPassive
Az isPassive SAML2-ben bevezetett lehetőség, mellyel azt szabhatjuk meg, hogy az azonosításnak úgy kell megtörténnie, hogy közben semmiféle látható felhasználói interakciónak nem szabad történnie. Ha az azonosítás így nem hajtható végre, akkor hibát kell visszaadni az SP-nek.
Miért jó?
Az isPassive használatával elérhetjük, hogy Lazy Session -nel védett oldalunkra a felhasználó bejelentkezése automatikusan - azaz "Bejelentkezés" gombra kattintás nélkül - megtörténjen. Ehhez három feltétel együttes teljesülése szükséges:
a felhasználó már rendelkezik az IdP-je által hitelesített munkamenettel
az IdP által használt autentikációs mechanizmus támogatja az isPassive-ot
erre kizárólag SAML2 IdP esetén van lehetőség
ha használunk Discovery Service-t, akkor az a felhasználó IdP-jét képes megállapítani interakció nélkül
ez általában azt jelenti, hogy a felhasználónak van olyan cookie-ja, amely alapján a DS meg tudja határozni az IdP-t. Érdemes megjegyezni, hogy a SWITCH Discovery Service IP cím alapján is képes meghatározni IdP-t.
Amennyiben ezen feltételek közül valamelyik nem teljesül, úgy az SP hibát fog dobni. Ezt redirectErrors attribútum segítségével átirányíthatjuk a saját alkalmazásunkra.
Hátrányok
Lehetséges olyan helyzet, hogy a hiba nem jut vissza az SP-hez:
az IdP nem SAML2-t használ
az IdP azonosítási mechanizmusa nem támogatja a passzív azonosítást (pl. azért, mert webszerver-alapú azonosítást használ)
a Discovery Service vagy a WAYF nem támogatja a passzív választást
Ebben az esetben a felhasználó olyan üzenetet kap, amit valószínűleg nem tud értelmezni. Pl.:
hibaüzenet az IdP vagy a DS részéről
IdP azonosítási felület (ami esetleg nem is a felhasználó IdP-je)
Ezért isPassive-ot csak abban az esetben szabad használni, ha garantálni tudjuk, hogy az IdP-k mind támogatják a passzív autentikációt!
Működése a gyakorlatban
Az alábbi szkriptet szúrjuk be az oldalunk főlapjára / fejlécébe.
A Shibboleth SP konfigurációjában ( shibboleth2.xml ) az adott alkalmazásra vonatkozó beállításoknál új attribútumként adjuk meg a redirectErrors="SAJÁT KEZDŐLAPOM" direktívát.
Bizonyosodjunk meg róla, hogy az oldalt lazy session-nel védjük
Kód
AttributePushPull
Egy IdP és egy SP között az attribútumok átadása push és pull modell szerint történhet.
Attribute Pull
Attribute Pull esetén a folyamat az alábbi:
IdP azonosítja a felhasználót (ill. feldolgozza az autentikációs kérést)
IdP autentikációs igazolást állít ki és elküldi az SP-nek
SP attribútum kérést (AttributeRequest) küld az IdP-nek
IdP attribútum igazolást állít ki, mely a felhasználó attribútumait tartalmazza, majd ezt visszaküldi az SP-nek
Attribute Push
Attribute Push használata esetén az IdP által küldött első válaszba beágyazva szerepelnek az attribútumok, ezért az SP részéről nincs szükség további kérésekre, a folyamat tehát a következő módon zajlik:
IdP azonosítja a felhasználót (ill. feldolgozza az autentikációs kérést)
IdP autentikációs és attribútum igazolást állít ki és ezeket egyetlen válaszként elküldi az SP-nek
Alkalmazási terület
Shibboleth esetén Browser/POST profil használata esetén a pull modell, míg Browser/Artifact profil esetén a push modell az alapértelmezett, ám ez felülbírálható.
Bizonyos föderációs megvalósítások (pl. a SimpleSAMLphp ) csak a push modellt támogatják, mivel ennek implementációja egyszerűbb.
Info
Nagyméretű attribútumok használata esetén a válasz mérete is elég nagy lehet, ezért ez POST profil esetén esetleg kényelmetlenséget (lassú működést) okozhat.
Webhosting
Webhosting
Futtatókörnyezet
Apache 2.4.25
PHP 7.0.33
MariaDB 10.0.38
Tűzfal
Szűrés kimenő és bejövő irányban. Külön kérésre portnyitási lehetőség.
Adminisztratív hozzáférés
SFTP hozzáférés a webroot-hoz.
Tartalomkezelő és blog-rendszer telepítés leírás
Drupal telepítés
Joomla telepítés
WordPress telepítés