AAI
Auto-generated book for AAI
- NIIFI_IdP
- Döntési_táblázat
- Shibboleth2_DiscoveryService
- AAIInterop-OpenSSOShib2
- Shibboleth2_SP
- Shib3IdpMetadata
- RelyingParty
- Shibboleth_Service_Provider__SP_
- ProviderId
- HREF_Key_Rollover_2020
- Shib2IdpAuth
- URN_SCHAC
- AAI
- FastCGI
- Lazy_Session
- Föderációs_modellek
- ShibAndEdugain
- ShibIdPAttrib
- Shib2PersistentId
- AAI_és_Shibboleth__2007.11.07_
- ArpFilterProposal
- Shib3IdpInstall
- HREFChecklist
- Shibenv
- SimpleSAMLphp
- HREFMetadataRegistrationPracticeStatement
- Shib2SPSourceInstall
- ShibIdPX509LdapAuthentication
- Shib2IdpSUSE
- MediaWikiShibboleth
- Attribútum_feloldás
- SimpleSAMLphp_proxy_vidyo_portálhoz
- OpenSSO_IdP_-_SimpleSAMLphp_SAML2_SP
- Shib2IdpInstall
- HREFServices
- Attribute_Conversion_for_eduGAIN
- Xmltooling_Log4cpp_patch
- IdP_Operational_Requirements
- Openidp
- WAYF
- HREF_Key_Rollover_2020_English
- Shib2IdpConnectionPool
- Shib3IdpAttrib
- OpenID
- Erasmusplus_ESI
- SAML
- Shibboleth
- Common-lib-terms
- SimpleSAMLMixedMetadata
- Károkozási_táblázat
- Shibboleth_IdP
- ErrorNoStatement
- HREF_szolgáltatási_szint_megállapodás
- Drupal_Shibboleth_module
- Tanúsítványok_a_föderációban
- Shibenv-PHP
- ShibMessages
- HREFPolicyStub
- AboutEduID.hu
- Shib2IdpRHELQuickStart
- NIIFSchema
- Shib2SP
- Resource_Registry
- SSP_EntityCategories
- FedEntitiesLogging
- HREF_műszaki_előírások
- OpenSSO_IdP_-_Shibboleth2_SP
- MTA_Sztaki_IdP
- Dunaújvárosi_Főiskola_IdP
- AA_Testing
- IdP_whichone
- Shibboleth_troubleshooting
- Intézmény_átnevezés
- Scope
- HREF_attribútum_specifikáció
- Attribútum_kiadás
- ShibSPInstallDebian
- ShibTest
- Szövetségi_alapon_történő_felhasználó_azonosítás_Huntéka_könyvtári_alkalmazásokban
- Shib3IdpProd
- UApprove
- URN
- Shib2IdpRHEL
- Shibboleth_SP
- AAIGettingStarted
- ElsevierSP
- Tomcat55_to_Tomcat6
- SP_Operational_Requirements
- AAI_szolgáltatási_IP
- EduidFedStats
- SessionCreationError
- Föderáció
- SamlSign
- FedReqDef
- HREFContract
- Metadata
- HREFUseCaseStub
- AAIInterop-Shib2SimpleSAMLphp
- DrupalShibbolethReadmeDev
- Shib3IdpAuth
- Shib2IdpAttrib
- HREF_metadata_specifikáció
- AAI_AzureADasAuthsource
- Metadata_Specification
- JoiningEduGAIN
- Shibenv-PHP-Lazy
- GoogleAuth
- Pont-pont_bizalmi_kapcsolati_modell
- Eszközök
- Log4whatever
- SLODemo
- Shibboleth2_IdP
- MDX
- Alkalmazások_samlizálást_segítő_teszt_IdP_simplesamlPHP_segítségével
- Shibenv-JSP
- MetadataTrust
- Shib2IdpCluster
- Shib2IdpTerracottaConfiguration
- Shib2IdpARP
- ShibIdpSLO
- FedDev
- EduPersonAffiliation
- Attribute_Conversion_for_simpleSAMLphp
- HREF_alapelvek_és_alapvető_szabályok
- Shib2SPConfig
- IsPassive
- AttributePushPull
- Alkalmazások_illesztése
- Shib2IdPMobileLogin
- Shib3IdpARP
- OpenSSO
- HREFJoin
- Sirtfi
- Attribute_Specification
- SSP2
- DrupalShibboleth
- Publikációk
- Federation_Policy
- Shibboleth_Service_Provider__SP__és_Docker
- EduIDTest
- Drupal_telepítés
- FederationStats
- HREFGlossary
- Shibboleth_IdP_telepítés__Debian_
- SimpleSAMLphp_NIIF_ldap_séma_mapping
- Shibboleth3_IdP
- Interoperabilitás_mátrix
- HREF
- WebmailShibboleth
- Shibboleth_IdP_konfigurációja
- Single_Logout_in_Shibboleth_IdP
- Shib2IdpTomcat6
NIIFI_IdP
Tulajdonság | Érték |
---|---|
Intézmény (IdP) neve | NIIF Intézet |
IdP szoftver | Shibboleth IdP 2.1 |
Technikai kapcsolattartó | Bajnok Kristóf, aai KuKaC niif PoNT hu |
Azonosítható felhasználók száma | 70 |
Hallgatók száma | 0 |
Alkalmazottak száma | 63 |
Külsősök száma | 3 |
Nem felhasználóhoz köthető bejegyzések száma | 4 |
Hallgatók felvételének folyamata | Nem alkalmazható |
Alkalmazottak felvételének folyamata | Új munkatárs érkezése esetén - az érkező felettesének kérésére - a névtár felelős veszi fel az adatokat az NIIFI névtárába. |
Külsősök felvételének folyamata | Az NIIF-fel speciális (szoros) viszonyban levők szintén azonosíthatók ennél az IdP-nél, de ez kivétel, csak igazgató(helyettesi) utasításra hozható létre. |
Hallgatók törlésének folyamata | Nem alkalmazható |
Alkalmazottak törlésének folyamata | A munkatárs kilépésekor a névtár felelős eltávolítja az edupersonAffiliation: employee attribútumot, az esetleg használt edupersonEntitlement értékeket és a kilépő munkatárs felettesével egyeztetett időpontban törli a felhasználó bejegyzését |
Külsősök törlésének folyamata | Nem meghatározott, mivel a felvétel is különleges eljárás szerint történik |
Felhasználó intézményhez való kapcsolatát leíró attribútum/érték | edupersonAffiliation: employee edupersonAffiliation attribútum vagy edupersonAffiliation: affiliate |
Egyes attribútumok származás helye ill. módosításra jogosultak | A felhasználók attribútumait - a jelszavukat leszámítva - kizárólag a névtár adminisztrációjára jogosult műszaki kollégák módosíthatják. A userCertificate;binary attribútumot a tanúsítvány publikálásakor az NIIF CA hozza létre. |
Jelszavak formai követelményei | A felhasználók jelszavait időnként audittal ellenőrizzük, legalább 6 karakter hosszú, szólistában nem található jelszavakat kell használniuk. A jelszóváltoztató felület ellenőrzi, hogy az új jelszó megfelel-e ezeknek a követelményeknek.A teszt felhasználók jelszavai minimálisan 8 karaktert (kis- és nagybetűket, számokat, opcionálisan egyéb karaktereket) kell, hogy tartalmazzanak. |
Naplóállományok rendelkezésre állási ideje | min. 6 hónap |
Autentikációs backend | LDAP |
Autentikációs mód | Username/password |
Vállalt rendelkezésre állás | Az Identity Provider funkciót egy nagy rendelkezésre állású klaszter biztosítja. A rendelkezésre állásnak nincs formálisan vállalt értéke (belső szolgáltatás). |
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 |
|||||
Policy dokumentumok bármilyen megváltoztatása |
|||||
Csatlakozás nemzetközi szervezetekhez és együttműködésekhez | |||||
Azonosítási szolgáltatás (Identity Management) kiszervezése | |||||
Metadata módosítása | |||||
Szolgáltatási díj bevezetése / megváltoztatása | |||||
Egyedi díjkedvezmények megállapításának joga | |||||
Bevételek felhasználása | |||||
Szerződés rendes felmondása | |||||
Súlyos szerződésszegés miatti rendkívüli felmondás | |||||
Föderáció megszüntetése | |||||
Tagok Tanácsak saját eljárási szabályainak elfogadása, módosítása |
Shibboleth2_DiscoveryService
Shibboleth2 Discovery Service
A Discovery Service ugyanazt a szerepet játssza a Shibboleth2 infrastruktúrában mint a WAYF szolgáltatás a Shibboleth1.x esetén. A WAYF szolgáltatás azonban Shibboleth-specifikus, míg a Discovery Service pontos működését a SAML2.0 szabvány írja le.
Részletes konfigurációs segédlet a Shibboleth2 Wikin
Az IdP Discovery menete
A Discovery Service (DS) feladata tehát, hogy az SP számára kiválasszon egy IdP-t, amit a felhasználó használ. Ezt alapvetően kétféleképpen éri el: cookie-k illetve egy webes IdP kiválasztó felület segítségével.
Amennyiben a DS cookie-ban tárolja a felhasználó által kiválasztott IdP-t, ezt egy _saml_idp nevű cookieban kell tennie, aminek a formátuma kötött: egy darab space-szel elválasztott, base64 kódolt IdP entityID lista (tehát több IdP-t is képes tárolni, és a használati sorrendet is megőrzi - bár utóbbit nem teszi kötelezővé a szabvány).
A Shibboleth2 DS képes arra, hogy a cookie-k használatán kívül a felhasználónak egy webes formot mutasson, amiben a federációk és az egyes federációkban szereplő IdP-k listáját jeleníti meg. Ezt a listát a felhasználó egy szöveges kereső segítségével szűrheti is.
A Discover Service metaadatok konfigurálása
A DS konfigurálása a wayfconfig.xml fájl segítségével történik. Itt kell megadni a használt template-et és a metaadatokat is. A metaadatokat ugyanazon formátumban kell konfigurálni mint az IdP esetén (tehát lehetőség van egy URL-ről automatikusan letöltött metaadat-állomány használatára is).
A DS-nek ismernie kell a kérő SP metaadatát is, alapbeállításként pedig csak azokat az IdP-ket listázza, amelyek egy metaadat-fájlban vannak az aktuális SP-vel.
Discovery Service pluginek
A DS kiterjeszthető olyan pluginekkel, amelyek segítik a felhasználót az IdP választásban. Ilyen plugin például a _saml_idp cookie kezelő, ami SAML2 szabvány-kompatibilissé teszi a DS-t.
AAIInterop-OpenSSOShib2
!!! bug "Elavult információ"
**Figyelem**: ez a szakasz vagy szócikk elavult információkat tartalmazhat!
OpenSSO IdP - Shibboleth2 SP Interoperabilitás
- IdP: maszat-opensso-idp.xml
- SP: papigw-shibboleth2-sp.xml{.download="papigw-shibboleth2-sp.xml"}
SAML2.0 Single Sign on
- SP oldali SAML2 bindingot támogató AttributeConsumerService-ek:
- 1: /SAML2/POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
- 2: /SAML2/POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
- 3: /SAML2/Artifact urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact
- 4: /SAML2/ECP urn:oasis:names:tc:SAML:2.0:bindings:PAOS
HTTP-Post
- Működik
- https://papigw.aai.niif.hu/saml2interop/opensso-post/
- SP oldalon
<SessionInitiator type="Chaining" Location="/Login" id="maszat-opensso-post"
relayState="cookie" entityID="https://idp.sch.bme.hu/niif-teszt">
<SessionInitiator type#"SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
</SessionInitiator>
HTTP-Artifact
- Az OpenSSO nem figyel arra hogy az SP milyen AttributeConsumerService-t kér, így az IDP oldalon kell konfigurálni az SP tulajdonságait úgy, hogy az alapbeállítás ne a POST legyen.
- TODO - Trust management a back-channel kommunikációnál a tanusítványt ismernie kell az SP-nek.
- JVM beállítása a kliens tanúsítvány használatához - https://opensso.dev.java.net/issues/show_bug.cgi?id=1409
Attribute push
- Gyári buildekkel nem működik, ugyanis az OpenSSO urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified formátumban küldi az attribútumokat, amiket a Shibboleth2 SP nem fogad el.
- Saját patch használata esetén bekonfigurálható az uri típusú NameFormat is, azzal működik probléma nélkül.
Attribute pull
- Az OpenSSO-ban nem lehet kikapcsolni az attribute push-t. FIXME
NameIDFormat
- A Shibboleth2 SP által generált metaadatba kézzel be kell illeszteni a NameIDFormat node-ot
- Az OpenSSO támogatja a perzisztens és a tranziens SAML2 azonosítót is.
SAML2.0 Single Log out
- A shibboleth2 nem támogatja (még) a Single Log-out protokollt, lásd: https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues
Metaadat problémák
- A Shibboleth2 SP metaadatból el kell távolítani az
<md:Extensions>
node-ot az összes gyerekelemével együtt.- Erre nagyon figyelni kell, mert összeomlik tőle az OpenSSO, és csak címtár-módosítással ('hibás' metaadat törlése) állítható helyre.
- Sajnos nem triviális javítani ezt a viselkedést...
- A metaadatba ágyazott certificate esetén csak a
<ds:X509Certificate>
node szerepelhet, semmi más- Ehhez írtam patch-et ami ezt javítja.
- https://opensso.dev.java.net/issues/show_bug.cgi?id=2985
Shibboleth2_SP
Telepítési leírások
Konfigurációs leírások
Shib3IdpMetadata
Shibboleth 3 IdP metaadat beállítása
Vonatkozó állományok:
{idp.home}/conf/metadata-providers.xml
Nem föderációs SP metaadat
Nem föderációs SP metaadatának felvitele a metadata-providers.xml
állományba az alábbiak szerint történik. A példában szereplő %{idp.home}/metadata/sp-sp.intezmenyneve-metadata.xml
állományt el kell helyezni az állományrendszerben és meg kell győződni annak valódiságáról (nincs aláírva).
<MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" ... >
<!-- ... további tartalom ... -->
<!-- Helyi, nem föderációs SP -->
<MetadataProvider id="SajatSPLocalMetadata"
xsi:type="FilesystemMetadataProvider"
metadataFile="%{idp.home}/metadata/sp-sp.intezmenyneve-metadata.xml"/>
<!-- ... további tartalom ... -->
</MetadataProvider>
EduID föderációs metaadat
EduID föderációs metaadat felvitele a metadata-providers.xml
állományba az alábbiak szerint történik.
Töltsük le föderáció metaadat aláíró tanúsítványát.
cd /opt/shibboleth-idp/credentials
wget https://metadata.eduid.hu/href-metadata-signer-2011.crt
A tanúsítvány SHA-1 és SHA-256 lenyomata a következőképpen ellenőrizhető le.
$ openssl x509 -in href-metadata-signer-2011.crt -noout -fingerprint
SHA1 Fingerprint=FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66
$ openssl x509 -in href-metadata-signer-2011.crt -noout -fingerprint -sha256
SHA256 Fingerprint=B3:2C:16:EB:3B:77:39:42:46:E3:CD:D7:86:D6:0D:11:A9:FB:6E:1C:11:E2:FD:23:71:67:E4:33:B4:ED:9F:FA
Szerkesszük a beállítóállományt.
<MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" ... >
<!-- ... további tartalom ... -->
<!-- eduID.hu föderációs metaadat -->
<MetadataProvider id="HTTPMetadata"
xsi:type="FileBackedHTTPMetadataProvider"
backingFile="%{idp.home}/metadata/localCopyFromEduID.xml"
metadataURL="https://metadata.eduid.hu/current/href.xml">
<MetadataFilter xsi:type="SignatureValidation"
requireSignedMetadata="true"
certificateFile="${idp.home}/credentials/href-metadata-signer-2011.crt" />
<!-- ... további tartalom ... -->
</MetadataProvider>
Az eduID föderáció metaadat weblapja a https://metadata.eduid.hu/ helyen érhető el.
Tovább a föderációba
Amennyiben a telepítendő IdP-t szeretnénk a HREF-be integrálni, úgy ennél a pontnál küldjünk egy levelet az aai@niif.hu címre, amely nyomán, ha minden rendben van, az IdP regisztrálásra kerül a Resource Registry-ben.
Dokumentáció
- https://wiki.shibboleth.net/confluence/display/IDP30/MetadataConfiguration
- https://wiki.shibboleth.net/confluence/display/IDP30/HTTPMetadataProviders
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)
Shibboleth_Service_Provider__SP_
Az alábbi lapon megkíséreljük összefoglalni a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő Shibboleth SP-t állítsunk üzembe. Fontos, hogy rengeteg olyan igény lehet, amely további speciális beállítások meglétét teszik szükségessé, ezeket ezen a lapon nem részletezzük, ilyen irányú tájékozódáshoz legbiztosabb forrás a http://wiki.shibboleth.net lap.
Telepítés
Előkészületek
A Shibboleth SP egy webszerver modul, így szükséges előfeltétel, hogy a gépünkön legyen egy webszerver telepítve, jelenleg Apache és IIS a biztosan támogatott webszerverek. Emellett szükséges, hogy a 443-as port a tűzfalon mindkét irányban engedélyezett legyen, ill. a hosztnév, amelyen a webszerver üzemel, be legyen jegyezve a DNS-be.
Letöltés és telepítés
A legfrissebb változat letölthető https://wiki.shibboleth.net/confluence/display/SP3 címről. Célszerű valamilyen előre csomagolt változattal dolgozni, melyet az adott rendszer csomagkezelőjén keresztül egy mozdulattal feltelepíthetünk minden függőségével együtt.
- Az alábbi parancs a Shibboleth webszerver modul függőségeit is telepíti. Előfordulhat, hogy a telepítés engedélyezni kell a modult és újraindítani az Apache webszervert.
Debian 9 “Stretch” / Ubuntu 16.04 LTS (Xenial)
sudo apt install apache2 libapache2-mod-shib2
Debian 8 “Stretch” / Ubuntu 14.04 LTS (Trusty)
sudo apt-get install apache2 libapache2-mod-shib2
Debian 6 “Squeeze” / Debian 7 “Wheezy” / Ubuntu 12.04 LTS (Precise)
Debian 6, Debian 7 és Ubuntu 12.04 rendszerek támogatása lejárt, így a Shibboleth csomag telepítését sem ajánljuk ezekre a rendszerekre!
A Debian Shibboleth csapat által készített új verziók időről időre bekerülnek backports.org tárolóiba is, ezért stable Debiant futtató rendszereken javasolt ezt használni.
A backports.org tárolójának beállításához adjuk hozzá a /etc/apt/sources.list
fájlhoz a következő sort:
deb http://backports.debian.org/debian-backports squeeze-backports main
A csomagokat így telepíthetjük:
sudo aptitude update
sudo aptitude install -t squeeze-backports libapache2-mod-shib2
Ez a Shibboleth webszerver modul függőségeit is telepíti. A Shibboleth használatba vételéhez engedélyezni kell a modult és újra kell indítani az Apache webszervert.
Red Hat / CentOS (RPM) alapú disztribúciók
Shibboleth SP-ből RHEL/CENTOS rendszerekre egyből rendelkezésünkre áll bináris csomag, a fejlesztők ezen platformokon dolgoznak első körben. A telepítés előtt a teendőnk mindössze annyi, hogy a YUM forrásokhoz hozzá kell adni a Shibboleth SP repóját. Ehhez látogassunk el a http://download.opensuse.org/repositories/security://shibboleth/ oldalra, majd a pontos verzió kiválasztása után a security:shibboleth.repo fájl tartalmát másoljuk be a /etc/yum/ /etc/yum.repos.d/CentOS-Base.repo
fájl aljára, majd
yum install shibboleth
Hibaelhárítás: Can't connect to listener process
Ha a fenti hibába futunk bele, az azt jelenti, hogy a SE linux nem engedi kommunikálni a shibd és a httpd folyamatokat, ezért ezt külön engedélyezni kell. Ehhez készítsünk egy fájlt shibd.te
néven, melynek tartalma az alábbi legyen:
module shibd 1.0;
require {
type var_run_t;
type httpd_t;
type initrc_t;
class sock_file write;
class unix_stream_socket connectto;
}
####### # httpd_t ######=
allow httpd_t initrc_t:unix_stream_socket connectto;
allow httpd_t var_run_t:sock_file write;
Ezek után futtassuk le az alábbi parancsokat, melyek a fenti fájlt megfelelően lefordítják, és be is illesztik a létrehozott szabályunkat.
# checkmodule -M -m -o shibd.mod shibd.te
checkmodule: loading policy configuration from shibd.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 6) to shibd.mod
# semodule_package -o shibd.pp -m shibd.mod
# semodule -i ./shibd.pp
Alapbeállítások
A telepített Shibboleth SP konfigurációs állományait Linux alatt a /etc/shibboleth könyvtárban találjuk. Itt a shibboleth2.xml
és az attribute-map.xml
fájlokkal lesz dolgunk.
shibboleth2.xml
A telepítéskor alapértelmezetten érkező fájl nagyrészt megfelelő számunkra, az induláshoz csak az alább részletezett módosításokat kell megejtenünk. A változtatandó kódrészletek mind szerepelnek már az eredeti xml-ben is, így a feladat többnyire csak változtatásról, átírásról, bizonyos részek kommentjelek közül történő kiszabadításáról szól.
-
Választanunk kell egy entityID-t. Ez általában a védendő szolgáltatást futtató hosztnévből származik:
https://hosztnev/shibboleth
, ezt az azonosítót beírni azApplicationDefaults
részbe az alábbi módon (az entityID és a homeURL értékein kívül, ahová a hosztnév írandó be, alapértelmezés szerint mást nem szükséges változtatni):<ApplicationDefaults entityID="https://hosztnév/shibboleth" homeURL="https://hosztnév/shib-error.html" signing="false" encryption="false" id="default" policyId="default" REMOTE_USER="eppn persistent-id targeted-id">
-
Meg kell adni, hogy egy Discovery Service-n keresztül kérjük meg a felhasználót, hogy adja meg, mely IdP-től érkezik, avagy csak IdP-t engedélyezünk számukra. Az első eset nyilvános szolgáltatások esetében indokolt, a második belső, pl. csak intézményi oldalak védésénél szükséges.
-
Discovery Service beállítása
<SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.eduid.hu"> SAML2 SAML1 </SSO>
-
Fix IdP beállítása
<SSO entityID="https://idp.example.org/idp/shibboleth"> SAML2 SAML1 </SSO>
-
-
Meg kell adnunk, hogy milyen metadata forrásból dolgozzon az SP, az alábbi példában az eduID-ban használatos beállítás látható (a hivatkozott href-metadata-signer-2011.crt fájl a http://metadata.eduid.hu címről töltendő le a shibboleth konfigurációs könyvtárába) :
<MetadataProvider type="XML" uri="http://metadata.eduid.hu/current/href.xml" backingFilePath="href.xml" reloadInterval="7200"> <MetadataFilter type="Signature" certificate="href-metadata-signer-2011.crt"/> </MetadataProvider>
-
Meg kell adni, hogy az SP mely kulcsot és tanúsítványt használja. Ehhez egy self-signed tanúsítványra lesz szükség, amely pl. az alábbi paranccsal generálható:
openssl req -new -newkey rsa:2048 -x509 -days 3652 -nodes -out sp.example.org.crt -keyout sp.example.org.key
Az xml-ben módosítandó részlet pedig:
<CredentialResolver type="File" key="sp.example.org.key" certificate="sp.example.org.crt"/>
-
Végül ugorjunk vissza a fájl első felére, szedjük ki a kommentjeleket a
RequestMapper
rész körül, adjuk meg a kezelendő hosztokat és path-okat. Egy Shibboleth SP példány több, az adott webszerver által kezelt hosztot is kezelni tud, és egy-egy hoszton belül több útvonalat is, ezeket itt meg kell adni. Alább egy példa:<RequestMapper type="Native"> <RequestMap applicationId="default"> <Host name="hosztnév" authType="shibboleth" requireSession="false"> <Path name="secure" authType="shibboleth" requireSession="true" /> </Host> </RequestMap> </RequestMapper>
A péda szerint a hosztnév alatti tartalom nem kíván meg shibbolethes azonosítást, kivéve a /secure
location. Ha valahol shibbolethes azonosítást kívánunk használni, azt ezen kívül az adott hoszt webszerver konfigjában is jeleznünk kell. Apache-nál az alábbi módon.
<Location /secure>
AuthType shibboleth
require valid-user
ShibUseHeaders On
ShibRequireSession On
</Location>
További részletek az authorizációval kapcsolatban: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPhtaccess
SP adatainak közzététele
A fenti beállítások után egy működő Shibboleth SP-t kapunk eredményül, ugyanakkor ténylegesen csak akkor fog tudni együttműködni a föderációban résztvevő IdP-kkel, ha az SP metaadatait közzétesszük, így azt az IdPk megismerhetik. Ehhez az eduID föderációban a frissen beállított SP adatait a Resource Registry nevű webes adminisztrációs oldalon kell felvinni egy varázsló segítségével, majd a jóváhagyás után várni pár órát, amíg a változások érvénybe lépnek. Ha nincs az intézményi entitások menedzseléséhez jogod ('Access denied'), akkor konzultálj az intézményed eduID kapcsolattartójával, hogy az SP-det szeretnéd a föderációba regisztrálni. Segítséget nyújt az alábbi lista: https://rr.eduid.hu/list
HEXAA integráció
Ha az eduID-ban használatos külső attribútum forrást is szeretnénk az SP-nkhez illeszteni, akkor a shibboleth2.xml fileban a következő példán keresztül lehet megtenni.
<AttributeResolver type="Chaining">
<AttributeResolver type="Query"/>
<AttributeResolver type="SimpleAggregation" attributeId="eppn" format="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">
<Entity>https://hexaa.eduid.hu/hexaa</Entity>
<Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="eduPersonEntitlement"/>
</AttributeResolver>
</AttributeResolver>
Kapcsolódó lapok
ProviderId
A föderációban résztvevő entitásokat (Identity Provider, Service Provider) providerId azonosítja a föderáción belül. Ennek a formája tetszőleges lehet, az egyetlen követelmény, hogy egyértelműen azonosítsa az entitást.
A gyakorlatban kétféle providerId formátumot használnak:
- URL: https://idp.niif.hu/shibboleth formában
- URN: valamilyen URN hierarchiában, pl.
urn:geant:niif.hu:href:idp:niifi
!!! info
Azt tanácsolják, hogy, amennyiben a providerId URL, akkor az az entitáshoz tartozó metaadatokat szolgálja ki, ezzel lehetővé téve dinamikus metaadatok használatát.
A [HREF](https://help.edu.hu/books/aai/page/href) jelenleg nem használ dinamikus metaadatokat.
A Shibboleth SP és IdP lehetővé teszi, hogy egy pédány több providerId-vel rendelkezzen, például akkor, ha több föderációban is részt vesz. SP-k esetében lehetőség van arra, hogy bizonyos alkalmazások külön providerId alatt látszódjanak, még akkor is, ha egyetlen környezetben (webszerveren) futnak. Ennek az a jelentősége, hogy így az IdP más és más szabályok szerint tudja kiadni az attribútumokat.
HREF_Key_Rollover_2020
Bevezetés
A HREF új metaadat aláírókulcsra áll át a SAML 2.0 metaadataiban (HREF-2020). A HREF szövetségi tagoknak és partnernek az új aláírókulcshoz tartozó konfigurációkat 2022. január 1.-ig frissíteniük kell az összes eduID.hu-t támogató rendszerükben. Ezt követően a régi - több, mint 6 éves aláírókulcs (HREF-2011) - leállításra kerül, és az utolsó aláírástól számított 10. napon a régi metaadat érvénytelen lesz.
Az alábbi táblázatok az átálláshoz szükséges összes adatot tartalmazzák. A konfigurációs példák, olyan megoldásokat kínálnak (ahol ez lehetséges), amelyekkel egyszerre lehet használni a régi és az új metaadatot.
Key Rollover
Elnevezések
Elnevezés | Metaadat aláíró tanúsítvány | Kivezetés tervezett időpontja |
---|---|---|
HREF-2011 | href-metadata-signer-2011.crt | 2022.01.01. |
HREF-2015 | mdx-test-signer-2015.crt | 2022.01.01. |
HREF-2020 | href-metadata-signer-2020.crt | 2025.06.14. |
SHA1 fingerprints
Elnevezés | SHA1 fingerprint |
---|---|
HREF-2011 | FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66 |
HREF-2015 | 91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43 |
HREF-2020 | C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61 |
Domain név változások
Domain | Technikai domain | Kulcs | Állapot |
---|---|---|---|
metadata.eduid.hu | metadata.eduid.hu/2011/href.xml |
HREF-2011 | Prod |
metadata.eduid.hu | metadata.eduid.hu/2020/href.xml |
HREF-2020 | Prod |
mdx.eduid.hu | mdx-2015.eduid.hu |
HREF-2015 | Prod |
mdx.eduid.hu | mdx-2020.eduid.hu |
HREF-2020 | Prod |
Shibboleth Service Provider beállítások
https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider
XML
https://wiki.shibboleth.net/confluence/display/SP3/XMLMetadataProvider
<MetadataProvider type="Chaining">
<MetadataProvider type="XML" id="href-2011" url="https://metadata.eduid.hu/2011/href.xml" backingFilePath="href-2011.xml">
<MetadataFilter type="Signature" certificate="href-metadata-signer-2011.crt"/>
<MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
<MetadataProvider type="XML" id="href-2020" url="https://metadata.eduid.hu/2020/href.xml" backingFilePath="href-2020.xml">
<MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
<MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
</MetadataProvider>
MDX
Shibboleth 3.X
https://wiki.shibboleth.net/confluence/display/SP3/MDQMetadataProvider
<MetadataProvider type="MDQ" id="href-2015" ignoreTransport="true" baseUrl="https://mdx-2015.eduid.hu/">
<MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
<MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
<MetadataProvider type="MDQ" id="href-2020" ignoreTransport="true" baseUrl="https://mdx-2020.eduid.hu/">
<MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
<MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
Shibboleth 2.X
<MetadataProvider type="Dynamic" id="href-2015" ignoreTransport="true">
<Subst>https://mdx-2015.eduid.hu/entities/$entityID</Subst>
<MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
</MetadataProvider>
<MetadataProvider type="Dynamic" id="href-2020" ignoreTransport="true">
<Subst>https://mdx-2020.eduid.hu/entities/$entityID</Subst>
<MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
</MetadataProvider>
Shibboleth Identity Provider beállítások
XML
Shibboleth 4.X
https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider
<MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
backingFile="%{idp.home}/metadata/href-2020.xml"
metadataURL="https://metadata.eduid.hu/2020/href.xml">
<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
<MetadataFilter xsi:type="EntityRoleWhiteList">
<RetainedRole>md:SPSSODescriptor</RetainedRole>
</MetadataFilter>
</MetadataProvider>
Shibboleth 3.X
https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider
<MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
backingFile="%{idp.home}/metadata/href-2020.xml"
metadataURL="https://metadata.eduid.hu/2020/href.xml">
<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
<MetadataFilter xsi:type="EntityRoleWhiteList">
<RetainedRole>md:SPSSODescriptor</RetainedRole>
</MetadataFilter>
</MetadataProvider>
MDX
Shibboleth 4.X
https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider
<MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
connectionRequestTimeout="PT2S"
connectionTimeout="PT2S"
socketTimeout="PT4S">
<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
<MetadataQueryProtocol>https://mdx-2020.eduid.hu/</MetadataQueryProtocol>
</MetadataProvider>
Shibboleth 3.X
https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider
<MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
connectionRequestTimeout="PT2S"
connectionTimeout="PT2S"
socketTimeout="PT4S">
<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
<MetadataQueryProtocol>https://mdx-2020.eduid.hu/</MetadataQueryProtocol>
</MetadataProvider>
SimpleSAMLphp
MDX
//config/config.php
'metadata.sources' => [[=> 'flatfile']('type'), // ez a *-hosted metadata konfiguráció betöltése miatt szükséges
[
'type' => 'mdq',
'server' => 'https://mdx-2020.eduid.hu',
/* --- */
'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61'
],
],
metarefresh
https://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_3
// config/config-metarefresh.php
$config = [
'sets' => [
'href-2011' => [
'cron' => ['hourly'],
'sources' => [
[
'src' => 'https://metadata.eduid.hu/2011/href.xml',
'validateFingerprint' => 'FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66',
],
],
'expireAfter' => 777600, // 9 nap
'outputDir' => 'metadata/metarefresh-href-2011/',
'outputFormat' => 'flatfile',
],
'href-2020' => [
'cron' => ['hourly'],
'sources' => [
[
'src' => 'https://metadata.eduid.hu/2020/href.xml',
'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61',
],
],
'expireAfter' => 777600, // 9 nap.
'outputDir' => 'metadata/metarefresh-href-2020/',
'outputFormat' => 'flatfile',
],
],
];
// config/config.php
'metadata.sources' => [
['type' => 'flatfile'],
['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2011'],
['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2020'],
],
FAQ /GYIK
Bővítés alatt!
- Miért cserél KIFÜ kulcsot?
- IdP-t érinti?
- Mi a helyzet az eduGAIN-t használó IdP-kkel?
- Mi a helyzet az eduGAIN-t használó SP-kkel?
- Hogyan tudom ellenőrízni, hogy jó kulcsot használok?
Shib2IdpAuth
Autentikáció nativan, Shib2Idp-ből
LDAP-alapon
Szerkesszük a ${SHIB_HOME}/conf/login.config
-ot:
ShibUserPassAuth {
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="ldap.example.com"
base="ou=people,dc=example,dc=com"
ssl="false"
serviceUser="userid=example-system,ou=systems,dc=example,dc=com"
serviceCredential="password"
userField="uid";
}
A serviceUser és a serviceCredential kihagyható, ekkor anonymous bind történik (azonban ilyen esetben a helytelen név / jelszó megadása LDAP Exception-t okoz és nem a jól értelmezhető hibás név / jelszó üzenetet adja a felhasználónak)
Ezután be kell állítani, hogy ezt a bekonfigurált autentikációt használja a Shibboleth (${SHIB_HOME}/conf/handlers.xml)
<LoginHandler xsi:type="UsernamePassword"
authenticationDuration="240"
jaasConfigurationLocation="file://${SHIB_HOME}/conf/login.config">
<AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthenticationMethod>
</LoginHandler>
<!-- SSO-hoz kell hogy az előző session-t át tudja venni -->
<LoginHandler xsi:type="PreviousSession">
<AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</AuthenticationMethod>
</LoginHandler>
Az authenticationDuration paraméter elhagyása esetén az IdP 30 perc érvényességgel állítja ki a munkamenetet (<AuthnStatement SessionNotOnOrAfter="...">
), tehát akár aktív tevékenység esetén is 30 perc múlva lejár a felhasználó session-je. Ezt érdemes tehát átállítani magasabb értékre.
A FORM-ot az idp.war -ban tudjuk testreszabni (login.jsp). A szállított login.jsp által beállított FORM tag és INPUT tag-ek tartalmát ne módosítsuk!
Ha a bejelentkezés nem sikerül jó felhasználónév/jelszó párral sem, a logging.xml
szerkesztésével tudjuk megjeleníteni a debug üzeneteket (a edu.vt.middleware.ldap
loggert kell átkonfigurálni).
Kerberos alapon
!!! warning "A szócikk vagy fejezet még megírásra vár"
Ha ki tudod egészíteni, megköszönjük!
SQL (JDBC) alapon
A Shibboleth 2 IdP képes az autentikálást szabványos JAAS (Java Authentication and Authorization Service) modulokkal elvégezni, ezért lehetőség van relációs adatbázist használó autentikációs modul használatára is. Számos JAAS modul létezik adatbázisos autentikációra is, azonban ezek vagy túl bonyolultak, vagy nem kellően rugalmasak. Az alábbiakban az NIIF által fejlesztett (a Tagish/JDBC kódbázisán alapuló) modul beállítását mutatjuk be:
- JAAS/JDBC modul megfelelő verziójának letöltése
- jaas-jdbc-VERSION.jar és adatbázis driver jar bemásolása az idp webalkalmazás (idp.war) WEB-INF/lib könyvtárába
- a MySQL Connector/J letölthető a MySQL oldalról
- MySQL esetén a mysql-connector-java-{verzio}-bin.jar fájlra van szükségünk
- handler.xml -ben UsernamePassword login handler engedélyezése és RemoteUser login handler tiltása
- login.config ShibUserPassAuth-ban a JDBCLoginModul engedélyezése (a többi JAAS modul legyen kikommentezve!)
- adatbázis kapcsolattal összefüggő beállítások:
- "hagyományos" megoldás
- dbDriver: JDBC Driver osztály neve
- dbURL, dbUser, dbPassword: adatbázis elérési paraméterek
- JNDI használata esetén
- jndiResourceName: DataSource API-t támogató JNDI név (bővebben lásd: Connection pool leírás)
- "hagyományos" megoldás
- egyéb beállítások
- usersPreparedStatement: egy olyan lekérdezés, ami a tárolt elhashelt jelszót kérdezi le egy felhasználónévhez (a felhasználónév helyén a ? karakter kell álljon, a lekérdezés egy vagy nulla sort kell visszaadjon!)
- passwordHashMethod: a hasheléshez alkalmazott metódus (a használható metódusakat a Java Cryptography Architecture dokumentáció írja le).
A JAAS modul konfigurációja a login.config fájlban:
hu.niif.middleware.jaas.JDBCLoginModule required
dbDriver="com.mysql.jdbc.Driver"
dbURL="jdbc:mysql://databaseHost:3306/databaseName"
dbUser="dbuser"
dbPassword="randomsecret"
usersPreparedStatement="SELECT password FROM users where username=?"
passwordHashMethod="MD5";
LDAP-ból ellenőrzött X.509 tanúsítvánnyal
Ezen autentikációs mód a konténer (pl. Apache) által a klienstől elkért klienstanúsítványt veti össze a felhasználó LDAP bejegyzésében tárolt tanúsítványokkal (userCertificate
). A modul használatának előfeltételei:
- a konténernek támogatnia kell a kliens-tanúsítványokat, azonban a CA ellenőrzés nem követelmény, a felhasználók self-signed tanúsítvánnyal is igénybe vehetik az autentikációs szolgáltatást
- az IdP-nek a kérésből el kell érnie a klienstanúsítványt
- a tanúsítványban szerepelnie kell a felhasználónévnek (mégpedig az
UID
mezőben)
A modul dokumentációja a ezen az oldalon érhető el.
Autentikáció konténer által
MySQL Autentikáció Apache-on keresztül
Az alábbiakban leírt Apache beállítások elsőre nyakatekertnek tűnhetnek, de az Apache 2.2-es sorozatában előforduló - ez idáig érdemben nem javított - bug miatt ez a megoldás működik csak.
Telepíteni kell a MySQL autentikációs Apache modult:
apt-get install libapache2-mod-auth-mysql
Engedélyezni kell a modul használatát
a2enmod auth_mysql
Az Apache adott hosthoz tartozó configjában meg kell adni:
Auth_MySQL_Info <host> <DB_user> <DB_password>
Ugyanitt meg kell adni az adott Location-re vonatkozó beállításokat - itt látja majd a webszerver, hogy ha az adott url-re érkezett kérés, akkor MySQL-ből kell autentikálnia az itt megadott paraméterek szerint
<Location /whereTo/Authn/RemoteUser>
AuthType Basic
AuthName "You can login here"
AuthUserFile /dev/null
AuthBasicAuthoritative Off
AuthMySQL on
AuthMySQL_Authoritative off
AuthMySQL_DB VHOtools
AuthMySQL_Password_Table vho_Users
AuthMySQL_Password_Field password
AuthMySQL_Encryption_Types PHP_MD5
require valid-user
</Location>
MySQL Autentikáció TomCat-en keresztül
!!! warning "A szócikk vagy fejezet még megírásra vár"
Ha ki tudod egészíteni, megköszönjük!
LDAP Autentikáció Apache-on keresztül
!!! warning "A szócikk vagy fejezet még megírásra vár"
Ha ki tudod egészíteni, megköszönjük!
Single Sign-on
IdP Session
Az IdP-ben a session-nek nincs rögzített lifetime-ja, hanem aktivitásfüggő timeout értéket lehet beállítani. A jelenlegi IdP-ben az IdP session timeout független a fent megadott authenticationDuration
értéktől, ezt az internal.xml
állományban állíthatjuk be:
<bean id="shibboleth.SessionManager"
class="edu.internet2.middleware.shibboleth.idp.session.impl.SessionManagerImpl"
depends-on="shibboleth.LogbackLogging">
<constructor-arg ref="shibboleth.StorageService" />
<constructor-arg value="<b>28800000</b>" type="long" />
</bean>
A példában a StorageService konstruktorának értéke ezredmásodpercben értendő.
Single Logout
URN_SCHAC
URN schac sémák
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
FastCGI
Amennyiben úgy szeretnék Shibboleth SP-t beüzemelni, hogy biztonsági, vagy bármilyen egyéb megfontolásokból az FastCGI-ként fusson, úgy az alábbiakban leírtak szerint kell(ene) a rendszernek működnie.
FastCGI-ről
CGI (Common Gateway Interface) alkalmazás esetén a program futása a következőképpen néz ki: jön a kérés a kiszolgáló felé, mire az továbbítja a kérést a CGI programnak. Jelen esetben ez a PHP értelmező lesz, ami futtatja a programot, és az eredményt visszaadja a kiszolgálónak, majd ezután eltűnik a memóriából. Egy következő kéréskor ugyanez a folyamat ismétlődik, amiből egyből láthatjuk, hogy ez a módszer nem túl hatékony, a PHP értelmezőt állandóan be kell tölteni, majd ki kell pakolni a memóriából.
A FastCGI ezt a be/ki töltögetést küszöböli ki: a PHP értelmező bent marad a memóriában addig, amíg szükség van rá. Sőt, egyszerre több értelmezőt is a memóriában tart, így egyszerre több kérést is ki tud szolgálni a szerver.
A CGI program külön szálként fut a kiszolgálón, elkülönítve tőle, és a többi hasonló száltól. Ha az egyik kedves felhasználó programja megöli a CGI értelmezőjét, akkor sincs semmi gond, az meghal, de a többi attól még vígan dolgozik, és szolgálja ki a lapokat.
Forrás: Weblabor
Lighttpd, mint webszerver
!!! warning FIGYELEM!
Az alább leírt módszer csak elviekben működik, a gyakorlatban - a szükséges patchelés ellenére sem - sikerült működésre bírni. A hiba oka [egy **lighttpd bug**](http://redmine.lighttpd.net/issues/show/322), melyről a fejlesztők is tudnak, ám kijavítása nem szerepel a napirenden, mivel hivatalosan a patch megjavítja, ám a gyakorlat ezt cáfolja. Az érthetőség kedvéért hibajelenség pontos leírása a telepítési folyamat leírása után található.
Lighttpd
A figyelmeztetésben is emlegetett, és az alább részletezett patch-elés miatt nem a legfrissebb, hanem az 1.4.15-ös lighttpd-t használjuk.
Beszerzés
wget http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz tar -xf http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz
A szükséges patch letöltése
wget http://redmine.lighttpd.net/attachments/download/91/fastcgi-authorizer-fixes.diff
Patchelés (a letöltött lighthttpd kitömörített könyvtárában vagyunk):
patch -p0 < fastcgi-authorizer-fixes.diff
Majd a patchelés kiegészítéseként be kell szúrnunk egy sort a src/mod_fastcgi.c
fájlba.
con->http_status == 0)) {
/*
* If we are here in AUTHORIZER mode then a request for autorizer
* was proceeded already, and status 200 has been returned. We need
* now to handle autorized request.
*/
+++ con->http_status = 0;
if ( ! buffer_is_empty(host->docroot) ) {
/*
* Serve local file if they specified
* a docroot
*/
Fordítás és telepítés (configure
paraméterei természetesen tovább finomíthatók)
./configure --libdir=/usr/lib/lighttpd --with-openssl --with-openssl-libs=/usr/lib
make
make install
Telepítés utáni beállítás:
vim /etc/lighttpd/lighttpd.conf
server.modules szekcióba be kell írni
"mod_fastcgi",
majd ugyanebben a fájlban meg kell adni az alapvető beállításokat mind a 80-as, mind a 443-as portra vonatkozólag
server.name = "sp2.example.org"
server.document-root = "/var/www/"
$SERVER["socket"] == "10.0.0.8:443" { // a host ip-címe
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/certs/lighttpd.pem" // ahol a domain-re vonatkozó tanusítványunk található
}
Shibboleth
Beszerzés
dget http://ftp.de.debian.org/debian/pool/main/s/shibboleth-sp2/shibboleth-sp2_2.0.dfsg1-4.dsc dpkg-source -x *.dsc
Fordítás előtti hangolás
vim debian/rules
Be kell szúrni a ./configure paramétereit meghatározó sorba:
--with-fastcgi=/usr/sbin/lighttpd (a lighttpd elérési útja)
Shibboleth + Lighttpd
Még két beállítást kell eszközölnünk, hogy a webszerver tudja, hogy shibbolethes hívások esetén mi a teendő. Először is a FastCGI beállításokat betöltetjük a lighttpd-vel (ez shibboleth-től függetlenül is kellhet, pl. php futtatása esetén). Egy egyszerű szimbolikus linket készítünk a mods-available könyvtár vonatkozó fájljáról a mods-enabled -be. A második, hogy ezt a fájlt kiegészítjük két, shibboleth specifikus sorral.
"/Shibboleth.sso" => ((
"socket" => "/tmp/fcgi-resp.sock",
"bin-path" => "/usr/lib/shibboleth/shibresponder",
"check-local" => "disable",
"mode" => "responder"
)),
"/" => ((
"socket" => "/tmp/fcgi-auth.sock",
"bin-path" => "/usr/lib/shibboleth/shibauthorizer",
"check-local" => "disable",
"mode" => "authorizer"
)),
Ezek után - s az itt nem részletezett Shibboleth SP beállítás után - a rendszernek további beállítások nélkül működnie kellene. Ám kizárólag statikus tartalmat tud rendeltetésszerűen kiszolgálni, dinamikusat nem.
A HIBAJELENSÉG
Amennyiben használni akarunk "authorizer" modult (a shibbolethnél ez ugye kell, a másik modul, a "responder" típusú mellett), akkor ehhez a fastcgi beállításoknál meg kell adni egy gyökér pontot, amelyhez viszonyítva az összes vele egy szinten lévő, ill. alatta lévő hivatkozás esetén lefut az authorizer, és megmondja, hogy jogosult, tehát mehet tovább, vagy sem. Ez a gyökérpont a shibbolethes beállításoknál a "/" kell, hogy legyen, tehát minden esetben átfut az authorizer-en egy-egy kérés. Ez nem is lenne rossz, de a bug miatt, amennyiben a fastcgi beállításoknál az authorizer megadása után bármilyen (pl. php) respondert beállítunk, akkor az az authorizer által lefedett környezetben (esetünkben a "/" miatt mindenhol) a webszerver 403 hibát dob.
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://
vagyhttps://
- 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!
Föderációs_modellek
ShibAndEdugain
Loading metadata
Metadata downloaded from https://mds.edugain.org
Strange things
- Metadata is not signed by a third party
- Line breaks and indentation is quite by chance, however running through
xml_pp
of course invalidates the signature of the individual<EntityDescriptor>
s - Metadata cannot be validated to the schema (see later)
Problems loading metadata to Shibboleth SP
For perl processing, MDS output is run through xml_pp
, an XML pretty-printer.
Here is the command I use to load MDS output to a Shibboleth 2.0 SP:
wget -O- --ca-certificate=/home/bajnokk/edugain_bundle.crt https://mds.edugain.org |xml_pp \
| perl -pe 's/(<(md:)?EntitiesDescriptor)/\1 xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/; s/.*RoleDescriptor.*//g; s/.*OnlineCA.*//g; \
s/cacheDuration[>](^)*//g; ' >/tmp/mds-pp.xml
Explanation follows:
Unable to connect
For some reason, Shibboleth 2.0 cannot connect to https://mds.edugain.org. It seems to be a libcurl
issue, which is not easy to circumvent. (See this shib-users thread) Newer cURL's can handle the SSL handshake (the ones in Ubuntu Intrepid and Debian Lenny can not). So it's necessary to wget
the metadata.
It turned out that newer versions of Shibboleth can connect to mds.edugain.org, however the following errors prevent the metadata from being loaded directly.
No default namespace
There is no default namespace for the outer EntitiesDescriptor
, the root element. No problem with that, but there is at least one EntityDescriptor
, which is not correctly namespaced (and assumes that the default namespace is urn:oasis:names:tc:SAML:2.0:metadata
)
Solution:
| perl -pe 's/(<(md:)?EntitiesDescriptor)/\1 xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/;'
Invalid use of RoleDescriptor
SAML Metadata Schema declares that RoleDescriptor is an abstract element, whatever it means. Shibboleth (2.0) cannot load an entity with such an element.
Solution: | perl -pe 's/.RoleDescriptor.//g;' At the time of writing, it only affects Fresco-AAI. For some unknown reason, Fresco-AAI metadata is a one-liner (even after pretty printing), so it's possible to remove it such a way. If it wasn't the case, proper XSLT would be necessary.
Invalid extension of the schema
GIdP entity contains an egmd:OnlineCADescriptor
element, which is not a standard extension of the SAML schema.
Solution:
| perl -pe 's/.*OnlineCA.*//g;'
At the time of writing, it only affects GIdP. For some unknown reason, GIdP metadata is a one-liner (even after pretty printing), so it's possible to remove it such a way. If it wasn't the case, proper XSLT would be necessary.
ShibIdPAttrib
- REDIRECT Attribútum feloldás
Shib2PersistentId
Perzisztens azonosító használata Shibboleth2 IdP esetén
Ez az oldal a Shibboleth storedId
plugin telepítését írja le MySQL adatbázis motorral.
Adatbázis driver telepítése
A MySQL JDBC driver a következő URL-ről érhető el: http://dev.mysql.com/downloads/#connector-j. Letöltés után a kitömörített drivercsomagból a .jar végű fájlt kell bemásolni a /usr/share/tomcat6/lib
könyvtár alá.
Táblaszerkezet
CREATE TABLE `shibpid` (
`localEntity` varchar(200) NOT NULL,
`peerEntity` varchar(200) NOT NULL,
`principalName` varchar(200) NOT NULL,
`localId` varchar(200) NOT NULL,
`persistentId` varchar(200) NOT NULL,
`peerProvidedId` varchar(200) default NULL,
`creationDate` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`deactivationDate` timestamp NULL default NULL,
KEY `i_shibpid_pid` (`persistentId`),
KEY `i_shibpid_pid_date` (`persistentId`,`deactivationDate`),
KEY `i_shibpid_lid` (`localEntity`,`peerEntity`,`localId`),
KEY `i_shibpid_lid_date` (`localEntity`,`peerEntity`,`localId`,`deactivationDate`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
Perzisztens attribútum feloldása
Az attribute-resolver.xml konfigurációs fájlban vegyük fel a következő DataConnectort illetve PrincipalConnectort:
<resolver:DataConnector xsi:type="StoredId"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="persistentIdConnector"
sourceAttributeID="uid"
generatedAttributeID="persistentId"
salt="valami-random-sztring">
<resolver:Dependency ref="myLDAP" />
<ApplicationManagedConnection jdbcDriver="com.mysql.jdbc.Driver"
jdbcURL="jdbc:mysql://localhost/installfest"
jdbcUserName="root"
jdbcPassword="" />
</resolver:DataConnector>
<resolver:PrincipalConnector xsi:type="StoredId"
xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="saml2Persistent"
nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
storedIdDataConnectorRef="persistentIdConnector" />
Amennyiben alkalmazásszerver oldali kapcsolatkezelést szeretnénk használni, a következő leírás hasznos lehet.
Definiáljuk a persistentId attribútumot (a transientId ELŐTT! - különben a transientId -t választja ki az idp...):
<resolver:AttributeDefinition id="persistentId" xsi:type="Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad">
<resolver:Dependency ref="persistentIdConnector" />
<resolver:AttributeEncoder xsi:type="SAML2StringNameID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
</resolver:AttributeDefinition>
Perzisztens attribútum kódolása a SAML válaszba
Az attribute_filter.xml -ben meg kell adni hogy a frissen létrehozott persistentId attribútumot kiadja az SP-nek:
<AttributeFilterPolicy id="releaseNameIDToAnyone">
<PolicyRequirementRule xsi:type="basic:ANY" />
<AttributeRule attributeID="transientId">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
<AttributeRule attributeID="persistentId">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
</AttributeFilterPolicy>
AAI_és_Shibboleth__2007.11.07_
Elhangzott a 2007-es HBONE Workshopon
Letöltés
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).
Shib3IdpInstall
Az alábbiakban a Shibboleth 3 Identity Provider telepítése olvasható egyszerű beállítással.
A telepítés Debian 8 (Jessie) operációs rendszerre történik Jetty 9.2 alkalmazáskonténerbe.
Előkészületek
Telepítés előtt praktikus előkészíteni az Shibboleth 3 Identity Provider (IdP) környezetét. Az IdP központi szerepet tölt be, így elérhetősége szerencsés esetben ritkán változik.
entityID
(URI)- z entityID az a SAML azonosító, mely egyedi névvel látja el az IdP-t. Az első lépések egyike telepítéskor a megfelelő és gondos kiválasztása. Föderáción belül és világszinten egyedi kell legyen az ütközések elkerülése érdekében.
- avasolt forma:
https://idp.intezmenyneve.hu/idp/shibboleth
. - gépnév rész legyen bejegyzett DNS név.
- e tartalmazzon portszámot, lekérdezést, részazonosítót.
DNS
- Az entityID megtalálása után szükséges az IdP nevének DNS-be jegyzése.
- avasolt forma:
idp.intezmenyneve.hu
.
!!! warning
Az entityID a szolgáltatás neve, nem a kiszolgáló számítógépé. Érdemes a neveket úgy megválasztani, hogy egy későbbi gépcsere esetén is független legyen a gépnév a szolgáltatás nevétől.
Tűzfal
- Szükséges nyitott portok a TCP/443 és TCP/8443.
Operációs rendszer és Java futtató-környezet
- A jelen telepítési leírás Debian 8 (Jessie) rendszerhez készült.
- Java telepítése
apt-get install default-jdk
Jetty 9.2 telepítés és előkészítés
Letöltés: http://download.eclipse.org/jetty/
Telepítés menete.
cd /opt
tar -xf jetty-distribution-9.2.<legutóbbi stabil verzió>.tar.gz
Jetty előkészítése Shibboleth 3 IdP számára.
cd /opt
mkdir jetty-shibboleth-idp
cd jetty-shibboleth-idp
mkdir etc modules lib logs resources webapps tmp
cd /opt/jetty-distribution-9.<legutóbbi stabil verzió>
cp etc/jetty-ssl.xml /opt/jetty-shibboleth-idp/etc/
cp etc/jetty-https.xml /opt/jetty-shibboleth-idp/etc/
cp etc/keystore /opt/jetty-shibboleth-idp/etc/
cp etc/keystore.pkf /opt/jetty-shibboleth-idp/etc/
cp modules/https.mod /opt/jetty-shibboleth-idp/modules/
cp modules/ssl.mod /opt/jetty-shibboleth-idp/modules/
Hozzuk létre a Jetty start.ini
állományt az alábbi tartalommal az /opt/jetty-shibboleth-idp/start.ini
helyen.
# Required Jetty modules
--module=server
--module=deploy
--module=annotations
--module=resources
--module=logging
--module=requestlog
--module=https
--module=ssl
--module=servlets
--module=jsp
--module=jstl
--module=ext
--module=plus
# Allows setting Java system properties (-Dname=value)
# and JVM flags (-X, -XX) in this file
# NOTE: spawns child Java process
--exec
-Didp.home=/opt/shibboleth-idp
-Djava.io.tmpdir=tmp
# Maximum amount of memory that Jetty may use, at least 512M is recommended
-Xmx512m
# Maximum amount of memory allowed for the JVM permanent generation
-XX:MaxPermSize=128m
Webapp XML állomány létrehozása az IDP-hez az /opt/jetty-shibboleth/webapps/idp.xml
helyen az alábbi tartalommal.
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<Set name="war"><SystemProperty name="idp.home"/>/war/idp.war</Set>
<Set name="contextPath">/idp</Set>
<Set name="extractWAR">false</Set>
<Set name="copyWebDir">false</Set>
<Set name="copyWebInf">true</Set>
</Configure>
Shibboleth 3 Identity Provider telepítés Jetty 9.2 konténerbe
Letöltés: http://shibboleth.net/downloads/identity-provider/latest/
cd /opt
wget http://shibboleth.net/downloads/identity-provider/latest/shibboleth-identity-provider-VERSION.tar.gz
tar -xf shibboleth-identity-provider-VERSION.tar.gz
Telepítés
root@idp:~# cd /opt/shibboleth-identity-provider-VERSION
root@idp:/opt/shibboleth-identity-provider-3.1.1# bin/install.sh
Source (Distribution) Directory: [/opt/shibboleth-identity-provider-3.1.1]
Installation Directory: [/opt/shibboleth-idp]
Hostname: [localhost.localdomain]
**idp.intezmenyneve.hu**
SAML EntityID: https://idp.intezmenyneve.hu/idp/shibboleth
Attribute Scope: [localdomain]
**intezmenyneve.hu**
TLS Private Key Password: ********
Re-enter password: ********
Cookie Encryption Key Password: ********
Re-enter password: ********
Warning: /opt/shibboleth-idp/bin does not exist.
Warning: /opt/shibboleth-idp/dist does not exist.
Warning: /opt/shibboleth-idp/doc does not exist.
Warning: /opt/shibboleth-idp/system does not exist.
Warning: /opt/shibboleth-idp/webapp does not exist.
Generating Signing Key, CN = idp.intezmenyneve.hu URI = https://idp.intezmenyneve.hu/idp/shibboleth ...
...done
Creating Encryption Key, CN = idp.intezmenyneve.hu URI = https://idp.intezmenyneve.hu/idp/shibboleth ...
...done
Creating TLS keystore, CN = idp.intezmenyneve.hu URI = https://idp.intezmenyneve.hu/idp/shibboleth ...
...done
Creating cookie encryption key files...
...done
Rebuilding /opt/shibboleth-idp/war/idp.war ...
...done
BUILD SUCCESSFUL
Total time: 1 minute 21 seconds
root@idp:/opt/shibboleth-identity-provider-3.1.1#
Az IdP indítása
cd /opt/jetty-shibboleth-idp
java -jar /opt/jetty-distribution-9.2.<legutóbbi stabil verzió>/start.jar
Böngészőben a https://idp.intezmenyneve.hu:8443/idp URL-en rövid tájékoztatást kell kapnunk No services are available at this location. szöveggel.
HREFChecklist
Előzetes ellenőrzés
Az alábbi listán haladunk végig egy-egy csatlakozási kérelem beérkeztekor, és ennek eredményének figyelembe vételével hozza meg a Tagok Tanácsa a döntést a felvételről.
-
Adatkezelés
- Van-e adatkezelési szabályzat?
- A felhasználókról szóló, intézmény által ismert adatok forrása, karbantartásának módja dokumentált-e? (TAG)
- Elérhetők-e a fenti dokumentumok? A hivatkozásnak a metadata állományban kell szerepelnie.
- Ezek megfelelnek-e a Föderációs alapelvek-ben foglaltaknak?
-
Műszaki követelmények
- Az intézmény teljesíti-e a Műszaki előírásokat leírtakat? ( Műszaki előírások IdP-k számára, Műszaki előírások SP-k számára)
- Van-e kijelölt ember, aki a föderációs ügyekért felelős, technikailag be tud avatkozni (be tud-e lépni a Resource Registry-be és a saját IdP-jét adminisztrálni is tudja)?
- Van-e jól beállított naplózási mechanizmus?
- Megfelelőek-e az entitás által használt kulcsok?
- Megfelelőek-e az entitás által támogatott SAML-profilok?
- Az attribútumspecifikációnak megfelelő-e az attribútumok használata?
- Ajánlásoktól eltéréseket dokumentálni
-
Egyéb
- Hány felhasználót tud az IdP azonosítani?
- Elvárt, hogy az entitás technikai kapcsolattartója iratkozzon fel a href-tech levelezőlistára, az entitás adminisztratív kapcsolattartója pedig a href-admin levelezőlistára.
Shibenv
Az alábbi test scriptek a Leuveni Egyetem Shibboleth oldaláról valók. (http://shib.kuleuven.be/download/sp/test_scripts/)
- PHP implementáció
- JSP (Java Server Pages) implementáció
- Lazy Session-t használó PHP implementáció (saját kiterjesztés)
SimpleSAMLphp
Az alábbi lapon megkíséreljük összefoglalni a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő SimpleSAMLphp (SSP) alkalmazást állítsunk üzembe.
Telepítés
A leírás a forrásból történő telepítés lépéseit írja le. Az itt részletezetten kívül a SimpleSAMLphp telepíthető Debian (vagy más) operációs rendszer csomagjából, de ebben az esetben ne telepítsunk composerrel third-party (pl. általunk készített) modulokat!
Előkészületek
Ahhoz, hogy problémamentesen telepíthessük SSP alkalmazásunkat, az alábbi szoftverkomponenseknek kell működniük szerverünkön.
- PHP futtatására alkalmas webszerver
- PHP környezet (>=5.4)
- A következő PHP kiterjesztéseket engedélyezni kell
date
,dom
,hash
,libxml
,openssl
,pcre
,SPL
,zlib
- LDAP-ból történő autentikáció esetén:
ldap
- Adatbázisból történő autentikáció esetén a megfelelő adatbázis-csatolót
mysql
,pgsql
- RADIUS szerveren keresztül történő autentikáció esetén:
radius
- Assertion-ök titkosítása esetén:
mcrypt
- Memcache használata esetén:
memcache
- HEXAA integrációhoz (SP):
soap
Debian 9 / Ubuntu 16.04 LTS csomagok
sudo apt install php php-dom mcrypt php-xml php-mbstring
RHEL / CentOS 7 csomagok
A php-mcrypt csomaghoz engedélyezni kell az "epel-release"-t.
sudo yum install epel-release
sudo yum update
sudo yum install php php-dom php-mcrypt php-xml php-mbstring php-common mod_ssl
Composer
A composer PHP csomagkezelőt is telepíteni kell (akár forrásból, akár csomagból), hogy telepíteni lehessen a SimpleSAMLphp futásához szükséges PHP library-ket.
Letöltés
A GitHubról történő telepítés előnye, hogy a simplesamlphp könnyen frissíthető marad, csak a third party modulokat kell újratelepíteni. Az utolsó stabil verzió számát a https://simplesamlphp.org/download oldalról tudhatjuk meg.
cd /var
git clone [https://github.com/simplesamlphp/simplesamlphp.git](https://github.com/simplesamlphp/simplesamlphp.git)
cd simplesamlphp
git checkout tags/v1.16.2 -b v1.16.2
composer install --no-dev
Apache konfigurálás
A webről csak a /var/simplesamlphp/www
könyvtárat kell elérni. Tilos a teljes simplesamlphp könyvtárat a DocumentRoot alá tenni!
Alias /simplesaml /var/simplesamlphp/www
<Directory /var/simplesamlphp/www>
Require all granted
</Directory>
Alapbeállítások
Konfigurációs fájlok másolása
Mielőtt aktiváljuk valamelyik főszolgáltatását (IdP,SP...) a telepített alkalmazásnak, néhány beállítást meg kell adnunk a config/config.php
és config/authsources.php
konfigurációs fájlokban.
-
config.php másolása a config-templates mappából cp config-templates/config.php config/
-
authsources.php másolása a config-templates mappából cp config-templates/authsources.php config/
A config.php és authsources.php fájlok másolása utána ellenőrizzük, hogy a SimpleSAMLphp működik-e, a https://example.org/simplesaml oldalon.
Konfigurációs fájlok szerkesztése
Adminisztrációs adatok beállítása
Amennyiben az SimpleSAMLphp kezdőlapja hiba nélkül megjelent, akkor nyissuk meg a config/config.php fájl szerkesztésre és végezzük el az alábbi beállításokat.
-
Az "admin" felhasználó jelszavát, mellyel webes felületen keresztül be tud lépni a települő SSP-be.
'auth.adminpassword' => 'ujjelszotirdide',
-
Titkosítási feladatokhoz szükséges "salt", azaz véletlenszerűen összeálló karaktersorozat
'secretsalt' => 'randombytesinsertedhere',
A karaktersorozat előállításában segíthet az alábbi parancs:
tr -c -d '0123456789abcdefghijklmnopqrstuvwxyz' </dev/urandom | dd bs=32 count=1 2>/dev/null;echo
-
Elérhetőségeket, amely adatok bekerülnek majd a generált metaadatba
'technicalcontact_name' => 'Gipsz Jakab', 'technicalcontact_email' => 'jakab.gipsz@example.org',
-
Nyelv és időzóna adatok
'language.default' => 'hu', 'timezone' => 'Europe/Budapest',
Az alapadatok megadása után mentsük és zárjuk be a config.php-t.
Naplózás beállítása
Alapértelmezetten a SimpleSAMLphp a syslog-ba irányítja a naplózást.
Ha fájlba akarunk naplózni, akkor a megfelelő könyvtárhoz biztosítsunk írás jogot a webszerver felhasználónak, és ne felejtsünk el gondoskodni a naplófájlok rotálásáról!
-
log mappa létrehozása és jogosultság beállítása
sudo mkdir log; sudo chown www-data:adm log; sudo chmod 755 log
-
Naplózási szint beállítása a config/config.php-ban
'debug' => array( 'saml' => true, 'backtraces' => true, 'validatexml' => false, ), 'logging.level' => SimpleSAML\Logger::DEBUG, 'logging.handler' => 'file',
A "SimpleSAML\Logger::DEBUG" a legrészletesebb naplózási beállítás, éles rendszernél nem ajánlott csak hiba keresés esetén.
Tanúsítvány készítése
Nem ajánlott a SimpleSAMLphp-hoz és webszerverhez ugyanazt a tanúsítvány használni!
-
A SimpleSAMLphp alapértelmezetten a tanúsítványt a cert mappában keresi.
mkdir cert
-
Az alábbi paranccsal egy 10 éves self-signed tanúsítvány generálunk a SimpleSMALphp számára.
openssl req -new -newkey rsa:2048 -x509 -days 3652 -nodes -out cert/saml-example-org.crt -keyout cert/saml-example-org.key
A fingerprint az alábbi módon kérdezhető le a legegyszerűbben
openssl x509 -fingerprint -noout -in cert/saml-example-org.crt
Telepítés kész
Amennyiben elkészültünk a fenti lépésekkel, úgy a https://service.example.org/simplesaml/ címen elérjük a telepített SSP-nk webes adminfelületét, ahol megejthetjük a további beállítások nagy részét.
Identity Provider (IdP) beállítás
Alapbeállítások
IdP engedélyezése: a config/config.php fájlban kell a saml20 idp-t "true"-re állítani.
'enable.saml20-idp' => true,
LDAP autentikáció
Meg kell adni, hogy az IdP milyen módon azonosítsa a felhasználót, amennyiben alapértelmezés szerint nem engedélyezett modult szeretnénk használni, úgy a megfelelő modult a modules
könyvtár alatt engedélyezni kell. Az alábbi példában az LDAP alapú azonosítást mutatjuk be, amely külön modult nem igényel, alapértelmezés szerint része a telepített alkalmazásnak.
Javasolt az LDAP-ban egy olyan bejegyzést létrehozni az IdP számára, amely olvasni tudja a felhasználóknak a föderációban használt attribútumait. Az azonosítás alapértelmezett módon a felhasználó nevében történő újra bind-olással történik, így a jelszóhoz nem kell hozzáférést adni.
Ahhoz, hogy megadhassuk az LDAP-hoz tartozó beállításokat, a config/authsources.php
fájlt kell szerkesztenünk. Az alábbi kódrészletet elegendő beszúrni, és az egyes változóknak a helyi LDAP-nak megfelelő adatokat értékül adni.
'example-ldap' => array(
'ldap:LDAP',
/* The hostname of the LDAP server. */
'hostname' => 'ldap.example.org',
/* Whether SSL/TLS should be used when contacting the LDAP server. */
'enable_tls' => FALSE,
/*
* Which attributes should be retrieved from the LDAP server.
* This can be an array of attribute names, or NULL, in which case
* all attributes are fetched.
*/
'attributes' => NULL,
/*
* The pattern which should be used to create the users DN given the username.
* %username% in this pattern will be replaced with the users username.
*
* This option is not used if the search.enable option is set to TRUE.
'dnpattern' => 'uid=%username%,ou=people,dc=example,dc=org',
*/
/*
* As an alternative to specifying a pattern for the users DN, it is possible to
* search for the username in a set of attributes. This is enabled by this option.
*/
'search.enable' => TRUE,
/*
* The DN which will be used as a base for the search.
* This can be a single string, in which case only that DN is searched, or an
* array of strings, in which case they will be searched in the order given.
*/
'search.base' => 'ou=people,dc=example,dc=org',
/*
* The attribute(s) the username should match against.
*
* This is an array with one or more attribute names. Any of the attributes in
* the array may match the value the username.
*/
'search.attributes' => array('uid', 'mail'),
/*
* The username & password the simpleSAMLphp should bind to before searching. If
* this is left as NULL, no bind will be performed before searching.
*/
'search.username' => 'cn=simplesamlphp,dc=example,dc=org',
'search.password' => 'servicepassword',
'priv.read' => TRUE,
// The DN & password the SimpleSAMLphp should bind to before
// retrieving attributes. These options are required if
// 'priv.read' is set to TRUE.
'priv.username' => 'cn=simplesamlphp,dc=example,dc=org',
'priv.password' => 'servicepassword;,
),
Metaadat alapok
A beállítandó IdP alapvető paraméterei a metadata/saml20-idp-hosted.php
fájlban állíthatók. Az alábbi kódrészlet egy minimális, de már működő példát mutat.
$metadata['__DYNAMIC:1__'] = array(
/*
* The hostname for this IdP. This makes it possible to run multiple
* IdPs from the same configuration. '__DEFAULT__' means that this one
* should be used by default.
*/
'host' => '__DEFAULT__',
/*
* The private key and certificate to use when signing responses.
* These are stored in the cert-directory.
*/
'privatekey' => 'saml-example-org.key',
'certificate' => 'saml-example-org.crt',
/*
* The authentication source which should be used to authenticate the
* user. This must match one of the entries in config/authsources.php.
*/
'auth' => 'example-ldap',
);
Megfelelő beállítások után a dinamikusan generált metadata a /saml2/idp/metadata.php
útvonalon érhető el.
Tesztelés
Legegyszerűbben a telepített SSP felületén tudjuk ellenőrizni, hogy a beállított autentikációs forrás működik-e. A felületen az Authentication fül alatt található egy 'Test authentication sources' link, amelyre kattintva látható minden beállított autentikációs forrás is, így a két alapértelmezett, teszt célokat szolgáló alatt a most beállított example-ldap névre hallgatónak is meg kell jelenni. (A közvetlen url erre az oldalra: simplesaml/module.php/core/authenticate.php) Ez utóbbira kattintva a beállított LDAP-ból autentikálva be kell tudnunk jelentkeznünk; siker esetén az LDAP-ból kinyerhető attribútumokat láthatjuk.
Service Provider (SP) beállítás
Alapbeállítások
A telepített alkalmazásunk által kezelt SP-ket a config/authsources.php fájlban tudjuk beállítani. Az entityID, idp, discoURL értékeket most hagyjuk NULL értéken és adjuk hozzá a privatekey / certificate részt.
A SimpleSAMLphp a tanúsítvány fájlokat a korábban létrehozott cert mappában fogja keresni, a fájlokat elég relatív elérési úttal megadni.
'default-sp' => array(
'saml:SP',
// The entity ID of this SP.
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => NULL,
// The entity ID of the IdP this should SP should contact.
// Can be NULL/unset, in which case the user will be shown a list of available IdPs.
'idp' => NULL,
// The URL to the discovery service.
// Can be NULL/unset, in which case a builtin discovery service will be used.
'discoURL' => NULL,
'privatekey' => 'saml-example-org.key',
'certificate' => 'saml-example-org.crt',
),
A fenti beállítások alapján az SP entityID-ja megegyezik a metadata elérési útvonalával (szokásos megoldás SSP-nél), nem adunk meg alapértelmezett idp-t, ezáltal az SSP választási lehetőséget kínál fel számunkra, mikor az SP-re szeretnénk bejelentkezni, ill. most még Discovery Service URL-t sem adunk meg, hanem a beépítettet használjuk. Ez utóbbit majd a HREF-be történő integrációkor meg kell változtatni - lásd lejjebb.
Az SP készen áll arra, hogy összekössük egy IdP-vel (ez jellemzően szintén egy SimpleSAMLphp alkalmazás). Ehhez szükséges, hogy SP oldalon beállítsuk az IdP metadata-t és IdP oldalon is beállítsuk az SP metadata-t.
Metadata
Metadata fájlok
A különböző metadata template fájlok a metadata-templates mappában találhatóak. A nekünk szükséges template fájlt másoljuk át a metadata mappába.
-
SP oldalon lennie kell egy metadata/saml20-idp-remote.php fájlnak. Ez a fájl tartalmazza az IdP eléréséhez szükséges adatokat.
cp metadata-templates/saml20-idp-remote.php metadata
-
IdP oldalon lennie kell egy metadata/saml20-sp-remote.php fájlnak. Ez a fájl tartalmazza az SP eléréséhez szükséges adatokat.
cp metadata-templates/saml20-sp-remote.php metadata
Metadata letöltés
Ezen az oldalon megtaláljuk az SP vagy IdP-re vonatkozó metadata-t, XML és PHP formátumban: https://example.org/simplesaml/module.php/saml/sp/metadata.php/default-sp?output=xhtml
SP metadata beállítás IdP oldalon
A metadata simplesaml kezdőlapon, az alábbi helyen érhető el:
- Magyar nyelv esetén: "Föderáció" fül / "SAML 2.0 SP Metaadatok" pont alatt a "Mutasd a metaadatokat" linkre kattintva juthatunk el a fenti menüponthoz.
- Angol nyelv esetén: "Federation" fül / "SAML 2.0 SP Metadata" pont alatt a "Show metadata" linkre kattintva juthatunk el a fenti menüponthoz.
A "SimpleSAMLphp fájl formátumban - akkor használható, ha a másik oldalon SimpleSAMLphp van" mezőből tegyük a vágólapra az alábbi PHP kódot:
$metadata['https://example.org/simplesaml/module.php/saml/sp/metadata.php/default-sp'] = array (
'SingleLogoutService' =>
array (
0 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp',
),
),
'AssertionConsumerService' =>
array (
0 =>
array (
'index' => 0,
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
),
1 =>
array (
'index' => 1,
'Binding' => 'urn:oasis:names:tc:SAML:1.0:profiles:browser-post',
'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml1-acs.php/default-sp',
),
2 =>
array (
'index' => 2,
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact',
'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
),
3 =>
array (
'index' => 3,
'Binding' => 'urn:oasis:names:tc:SAML:1.0:profiles:artifact-01',
'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml1-acs.php/default-sp/artifact',
),
),
'contacts' =>
array (
0 =>
array (
'emailAddress' => 'admin@example.org',
'contactType' => 'technical',
'givenName' => 'Example Corp. IT Dept.',
),
),
'certData' => 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==',
);
A vágólapra másolt kódot IdP oldalon, a metadata/saml20-sp-remote.php fájl végére illesszük be.
IdP metadata beállítás SP oldalon
A metadata simplesaml kezdőlapon, az alábbi helyen érhető el:
- Magyar nyelv esetén: "Föderáció" fül / "SAML 2.0 IdP Metaadatok" pont alatt a "Mutasd a metaadatokat" linkre kattintva juthatunk el a fenti menüponthoz.
- Angol nyelv esetén: "Federation" fül / "SAML 2.0 IdP Metadata" pont alatt a "Show metadata" linkre kattintva juthatunk el a fenti menüponthoz.
A "SimpleSAMLphp fájl formátumban - akkor használható, ha a másik oldalon SimpleSAMLphp van" mezőből tegyük a vágólapra az alábbi PHP kódot:
$metadata['https://idp.example.org/simplesaml/saml2/idp/metadata.php'] = array (
'metadata-set' => 'saml20-idp-remote',
'entityid' => 'https://idp.example.org/simplesaml/saml2/idp/metadata.php',
'SingleSignOnService' =>
array (
0 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
'Location' => 'https://idp.example.org/simplesaml/saml2/idp/SSOService.php',
),
),
'SingleLogoutService' =>
array (
0 =>
array (
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
'Location' => 'https://idp.example.org/simplesaml/saml2/idp/SingleLogoutService.php',
),
),
'certData' => 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==',
'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
);
A vágólapra másolt kódot SP oldalon, a metadata/saml20-idp-remote.php fájl végére illesszük be.
Tesztelés
A fent elvégzett alapbeállítások után már tudjuk tesztelni a, hogy a felépített IdP - SP kapcsolat működik-e.
SP oldalon nyissuk meg a simplesaml kezdőlapot:
- Magyar nyelv esetén: "Azonosítás (autentikáció)" fül / "Azonosítási (autentikációs) beállítások tesztelése" link / "default-sp" link-re kattintva tudjuk tesztelni az IdP - SP kapcsolatot.
- Angol nyelv esetén: "Authentication" fül / "Test configured authentication sources" link / "default-sp" link-re kattintva tudjuk tesztelni az IdP - SP kapcsolatot.
A legördülő menüben az IdP-nk "nevére" kattintva, be kell tudnunk jelentkezni (az IdP-n keresztül). Ha működik, akkor az IdP visszairányít az SP-re, kiírja az azonosított felhasználó attribútumait.
Az alapvető lépsekkel kész vagyunk, van egy működő SP-nk és egy működő IdP-nk.
HREF-integráció
Metadata beállítása (IdP és SP is)
Javasolt dinamikus metaadatforrást (MDX) használni, opcionálisan kiegészítve statikus állományokkal. Részletes leírás itt: SimpleSAMLMixedMetadata
IdP
Amennyiben van SSP alapú IdP-nk, melyet szeretnénk a föderáció részévé tenni, úgy a teendők a következők.
-
(Az adminisztratív teendőktől itt most eltekintünk, a csatlakozás folyamata itt van leírva)
-
Kell küldeni egy levelet a info@eduid.hu címre, benne néhány mondat mellett az IdP metaadatának URL-jével (https://example.org/simplesamlphp/saml2/idp/metadata.php)
-
Ha minden rendben megy, akkor az IdP bekerül a Resource_Registry-be, ezáltal a föderációs metaadatba is.
-
Az előző pontban leírt módon be kell állítani a központi metadata feldolgozását.
-
Amennyiben a föderációs metaadatban már szerepel a mi IdP-nk is, úgy a föderáció valamelyik, tesztelési célokat szolgáló SP-jénél ki is próbálhatjuk a bejelentkezést.
-
Fontos, hogy a föderációs Discovery Service óránként generálja újra az IdP-k listáját, így ennyi idő mindenképp szükséges, hogy az új IdP megjelenjen itt, az egyes SP-k pedig két óránként töltik újra a metaadatot, így előfordulhat, hogy azonnal nem fog minden működni, de néhány óra alatt várhatóan beindul. :)
-
Tesztelésre használható oldal: https://attributes.eduid.hu
-
Ahhoz, hogy a Resource Registry-be is be tudjunk lépni és az IdP további, a föderációra vonatkozó beállításait meg tudjuk ejteni, ehhez az IdP-nek ki kell adnia az alábbi attribútumokat:
- mail - ez belépés után, manuálisan is beállítható
- eduPersonPrincipalName
schacHomeOrganizationType(az attribútumot hamarosan kivezetjük a kötelező attribútumok közül)- eduPersonScopedAffiliation
Attribútumok kezelése
Beállított IdP-nk alapértelmezés szerint azokat az attribútumokat adja ki, melyeket a metaadat alapján az SP kért (Lásd a metadatában a RequestedAttribute elemeket), és egyúttal alapból meg tudta szerezni a felhasználói adatbázisból, esetünkben az LDAP-ból. Mivel néhány attribútum nem szerepel az LDAP-ban, hanem az IdP-ben kell előállítani, így pár helyen módosítanunk kell az alapértelmezett konfiguráción.
A metadata/saml20-idp-hosted.php
fájlba szerkesszük be az alábbi kódrészlet értelemszerűen módosított változatát. Az 'auth' => 'example-ldap',
sor alatt kezdjük. Fontos, hogy egyúttal a config.php authproc.idp
részét kikommentezzük, nehogy az ottani sorszámokkal megadott default feladatok bekavarjanak.
'AttributeNameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
'userid.attribute' => 'uid', // Itt adjuk meg, hogy mely, az LDAPból származó attribútum alapján fogja az IdP kiszámítani az eduPersonTargetedID-t
'authproc' => array(
10 => array(
'class' => 'core:AttributeMap',
'uid' => 'eduPersonPrincipalName'
//Itt az 'uid' az az attribútum az LDAP-ban, amely a felhasználó azonosítóját tartalmazza, mert ebből képezzük az eduPersonPrincipalName-t.
),
# 20 => array(
# 'class' => 'core:AttributeAdd',
# 'schacHomeOrganizationType' => array('urn:schac:homeOrganizationType:hu:university')
# //Kötelező statikus attribútum az [[HREFAttributeSpec#schacHomeOrganizationType|intézmény jellegének]] megfelelően
# ),
30 => array(
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonPrincipalName',
'pattern' => '/^.*$/',
'replacement' => '${0}@intezmenydomain.hu',
// Itt adjuk hozzá az intézményi scope-ot az eduPersonPrincipalName már meglévő értékéhez
),
40 => array(
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonAffiliation',
'pattern' => '/^.*$/',
'replacement' => '${0}@intezmenydomain.hu',
// Itt adjuk hozzá az intézményi scope-ot az eduPersonAffiliation már meglévő értékéhez
),
50 => array(
'class' => 'core:AttributeMap',
'eduPersonAffiliation' => 'eduPersonScopedAffiliation'
// Az LDAP-ból eduPersonAffiliation-ként érkező attribútumból föderációs elvárásoknak megfelelően eduPersonScopedAffiliationt készítünk
),
60 => array(
'class' => 'core:AttributeAdd',
'eduPersonScopedAffiliation' => array('member@intezmenydomain.hu')
// Az eduPersonScopedAffiliation-ben tesztelés céljából kiadhatjuk member értéket,
// így ha LDAP-ból nem jön érték, akkor is láthatjuk, hogy működik az attribútum kiadás
),
61 => array(
'class' => 'core:TargetedID',
'nameId' => TRUE,
),
// Itt állítjuk be, hogy az IdP előállítson és kiadhasson állandóazonosítóként eduPersonTargetedID-t, ha kérik
70 => array('class' => 'core:AttributeMap',
'name2oid'
// Az LDAP-os attribútum nevekből itt kreálunk szabványos urn:oid formátumúakat
),
80 => 'core:AttributeLimit',
), // .authproc
'simplesaml.nameidattribute' => 'eduPersonPrincipalName',
'attributeencodings' => array(
'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw',
),
'sign.logout' => true
-
További tudnivalók a Resource Registry-ről, ill. a Föderációs attribútum specifikációról.
-
Ha minden rendben ment, akkor a Resource Registry-ben regisztrált IdP-hez tartozó adminisztrációs jogok átkerülnek az IdP technikai gazdájához, s ezzel a folyamat kész is.
SP
Amennyiben IdP-t is beállítottunk, és be is tudunk lépni a Resource Registry-be, úgy nincs más dolgunk, mint az RR-ben új SP-t hozzáadni a föderációhoz, amely a megfelelő átfutási idő után a föderáció minden tagjánál látható is lesz.
Ellenkező esetben (nincs IdP, és nem is tervezünk beállítani), akkor az IdP hozzáadásánál részletezett pontokon kell végig menni a metaadat betöltéséig, s a továbbiakat az említett e-mail címen megbeszélni.
Attribútum scopeok használata
A HREF föderáció IdP-i ún. scopeolt attribútumokat is használnak. Ez a scopeolás azt jelenti, hogy minden egyes IdP csak a saját scopejában ad ki attribútumokat, és a Shibboleth SP-k ezt ellenőrzik is. A scope és az attribútum valódi értéke egy '@' karakterrel kerül elválasztásra (ilyen attribútumok jelenleg: eduPersonScopedAffiliation illetve eduPersonPrincipalName).
A SimpleSAMLphp alapértelmezett telepítése nem szűri a hibásan scopeolt értékeket. Kiegészítő modulként szűrésre használható az NIIF által fejlesztett attributescope modul, ami reményeink szerint rövid távon a hivatalos SimpleSAMLphp kiadás része lehet.
A telepítésről és konfigurációról bővebben itt lehet olvasni: https://github.com/NIIF/simplesamlphp-module-attributescope
- Az
attributescope
modul használata esetén a következőképp kell módosítani aconfig/config.php
fájlt:
authproc.sp = array(
...
// 49 => array('class' => 'core:AttributeMap', 'oid2name'),
50 => array( 'class' => 'attributescope:FilterAttributes'
),
...
),
Figyeljünk arra, hogy mire a modulhoz ér a vezérlés, az attribútumok nevei friendlyName alakúak legyenek (ne pedig oid-ok). A példában erre utal a 49-es sor.
HREFMetadataRegistrationPracticeStatement
Metadata Registration Practice Statement
Federation Name: eduID Federation Operator: NIIFI, Hungary Federation Web Page: http://www.eduid.hu
Date of last change: 20110907
Common Practices
All IdP, SP and RRA [1] administrators connect via https and authenticate via eduID to the Resource Registry, where the original information gets administrated which is later used for generating the federation metadata.
In addition, before the federation operator publishes metadata dedicated for interfederation, an institution has first to declare that its processes are ready for interfederation. Only then the federation operator will be able to declare that their respective entity is also technically ready to participate in interfederation.
Practices on Identity Provider Registration
An IdP registering to the federation needs to be manually approved by the Members' Board. Such approval requires:
- a completed membership service agreement signed by official representative(s) of the newly participating institution
- elements and attributes to be registered must use a domain name of that institution
Subsequent changes to these elements and attributes do not require re-approval by the federation operator. Only, administrators appointed specifically by that institution can modify the IdP specific information.
Practices on Service Provider Registration
Each SP must be manually approved by an RRA Administrator in order to be registered with the federation. RRA Administrators must be from the institution on whose behalf the SP gets registered.
It is the duty of the RRA Administrator to review and approve all the details provided by the SP administrator. In addition, an RRA Administrator can reject changes or further modify details of an SP before approving it.
After approving the details about a new SP, the user who requested to register it becomes its first SP administrator. An SP administrator can transfer the administration right to further users. Only users with administrator rights for a specific SP are able to modify its elements and attributes. Such changes require re-approval by an RRA Administrator.
Additional Rules for Federation Partner Service Providers
A signed Federation Partner Agreement is required before a Federation Partner SP can register with the federation. Federation Partner SPs are always approved by a Federation Operator.
Practices regarding metadata modifications
In eduID, no metadata gets modified because the federation operator generates it on behalf of all entities.
The source for generating metadata is the Resource Registry. The details of a registering entity are entered manually by providing the necessary information. Alternatively, a wizard will parse existing entity metadata to gather as many details as possible in order to facilitate the registration.
The IdP/SP administrator also has to supply non-technical information like descriptions or support contacts. All technical and non-technical information is stored as decomposed items in a database. To generate federation metadata, information from that database gets composed into SAML metadata format.
All entites in the Resource Registry could be in one or more metadata-sets. Beside the federation metadata there are metadata-sets with generated metadata files for each institution and for edugain.
[1] RRA Administrator = Resource Registration Authority Administrator A role assigned to one or more persons to act on behalf of the institution which signed the federation service agreement. An RRA Administrator has to review and approve new and changed SPs belonging to or sponsored by the institution before such an SP gets loaded into federation metadata.
Shib2SPSourceInstall
Függőségek
Fordítás
A Shibboleth fordításához néhány "külső" csomagot is le kell fordítani.
log4shib vs. log4cpp
!!! danger "Figyelem"
Lásd: [log4cpp kontra log4shib](https://help.edu.hu/books/aai/page/log4whatever)
XML-Security C
Ez a csomag igazából része általában a disztribúcióknak, de a Shibboleth 2-nek (és az OpenSAML-nak) >=1.4.0 verzió kell, ami jelenleg még nincs is kiadva (2008.04.24.). Hurrá :(
Örüljünk, a download könyvtárban meg lehet találni az 1.4.0 verziójú .tar.gz-t.
wget http://xml.apache.org/security/dist/c-library/xml-security-c-1.4.0.tar.gz
tar xzf xml-security-c-1.4.0.tar.gz
cd xml-security-c-1.4.0
./configure --prefix=/opt
make
sudo make install
xmltooling
Az xmltooling log4cpp-vel történő lefordításához szükség van erre a patch-re.
patch -p0 <../xmltooling_log4cpp5.patch
./configure --prefix=/opt --with-xmlsec=/opt
make
sudo make install
opensaml
./configure --prefix=/opt --with-xmlsec=/opt --with-xmltooling=/opt
make
sudo make install
Shibboleth SP
./configure --prefix=/opt --with-xmltooling=/opt --with-saml=/opt
make
sudo make install
ShibIdPX509LdapAuthentication
Shibboleth 2.x IdP X.509/LDAP autentikációs modul
Ezen az oldalon az NIIF által fejlesztett X.509 klienstanúsítvány alapú Shibboleth autentikációs modul leírása szerepel.
In English
Motivations
- The use of hardware tokens as authentication source. However, X.509 certificate authentication is not generally considered secure by nature, hardware tokens are designed to be safer than passwords. Local policy can decide whether they accept software tokens or not.
- Give the choice to our SPs. Some SPs can decide if they wanted to force the X.509 authentication (or force password authentication).
PKIful versus PKIless
- If one has built their full-fledged PKI infrastructure, one could use it for client certificate authentication.
- But it is hard to do PKI right, CRLs and/or OCSP are crucial in PKI.
- If only authentication is needed, storing the (self-signed) certificate is enough.
Shibboleth X.509 authentication
- With PKI, you would use simple RemoteUser authentication with container support.
- Without PKI, the container can not authenticate the user, it can only check if the user has the corresponding private key.
- You will also need some custom workflow to validate the presented client certificates. Eg. checking them against the directory attribute 'userCertificate'. This is step is a must to have control over certificate revocation.
X.509 + LDAP certificate authentication (implementation details)
- The web container does client certificate checking, but does not validate. Instead, it handles the certificate to the Shibboleth authentication module which will validate it.
- Shibboleth is configured with RemoteUser login handler pointing to our X.509 authentication servlet.
- The certificate must contain some identification data (eg the X.500 'UID' RDN). Our authentication servlet takes the presented certificate and compares it to the stored certificate(s) for the user. If a matching certificate is found in the directory, then the user is authenticated.
- The certificate authentication is implemented as a standard JAAS module, and can be reused elsewhere.
Combining X.509 and username/password authentication
- When SP does not specifically request authentication methods, the user should have the choice between supported authentication modes. Otherwise, the IdP must conform with the authentication context class the SP sent. The IdP must refuse to authenticate the user with authentication methods unacceptable to the SP. There is a support ticket named SIDP-258 about this flaw in Shibboleth IdP.
- We want to support two authentication methods: username/password (PasswordProtectedTransport) and X.509 authentication.
- Unfortunately this is not enough, we need a default authentication method which offers the choice of these two methods to our users. This can be done by placing a link to the X.509 authentication servlet in login.jsp. However when the SP requests PasswordProtectedTransport, this link must not be visible, so we decided to configure a new UserPassword login handler which maps to the unspecified authentication class and uses this tweaked login.jsp.
- We also want to send the actual authentication method to the SP (instead of saying 'unspecified'), so both login handlers must set their corresponding authentication class in the Shibboleth request. As the internal UsernamePassword login servlet does not do this, we subclassed it.
- Playing with Shibboleth login handlers and authentication contexts revealed that Shibboleth IdP can not properly support default authentication methods, and our hybrid handler with its 'unspecified' authentication method is invoked on every authentication request (because both actual methods it uses override this unspecified method in the request and IdP can not decide whether the unspecified class is requested by the SP or it is simply the default method configured in relying-party.xml). Fixing SIDP-265 with our proposed patch corrected this behavior.
Követelmények
Az X.509/LDAP autentikációs modul a következő követelmények alapján került kifejlesztésre:
- a felhasználók saját maguk által aláírt tanúsítványokat is használhassanak autentikációra
- ne kelljen PKI infrastruktúrát üzemeltetni a klienstanúsítványok használatához
- a tanúsítványok központilag menedzseltek, egyszerűen visszavonhatók legyenek
Ezen követelmények kielégíthetők a címtárban tárolt klienstanúsítványokkal, ugyanis a címtárba csak egy felettes szerv képes beírni a tanúsítványt, ott minden bejelentkezéskor ellenőrzésre is kerül, ezért könnyen visszavonható.
!!! info
A felhasználó tanúsítvány alapú azonosításához (identification) szükséges, hogy a tanúsítvány tartalmazza a felhasználónevet, mégpedig az `UID` (subject) mezőben.
Telepítés
Az autentikációs modul letölthető a http://software.niif.hu oldalról. A Shibboleth2 IdP autentikációs motorjának konfigurációját részetesen a Shibboleth2 User Authentication wikioldal írja le.
Apache beállítása
Amennyiben az alapértelmezett szervlet elérési utat választjuk (/Authn/X509
), a következő opciókat kell megadni az Apache webszerver konfigurációjában:
<Location /idp/Authn/X509>
SSLVerifyClient optional_no_ca #nincs CA ellenorzes
SSLOptions +ExportCertData #tanusitvany exportalasa
</Location>
IdP webalkalmazás beállítása
A letöltött modulban található shibboleth-x509auth-verzio.jar
java osztálykönyvtárat be kell másolni a Shibboleth webalkalmazás WEB-INF/lib
könyvtárába, valamint a WEB-INF/web.xml
fájlban meg kell adni az autentikációs szervlet paramétereit:
<servlet>
<servlet-name>X509LdapAuthHandler</servlet-name>
<servlet-class>hu.niif.middleware.shibboleth.auth.X509LdapLoginServlet</servlet-class>
<init-param>
<param-name>jaasConfigName</param-name>
<param-value>X509LdapAuth</param-value>
</init-param>
<load-on-startup>4</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>X509LdapAuthHandler</servlet-name>
<url-pattern>/Authn/X509</url-pattern>
</servlet-mapping>
!!! info
Az IdP webalkalmazás az `${SHIB_HOME}/war/idp.war` fájlban található, ebben kell elvégezni a módosításokat, majd újratelepíteni az alkalmazást a webkonténerbe.
IdP konfiguráció
Az IdP konfigurációjában két dolgot kell módosítani: a JAAS autentikációs modul login.config
konfigurációját, valamint a handler.xml
-ben az autentikációs módokat.
Az X.509/LDAP JAAS modul beállításához a ${SHIB_HOME}/conf/login.config
fájl tartalmához a következő sorokat adjuk hozzá (az LDAP elérési paramétereket értelem szerint kitöltve; az értékek általában a ShibUserPassAuth
JAAS konfigurációból átmásolhatóak):
X509LdapAuth {
hu.niif.middleware.jaas.X509LdapLoginModule required
host=""
port=""
base=""
ssl=""
userField=""
serviceUser=""
serviceCredential="";
};
!!! info
Figyelni kell arra, hogy az itt megadott `serviceUser` olvasási joggal rendelkezzen a `userCertificate` LDAP attribútumra.
A JAAS modul beállítása után a ${SHIB_HOME}/conf/handler.xml
fájlban meg kell adnunk az új autentikációs modulunkat, a következőképpen:
<LoginHandler xsi:type="RemoteUser" protectedServletPath="/Authn/X509" >
<AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:X509</AuthenticationMethod>
</LoginHandler>
Ha továbbra is alapértelmezetten felhasználónév/jelszó autentikációt szeretnénk használni, akkor a Shibboleth IdP-ben be kell állítani az alapértelmezett hitelesítési módot, a ${SHIB_HOME}/conf/relying_party.xml
fájlban:
...
<DefaultRelyingParty provider="..."
defaultSigningCredentialRef="..."
defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
...
Shibboleth SP beállítása
Az egyes SP-k eldönthetik hogy ők kérik-e az X.509 autentikációt, ezt az authnContextClassRef
SP opcióval lehet jelezni a Shibboleth SP felé.
Ez a kérés azonban nem teljesen megbízható, ezért érdemes az IdP oldalon konfigurálni hogy egy adott SP kérése alapján az X.509 autentikációs módot használjuk (a ${SHIB_HOME}/conf/relying-party.xml
fájlban):
...
<RelyingParty id="x509-protected-sp-entityid"
provider="our-idp-entityid"
defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:X509" />
...
Integráció a felhasználónév / jelszó bejelentkezéssel
A fent leírt telepítési módszer nem biztosítja azt a lehetőséget, hogy egy felhasználó eldönthesse hogy ő jelszóval vagy klienstanúsítvánnyal autentikál. Amennyiben szeretnénk ezt a választási lehetőséget megadni abban az esetben, amikor az SP nem jelez általa preferált autentikációs módot, az alábbi plusz konfiguráció segítségével ezt megtehetjük.
!!! info
A klienstanúsítvány segítségével történő autentikáció **nem feltétlenül biztonságosabb** mint a jelszavas bejelentkezés, ezért jól fontoljuk meg, hogy minden felhasználónak felkínáljuk-e ezt a lehetőséget.
Shibboleth IdP webalkalmazás módosítása
Az X.509/LDAP autentikációs modul tartalmaz egy olyan szervletet, ami képes a felhasználónév/jelszó és az X.509 autentikáció együtt történő futtatására. Első lépésként ezt a szervletet kell beállítani a WEB-INF/web.xml
webalkalmazás konfigurációban:
<servlet>
<servlet-name>UsernamePasswordX509LoginServlet</servlet-name>
<servlet-class>hu.niif.middleware.shibboleth.auth.UsernamePasswordX509LoginServlet</servlet-class>
<init-param>
<param-name>loginPage</param-name>
<param-value>login_.jsp</param-value>
</init-param>
<load-on-startup>4</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>UsernamePasswordX509LoginServlet</servlet-name>
<url-pattern>/Authn/UserPasswordX509</url-pattern>
</servlet-mapping>
Ez a konfiguráció hivatkozik a login_.jsp
fájlra, ez egy módosított Shibboleth bejelentkeztető form, amiben két plusz gomb kapott helyet. Ezekkel a gombokkal a felhasználó kérheti, hogy erre az egy autentikációra szeretne klienstanúsítványt használni, vagy a munkamenetben mindig. Utóbbi esetben a bejelentkezést lekezelő szervlet létrehoz egy cookie-t a felhasználó gépén, ami ezt a preferenciát megőrzi a böngésző bezárásáig.
!!! info
Amennyiben a felhasználó egyszer bejelölte a tanúsítványos autentikációt a teljes munkamenetre, azt nem tudja kikapcsolni, csak a böngésző újraindításával.
Shibboleth IdP konfiguráció
Az IdP konfigurációjában meg kell adni ezt a hibrid autentikációs módot, mégpedig a következőképpen (${SHIB_HOME}/conf/handler.xml
):
<LoginHandler xsi:type="UsernamePassword"
authenticationDuration="240"
jaasConfigurationLocation="file://PATH/TO/IDP/conf/login.config"
authenticationServletURL="/Authn/UserPasswordX509">
<AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</AuthenticationMethod>
</LoginHandler>
Ez a konfigurációs részlet azt közli az IdP-vel, hogy az autentikációs modul nem specifikált autentikációs mód esetén működik. Ezt a módot alapértelmezetté tehetjük a ${SHIB_HOME}/conf/relying_party.xml
fájlban:
...
<DefaultRelyingParty provider="..."
defaultSigningCredentialRef="..."
defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified">
...
Shib2IdpSUSE
Shibboleth 2 IdP függőségeinek beállítása OpenSUSE alatt
Debian telepítési útmutató: Shib2IdpInstall, ezen az oldalon az OpenSUSE alatt történő azon beállításokat részletezzük, amelyek eltérnek a Debianban megszokottól.
Szükséges csomagok
- apache2
- tomcat6
- java-1_6_0-sun
Apache beállítása
chkconfig apache2 on
chkconfig tomcat6 on
#alapbol nincs engedelyezve a proxy_ajp modul
a2enmod proxy proxy_ajp
További információk: Shib2IdpInstall#apache-beállítás
Tomcat6 beállítása
A /etc/tomcat6/tomcat6.conf
fájlban találhatóak meg a környezeti beállítások:
JAVA_OPTS="-Xms256M -Xmx512M -XX:-DisableExplicitGC"
JAVA_ENDORSED_DIRS="/usr/local/shibboleth-idp/endorsed"
CLASSPATH="/usr/share/java/mysql-connector-java.jar"
SECURITY_MANAGER="false"
További információk: Shib2IdpInstall#Tomcat_6
MediaWikiShibboleth
- Shibboleth Authentication Extension: http://www.mediawiki.org/wiki/Extension:Shibboleth_Authentication
- Shibboleth Authentication Plus Extension: http://www.mediawiki.org/wiki/Extension:Shibboleth_Authentication_Plus
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ó
<AttributeResolver xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:mace:shibboleth:resolver:1.0"
xsi:schemaLocation="urn:mace:shibboleth:resolver:1.0 shibboleth-resolver-1.0.xsd">
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonEntitlement">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonAffiliation">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:uid">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonPrincipalName" smartScope="niif.hu">
<AttributeDependency requires="urn:mace:dir:attribute-def:uid"/>
</SimpleAttributeDefinition>
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" smartScope="niif.hu">
<AttributeDependency requires="urn:mace:dir:attribute-def:eduPersonAffiliation"/>
</SimpleAttributeDefinition>
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonOrgDN" >
<DataConnectorDependency requires="staticOrgDN"/>
</SimpleAttributeDefinition>
<JNDIDirectoryDataConnector id="directory">
<Search filter="uid%PRINCIPAL%">
<Controls searchScope="ONELEVEL_SCOPE" returningObjects="false" />
</Search>
<Property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" />
<Property name="java.naming.provider.url"
value="ldap://directory.iif.hu:636/ou=users,o=niifi,on=iif,c=hu" />
<Property name="java.naming.security.protocol" value="ssl" />
<Property name="java.naming.security.principal"
value="uidniif-idp,ou=shib,ou=applications,o=niifi,o=niif,c=hu" />
<Property name="java.naming.security.credentials" value="XXXXXXXX" />
</JNDIDirectoryDataConnector>
<StaticDataConnector id="staticOrgDN">
<Attribute name="eduPersonOrgDN">
<Value>o=niifi,o=niif,c=hu</Value>
</Attribute>
</StaticDataConnector>
</AttributeResolver>
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:
<JNDIDirectoryDataConnector id="directory">
<Search filter="uid=%PRINCIPAL%">
<Controls searchScope="ONELEVEL_SCOPE" returningObjects="false" />
</Search>
<Property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" />
<Property name="java.naming.provider.url"
value="ldap://directory.iif.hu:636/ou=users,o=niifi,o=niif,c=hu" />
<Property name="java.naming.security.protocol" value="ssl" />
<Property name="java.naming.security.principal"
value="uid=niif-idp,ou=shib,ou=applications,o=niifi,o=niif,c=hu" />
<Property name="java.naming.security.credentials" value="XXXXXXXX" />
</JNDIDirectoryDataConnector>
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 tartalmazzajava.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 SSLjava.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.
<JDBCDataConnector id="studentSystem"
dbURL="jdbc:postgresql://test.example.edu/test?user=postgres&password=test"
dbDriver="org.postgresql.Driver"
<Query>select entitlement from foo where name = ?</Query>
</JDBCDataConnector>
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.
<StaticDataConnector id="staticOrgDN">
<Attribute name="eduPersonOrgDN">
<Value>o=niifi,o=niif,c=hu</Value>
</Attribute>
</StaticDataConnector>
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 asmartScope
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. Hatrue
, 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.
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
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:<b>cn</b>
(!) attribútumban küldi el a másik félnek.
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn" sourceName="displayName">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
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
.
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonPrincipalName" smartScope="niif.hu">
<AttributeDependency requires="urn:mace:dir:attribute-def:uid"/>
</SimpleAttributeDefinition>
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
<Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="ttp://www.w3.org/2001/XMLSchema-instance"
AttributeName="urn:mace:dir:attribute-def:eduPersonOrgDN"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<AttributeValue>o=niifi,o=niif,c=hu</AttributeValue>
</Attribute>
<Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
AttributeName="urn:mace:dir:attribute-def:uid"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<AttributeValue>bajnokk</AttributeValue>
</Attribute>
<Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc)"
AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<AttributeValue Scope="niif.hu">bajnokk</AttributeValue>
</Attribute>
Forrás
- https://spaces.internet2.edu/display/SHIB/NewIdPAttribute
- https://spaces.internet2.edu/display/SHIB/IdPAttributeConfig
SimpleSAMLphp_proxy_vidyo_portálhoz
Vidyo Portal Authentication Proxy
A vidyo portál utolsó fejlesztései lehetővé tették a SAML alapú authentikációt, és authorizációt.
Az implementáció nem teljesen fedi le a SAML feature-öket, az SP implementáció csak egy IdP-vel képes kapcsolatot létesíteni.
A portált a simpleSAMLphp proxy-ként való telepítésével tehetjük egy föderáció tagjává.
simpleSAMLphp telepítése
A simplesamlphp telepítését elvégezzük a dokumentáció szerint.
SSP IdP oldalának konfigurálása, illesztés a Vidyo portál felé
Legelőször is engedélyezni kell az IdP funkciót
config/config.php
'enable.saml20-idp' => true,
Gyártsuk le az IdP certificate-jét, és rakjuk a cert könyvtárba idp.pem, illetve idp.crt néven.
cd cert
openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out idp.crt -keyout idp.pem
metadata/saml20-idp-hosted.php
'auth' => 'default-sp',
'privatekey' => 'idp.pem',
'certificate' => 'idp.crt',
),
A vidyo portál admin felületéről le kell tölteni a portál metaadatát, és el kell menteni a metadata könyvtárba.
metadata/vidyo-sp.xml
Erre hivatkozni kell a config/config.php-ben is:
'metadata.sources' => array(
...
array('type' # > 'xml', 'file' > 'metadata/vidyo-sp.xml'), // vidyo sp
... ),
Vidyo admin portál
A portálon be kell állítani,
- hogy az azonosítás SAML alapú legyen, Authentication Type
- fel kell tölteni az IdP metaadatát, ezt az ssp telepítés saml2/idp/metadata.php oldaláról tölthetjük le. Identity Provider (IdP) Metadata XML
- be kell állítani az auto provisioninget, SAML provision type
Az előző fejezetben említett portál metaadatát ezen az oldalon érjük el. View Service Provider (SP) metadata XML Össze kell illeszteni a SAML rétegből jövő attribútumokat a Vidyo portál által használt adatmodellel. Edit IdP Attribute Mapping...
A SAML IdP Attribute Name oszlopokba az SSP-től kapott attribútum neveket kell írni. Ha a proxy IdP oldalán a példa szerint állítottuk be az AttributeMap szűrőt, akkor itt az attribútumok friendly nevét kell beírnunk. Tipp: https://github.com/simplesamlphp/simplesamlphp/blob/master/attributemap/name2oid.php
Bizonyos attribútumoknál lehetőség van érték mapping-re is, tipikusan csoport, vagy típus jellegű attribútumoknál, ahol a kapott attirbútumok értéke alapján történik a megfeleltetés.
SSP SP oldalának konfigurálása, illesztés a föderációba
A proxy egyik oldala a föderáció felé, mint SP viselkedik. Az authsource-ot 'default-sp'-nek nevezzük el, erre kell hivatkozni a későbbiekben az IdP konfigurációban.
A config/config.php file-ba
Hogy a vidyo portál, és egyé authentikációs szűrők futtatásakor az attribútum megfeleltetéseknél ne okozzanak gondot az oid formátumú attribútum nevek, mielőtt kiadjuk őket, az AttributeMap szűrő segítségével alakítsuk át az attribútum neveket.
config/config.php
'authproc.sp' => array(
...
200 # > array('class' > 'core:AttributeMap', 'oid2name'),
...
),
Ha még nem tettük meg, rakjunk ide is certificate-et.
cd cert
openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out sp.crt -keyout sp.pem
és könyveljük be a config/authsrouces.php -ba
'default-sp' => array(
'saml:SP',
...
'privatekey' => 'sp.pem',
'certificate' => 'sp.crt',
...
metadata
Az SP-t regisztráljuk be a kívánt föderációba a föderáció által megadott szabályok alapján.
metarefresh
Hogy a metadadatok mindig napra készek legyenek, gondoskodjunk a metarefresh és cron modul beállításáról.
A konfigurációs file-okat a config könyvtárba kell elhelyezni a sablonokat a modulok config-templates alkönyvtáraiban találjuk meg.
A modulok bekapcsolásáról a rendszer konfigurációban rendelkezhetünk a legegyszerűbben.
config/config.php
'module.enable' => array(
'cron' => TRUE,
'metarefresh' => TRUE,
),
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 :)
Shib2IdpInstall
Előkészületek
entityID
Fontos, hogy az entityID egyedi és állandó legyen. Javasolt forma: https://idp.intezmenyneve.hu/idp/shibboleth
.
Tűzfal
Be kell engedni a 443-as és a 8443-as portokat. Ha nagyon szigorúan vesszük, akkor a 8443-as portot elegendő csak a szóbajöhető SP-kről beengedni, de ezzel általában nem vagyunk tisztában, ezért célszerű a "nagyvilágból" beengedni. Biztonsági szempontból nem sok különbség van a 443-as és a 8443-as porton elérhető alkalmazások között.
JDK
Debian Lenny alatt a sun-java6-jdk
csomagot kell feltelepíteni. Telepítés előtt érdemes az aptitude-ban kikapcsolni az opcionális függőségek telepítését.
aptitude install sun-java6-jdk
Állítsuk be, a JAVA_HOME
környezeti változót!
export JAVA_HOME=/usr/lib/jvm/java-6-sun
!!! danger "Figyelem"
Az `openjdk-6-jdk` csomag használata esetén ne felejtsük feltenni a `ca-certificates-java` csomagot, anélkül ugyanis hibát fogunk kapni az IdP indításakor!
Shibboleth security provider
!!! info
A Shibboleth Security Provider csak akkor szükséges, ha a Java alkalmazásszerver (Tomcat) önállóan fog kéréseket feldolgozni és nem kerül elé proxy (Apache)
Be kell másolni a lib/shib-jce-1.0.jar
állományt a $JAVA_HOME/jre/lib/ext
könyvtárba. Ha az ext/
könyvtár nem létezik, akkor hozzuk létre.
cp lib/shib-jce-1.0.jar $JAVA_HOME/jre/lib/ext
Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a $JAVA_HOME/jre/lib/security/java.security
fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort:
security.provider.7=edu.internet2.middleware.shibboleth.DelegateToApplicationProvider
- Megj.: a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!
Bouncy Castle JCE
!!! question "Bizonytalan információ!"
Az alábbi leírás az 5-ös JVM-hez készült, 6-os JVM esetén erre nem biztos hogy szükség van.
A JVM-mel jövő Java Cryptography Engine (JCE) nem támogatja az összes kriptográfiai algoritmust, amelyre az Identity Providernek szüksége lehet (pl. XML Digital Signature, XML Encryption). A Bouncy Castle JCE ezek mellett még olyan algoritmusokat is tartalmaz (általában hatékonyabb és szabványosabb formában), amelyek benne vannak a Java JCE-ben.
Ehhez először le kell tölteni a Bouncy Castle JCE-t. A JCE állományok a Provider oszlopban, a "Signed Jar Files" részben találhatók. (A nevük bcprov-jdk-VERZIO.jar
.) Letöltés után a .jar fájlokat a $JAVA_HOME/jre/lib/ext
könyvtárba kell tenni.
wget http://www.bouncycastle.org/download/bcprov-jdk15-141.jar
cp bcprov-jdk15-141.jar $JAVA_HOME/jre/lib/ext
Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a $JAVA_HOME/jre/lib/security/java.security
fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort:
security.provider.8=org.bouncycastle.jce.provider.BouncyCastleProvider
- Megj.: a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!
Tomcat 6
A 2.1.3 és újabb IdP megköveteli a Tomcat6 használatát (Tomcat5.5 -tel bizonyos böngészők esetén nem működik rendesen). A Debian Lenny nem tartalmazza a Tomcat6-ot, ezért a testing ágból kell feltelepíteni.
A Tomcat6-ra való frissítésről további - vázlatos - információkkal ez az oldal szolgál.
Telepítés
Ha minden rendben meg, és a squeeze source beállításra került, akkor elegendő egy
aptitude install tomcat6
parancs kiadása. Ez felpakolja a tomcat különböző függőségeit is - az ajánlott függőségek (tomcat6-admin, -docs, stb.) feltelepítése nem szükséges.
Ne felejtsük el, hogy a Tomcat szerver "tomcat6" user nevében fog futni! Mivel a Shibboleth servletnek szüksége van arra, hogy hozzáférjen a filerendszerhez, a Java Security Manager-t ki kell kapcsolni a /etc/default/tomcat6
fájlban:
TOMCAT6_SECURITY=no
Ahhoz, hogy a Tomcat számára üzembiztosan elegendő memóriát biztosítsunk, ugyanebbe a fájlba ( /etc/default/tomcat6
) adjuk meg:
JAVA_OPTS="-Xms256M -Xmx512M -XX:-DisableExplicitGC "
Beállítás
A /etc/tomcat6/server.xml
fájlt kell szerkesztenünk
Ha a Tomcat Apache mögött fut
A 8009-es porton figyelő Connector elem konfigurációjához hozzá kell adni, hogy a tomcatAuthentication
értéke "false" legyen, ezen kívül a hozzáférést korlátozhatjuk a localhost-ra is (hiszen a Connector-t csak a helyben futó Apache mod_proxy_ajp konnektora érheti el).
<Connector port="8009" address="127.0.0.1" tomcatAuthentication="false"
enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
Ha a Tomcat önállóan, Apache nélkül fut
Ha a Tomcat Apache nélkül fut, akkor be kell állítani, hogy az SP-vel való kommunikációra fenntartott 8443-as porton egyből a Tomcat figyeljen.
<Connector port="8443"
maxHttpHeaderSize="8192"
maxSpareThreads="75"
scheme="https"
secure="true"
clientAuth="want"
SSLEnabled="true"
sslProtocol="TLS"
keystoreFile="IDP_HOME/credentials/idp.jks"
keystorePass="PASSWORD"
truststoreFile="IDP_HOME/credentials/idp.jks"
truststorePass="PASSWORD"
truststoreAlgorithm="DelegateToApplication"/>
Ahol az IDP_HOME
az IdP alapkönyvtára, a PASSWORD
pedig az IdP telepítésekor megadandó jelszó lesz.
!!! info
Amennyiben a Tomcat önállóan fut, szükség van a Shibboleth Security Provider telepítésére!
Apache beállítás
Tanúsítványok beszerzése és bemásolása /etc/ssl
vonatkozó alkönyvtárai alá.
Meg kell adni, hogy az Apache figylejen a 443-as és 8443-as portokon. Az alábbiak kerüljenek a /etc/apache2/ports.conf
fájlba
Listen 443
Listen 8443
SSO URL (443-as port)
Be kell állítani a virtuális hosztot, amelyhez az IdP-t rendeltük. Először a 443-as portot konfiguráljuk.
<VirtualHost _default_:443>
ServerName aai.example.org:443
SSLEngine On
SSLCertificateFile /etc/ssl/certs/aai.example.org.crt
SSLCertificateKeyFile /etc/ssl/private/aai.example.org.key
SSLCertificateChainFile /etc/ssl/certs/aai.example.org.crt
ProxyRequests Off
<Proxy ajp://localhost:8009>
Allow from all
</Proxy>
ProxyPass /idp ajp://localhost:8009/idp retry=5
</VirtualHost>
Ezen a porton valamilyen széles körben ismert tanúsítványt kell használni, mivel a felhasználók böngészőjének ismerniük kell(ene) a kibocsátót.
AA ill. Artifact (8443-as port)
Ezen keresztül az SP és az IdP közvetlenül kommunikálnak egymással. Ide arra a tanúsítványra van szükség, amely a föderációs metadatában szerepel - az aláírója nem érdekes.
A csatorna felépítésekor az IdP és az SP is autentikálja magát. Az SP autentikációját az Apache végzi, ami nem végez kibocsátó-ellenőrzést (optional_no_ca
). Ez utóbbit az IdP alkalmazás végzi el, ezért nagyon fontos, hogy a kliens tanúsítványát az Apache továbbadja az alkalmazásnak (ExportCertData
).
!!! danger "Figyelem"
Az Apache a tanúsítvány-ellenőrzésnél ellenőrzi a tanúsítvány típusát. Ezért az SP tanúsítványának vagy kliens tanúsítványnak kell lennie, vagy nem lehet benne típus információ.
<VirtualHost _default_:8443>
ServerName aai.example.org:8443
SSLEngine On
SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:!SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
SSLCertificateFile /etc/ssl/certs/aai-aa.example.org.crt
SSLCertificateKeyFile /etc/ssl/private/aai-aa.example.org.key
SSLVerifyDepth 10
SSLVerifyClient optional_no_ca
SSLOptions -StdEnvVars +ExportCertData
ProxyRequests Off
<Proxy ajp://localhost:8009>
Allow from all
</Proxy>
ProxyPass /idp ajp://localhost:8009/idp retry=5
</VirtualHost>
A virtuális hoszt engedélyezése után be kell tölteni az ssl
és proxy_ajp
modulokat, majd újra kell indítani az apache-ot.
Shibboleth 2.x IdP servlet telepítés
Letöltés
A hivatalos IdP kiadás innen innen tölthető le
Alternatívaként az NIIF által patchelt, ezáltal SLO képes IdP kiadást ajánljuk, ami a NIIF AAI oldalról érhető el. A Single Logout-képes IdP-ről további információ itt.
Kicsomagolás
A shibboleth-idp-2.x.x-bin.zip
fájl tartalma kicsomagolás után a /usr/local/shibboleth-idp
könyvtár alákerül
cd /usr/local
jar -xf shibboleth-idp-2.x.x-bin.zip
Endorsed jar állományok
Sajnos - legalábbis a cikk írásakor - a "kincstári" Sun-os Tomcat (Java?) JAXP parser egy ismert memóriaszivárgást tartalmaz, ezért a disztribúcióban az endorsed/
könyvtárban található .jar file-okat kézzel be kell másolni a Tomcat endorsed/
könyvtárába.
-
A Debian alatti tomcat6 csomag használatakor a
/usr/share/tomcat6/common/endorsed
könyvtárba kell tenni a jar file-okat (ezt a könyvtárt létre is kell hozni).mkdir /usr/share/tomcat6/endorsed cp endorsed/*.jar /usr/share/tomcat6/endorsed/
Installer
export JAVA_HOME=/usr/jdk
cd /usr/local/shibboleth-idp
chmod 755 install.sh
./install.sh
A telepítés során az alábbi kérdésekre kell választ adnunk:
Is this a new installation? Answering yes will overwrite your current configurat ion. [yes|no] yes
Új telepítés, vagy sem.
Where should the Shibboleth Identity Provider software be installed? / opt/shibboleth-idp-2.0.0 /usr/local/shobboleth-idp
Itt található a letöltött és kicsomagolt shibboleth programcsomag
What is the hostname of the Shibboleth Identity Provider server? idp.example.org idp.example.org
Shibboleth IdP alkalmazás URI alapú azonosítója.
A keystore is about to be generated for you. Please enter a password that will be used to protect it. changeme
Feljegyzendő jelszó :)
Befejezés
Környezeti változó beállítása
IDP_HOME=/usr/local/shibboleth-idp
export IDP_HOME
Szimbolikus linkek megadása - az egyértelműség és konvenció kedvéért...
mv $IDP_HOME/conf /etc/`basename $IDP_HOME`
ln -s /etc/`basename $IDP_HOME` $IDP_HOME/conf
mv $IDP_HOME/logs /var/log/`basename $IDP_HOME`
ln -s /var/log/`basename $IDP_HOME` $IDP_HOME/logs
mkdir /var/lib/`basename $IDP_HOME`
mv $IDP_HOME/metadata /var/lib/`basename $IDP_HOME`/metadata
ln -s /var/lib/`basename $IDP_HOME`/metadata $IDP_HOME/metadata
Jogosultságok beállítása - hogy a tomcat6
felhasználó hozzáférhessen az alábbi könyvtárakhoz
chown -R tomcat6 /var/log/`basename $IDP_HOME` /var/lib/`basename $IDP_HOME`
További, már telepített IdP-től függő tomcat beállítás
cd /var/lib/tomcat6/
mkdir -p conf/Catalina/localhost
Az így létrehozott könyvtárban készítsünk egy idp.xml
nevű (a név legyen azonos a idp webalkalmazás nevével) fájlt az alábbi tartalommal:
<Context
docBase="/usr/local/shibboleth-idp/war/idp.war"
privileged="true"
antiResourceLocking="false"
antiJARLocking="false"
unpackWAR="false" />
Naplófájlok rotálása
Az alapértelmezett logging.xml nem törli a régi állományokat, ezért ezek egy idő után megtöltik a diszket.
Erre a korrekt megoldás az (lenne), ha a Logback alrendszert utasítjuk, hogy az N (a példában 90) napnál régebbi fájlokat rotálja ki. Ehhez a logging.xml
-ben adjuk meg a maxHistory
paramétert az összes rollingPolic
y-nál, valahogy így:
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<FileNamePattern>/usr/local/shibboleth-idp/logs/idp-access-%d{yyyy-MM-dd}.log</FileNamePattern>
<maxHistory>4</maxHistory>
</rollingPolicy>
Sajnos azonban jelenleg a logback csak egy állományt töröl, a régi file-okat megtartja (pl. akkor is, ha több, mint egy napig nem futott az IdP. Amíg ez nincs megoldva, addig kerülő megoldás lehet cron-ból törölni a régi file-okat
sudo crontab -u tomcat6 -e
MAILTO=mail@example.com
#m h dom mon dow command
52 18 * * * find /var/log/shibboleth-idp/ -mtime +90 -delete
Teszt
Ahhoz, hogy kiderítsük, működik-e (ill. fut-e :) ) az IdP webalkalmazásunk, ahhoz böngészőben hívjuk meg az alábbi urlt: https://idp.example.org/idp/profile/Status
, amennyiben az oldalon egy ok
-t látunk, akkor az alkalmazásunk fut, és elkezdhetjük beállítani az attribútumok feloldását és kiadását.
Ha nem működik a webalkalmazás, akkor az alábbi naplófájlokban kezdjünk el keresgélni:
/var/log/shibboleth/idp-error.log
/var/log/shibboleth/idp-process.log
A naplózás mélységét a /etc/shibboleth/logging.xml
fájlban állíthatjuk be. Hibakereséshez érdemes a <ErrorLog>
értékét DEBUG
-ra állítani.
Shibboleth 2.0 IdP beállítás
Metadata beállítása
Metadata aláírás ellenőrzés beállítása
Az IdP-be beállított metaadat(ok) valódiságának ellenőrzéséhez szükséges egy ún. TrustEngine
beállítása. Ezt a relying-party.xml
-ben kell megtenni a Security Configurations
részben:
<security:TrustEngine
id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
<security:Credential id="HREFSigner" xsi:type="security:X509Filesystem">
<security:Certificate>/path/to/idp/credentials/href-metadata-signer-2011.crt</security:Certificate>
</security:Credential>
</security:TrustEngine>
A konfigurációban hivatkozott href-metadata-signer-2011.crt
elérhető innen: https://metadata.eduid.hu/href-metadata-signer-2011.crt, SHA-1 lenyomata a következő: FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66
HREF föderációs metadata beállítása az IdP-ben
A HREF metadata állomány elérhetősége:
A Shibboleth IdP relying-party.xml
konfigurációban a következőképpen lehet beállítani a HREF metaadatot (fontos hogy az előző pontban leírt TrustEngine
is be legyen állítva):
<MetadataProvider id="HREF-Metadata"
xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
metadataURL="http://metadata.eduid.hu/current/href.xml"
backingFile="/path/to/idp/metadata/href.xml"
maxRefreshDelay="PT1H">
<MetadataFilter xsi:type="SignatureValidation" trustEngineRef="shibboleth.MetadataTrustEngine" />
</MetadataProvider>
Tovább a föderációba
Amennyiben a telepítendő IdP-t szeretnénk a HREF-be integrálni, úgy ennél a pontnál küldjünk egy levelet az aai@niif.hu címre, amely nyomán, ha minden rendben van, az IdP regisztrálásra kerül a Resource Registry-ben, s a válasz e-mail tartalmaz majd két hivatkozást, melyekről letölthetők az attribute-filter.xml
és attribute-resolver.xml
fájlok. Ezek már testreszabva tartalmazzák az IdP igényeit, az első fájlt elég csak bemásolni, a másodikban pedig - értelemszerűen - az egyes, a helyi erőforrásokra vonatkozó felhasználóineveket és jelszavakat kell kicserélni a megfelelőre.
További információk a Resource Registry-be történő felvételről
Attribútum filter automatikus frissítése
A Resource Registry automatikusan generálja minden egyes föderációban szereplő IdP számára a saját, testre szabott attribútum filterét, így célszerű úgy beállítani az IdP-t, hogy ezt a fájlt automatikusan töltse le. Ehhez hozzunk létre egy confcache
nevű könyvtárat, adjunk rá írásjogot a tomcat6
felhasználónak, majd szerkesszük a conf/service.xml
fájlt. Az XML felső harmadában kerül megadásra az AttributeFilterEngine
, melyet az alábbiak alapján kell átírni.
<Service id="shibboleth.AttributeFilterEngine"
xsi:type="attribute-afp:ShibbolethAttributeFilteringEngine"
configurationResourcePollingFrequency="3600000"
configurationResourcePollingRetryAttempts="128">
<ConfigurationResource url="https://rr.aai.niif.hu/gen_attribute-filter.php/href/IDP_NEVE_AZ_RRBEN/attribute-filter.xml"
file="/path/to/shibboleth-idp/confcache/attribute-filter.xml" xsi:type="resource:FileBackedHttpResource" />
</Service>
Több attribútum filter használata
Hasznos lehet, ha a föderációs szűrőkön kívül további irányokba kívánunk IdP-nkből attribútumokat kiadni. Elterjedt, hogy pl. különböző google szolgáltatásokhoz lehet az intézményen keresztül autentikálni, amely beállítási részleteket értelemszerűen a Resource Registry nem tartalmazza, így a letöltött friss, és a régi, helyi adatokat is tartalmazó fájlok egyesítése bosszantó plusz munka lehet. Ezt elkerülendd dolgozhatunk több attribútum filterfájlból. Ehhez ismét a conf/service.xml
fájlt kell szerkeszteni. Alább a fenti kódrészlet kiegészítése.
<Service id="shibboleth.AttributeFilterEngine"
xsi:type="attribute-afp:ShibbolethAttributeFilteringEngine"
configurationResourcePollingFrequency="3600000"
configurationResourcePollingRetryAttempts="128">
<ConfigurationResource url="https://rr.aai.niif.hu/gen_attribute-filter.php/href/IDP_NEVE_AZ_RRBEN/attribute-filter.xml"
file="/path/to/shibboleth-idp/confcache/attribute-filter.xml" xsi:type="resource:FileBackedHttpResource" />
<ConfigurationResource file="/path/to/shibboleth-idp/conf/attribute-filter-local.xml" xsi:type="resource:FilesystemResource" />
</Service>
Ezek a lépések természetesen kihagyhatók, ha nincs szándékunkban a föderáció tagjaivá válni, ekkor érdemes az alább részletezett attribútumokhoz kapcsolódó tudnivalókkal folytatni.
Autentikáció beállítása
Attribútum feloldás beállítása
Attribútum kiadás beállítása
HREFServices
Föderációs Szolgáltatások
Tagi Szolgáltatások
A Tag az alábbi szolgáltatásokat regisztrálhatja a Föderációba:
- Azonosító Szolgáltatás (Identity Provider, IdP): a tag felhasználóinak azonosítását végző szolgáltatás. Az Azonosító Szolgáltatás szabványos protokollon elérhető a Tartalomszolgáltatások számára.
- Tartalomszolgáltatás (Service Provider, SP): a Föderáció Tagjainak felhasználói számára nyújtott szolgáltatások vagy elérhetővé tett erőforrások.
- Attribútum Szolgáltatás (Attribute Authority, AA): bizonyos felhasználói adatok Tartalomszolgáltatók általi lekérdezését speciális esetekben (pl. virtuális szervezet, VO) lehetővé tevő szolgáltatás.
Partner Szolgáltatások
A Partner az alábbi szolgáltatásokat regisztrálhatja a Föderációba:
- Tartalomszolgáltatás (Service Provider, SP): a Föderáció Tagjainak felhasználói számára nyújtott szolgáltatások vagy elérhetővé tett erőforrások.
Attribute_Conversion_for_eduGAIN
JRA5 Attribute Conversion allows a Bridging Element administrator to define rules to transform attributes being released or received. The same logic can work in both Home and Remote Bridging Elements.
Introduction
Attributes are travelling on the wire in eduGAIN-defined format, ie. SAML. Naming attributes and defining their contents might be a standardization task of eduGAIN operators; however it should be possible for federations to agree on custom set of attributes beyond "eduGAIN commons".
Attribute Conversion only adds attributes (or values) to the attribute set; use Attribute Filtering for filtering out unnecessary attributes. It also means that if no rules match an attribute, then it will go to the filter unmodified - so conversion works with a default by-pass policy.
Attribute conversion rule concepts
Most of the rules are based on standard regular expressions and Unified Expression Language.
Each rule works on the actual attribute set which is not necessarily the initial set, as each rule can alter the set (ie. by changing values or names, adding new attributes to the set). This means that the order of the rules is important.
Every rule consists of two parts: condition and action. The condition element is used to determine whether this particular rule is to be processed or not. Thus, the rule action is only processed when all the conditions are met (a rule without any conditions is processed by default).
The condition engine now only supports regular expression -based matching rules. There are three types of matching rules
- local federation peer's identifier (LocalProviderMatch)
- remote federation peer's identifier (RemoteProviderMatch)
- attribute values (AttributeMatch)
The rule's action is to create new attributes (or to modify existing ones). Please refer to the detailed BasicRule, MergeRule, SplitRule documentation below.
Attribute conversion rule types
BasicRule
The Basic rule is the simplest attribute conversion rule type. It can create one attribute and optionally use one attribute and regular expressions to transform attribute values.
Basic Rule can create static attributes. You can achieve this by omitting the Condition node. The replaceValues
parameter is true by default, so if you want to append values to (probably) existing attributes, you must declare it using replaceValues="false"
. Also note that you can use multiple AttributeValue nodes.
<BasicRule>
<Description>Create static attribute (or append to existing if attribute with this name already exists)</Description>
<Attribute attributeName="eduPersonScopedAffiliation" replaceValues="false">
<AttributeValue>staff@niif.hu</AttributeValue>
<AttributeValue>member@href.hu</AttributeValue>
</Attribute>
</BasicRule>
The next rule is using remote provider matching to determine whether the remote side has an identifier of 'urn:geant:edugain:be:' and any Hungarian domain appended to it.
<BasicRule>
<Description>Create static attribute for some remote providers</Description>
<Condition>
<RemoteProviderMatch>^urn:geant:edugain:be:[^:]+\.hu$</RemoteProviderMatch>
</Condition>
<Attribute attributeName="homeOrganization">
<AttributeValue>niif.hu</AttributeValue>
</Attribute>
</BasicRule>
This example shows how to rename an attribute without converting its values. Note that you must use AttributeMatch
without regular expressions to achieve this.
<BasicRule>
<Description>Rename attribute uid to edupersonPrincipalName</Description>
<Condition>
<AttributeMatch attributeName="uid"/>
</Condition>
<Attribute attributeName="edupersonPrincipalName">
<AttributeValue>${uid}</AttributeValue>
</Attribute>
</BasicRule>
The next example demonstrates the use of regular expression matching groups.
<BasicRule>
<Decription>Transform 'o=org,c=country'-style OrgDN to DNS-based homeOrganization</Decription>
<Condition>
<AttributeMatch attributeName="edupersonOrgDN" id="regex">o=(.*),c=(.*)</AttributeMatch>
</Condition>
<Attribute attributeName="homeOrganization">
<AttributeValue>${regex[1]}.${regex[2]}</AttributeValue>
</Attribute>
</BasicRule>
This last example needs some more explanation. When you want to reference the regular expression matching groups (enclosed by parentheses), you must define the reference name with the 'id' parameter of AttributeMatch
. Then, use ${id[0]
to refer to the whole regular expression match (ie. the whole attribute value), and ${id[0]}
to refer to the Nth. matching group of the regular expression.
!!! info
You cannot reference regular expressions from another rule.
MergeRule
The merge rule can merge two or more attributes into one. The attributes whose values you want to merge is declared using the InputAttribute node. You can also use the condition node, but only with RemoteProviderMatch
and LocalProviderMatch
(AttributeMatch
is ignored).
This example shows how to combine two attribute values:
<MergeRule>
<Description>Merges the uid and homeOrganization to edupersonPrincipalName</Description>
<InputAttribute attributeName="homeOrganization" />
<InputAttribute attributeName="uid" />
<Attribute attributeName="edupersonPrincipalName" replaceValues="true">
<AttributeValue>${uid}@${homeOrganization}</AttributeValue>
</Attribute>
</MergeRule>
You can also use regular expressions, as with BasicRule.
SplitRule
The SplitRule is very similar to the MergeRule, the only difference is that the SplitRule contains one InputAttribute
and more Attribute
nodes.
<SplitRule>
<Description>Split the edupersonScopedAffiliation to edupersonAffiliation and homeOrganization</Description>
<InputAttribute attributeName="edupersonScopedAffiliation" id="scopedAffiliation" >^([^@]+)@(.+)$</InputAttribute>
<Attribute attributeName="edupersonAffiliation">
<AttributeValue>${scopedAffiliation[1]}</AttributeValue>
</Attribute>
<Attribute attributeName="homeOrganization">
<AttributeValue>${scopedAffiliation[2]}</AttributeValue>
</Attribute>
</SplitRule>
CustomRule
If you need to create new attributes from program (eg. appending generated identifiers), you can use the CustomRule type.
<CustomRule className="org.test.MyCustomRuleImpl">
<Configuration>
<!-- any xml here -->
</Configuration>
</CustomRule>
CustomRule class must implement the net.geant.edugain.attributes.rules.Rule
interface, configuration can be read with the DOM API. Please refer to the Attribute Converter JavaDOC, and see the test package as it contains a sample implementation.
Negating matches
If your federation has optional attributes then sometimes it is desirable to process rules only if a particular attribute does not exist. Therefore it is possible to append a negate
boolean attribute (setting it to true) to the <*Match>
nodes (inside the <Condition>
element) to revert the match. It means that the rule is only processed if there is no match for the given value.
The following example creates preferredLanguage
only if it is not set by the IdP (or by the peer's home bridging element):
<BasicRule>
<Decription>Create preferredLanguage only if source has not supplied it</Decription>
<Condition>
<AttributeMatch attributeName="preferredLanguage" negate="true"/>
</Condition>
<Attribute attributeName="preferredLanguage">
<AttributeValue>hu, en-gb;q=0.8, en;q=0.7</AttributeValue>
</Attribute>
</BasicRule>
Using attribute name mapper
For interoperability, SAML AttributeStatement carries attribute names with URN-style attribute naming scheme. For example, the 'mail' logical attribute name can be named as 'urn:mace:dir:attribute-def:mail'
, or 'urn:oid:0.9.2342.19200300.100.1.3'
. Shibboleth2 further encourages federations to use the latter form (ie. the LDAP oid).
The eduGAIN Attribute Converter library comes with an attribute name mapping subsystem. With the help of the attribute name mapper, system administrators can write the attribute converter configuration independently of the currently used attribute name format in AttributeStatement.
Attribute name mapper concepts
As the attribute conversion sits between two federations (and probably two attribute naming schemes), there are two types of physical attributes: the 'input' and 'output' attributes. Note that these notation is different in Home and Remote BEs: Home BE releases attributes to the eduGAIN federation, Remote BE releases attributes to the local federation. So the eduGAIN format is the 'output' attribute format of the Home BE, and the 'input' format of the Remote BE.
The following example shows the difference between logical and physical attribute names.
Physical input attribute name | Logical attribute name | Physical output attribute name |
---|---|---|
urn:mace:dir:attribute-def:mail | mail {: rowspan="2"} | urn:mace:dir:attribute-def:mail {: rowspan="2"} |
urn:oid:0.9.2342.19200300.100.1.3 | ⁠ {: style="padding:0"} | ⁠ {: style="padding:0"} |
Configuration of the attribute name mapper
The configuration xml of the attribute name mapper consists of one or more AttributeDefinition nodes. Each AttributeDefinition node specifies one logical attribute name (called 'id') and one physical AttributeName - which is the physical 'output' attribute name format. You can also specify AttributeNamespace (for SAML1.0).
The 'input' attribute names are configured using the 'Attribute' node. Note that the output name is also interpreted as input name, so it is not necessary to declare it twice.
<AttributeDefinition
Id="mail"
AttributeName="urn:mace:dir:attribute-def:mail">
<Attribute AttributeName="urn:oid:0.9.2342.19200300.100.1.3" />
</AttributeDefinition>
Using logical attribute names
When attribute name is referenced in a conversion rule, attribute mapper tries to interpret it as logical attribute name. Note that the logical attribute names are case-insensitive.
Using SAML1.1 Namespaces
EduGAIN Bridging Elements use SAML1.1 as communication protocol. SAML1.1 forces the use of Attribute NameSpace. You can specify the exact namespace in the attribute name mapping configuration using the 'AttributeNameSpace' attribute (with both the AttributeDefinition and Attribute nodes). When you use AttributeNameSpace, the input matching considers two attributes with the same name but different namespace different. The output attributes will contain the namespace information.
Attribute Filtering
Concepts
At Home BE, Filtering normally gets its incoming attribute set from Conversion; at Remote BE, it gets incoming attributes from the other bridging element.
From a technical viewpoint, Attribute Filtering is just a Rule extension to Conversion, so you can use most of the features of Converter, especially regular expressions and matching conditions. One major difference is that only explicitly allowed attributes can pass through, so you have to list all the attributes that you want to support in eduGAIN.
Filter uses name mappers in the same way as Converter. So you should define your attributes there before you start using 'friendly' attribute names here.
Allowing and denying attributes
Three main rules of the filtering:
- Default action is to deny ALL attributes.
- You can allow/deny whole attributes or specific values of the attributes.
- The first rule decides. If you allowed something, you can not deny it later and vice versa. So start with the special rules and leave the generic rules to the end.
You can allow an attribute by using <AllowAttribute>
element and deny it with <DenyAttribute>
. Each element can optionally have child elements <AttributeValue>
, which means that the action is only performed on certain values of the attribute.
!!! info
An attribute is removed from the set if its last value is removed. It means that it's not possible to pass through attributes without at least one value.
Using conditions
You can use the <Condition>
node in a filter rule just like with converter. The syntax is the same. So if you omit the Condition
element then the rule is evaluated unconditionally.
There is one slight difference: in FilterRule, AttributeMatch is always evaluated on the original input attribute set. It means that you can reference attributes in conditions even if they were allowed or denied before. (This is what you would normally expect, though.)
You can allow or deny multiple attributes within one <FilterRule>
. Note that the rule only applies if all the conditions within its <Condition>
element evaluate to true.
Examples
<?xml version="1.0" encoding="UTF-8"?>
<AttributeFilter xmlns='urn:geant:edugain:attribute-mangling:1.0'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:schemaLocation='urn:geant:edugain:attribute-mangling:1.0 AttributeMangling.xsd'>
<FilterRule>
<Description>Unconditional allowing and denying. The main rule is to deny ALL attributes.</Description>
<AllowAttribute attributeName="mail" />
<AllowAttribute attributeName="cn" />
<AllowAttribute attributeName="eppn" />
<DenyAttribute attributeName="userPassword" />
<DenyAttribute attributeName="uid" />
<DenyAttribute attributeName="homeOrganization" />
<AllowAttribute attributeName="schacHomeOrganization" />
</FilterRule>
<FilterRule>
<Description>Use conditions - allow only specific attribute values</Description>
<Condition>
<LocalProviderMatch>^urn:.*\.hu$</LocalProviderMatch>
</Condition>
<AllowAttribute attributeName="eduPersonEntitlement">
<AttributeValue>^.*@.*\.hu$</AttributeValue>
</AllowAttribute>
</FilterRule>
<FilterRule>
<Description>Use conditions - reference any attribute</Description>
<Condition>
<AttributeMatch attributeName="homeOrganization">niif.hu</AttributeMatch>
</Condition>
<AllowAttribute attributeName="eduPersonEntitlement">
<AttributeValue>^.*@niif\.hu$</AttributeValue>
</AllowAttribute>
</FilterRule>
</AttributeFilter>
Integration
You can integrate Attribute Conversion and Filtering into your Bridging Element by using these java code snippets. (Of course, edugain.jar and converter.jar need to be placed on the classpath.)
Initialization time
This code needs to be invoked in BE initialization time (and not in runtime, as XML configuration parsing is a time-consuming process).
// get a reference to the AttributeConverterFactory singleton object
AttributeConverterFactory factory = AttributeConverterFactory.getInstance();
// set the configuration file paths (which paths can be set in web.xml for example)
factory.setAttributeConverterFilePath("path-to-converter.xml");
factory.setAttributeFilterFilePath("path-to-filter.xml");
factory.setAttributeNameMapperFilePath("path-to-namemapper.xml");
// create converter and filter objects
try {
AttributeConverter converter = factory.createAttributeConverter();
AttributeFilter filter = factory.createAttributeFilter();
} catch (ConfigurationException ex) {
// handle configuration errors (missing files, not valid xmls and more issues)
log.error(ex);
}
Runtime
This code is invoked in BE runtime. You should have a List of AttributeValues, which was either received from the IdP or from the H-BE. You will get the output attribute set after invoking process()
method. Note that process()
takes two more arguments: remote
and local
. These represent the local and remote peers that your BE bridges together. Use of these identifiers is optional, you can pass null
.
!!! danger "Figyelem"
If you do not pass `local` or `remote` then rules containing `LocalProviderMatch` or `RemoteProviderMatch` will **NOT** be executed.
String remote = "remote-federation-peer-identifier";
String local = "local-federation-peer-identifier";
// get Attributes from the assertion
List<AttributeValues> input = ...;
// Call converter and filter in order.
// Home BE should call converter first, remote BE should call filter first.
if (isHomeBE) {
List<AttributeValues> output = converter.process(input, remote, local);
output = filter.process(output, remote, local);
} else {
List<AttributeValues> output = filter.process(input, remote, local);
output = converter.process(output, remote, local);
}
// process output here, create new assertion, etc.
Testing
XMLTest.sh
Attribute conversion library comes with XML-based test framework. The test can be invoked by the net.geant.edugain.attributes.xmltest.AttributeConverterTest
main class. There is the XMLTest.sh
script attached to the project, which makes it easy to execute the testing framework.
$ ./XMLTest.sh
Attribute Converter Test usage
java AttributeConverterTest
[-debug]
[AttributeConverter.xml](-converterconfig)
[AttributeFilter.xml](-filteringconfig)
[AttributeNameMapping.xml](-attributenameconfig)
[output.xml](-output)
input.xml
Example test configuration
The xmltest/
directory contains the following examples
AttributeNameMapper.xml
converter name mapper configuration
<?xml version="1.0" encoding="UTF-8"?>
<AttributeMapper
xmlns='urn:geant:edugain:attribute-mapper:1.0'>
<AttributeDefinition
Id="mail"
AttributeName="urn:mace:dir:attribute-def:mail">
<Attribute AttributeName="urn:oid:0.9.2342.19200300.100.1.3" />
</AttributeDefinition>
<AttributeDefinition
Id="edupersonAffiliation"
AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation" />
<AttributeDefinition
Id="homeOrganization"
AttributeName="urn:mace:dir:attribute-def:homeOrganization" />
<AttributeDefinition
Id="cn"
AttributeName="urn:mace:dir:attribute-def:cn">
<Attribute AttributeName="urn:oid:2.5.4.3"/>
</AttributeDefinition>
</AttributeMapper>
AttributeConverter.xml
converter configuration
<?xml version="1.0" encoding="UTF-8"?>
<AttributeConverter
xmlns='urn:geant:edugain:attribute-mangling:1.0'>
<BasicRule>
<Description>Create static attribute</Description>
<Attribute attributeName="eduPersonAffiliation" replaceValues="false">
<AttributeValue>staff@niif.hu</AttributeValue>
</Attribute>
</BasicRule>
<BasicRule>
<Description>Create static attribute for some remote providers</Description>
<Condition>
<RemoteProviderMatch>^urn:geant:edugain:be:[^:]+\.hu$</RemoteProviderMatch>
</Condition>
<Attribute attributeName="homeOrganization">
<AttributeValue>niif.hu</AttributeValue>
</Attribute>
</BasicRule>
<MergeRule>
<Description>Merges the common name to the email address(es)</Description>
<InputAttribute attributeName="cn" />
<InputAttribute attributeName="mail" />
<Attribute attributeName="mail" replaceValues="true">
<AttributeValue>${cn} <${mail}></AttributeValue>
</Attribute>
</MergeRule>
</AttributeConverter>
AttributeTest.xml
test input xml
<?xml version="1.0" encoding="UTF-8"?>
<AttributeTest
xmlns='urn:geant:edugain:attribute-test:1.0'
Remote="urn:geant:edugain:be:niif.hu" >
<Attribute AttributeName="urn:oid:0.9.2342.19200300.100.1.3">
<AttributeValue>adam.lantos@niif.hu</AttributeValue>
<AttributeValue>hege@niif.hu</AttributeValue>
</Attribute>
<Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation">
<AttributeValue>staff</AttributeValue>
</Attribute>
<Attribute AttributeName="urn:oid:2.5.4.3">
<AttributeValue>Adam Lantos</AttributeValue>
</Attribute>
</AttributeTest>
Output of the example
$ ./XMLTest.sh \
-converterconfig xmltest/AttributeConverter.xml \
-attributenameconfig xmltest/AttributeNameMapper.xml \
xmltest/AttributeTest.xml
AttributeConverter.<init> (80) : Creating new rule: class net.geant.edugain.attributes.rules.BasicRule
AttributeConverter.<init> (81) : Rule Description: Create static attribute
AttributeConverter.<init> (80) : Creating new rule: class net.geant.edugain.attributes.rules.BasicRule
AttributeConverter.<init> (81) : Rule Description: Create static attribute for some remote providers
AttributeConverter.<init> (80) : Creating new rule: class net.geant.edugain.attributes.rules.MergeRule
AttributeConverter.<init> (81) : Rule Description: Merges the common name to the email address(es)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AttributeTest xmlns="urn:geant:edugain:attribute-test:1.0">
<Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation">
<AttributeValue>staff</AttributeValue>
<AttributeValue>staff@niif.hu</AttributeValue>
</Attribute>
<Attribute AttributeName="urn:mace:dir:attribute-def:mail">
<AttributeValue>Adam Lantos &lt;adam.lantos@niif.hu&gt;</AttributeValue>
<AttributeValue>Adam Lantos &lt;hege@niif.hu&gt;</AttributeValue>
</Attribute>
<Attribute AttributeName="urn:mace:dir:attribute-def:homeOrganization">
<AttributeValue>niif.hu</AttributeValue>
</Attribute>
<Attribute AttributeName="urn:mace:dir:attribute-def:cn">
<AttributeValue>Adam Lantos</AttributeValue>
</Attribute>
</AttributeTest>
Real-life examples
!!! warning "A szócikk vagy fejezet még megírásra vár"
Please post your BE configuration here.
Hungarnet
Home
Remote
Xmltooling_Log4cpp_patch
--- xmltooling/soap/impl/SOAPClient.cpp.orig 2008-03-14 23:50:29.000000000 +0100
+++ xmltooling/soap/impl/SOAPClient.cpp 2008-04-25 13:14:29.000000000 +0200
@@ -89,8 +89,11 @@
XercesJanitor<DOMDocument> janitor(doc);
Category& log = Category::getInstance(XMLTOOLING_LOGCAT".SOAPClient");
- if (log.isDebugEnabled())
- log.debugStream() << "received XML:\n" << *(doc->getDocumentElement()) << logging::eol;
+ if (log.isDebugEnabled()) {
+ string serializedXml;
+ XMLHelper::serialize (doc->getDocumentElement(),serializedXml,false);
+ log.debugStream() << "received XML:\n" << serializedXml << logging::eol;
+ }
auto_ptr<XMLObject> xmlObject(XMLObjectBuilder::buildOneFromElement(doc->getDocumentElement(), true));
janitor.release();
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
- 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
- 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 <https://discovery.eduid.hu/>
, amelyet ki kell egészíteni ily módon: <https://discovery.eduid.hu/openidp/>
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.
WAYF
A WAYF szó a Where Are You From? mondat rövidítése. Olyan szolgáltatást jelent, amely kideríti, hogy a felhasználót melyik IdP képes azonosítani. A SAML2 szabvány ezt a szolgáltatást Discovery Service-nek nevezi.
Legegyszerűbb esetben a WAYF kilistázza az elérhető IdP-ket, amelyek közül a felhasználó választhat. A választást bizonyos ideig (a böngésző bezárásáig, néhány napig, stb) megjegyeztethetjük, ekkor a WAYF szerver a választásunkat cookie-ban tárolja.
A WAYF lehet az IdP-nek és az SP-nek is része, ill. különálló elem, a működést ez nem befolyásolja.
** Szoftverek:**
- SWITCHaai WAYF (http://www.switch.ch/aai/support/tools/wayf.html)
- A Shibboleth 1.3 IdP tartalmaz WAYF alkalmazást
HREF_Key_Rollover_2020_English
Introduction
The Hungarian Research and Educational Federation is migrating to a new metadata signing certificate (HREF-2020).
All HREF member and partner have to update their IdP and SP configurations before 2022. January 1st., in order to provide the federational services without interruption. After 2022 January 1st., the old metadata signing certificate (HREF-2011) will be shut down.
The tables below and configuration examples are containing all the necessary technical information.
Key Rollover
Code names
Code name | Metadata signing certificate | Date of expiration |
---|---|---|
HREF-2011 | href-metadata-signer-2011.crt | 2022.01.01. |
HREF-2015 | mdx-test-signer-2015.crt | 2022.01.01. |
HREF-2020 | href-metadata-signer-2020.crt | 2025.06.14. |
SHA1 fingerprints
Code name | SHA1 fingerprint |
---|---|
HREF-2011 | FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66 |
HREF-2015 | 91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43 |
HREF-2020 | C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61 |
Domain names
Domain | URL | Key | Status |
---|---|---|---|
metadata.eduid.hu | metadata.eduid.hu/2011/href.xml |
HREF-2011 | Prod |
metadata.eduid.hu | metadata.eduid.hu/2020/href.xml |
HREF-2020 | Prod |
mdx.eduid.hu | mdx-2015.eduid.hu |
HREF-2015 | Prod |
mdx.eduid.hu | mdx-2020.eduid.hu |
HREF-2020 | Prod |
Shibboleth Service Provider Configurations
https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider
XML
https://wiki.shibboleth.net/confluence/display/SP3/XMLMetadataProvider
<MetadataProvider type="Chaining">
<MetadataProvider type="XML" id="href-2011" url="https://metadata.eduid.hu/2011/href.xml" backingFilePath="href-2011.xml">
<MetadataFilter type="Signature" certificate="href-metadata-signer-2011.crt"/>
<MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
<MetadataProvider type="XML" id="href-2020" url="https://metadata.eduid.hu/2020/href.xml" backingFilePath="href-2020.xml">
<MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
<MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
</MetadataProvider>
MDX
Shibboleth 3.X
https://wiki.shibboleth.net/confluence/display/SP3/MDQMetadataProvider
<MetadataProvider type="MDQ" id="href-2015" ignoreTransport="true" baseUrl="https://mdx-2015.eduid.hu/">
<MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
<MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
<MetadataProvider type="MDQ" id="href-2020" ignoreTransport="true" baseUrl="https://mdx-2020.eduid.hu/">
<MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
<MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
Shibboleth 2.X
<MetadataProvider type="Dynamic" id="href-2015" ignoreTransport="true">
<Subst>https://mdx-2015.eduid.hu/entities/$entityID</Subst>
<MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
</MetadataProvider>
<MetadataProvider type="Dynamic" id="href-2020" ignoreTransport="true">
<Subst>https://mdx-2020.eduid.hu/entities/$entityID</Subst>
<MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
</MetadataProvider>
Shibboleth Identity Provider Configurations
XML
Shibboleth 4.X
https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider
<MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
backingFile="%{idp.home}/metadata/href-2020.xml"
metadataURL="https://metadata.eduid.hu/2020/href.xml">
<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
<MetadataFilter xsi:type="EntityRoleWhiteList">
<RetainedRole>md:SPSSODescriptor</RetainedRole>
</MetadataFilter>
</MetadataProvider>
Shibboleth 3.X
https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider
<MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
backingFile="%{idp.home}/metadata/href-2020.xml"
metadataURL="https://metadata.eduid.hu/2020/href.xml">
<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
<MetadataFilter xsi:type="EntityRoleWhiteList">
<RetainedRole>md:SPSSODescriptor</RetainedRole>
</MetadataFilter>
</MetadataProvider>
MDX
Shibboleth 4.X
https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider
<MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
connectionRequestTimeout="PT2S"
connectionTimeout="PT2S"
socketTimeout="PT4S">
<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
<MetadataQueryProtocol>https://mdx-2020.eduid.hu/</MetadataQueryProtocol>
</MetadataProvider>
Shibboleth 3.X
https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider
<MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
connectionRequestTimeout="PT2S"
connectionTimeout="PT2S"
socketTimeout="PT4S">
<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
<MetadataQueryProtocol>https://mdx-2020.eduid.hu/</MetadataQueryProtocol>
</MetadataProvider>
SimpleSAMLphp Configurations
MDX
//config/config.php
'metadata.sources' => [[=> 'flatfile']('type'), // ez a *-hosted metadata konfiguráció betöltése miatt szükséges
[
'type' => 'mdq',
'server' => 'https://mdx-2020.eduid.hu',
/* --- */
'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61'
],
],
metarefresh
https://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_3
// config/config-metarefresh.php
$config = [
'sets' => [
'href-2011' => [
'cron' => ['hourly'],
'sources' => [
[
'src' => 'https://metadata.eduid.hu/2011/href.xml',
'validateFingerprint' => 'FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66',
],
],
'expireAfter' => 777600, // 9 nap
'outputDir' => 'metadata/metarefresh-href-2011/',
'outputFormat' => 'flatfile',
],
'href-2020' => [
'cron' => ['hourly'],
'sources' => [
[
'src' => 'https://metadata.eduid.hu/2020/href.xml',
'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61',
],
],
'expireAfter' => 777600, // 9 nap.
'outputDir' => 'metadata/metarefresh-href-2020/',
'outputFormat' => 'flatfile',
],
],
];
// config/config.php
'metadata.sources' => [
['type' => 'flatfile'],
['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2011'],
['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2020'],
],
Shib2IdpConnectionPool
Mi is az a connection pooling?
A Java webalkalmazások általában többszálú, hosszú életciklusú környezetben futnak, az adatbázis kapcsolatok azonban természetükből fakadóan nem szálbiztosak (egy kapcsolaton egyszerre csak szál dolgozhat). Ezért szükség van arra, hogy a feldolgozó szálakhoz adatbázis kapcsolatokat rendeljünk. Megjegyzendő, hogy ez nem újdonság, ugyanis PHP esetén például minden egyes futáskor új kapcsolat nyílik.
A kapcsolatkezelésre tehát alapvetően három módszer ismert:
- egy adatbáziskapcsolat, szinkronizációval. Ebben az esetben az alkalmazásunk tulajdonképpen egyszálúvá válik.
- feldolgozó szálanként külön adatbáziskapcsolat, így nem kell a szinkronizációval foglalkozni. Így azonban a kapcsolatok jelentős része kihasználatlan, szélsőséges esetben az adatbázis által engedélyezett kapcsolatok száma telítődhet is. Ez a megoldást tehát jelentős overheadet okoz.
- az adatbázis kapcsolatok dinamikus kiosztása a feldolgozó szálak között.
A fenti három megoldás közül az első kettő webes környezetben teljesítmény okokból erősen ellenjavallt, csak a harmadik módszer a járható út: az adatbázis kapcsolatokat tehát érdemes "készletezni" (connection pooling), és a kapcsolatot kérő szálakhoz futás közben, igény szerint hozzárendelni őket.
Ezen paradigma hatékony működéséhez rendkívül fontos, hogy az alkalmazás csak annyi ideig használja a kapcsolatot, ameddig szükséges, majd azonnal jelezze a pool felé, hogy a kapcsolat szabad (ezt tulajdonképpen a kapcsolat API-szintű lezárásával jelzi, de ilyenkor a fizikai kapcsolat természetesen nem bomlik fel, az másik szál számára ismét kiajánlhatóvá válik).
Az elterjedtebb connection pool implementációk rengeteg segítséget képesek nyújtani:
- minimális és maximális kapcsolatszám meghatározása
- inaktivitás esetén lezárás
- adatbázis oldali lezárás megakadályozása folyamatos "pingeléssel"
- halott kapcsolatok transzparens eltávolítása
A Java alkalmazásszervereknek egy szabványos módszert kell biztosítaniuk az adatbázis kapcsolatok elérésére. Az alkalmazások egy ún. JNDI erőforráson keresztül képesek elérni a kapcsolatok menedzseléséért felelős osztályt (ami általában egy ún. DataSource interfészt implementál). Fontos megemlíteni, hogy ilyenkor az adatbáziskapcsolat felépítését az alkalmazásszerver végzi, így az elérés paramétereit (url, felhasználónév, jelszó) ott kell adminisztrálni, és nem az alkalmazás saját konfigurációjában. Ez lehetőséget ad az adminisztrátor számára, hogy az egyes alkalmazásspecifikus beállítások megtanulása nélkül képes legyen egyik adatbázisról a másikra migrálni.
Connection pool használata Tomcat6 alatt
A Tomcat jelenleg a dbcp nevű pool implementációt használja, ami elég régi és a teljesítménye sem a legjobb, de legalább működik.
Az alábbi példakód egy MySQL kapcsolatot állít be (/etc/tomcat6/server.xml
), ami kapcsolat-ellenőrzést is végez, mielőtt az alkalmazásnak válaszolna:
<GlobalNamingResources>
<!-- Create connection pool for idptest.
Connections will be validated before handed over to the application,
and every 10 minutes. -->
<Resource name="jdbc/mymysql" auth="Container"
type="javax.sql.DataSource"
driverClassName="com.mysql.jdbc.Driver"
maxActive="10" maxIdle="2" maxWait="10000"
username="username" password="password"
url="jdbc:mysql://localhost:3306/database"
testWhileIdle="true" timeBetweenEvictionRunsMillis="6000000"
testOnBorrow="true" validationQuery="SELECT 1" />
</GlobalNamingResources>
A fenti globális JDNI erőforrást egyes alkalmazásokhoz kell rendelni a Context leíróban (pl /etc/tomcat6/Catalina/localhost/idp.xml
):
<Context docBase="...." ... >
<ResourceLink name="jdbc/mymysql"
global="jdbc/mymysql"
type="javax.sql.DataSource" />
</Context>
A fenti konfiguráció elkészülte után az alkalmazás a java:comp/env/jdbc/mymysql
JNDI néven éri el az adatbázis kapcsolatot, valahogy így (hibakezelés nélkül, természetesen):
// initialize jndi datasource
Context ctx = new InitialContext();
DataSource dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/mymysql");
// acquire a new connection
Connection conn = dataSource.getConnection();
try {
// do something
} finally {
//don't forget to close the connection in the finally block!
conn.close();
}
Egy fontos megjegyzés
Az alkalmazásszerver és az alkalmazás általában két külön osztálybetöltőt (classloader) használ, ezért ebben az esetben nem az alkalmazás mellé kell csomagolni a megfelelő adatbázis drivert, hanem az alkalmazásszerver által látható helyre. Debian Lenny alatt ez például a következőképpen valósítható meg:
sudo aptitude install libmysql-java
sudo ln -s /usr/share/java/mysql.jar /usr/share/tomcat6/lib/
IdP konfigurálása
Tegyük fel, hogy alkalmazásszerverünk képes a connection poolingra, és a megfelelő DataSource objektumot a JNDI térben rendelkezésre bocsátja jdbc/idp
néven.
Attribútumok feloldása
Az IdP leggyakrabban attribútum feloldáshoz (pl. perzisztens azonosítókhoz) használ relációs adatbázist, ezért példaként álljon itt egy DataConnector konfiguráció:
<resolver:DataConnector xsi:type="StoredId" ...>
<resolver:Dependency ref="myLDAP" />
<ContainerManagedConnection resourceName="java:comp/env/jdbc/idp" />
</resolver:DataConnector>
Gyakorlatilag az ApplicationManagedConnection
mondásokat kell ContainerManagedConnection
-ra cserélni.
JDBC login modul
Bővebben lásd: Shib2IdpAuth#SQL (JDBC) alapon
uApprove
Az alábbi leírás a uApprove legalább 2.3-as verzióihoz íródtak, korábbiak használata nem javasolt.
Ahhoz, hogy a tomcat által kezelt adatbáziskapcsolat használatára rávegyük a uApprove-ot, az alábbiakat kell tennünk.
vim conf/uApprove.properties
Az adatbázisbeállításoknál kommentezzük ki a default beállításokat és írjuk be a használni kívánt JNDI resource nevét:
#---------------------------------------------------------------------#
# Database configuration #
#---------------------------------------------------------------------#
database.resourceName = java:comp/env/jdbc/mymysql
#database.driver = com.mysql.jdbc.Driver
#database.url = jdbc:mysql://localhost:3306/uApprove
#database.username = uapprove
#database.password = password
vim conf/uApprove.xml
Tegyük inaktívvá az alapértelmezett uApprove.dataSource bean-t, és helyére tegyük az alábbi definíciót
<bean id="uApprove.dataSource" class="org.springframework.jndi.JndiObjectFactoryBean" depends-on="shibboleth.LogbackLogging"
p:jndiName="${database.resourceName}" p:lookupOnStartup="true"
p:cache="true" p:proxyInterface="javax.sql.DataSource" />
Utolsó lépésként másoljuk be a shibboleth-idp/lib
és a shibboleth-idp/war/WEB-INF/lib
könyvtárba az alábbi két jart is. (Alapértelmezés szerint az utóbbi útvonal becsomagolva található a shibboleth-idp/war/idp.war fájlban, ezesetben kicsomagolás --> fájlok bemásolása --> visszacsomagolás a követendő út):
Shib3IdpAttrib
Shibboleth 3 IdP attribútum feloldás beállítása
Vonatkozó állományok:
{idp.home}/conf/attribute-resolver.xml
{idp.home}/conf/idp.properties
Az alábbiakban LDAP címtárat használunk forrás adatbázisként az attribútumok feloldásához. Az {idp.home}/conf/ldap.properties
állományban beállított kapcsolódási paraméterek az attribútum feloldáshoz is használhatók.
Az {idp.home}/conf/attribute-resolver-ldap.xml
állomány jó kiindulási pont, cseréljük le erre az {idp.home}/conf/attribute-resolver.xml
állományt.
cd /opt/shibboleth-idp/conf # vagy ahová az IdP telepítésre került
cp attribute-resolver.xml attribute-resolver-simple.xml # másolat készítése
cp attribute-resolver-ldap.xml attribute-resolver.xml
Szerkesszük az alábbiak szerint az {idp.home}/conf/attribute-resolver.xml
állományt. A mail attribútumot már tartalmazza a beállító állomány. Az alábbi példában az sn és givenName attribútumokat vesszük fel.
<!-- ========================================== -->
<!-- Attribute Definitions -->
<!-- ========================================== -->
<!-- ... további tartalom ... -->
<!--
In the rest of the world, the email address is the standard identifier,
despite the problems with that practice. Consider making the EPPN value
the same as your official email addresses whenever possible.
-->
<resolver:AttributeDefinition id="mail" xsi:type="ad:Simple" sourceAttributeID="mail">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="sn" xsi:type="ad:Simple" sourceAttributeID="sn">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:sn" encodeType="false" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.4" friendlyName="sn" encodeType="false" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="givenName" xsi:type="ad:Simple" sourceAttributeID="givenName">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:givenName" encodeType="false" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.42" friendlyName="givenName" encodeType="false" />
</resolver:AttributeDefinition>
<!-- ========================================== -->
<!-- Data Connectors -->
<!-- ========================================== -->
<!-- ... további tartalom ... -->
- A 18, 24. sorban adjuk meg az attribútum nevét, valamint, hogy egyszerű attribútumról van szó, nem szükséges átalakítani.
- A 19, 25. sor hivatkozik a használandó LDAP kapcsolatra.
- A 21, 27. sorbeli SAML2String előállításához szükséges oid megegyezik az attribútum LDAP sémabeli oid-jával.
Dokumentáció:
OpenID
Mi az OpenID?
Az OpenID egy nyílt, decentralizált, ingyenes keretrendszer felhasználóközpontú digitális identitásmenedzsmenthez. Az OpenID elképzelés abból indul ki, hogy az interneten bárki azonosíthatja önmagát egy URI (avagy URL, web cím) segítségével, pontosan úgy, ahogy a weboldalak is teszik. Mivel az URIk a web felépítésének alapvető elemei, biztos alapjául szolgálhatnak a felhasználóközpontú identitásmenedzselésnek is.
Az OpenID keretrendszer egyik fő eleme az autentikáció, vagyis hogy miképp bizonyítod, te birtokolsz egy adott URI-t. Manapság a weboldalak felhasználóneveket és jelszavakat kérnek a belépéshez, ami azt jelenti, hogy sokan ugyanazt a jelszót használják minden weboldalon. Az OpenID autentikáció esetében a felhasználóneved a saját URI-d, jelszavad (vagy további adatod) pedig biztonságosan el lesz tárolva az OpenID szolgáltatódnál (amelyet te magad is működtethetsz, vagy használhatsz egyéb identitás szolgáltatót).
Egy OpenID-re nyitott weboldalra történő belépéshez (még ha sosem jártál rajta ezelőtt) csak add meg az OpenID URI-dat. A weboldal ezután át fog irányítani az OpenID szolgáltatódhoz, ahol meg kell adnod a szükséges adatokat. Amint megtörténik az autentikáció, OpenID szolgáltatód visszairányít a weboldalra a belépéshez szükséges adatokkal együtt. Ha erős autentikációra van szükség, az OpenID keretrendszer számos tranzakció típushoz is használható - az egyszerű Single-Sign-On eljárás vagy a megosztott adatok érzékenységének rugalmas kiterjesztésére.
Az autentikáció mellett az OpenID keretrendszer eszközöket is biztosít a felhasználóknak ahhoz, hogy megosszák digitális identitásuk egyéb összetevőit. A folyamatosan bővülő OpenID Attribute Exchange specifikáció alapján a felhasználók képesek pontosan meghatározni az Identitás szolgáltatójuk által megosztható információk körét.
Erasmusplus_ESI
Erasmus+ és ESI
Az Európai Hallgatói Kártya Kezdeményezés részeként az Európai Bizottság 2021 júniusától kezdve digitális formában kívánja támogatni az Erasmus programhoz kapcsolódó összes szolgáltatást, mint például az Online Learning Agreement (OLA) és az Erasmus+ mobilalkalmazást. A digitalizálás alapvető része a hallgatók azonosítása, amely az eduGAIN-en keresztül fog történni.Az eduGAIN szövetség hazai képviselője a KIFÜ, aki Magyarországon az eduID.hu szövetséget működteti, hogy az oktatás, kutatás és közgyűjtemények szereplői az intézményi hitelesítő adataikkal bejelentkezhessenek az eduGAIN szolgáltatásokba. Az eduGAIN-ben a szolgáltatások sikeres azonosítás esetén azonnal megkapják a felhasználók helyes azonosításához és jogosultság kezeléséhez szükséges információkat. Az MyAcademicID működéséhez, az európai hallgatói azonosító (European Student Identifier) helyes létrehozásához és az Erasmus+ szolgáltatásokban szükséges attribútumok beállításhoz szükséges információk az alábbiak.
MyAcademicID proxy
Az Erasmus+ szolgáltatásokhoz való hozzáférés a MyAcademicID projektben létrehozott és a GEANT által kezelt proxyn keresztül történik. Ez azt jelenti, hogy az Erasmus+ összes szolgáltatásának egyetlen szolgáltatója van a következő entitásazonosítóval:
https://proxy.prod.erasmus.eduteams.org/metadata/backend.xml
A Szolgáltatót az eduID.hu az eduGAIN-en keresztül teszi közzé, így ha az intézménye tagja az eduGAIN-nek is (lásd: Metaadatok), akkor nem kell további lépéseket tenni. Ellenkező esetben lépjen kapcsolatba először a KIFÜ eduID.hu csapatával, hogy kérje identitásszolgáltatójának exportálását az eduGAIN-ba, majd konfigurálja be az eduID.hu szolgáltatás által terjesztett eduGAIN metaadatokat (lásd: Metadata ).
Attributumok
Az Erasmus + szolgáltatások eléréséhez szükséges attribútumok a következők.
Attributumok | Leírás | Példa |
---|---|---|
eduPersonPrincipalName | Állandó, nem célzott, nem újra kiosztható globálisan egyedi azonosító | username@foobar.hu |
eduPersonTargetedID | Nem átlátszó, célzott (minden szolgáltatónál más) azonosító, amely nem osztható ki újra | https://idp.foobar.hu/idp/shibboleth!https://sp.example.com/shibboleth!a1b2c3d4-789a-4ca7-8ff9-43216789bd |
displayName | A felhasználó megjelenítendő neve. Szükséges, ha nincsen cn, vagy givenName+sn. | |
cn | A felhasználó teljes neve. Szükséges, ha nincsen displayName vagy givenName+sn. | Gipsz Jakab Aladár |
givenName | Felhasználó keresztneve. Szükséges, ha nincsen displayName vagy cn. | Jakab |
sn | Felhasználó családi neve. Szükséges, ha nincsen displayName vagy cn. | Gipsz |
eduPersonAffiliation | Felhasználó és intézmény közti viszony leírása. | [student](member,) |
eduPersonScopedAffiliation | Felhasználó és intézmény közti viszony leírása. scope-al | [student@foobar.hu](member@foobar.hu,) |
schacPersonalUniqueCode | A szervezet által hozzárendelt személyes egyedi kód (URN). '''Az európai hallgatói azonosító kódolására és továbbítására szolgál. | <nowiki>urn:schac:personalUniqueCode:int:esi:foobar.hu:123456789</nowiki> |
schacHomeOrganization | Szervezete domainje. | foobar.hu |
schacHomeOrganizationType | Szervezet típusa (URN) | <nowiki>urn:schac:homeOrganizationType:eu:higherEducationalInstitution</nowiki> |
European Student Identifier
Az European Student Identifier (ESI) globálisan egyedi, tartós, nem célzott azonosító (minden szolgáltatónál ugyanaz marad). Titkosítva kerül továbbításra a schacPersonalUniqueCode
attribútumon keresztül. Az ESI két fő módját támogatott:
- országos kód:ha rendelkezésre áll nemzeti hallgatói kód
- intézményenként:jelenleg ez támogatható Magyarországi szinten
Az ESI három részből áll:
- változatlan URN névtér:
<nowiki>urn:schac:personalUniqueCode:int:esi:</nowiki>:
- szervezet domainje: foobar.hu
- hallgatói azonosító kód (pl. belső nyilvántartási szám): 123456789
Az így kapott teljes ESI: <nowiki>urn:schac:personalUniqueCode:int:esi:foo.bar:123456789</nowiki>
Az ESI teljes specifikációja elérhető a GEANT wiki-n:
https://wiki.geant.org/display/SM/European+Student+Identifier
EWP adminisztrátori funkció
Az eduGAIN közösség 2022 öszén definiálta EWP Admin szerepkört. EWP Admin szerepkör (Erasmus Without Paper Administrator szerepkör) lehetővé teszi az Erasmus+ tevékenységeiben részt vevő felsőoktatási intézmények (HEI) felhatalmazott képviselői számára, hogy szabványos módon bejelentkezzenek az EWP-eszközökbe és EWP-információik és -beállításaik kezelése egységes legyen. Erről bővebb információ itt található:
https://wiki.geant.org/display/SM/EWP+Admin+Role
További információk
https://wiki.geant.org/display/SM/Identifier+in+Erasmus+mobility
SAML
SAML 1.1
SAML 2.0
Bindingok
- TODO
Profilok
Shibboleth
Architektúra
Profilok
Jelentés
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.
<resolver:AttributeDefinition xsi:type="Script"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
id="eduPersonEntitlement"
sourceAttributeID="eduPersonEntitlement">
<!-- Dependency that provides the source attribute. -->
<resolver:Dependency ref="myLDAP" />
<resolver:Dependency ref="eduPersonAffiliation" />
<!-- SAML 1 and 2 encoders for the attribute. -->
<resolver:AttributeEncoder xsi:type="SAML1String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:eduPersonEntitlement" />
<resolver:AttributeEncoder xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7"
friendlyName="eduPersonEntitlement" />
<!-- The script, wrapped in a CDATA section so that special XML characters don't need to be removed -->
<Script><![CDATA[
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
// Create attribute to be returned from definition
if (eduPersonEntitlement == null) eduPersonEntitlement = new BasicAttribute("eduPersonEntitlement");
if (eduPersonAffiliation.getValues().contains("staff") || eduPersonAffiliation.getValues().contains("student")) {
eduPersonEntitlement.getValues().add("urn:mace:dir:entitlement:common-lib-terms");
}
]]></Script>
</resolver:AttributeDefinition>
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',
),
SimpleSAMLMixedMetadata
Ez a vázlatos leírás egy olyan SimpleSAMLphp IdP (vagy SP) konfigurálásában kíván segítséget nyújtani, amely az alábbi metaadatforrásokat használja:
-
kézzel szerkesztett saml20-sp-remote (vagy saml20-idp-remote) például Google Apps vagy Office365 használatához;
-
az intézményi metadata halmazt, azaz a belső SP-k (esetleg teszt IdP-k) halmazát;
-
a magyar eduID.hu föderációban levő entitásokat;
-
és az eduGAIN-ben levő entitásokat.
Ez utóbbi kettőt a föderáció MDX szolgáltatása biztosítja leghatékonyabban.
Metaadatforrások beállítása
A config/config.php állományban cseréljük le a metadata.sources részt az alábbira:
'metadata.sources' => array(
array('type' => 'flatfile'),
array('type' => 'flatfile','directory' => 'metadata/metarefresh'),
array('type' => 'mdx', 'server' => 'http://mdx.eduid.hu', 'cachedir' => '/var/simplesamlphp/mdx-cache', 'cachelength' => 7200,
'validateFingerprint' => '91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43'
),
),
Az MDX cache könyvtárat és a statikus metaadatok könyvtárát hozzuk létre, és tegyük a webszerver által írhatóvá:
sudo mkdir /var/simplesamlphp/{mdx-cache,metadata/metarefresh}
sudo chgrp www-data /var/simplesamlphp/{mdx-cache,metadata/metarefresh}
sudo chmod g+w /var/simplesamlphp/{mdx-cache,metadata/metarefresh}
Statikus metaadatok
A fenti szakaszban a dinamikus metaadatok konfigurációját már megadtuk, a statikus metaadatokat viszont a cron modul által meghívott metarefresh program végzi, így ezeket is konfigurálni kell.
!!! note
Ha nem használunk belső SP-ket, akkor a szakaszban leírt konfigurációra nincs szükségünk, **készen vagyunk**!
config/config-metarefresh.php:
<?php
$config = array(
'sets' => array(
'href' => array(
'cron' => array('hourly'),
'sources' => array(
array(
'src' => 'http://metadata.eduid.hu/2011/niifi.xml',
'validateFingerprint' => 'FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66',
),
),
'expireAfter' => 60*60*24*7, // Maximum 4 days cache time.
'outputDir' => 'metadata/metarefresh/',
'outputFormat' => 'flatfile',
),
),
);
config/module_cron.php:
<?php
/*
* Configuration for the Cron module.
*/
$config = array (
'key' => 'eztajelszotcsereldle',
'allowed_tags' => array('daily', 'hourly', 'frequent'),
'debug_message' => TRUE,
'sendemail' => FALSE,
);
Engedélyezzük a cron és a metarefresh modulokat:
sudo touch /var/simplesamlphp/modules/{cron,metarefresh}/enable
Hozzuk létre azt a rendszer cron bejegyzést, amely időzítve meghívja a SimpleSAMLphp cron modulját:
echo '03 * * * * www-data curl --silent "https://idp.example.org/simplesamlphp/module.php/cron/cron.php?key=eztajelszotcsereldle&tag=hourly" \
>/dev/null 2>&1' > sudo tee /etc/cron.d/simplesamlphp
Ezzel az IdP-nk készen áll az eduGAIN konföderációba való publikálásra. A haladó attribútumkiadás-konfiguráció leírása itt található: SSP EntityCategories.
A Resource Registry felületen belépve állítsuk át az entitást az eduGAIN-ben való publikálásra:
Károkozási_táblázat
/- X -> | User | IdP | SP | Föderáció |
---|---|---|---|---|
User | ||||
IdP | ||||
SP | ) |
|||
FedOp |
Shibboleth_IdP
!!! bug "Elavult információ"
**Figyelem:** a Shibboleth szoftver ezen változata már nem támogatott. Az új verziókhoz a leírások itt találhatók:
* [Shibboleth2_IdP](https://help.edu.hu/books/aai/page/shibboleth2-idp)
* [Shibboleth2_SP](https://help.edu.hu/books/aai/page/shibboleth2-sp)
Telepítési leírások
Konfigurációs leírások
- IdP alkalmazás konfigurációja
- Attribútumok használata
- Attribútum kiadás konfigurációja
- Felhasználó azonosítás
ErrorNoStatement
Első tipp: rosszul jár az SP vagy az IdP órája
HREF_szolgáltatási_szint_megállapodás
Műszaki szolgáltatások
Metadata
A metadata a föderáció tagjait leíró, a föderációs operátor által digitálisan aláírt állomány, mely létfontosságú a résztvevők egymással való kommunikációjának szempontjából. A metadata által tartalmazott információkkal és a metadata biztonságával kapcsolatban további információkat a Metadata Specifikáció tartalmaz.
Elérhetőség kritériumai
A legfontosabb szempont, hogy az elérhetetlenségből fakadó szolgáltatáskiesés megakadályozható legyen. A föderációban részt vevő komponensek a központi metadatát helyileg gyorstárazzák, így a metadata elérhetetlensége a gyorstárazási idő (cacheDuration
) alatt nem okozhat szolgáltatáskiesési problémát - kivéve azon entitások esetén, melyek a kiesés időtartama alatt kerülnek újraindításra.
Fontos kiemelni, hogy a központi metadata elérhetetlensége miatti szolgáltatáskiesés bármely föderációs komponensnél a fent leírt gyorstárazási és érvényességi időszakon belül mindenképpen helyi szoftver- (vagy konfigurációs) hiba következménye.
A metadata akkor tekinthető elérhetőnek, ha legalább egy, a föderációs operátor hálózatán kívül levő IP címről elérhető, és az URL-ről egy szabványos SAML metadata állomány tölthető le, és aláírása egy ismert kulccsal ellenőrizhető. A metadata akkor tekinthető aktuálisnak, ha elérhető, és a letöltött állomány 2 óránál nem régebben keletkezett.
Vállalt rendelkezésre állás
A föderációs operátor vállalja, hogy a metadata tetszőleges 12 hónapos időtartamra nézve az idő 99.9%-ában elérhető, 99%-ában aktuális.
Föderáció adminisztráció (Resource Registry)
A Resource Registry a metaadat állományban található - az egész föderációt leíró - adatok szerkesztését lehetővé tevő alkalmazás. A Resource Registryben tárolt adatokat a föderációs operátor illetve az intézmények kapcsolattartói szerkeszthetik.
Elérhetőség kritériumai
A Resource Registry elérhetősége a benne tárolt adatok szerkesztésére vonatkozik, a metaadatok elérhetőségét nem érinti. Mivel azonban az esetleges kompromittálódott kulcsok visszavonása az intézmények részéről csak ezen az adminisztrációs rendszeren keresztül elvégezhető, ezért a rendszer elérhetősége a föderáció operatív működése szempontjából fontos.
A Resource Registry elérhető, ha legalább egy, a föderációs operátor hálózatán kívül eső IP címről megnyitható, és bejelentkezés működőképes (feltételezve, hogy az azonosító szervezet rendben működik).
Vállalt rendelkezésre állás
Tetszőleges 12 hónapos időtartamra nézve a szolgáltatás az idő 98%-ában elérhető.
Discovery Service
A Discovery Service (keresőszolgáltatás) az SP-k számára a felhasználó azonosító szervezetét kiválasztó alkalmazás. Amennyiben egy SP adminisztrátora úgy dönt, hogy az SP a központi keresőszolgáltatást használja, úgy az adott SP-n történő belépések esetén a komponens elérhetősége kritikus.
A keresőszolgáltatás a metaadatokból dolgozik, a metaadat változásait 1 napon (24 órán) belül átveszi.
Elérhetőség kritériumai
A keresőszolgáltatás elérhetőnek tekintendő, ha legalább 1, föderációs operátor hálózatán kívül eső IP címről elérhető, és a protokoll által leírt működést mutatja, valamint a metadatában szereplő azonosító szervezeteket ajánlja fel (figyelembe véve az előző pontban leírt időkorlátot a módosítások átvezetésére).
Vállalt rendelkezésre állás
Tetszőleges 12 hónapos időtartamra nézve a szolgáltatás az idő 99.9%-ában elérhető.
Virtuális azonosítószervezet
A föderációs operátor által biztosított virtuális azonosítószervezet biztosítja a saját azonosítószervezettel nem rendelkező intézmények számára a felhasználók AAI infrastruktúrába kapcsolását, illetve a többi azonosítószervezet számára a vendégfelhasználók regisztrálását és karbantartását.
Elérhetőség kritériumai
A virtuális azonosítószervezet két komponensből áll:
- adminisztrációs felület a felhasználók kezelésére
- azonosító szerver
A virtuális azonosítószerv elérhetőnek tekinthető, ha legalább egy, föderációs operátor hálózatán kívül eső IP címről elérhető az adminisztrációs felület (feltéve, hogy az adminisztrátor saját azonosító szervezete és a föderációs infrastruktúra megfelelően működik); illetve az azonosító szerver.
Vállalt rendelkezésre állás
A virtuális azonosítószervezet elérhető tetszőleges, 12 hónapos időtartamon számított teljes idő 99%-ában.
Föderációs komponensek monitorozása
A föderációs operátor az általa üzemeltetett komponenseket folyamatosan és automatikusan ellenőrzi. Ez az ellenőrzés kiterjed az infrastruktúra építőelemeire (switchek, hálózati elemek, szerverek), a szervereken futó operációs rendszerekre, és a föderációs szoftverekre is.
A monitorozás az NIIF hálózatán (HBONE) belülről történik.
Támogatás
Helpdesk intézményi adminisztrátorok számára
A föderációs operátor ügyfélszolgáltatot tart fenn a tagok és partnerek számára. Az ügyfélszolgálat feladata mind az incidensek kezelése, mind az általános segítségnyújtás (például csatlakozási szándék, vagy hibaelhárítás esetén).
Az ügyfélszolgálat munkanaponként 09-17 óra között működik, és az intézményi megkeresésekre legfeljebb 1 munkanapon belül válaszol.
Az esetleges incidensek 0-24 óráig bejelenthetők az NIIFI incidens-kezelő ügyeletén is (http://www.niif.hu/szolgaltatasok/middleware/csirt_kapcsolat).
Egyéb támogatás
A föderációs operátor a föderációs technológiákkal, trendekkel kapcsolatban folyamatosan frissülő tudásbázist tart fent, illetve rendszeres és eseti oktatásokkal segíti a tagok közötti tudásátadást. Ugyancsak elősegíti a használt szoftverekkel kapcsolatos információk, hibabejelentések terjedését a résztvevő intézmények és a szoftverek fejlesztői között. Az operátor feladata, hogy a felhasznált szoftverekkel kapcsolatos biztonsági frissítésekre felhívja a résztvevők figyelmét.
Kiegészítő szolgáltatások
A föderációs operátor az alábbi szolgáltatásokat garancia nélkül, best effort jelleggel működteti:
- URN registry (URN névterek kezelése, delegálása)
- Statisztika
- Audit
- Intézményi AAI komponensek monitorozása
- IdP és SP hosting
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](#bkmrk-change log) for the revisions of this document for the previous releases.
For documentation about the more recent 4.x version, please read [DrupalShibbolethReadmeDev](https://help.edu.hu/books/aai/page/drupalshibbolethreadmedev)
!!! warning
The following documentation assumes that
* You [understand how Shibboleth works](https://wiki.shibboleth.net/confluence/display/SHIB2/FlowsAndConfig)
* You have [successfully installed and configured Shibboleth SP](https://wiki.shibboleth.net/confluence/display/SHIB2/Installation) 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](#bkmrk-disallowing-password-change)
Example Shibboleth configuration
Note: this example uses lazy sessions. Configuration for Shibboleth 1.3 is quite similar.
/etc/shibboleth/shibboleth2.xml snippet:
<RequestMapper type="Native">
<RequestMap applicationId="default">
<Host name="your.host.name">
<Path name="location_of">
<Path name="your_Drupal">
<Path name="installation" authType="shibboleth" requireSession="false" />
</Path>
</Path>
</Host>
</RequestMap>
</RequestMapper>
Apache config file snippet (ie. /etc/apache2/sites-enabled/your.host.name
, or you can even use .htaccess
without the <Location>
tags):
<Location /location_of/your_Drupal/installation>
AuthType Shibboleth
ShibRequireSession Off
# the following single line is only valid for Shib2
ShibUseHeaders On
require shibboleth
</Location>
!!! danger "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://
orhttps://
) - host name
- Shibboleth handler URL (usually:
/Shibboleth.sso
) - 'location' part of the SessionInitiator definition
/etc/shibboleth/shibboleth2.xml snippet:
<Sessions lifetime="28800" timeout="3600" checkAddress="false"
handlerURL="/Shibboleth.sso" handlerSSL="false"
exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
idpHistory="false" idpHistoryDays"7">
<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
relayState="cookie" entityID="https://idp.example.org/shibboleth">
<SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" defaultACSIndex="5"/>
</SessionInitiator>
<!-- other things -->
</Sessions>
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](#bkmrk-automatic-role-assignment)
* 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
:
<!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
<LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
<!-- The following line should be commented out to make Drupal logout work,
as long as your IdPs do not support SAML2 logout -->
<!--LogoutInitiator type="SAML2" template="bindingTemplate.html"/-->
<LogoutInitiator type="Local"/>
</LogoutInitiator>
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.
!!! danger "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
Tanúsítványok_a_föderációban
SAML2 föderációkban az entitásoknak ismerniük kell egymás publikus kulcsát (amelyet X.509 tanúsítványokban osztanak meg egymással) ahhoz, hogy biztonságosan kommunikálhassanak egymással. Eközben a felhasználókkal is interakcióba lépnek, ami miatt könnyű összekeverni a két fajta tanúsítványt:
- amit az IdP/SP a felhasználó felé használ;
- amit másik entitások (SP/IdP) felé használ.
A felhasználók felé olyan tanúsítványt kell használni, amelyben a felhasználók böngészője megbízik. Ez a tanúsítvány nem szerepel a föderációs metadatában, ellenben a webszerver konfigurációjában hivatkozni kell rá. Jellemzően valamilyen jól ismert CA-val (pl. DigiCert vagy letsencrypt) aláírt tanúsítványt, ami azt is jelenti, hogy rendszeresen cserélni kell őket.
A föderációs metadatában szereplő tanúsítványt elsősorban a föderációs alkalmazás (Shibboleth, SimpleSAMLphp) konfigurációjában kell megadni, mert ez az, amivel alá tudja írni az általa küldött üzeneteket, illetve dekódolni tudja a fogadott titkosított adatokat. Ez a tanúsítvány lehetőség szerint hosszú (10+ éves) lejáratú, self-signed tanúsítvány legyen.
- A webszerver (Apache, Jetty) konfigurációban csak akkor szerepeljen a föderációs metadatában szereplő tanúsítvány, ha azt szeretnénk, hogy az IdP támogassa az attribútumok back-channel történő letöltését (a Shibboleth IdP ilyen), esetleg ha valamilyen oknál fogva önálló AttributeAuthority-t építünk. Ha valami fut a szabványos https porton (pl. az IdP SSO szolgáltatása vagy egy SP), akkor az AttributeAuthority szolgáltatást nem tehetjük ide, ezért az jellemzően a 8443-as porton szokott figyelni.
Shibenv-PHP
Eredeti forrás: http://shib.kuleuven.be/download/sp/test_scripts/shibenv.php.txt
<html>
<head>
<title>Shibboleth Attributes - <?php echo $_SERVER["SERVER_NAME"]; ?></title>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<script language"JavaScript" type="text/JavaScript">
<!--
function decodeAttributeResponse() {
var textarea = document.getElementById("attributeResponseArea");
var base64str = textarea.value;
var decodedMessage = decode64(base64str);
textarea.value = tidyXml(decodedMessage);
textarea.rows = 15;
document.getElementById("decodeButtonBlock").style.display='none';
}
function tidyXml(xmlMessage) {
//put newline before closing tags of values inside xml blocks
xmlMessage = xmlMessage.replace(/([^>])</g,"$1\n<");
//put newline after every tag
xmlMessage = xmlMessage.replace(/>/g,">\n");
var xmlMessageArray = xmlMessage.split("\n");
xmlMessage="";
var nestedLevel=0;
for (var n=0; n < xmlMessageArray.length; n++) {
if ( xmlMessageArray[n].search(/<\//) > -1 ) {
nestedLevel--;
}
for (i=0; i<nestedLevel; i++) {
xmlMessage+=" ";
}
xmlMessage+=xmlMessageArray[n]+"\n";
if ( xmlMessageArray[n].search(/\/>/) > -1 ) {
//level status the same
}
else if ( ( xmlMessageArray[< 0 ) && (xmlMessageArray[n](n].search(/<\//)).search(/</) > -1) ) {
//only increment if this was a tag, not if it is a value
nestedLevel++;
}
}
return xmlMessage;
}
var base64Key = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
function decode64(encodedString) {
var decodedMessage = "";
var char1, char2, char3;
var enc1, enc2, enc3, enc4;
var i = 0;
//remove all characters that are not A-Z, a-z, 0-9, +, /, or =
encodedString = encodedString.replace(/[^A-Za-z0-9\+\/\=]/g, "");
do {
enc1 = base64Key.indexOf(encodedString.charAt(i++));
enc2 = base64Key.indexOf(encodedString.charAt(i++));
enc3 = base64Key.indexOf(encodedString.charAt(i++));
enc4 = base64Key.indexOf(encodedString.charAt(i++));
char1 = (enc1 << 2) | (enc2 >> 4);
char2 = ((enc2 & 15) << 4) | (enc3 >> 2);
char3 = ((enc3 & 3) << 6) | enc4;
decodedMessage = decodedMessage + String.fromCharCode(char1);
if (enc3 != 64) {
decodedMessage = decodedMessage + String.fromCharCode(char2);
}
if (enc4 != 64) {
decodedMessage = decodedMessage + String.fromCharCode(char3);
}
} while (i < encodedString.length);
return decodedMessage;
}
// -->
</script>
</head>
<body>
<b>-all SHIB headers-</b> (`HTTP_SHIB_ATTRIBUTES` is not shown in this list)
<?php
echo '<table>';
foreach ($_SERVER as $key => $value)
{
$fkey='_'.$key;
if ( strpos($fkey,'SHIB')>1 && $key!="HTTP_SHIB_ATTRIBUTES")
# if ( strpos($fkey,'SHIB')>1 )
{
echo '<tr>';
echo '<td>'.$key.'</td><td>'.$value.'</td>';
echo '</tr>';
}
}
echo '<tr><td>(REMOTE_USER)</td><td>'.$_SERVER['REMOTE_USER'].'</td></tr>';
echo '<tr><td>(HTTP_REMOTE_USER)</td><td>'.$_SERVER['HTTP_REMOTE_USER'].'</td></tr>';
echo '<tr><td>HTTP_SHIB_LOGOUTURL</td><td>'.$_SERVER['HTTP_SHIB_LOGOUTURL']
.'<a href="/Shibboleth.sso/Logout?return='.$_SERVER['HTTP_SHIB_LOGOUTURL'].
'%3Freturn%3Dhttps%3A%2F%2Fshib.kuleuven.be%2Flogout.shtml">[logout]</a> </td></tr>';
echo '</table>';
?>
<br/>
attribute response from the IdP (`HTTP_SHIB_ATTRIBUTES`):<br/>
<textarea id="attributeResponseArea" onclick="select()" rows="1" cols="130">
<?php echo $_SERVER["HTTP_SHIB_ATTRIBUTES"]; ?></textarea><br/>
<span id="decodeButtonBlock">
<input type="button" id="decodeButton" value="decode base64 encoded attribute response using JavaScript"
onClick="decodeAttributeResponse();"><br/></span>
<br/>
<small>
notes:<br/>
The AAP throws away invalid values (eg an unscopedAffiliation of value "myBoss@<yourdomain>" or a value
with an invalid scope which scope is checked)<br/>
The raw attribute response (`HTTP_SHIB_ATTRIBUTES`) is NOT filtered by the AAP and should therefore
be disabled for most applications (`exportAssertion=false`).<br/>
</small>
<br/>
<hr/>
<br/>
<b>$_REQUEST</b>
<?php
echo '<table>';
foreach ($_REQUEST as $key => $value)
{
echo '<tr>';
echo '<td>'.$key.'</td><td>'.$value.'</td>';
echo '</tr>';
}
echo '</table>';
?>
<br/>
<hr/>
<br/>
<b>$_SERVER</b>
<?php
echo '<table>';
foreach ($_SERVER as $key => $value)
{
echo '<tr>';
echo '<td>'.$key.'</td><td>'.$value.'</td>';
echo '</tr>';
}
echo '</table>';
?>
<br/>
<hr/>
<br/>
<b>$_SESSION</b>
<?php
echo '<table>';
foreach ($_SESSION as $key => $value)
{
echo '<tr>';
echo '<td>'.$key.'</td><td>'.$value.'</td>';
echo '</tr>';
}
echo '</table>';
?>
<br/>
<hr/>
<br/>
</body>
</html>
ShibMessages
HTTP headers
Discovery Service, SAML2 Artifact
Felhasználó -> SP (1)
https://webadmin.iif.hu/ticketing/
GET /ticketing/ HTTP/1.1
HTTP/1.x 302 Found
Set-Cookie: _shibstate_7ed01b05=https%3A%2F%2Fwebadmin.iif.hu%2Fticketing%2F; path=/
Location: https://ds.niif.hu?entityID=https%3A%2F%2Fwebadmin.iif.hu%2Fshibboleth&return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05
A felhasználó lekéri a védett szolgáltatást, ám a Shibboleth modul közbeavatkozik, mivel még nincs Shibboleth session. Beállít egy cookie-t, ami alapján később rekonstruálható, hogy a felhasználó milyen szolgáltatást (URL) akart igénybe venni.
Mivel még nem lehet tudni a felhasználót azonosító IdP-t, ezért az SP átirányítja a felhasználót az Discovery Service-hez
Felhasználó -> DS
GET /?entityID=https%3A%2F%2Fwebadmin.iif.hu%2Fshibboleth&return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05 HTTP/1.1
HTTP/1.x 200 OK
Set-Cookie: _redirection_state=checked; expires=Mon, 18-May-2009 07:10:01 GMT; path=/; domain=ds.niif.hu
POST /?entityID=https%3A%2F%2Fwebadmin.iif.hu%2Fshibboleth&return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 80
user_idp=https%3A%2F%2Fidp.niif.hu%2Fshibboleth&Select=V%C3%A1laszt&session=true
HTTP/1.x 302 Found
Set-Cookie: _saml_idp=aHR0cHM6Ly9pZHAubmlpZi5odS9zaGliYm9sZXRo; expires=Sun, 12-Feb-2012 08:10:47 GMT; path=/; domain=ds.niif.hu
Set-Cookie: _redirect_user_idp=https%3A%2F%2Fidp.niif.hu%2Fshibboleth; path=/; domain=ds.niif.hu
Set-Cookie: _redirection_state=checked; expires=Wed, 26-Aug-2009 08:10:47 GMT; path=/; domain=ds.niif.hu
Location: https://webadmin.iif.hu/Shibboleth.sso/DS?SAMLDS=1&target=cookie%3A7ed01b05&entityID=https%3A%2F%2Fidp.niif.hu%2Fshibboleth
A példában egy PHP alkalmazás, a SWITCH WAYF (Discovery Service) egy legördülő listában felsorolja az IdP-ket (IP cím alapján előválasztást végez), majd a megfelelő kiválasztása után ezt egy cookie-ban eltárolja, mivel bejelöltük, hogy jegyezze meg a választást a munkamenet végéig. (Lehetőség van arra is, hogy megmaradó cookie-ban tárolja a kiválasztott IdP-t.)
Felhasználó -> SP (2)
GET /Shibboleth.sso/DS?SAMLDS=1&target=cookie%3A7ed01b05&entityID=https%3A%2F%2Fidp.niif.hu%2Fshibboleth HTTP/1.1
Cookie: _shibstate_7ed01b05=https%3A%2F%2Fwebadmin.iif.hu%2Fticketing%2F
HTTP/1.x 302 Found
Location: https://idp.niif.hu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZJPT8JAEMW%2FSrN3um0BgQ0lqXCQBJVQ9ODFTNup3WS7W3e2ot%2Fe8kfBg9w2%0A2XnvzftlpgS1akTSukpv8L1Fct5nrTSJw0fMWquFAZIkNNRIwuUiTe5XIvID%0A0VjjTG4U8xIitE4aPTea2hptivZD5vi0WcWscq4hwfkOMyhqqX0pS79qeVrJ%0ALDMKXeUTGb63jXjS2ZSQO%2BYtul2khr3r2UMWja9P%2Bu7NuxVKqfAk3mAhLeaO%0Ap%2Bkj85aLmL1GkyEEEAEUWX9c9PtFCOUEokE5uMkzKEfdGFGLS00OtItZFAST%0AXjDsheNtMBZhIAajF%2BatT01vpS6kfruOJTsOkbjbbte9c6FntHQo0w2x2XQP%0AWBzC7QXy69bww5nN%2FqNKv1Sn%2FCLimNeIh85zuVgbJfMvL1HK7OYWwWHMQsZn%0AR8nfe5h9Aw%3D%3D%0A&RelayState=cookie%3A7ed01b05
Az SP a HTTP requestben megkapott entityID
paraméterből tudja meg, hogy ki a felhasználóhoz tartozó IdP. Ez alapján kikeresi a metaadatok közül az IdP SingleSignOnService
URL-jét, és odairányítja a felhasználót, hogy azonosítsa magát.
Felhasználó -> IdP
GET /idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZJPT8JAEMW%2FSrN3um0BgQ0lqXCQBJVQ9ODFTNup3WS7W3e2ot%2Fe8kfBg9w2%0A2XnvzftlpgS1akTSukpv8L1Fct5nrTSJw0fMWquFAZIkNNRIwuUiTe5XIvID%0A0VjjTG4U8xIitE4aPTea2hptivZD5vi0WcWscq4hwfkOMyhqqX0pS79qeVrJ%0ALDMKXeUTGb63jXjS2ZSQO%2BYtul2khr3r2UMWja9P%2Bu7NuxVKqfAk3mAhLeaO%0Ap%2Bkj85aLmL1GkyEEEAEUWX9c9PtFCOUEokE5uMkzKEfdGFGLS00OtItZFAST%0AXjDsheNtMBZhIAajF%2BatT01vpS6kfruOJTsOkbjbbte9c6FntHQo0w2x2XQP%0AWBzC7QXy69bww5nN%2FqNKv1Sn%2FCLimNeIh85zuVgbJfMvL1HK7OYWwWHMQsZn%0AR8nfe5h9Aw%3D%3D%0A&RelayState=cookie%3A7ed01b05 HTTP/1.1
Cookie: _idp_authn_lc_key=_d1a773919fda20f6c4558c8784464ec0; JSESSIONID=2B35F7B27204BFE395EFB14C0BD27C2F; _idp_session=MTkzLjYuMjIyLjM%3D%7COWM0Y2Q5NzBoZDhhMJUwODdlMzgzNDk0NjLjNjA1ZLE2NmV1NjliMGFiMDRhZjBjOWY1MTA4ZjU0NDg3NjdjNA%3D%3D%7CWxuDg8LyyZtzzEUsqImA693l5yg%3D
HTTP/1.x 302 Moved Temporarily
Set-Cookie: _idp_authn_lc_key=_2594d4018d24a282156d9b9fc758d78b; Path=/idp; Secure
Set-Cookie: _idp_authn_lc_key=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT
Location: https://webadmin.iif.hu/Shibboleth.sso/SAML2/Artifact?SAMLart=AAQAAhzkZRgbhm%2BltdAF2yKfBGO7t%2BpaTrn3F1DpnZKFEAFI451jQHWhtBs%3D&RelayState=cookie%3A7ed01b05
A felhasználó korábban már azonosítva lett, ezért létezik session-je az IdP oldalán. Ezért nem történik meg a felhasználónév és jelszó bekérése.
Az IdP elkészíti a válasz SAML üzenetet, majd ebből Artifact-ot képez, és ezt GET paraméterként visszaküldi az SP-nek.
Felhasználó -> SP (3)
GET /Shibboleth.sso/SAML2/Artifact?SAMLart=AAQAAhzkZRgbhm%2BltdAF2yKfBGO7t%2BpaTrn3F1DpnZKFEAFI451jQHWhtBs%3D&RelayState=cookie%3A7ed01b05 HTTP/1.1
Cookie: _shibstate_7ed01b05=https%3A%2F%2Fwebadmin.iif.hu%2Fticketing%2F
HTTP/1.x 302 Found
Set-Cookie: _shibstate_7ed01b05=; path=/; expires=Mon, 01 Jan 2001 00:00:00 GMT
Set-Cookie: _shibsession_64656661756c7468747470733a2f2f77656261646d696e2e6969662e68752f73686962626f6c657468=_5aec103f1a8edb85ee42e4124ec0d222; path=/
Location: https://webadmin.iif.hu/ticketing/
Az IdP artifact üzenetét ellenőrzi az SP, majd - amennyiben a felhasználó jogosult az erőforrás igénybevételére - az SP tovább irányítja az alkalmazáshoz. Létrejön egy SP oldali session, ehhez a böngészőben cookie tartozik (_shibsession_
).
SP -> IdP
Az SP SOAP kapcsolatot nyit az IdP ArtifactResolutionService URL-jére, ahol az Artifact alapján megkapja a teljes SAML response-t.
Felhasználó -> Alkalmazás
https://webadmin.iif.hu/ticketing/
GET /ticketing/ HTTP/1.1
Cookie: _shibsession_64656661756c7468747470733a2f2f77656261646d696e2e6969662e68752f73686962626f6c657468=_5aec103f1a8edb85ee42e4124ec0d222
HTTP/1.x 200 OK
Discovery Service, POST
SAML üzenetek
AuthN request
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_afb021be7729adaa166dfb31b7c2c212c9d83183b9" Version="2.0"
IssueInstant="2009-05-19T08:07:26Z" ForceAuthn="false" IsPassive="false"
Destination="https://idptest.aai.niif.hu/idp/profile/SAML2/Redirect/SSO"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="https://papigw.aai.niif.hu/simplesaml/saml/sp/AssertionConsumerService.php">
<saml:Issuer>https://papigw.aai.niif.hu/simplesaml/saml2</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" AllowCreate="true"/>
</samlp:AuthnRequest>
HTML Form
POST profil használata esetén az IdP az alábbi formot küldi a felhasználó böngészőjének:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<body onload="document.forms[0].submit()">
<noscript>
<p>
<strong>Note:</strong> Since your browser does not support JavaScript,
you must press the Continue button once to proceed.
</p>
</noscript>
<form action="https://register.ca.niif.hu/Shibboleth.sso/SAML/POST" method="post">
<div>
<input type="hidden" name="SAMLResponse" value="PD94bWwgdmVyc2l ... wb25zZT4="/>
<input type="hidden" name="TARGET" value="cookie"/>
</div>
<noscript>
<div>
<input type="submit" value="Continue"/>
</div>
</noscript>
</form>
</body>
</html>
A form JavaScript-et támogató böngészők esetén automatikusan, a felhasználó közreműködése nélkül elküldésre kerül az SP-nek. A SAML válaszüzenet a SAMLResponse (rejtett) HTML mezőben található, base64 kódolással.
A SAMLResponse egy aláírt struktúra, opcionálisan titkosítható is. A válaszban opcionálisan szerepelhetnek a felhasználó attribútumai is (Attribute Push).
- Lehetséges aláírás nélküli választ küldeni, de ebben az esetben nem ellenőrizhető le a küldő személye, ezért ez általában nem megengedett
SAML response, attribute push
<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response Destination="https://be.aai.niif.hu/Shibboleth.sso/SAML2/POST" ID="_aecdf7920af52601ec97c78081968367" InResponseTo="_37534da3d36f1d629638c464f2614881" IssueInstant="2009-05-12T08:19:27.303Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.niif.hu/shibboleth</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_aecdf7920af52601ec97c78081968367">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="ds saml samlp xs" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>6BFgTMoHL9ynMIZpyYC+FG6v7mY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
nFsKAKnKhCr0J3W7yNoj8ulFPbB4Ba3ZUxJvtwahzCXMSCCEdUUNhIUntMhK3BpP10NGvf45SsH3
Ff0Vy0LvGe3hlmK/YmI+8oou/U0vJoQ2W8y4SBVtUXoJBb1GP2uhqnyW9Skmn8C7/bj0qc2ezieH
aOHEf1AGQyVnQxVJ64WIjlGT4AUTIMQzLTQ8+4yWNu2xJNHd5Pu55oqg7OhmWXDoaHGg46Gs+iXV
vD8wVi4Im4HlM3UL3VdOCwH0/aSGuy1yVoLAjvPTk/Dit2caB07HMMBVFErLW/alUm31L57QG8iW
iGkJi8GVZIL1Z1M0CxYrFG6TCSjlgNXBvFBGRA==
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIEmDCCA4CgAwIBAgILAQAAAAABGt7sf+4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCQkUx
EzARBgNVBAoTCkN5YmVydHJ1c3QxFzAVBgNVBAsTDkVkdWNhdGlvbmFsIENBMSIwIAYDVQQDExlD
eWJlcnRydXN0IEVkdWNhdGlvbmFsIENBMB4XDTA4MDcwMTE0MDAwOFoXDTExMDcwMTE0MDAwOFow
SDELMAkGA1UEBhMCSFUxFTATBgNVBAoTDE5JSUYgSW50ZXpldDEMMAoGA1UECxMDQUFJMRQwEgYD
VQQDEwtpZHAubmlpZi5odTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN06iS7LKoLF
5t5bUWBBUKnoMTVaufs1YMpiZKtEmbLqI/bNC4oq84JIf7118r698SjrZrLUbXLdnp9WIt4iAcHp
iY0Fa+0EJbtuylPuJ9iSzkqp9LIHwDbDid88kYAhM/MgELmKnn5xKUriskP2Z9He73j2JcLIeCUL
r20g4cwwhOed8fdJHqTVrDhYn6tao4/gbInNA28t86oACFzPGCWarU2J1RMSDPK/5J8DDf/ZjYFj
ebiBgIVjNboj/YO/il4Syi3/dcw+4B6pMQvG/VkcMiB4/AnZ3nfSbuEuqDCz/SA1/lxXqYuRS+Qy
+KF9mh5dwHvxIw/OknAOkFgqnrMCAwEAAaOCAWowggFmMFAGA1UdIARJMEcwRQYHKoZIsT4BADA6
MDgGCCsGAQUFBwIBFixodHRwOi8vd3d3Lmdsb2JhbHNpZ24ubmV0L3JlcG9zaXRvcnkvY3BzLmNm
bTAOBgNVHQ8BAf8EBAMCBaAwHwYDVR0jBBgwFoAUZWWjPdc7EaMKByU3yUJKW3Z3UOEwHQYDVR0O
BBYEFHCsimk81XhEkoU79Q2SVj85b8OdMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZ2xv
YmFsc2lnbi5uZXQvZWR1Y2F0aW9uYWwuY3JsME8GCCsGAQUFBwEBBEMwQTA/BggrBgEFBQcwAoYz
aHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLm5ldC9jYWNlcnQvZWR1Y2F0aW9uYWwuY3J0MB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAWBgNVHREEDzANggtpZHAubmlpZi5odTANBgkqhkiG
9w0BAQUFAAOCAQEATd78nlxnA5rMRwmbsa7yUssbx0sO86A3sFc28OLp92uYdgLMc0/Vg/hG3mAH
wA9CwaSeBbBRB2GK34vFFi6nCgWQomf+QuWkbarYBrFbG1LZ1VfvKdy3HewLwGI2cTsxVN67uUjE
+EsYna1yDWJY8GcaAvnkuey+O6HDSgmLy4lLdLKFbIcx4zL6ZBrXmFARc1oemRmZ3gJROTylfL8n
lM8T8MmiZESdDLoldxAHhMLtnLBWJcyfzfu70qPX/aXxnoLkoMl6Qz1CRQYjWOnn88g1MvWbg7aG
8thm/tTFesjf9uo4Ma9Rs86CwS21iaJNp/joRYmb0NfN9tLpAP2Kjw==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion ID="_914a5a444f1802bfaa78fd151855642a" IssueInstant="2009-05-12T08:19:27.303Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.niif.hu/shibboleth</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_1ea7e9633566f74726244c463af2e397</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData Address="193.6.223.101" InResponseTo="_37534da3d36f1d629638c464f2614881" NotOnOrAfter="2009-05-12T08:24:27.303Z" Recipient="https://be.aai.niif.hu/Shibboleth.sso/SAML2/POST"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2009-05-12T08:19:27.303Z" NotOnOrAfter="2009-05-12T08:24:27.303Z">
<saml:AudienceRestriction>
<saml:Audience>urn:niif.hu:aai:HREF:be:be.aai.niif.hu</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2009-05-12T08:19:27.145Z" SessionIndex="35dd1f81812518aa35822c97780abed2e137b049fcbb66d5dd89d78560cc8bc9">
<saml:SubjectLocality Address="193.6.223.101"/>
<saml:AuthnContext>
<saml:AuthnContextDeclRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</saml:AuthnContextDeclRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute FriendlyName="schacHomeOrganizationType" Name="urn:oid:1.3.6.1.4.1.25178.1.2.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:mace:terena.org:schac:homeOrganizationType:int:nren</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="cn" Name="urn:oid:2.5.4.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Bajnok Kristóf</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">bajnokk@niif.hu</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">employee@niif.hu</saml:AttributeValue>
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">staff@niif.hu</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="sn" Name="urn:oid:2.5.4.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Bajnok</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="givenName" Name="urn:oid:2.5.4.42" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Kristóf</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="schacHomeOrganization" Name="urn:oid:1.3.6.1.4.1.25178.1.2.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">niif.hu</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="eduPersonOrgDN" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">o=niifi,o=niif,c=hu</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">bajnokk@niif.hu</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="eduPersonEntitlement" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:niif.hu:services:aai:entitlement:test1</saml:AttributeValue>
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:niif.hu:services:aai:entitlement:test2</saml:AttributeValue>
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:mace:rediris.es:entitlement:wiki:jra5</saml:AttributeValue>
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:geant:edugain:entitlement:eduroam:TTS</saml:AttributeValue>
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:geant:edugain:entitlement:eduroam:wiki</saml:AttributeValue>
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:mace:rediris.es:entitlement:wiki:tfemc2</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
HREFPolicyStub
Általános elvárások
- A Tag és Partner az NIIFI-vel az NIIF AAI üzemeltetése érdekében folyamatosan együttműködik, különösen az NIIF AAI-val összefüggésben felmerülő visszaélések kivizsgálása érdekében.
- Az NIIF AAI Operátor a föderáció zavartalan üzemeltetése érdekében utólagos monitoring vizsgálatot végezhet, amely során jogosult ellenőrizni:
- az Üzemeltetéssel kapcsolatos műszaki elvárások és feltételekben meghatározott kötelezettségek betartását;
- azonosítási eljárások megfelelőségét;
- a hatályban lévő adatvédelmi és felhasználói szabályzatnak a Tagok Tanácsa Ajánlásainak megfelelő módosítását;
- a Tagok Tanácsa egyéb Ajánlásainak való megfelelést.
- A Tag biztosítja, hogy a Metadata mindenkor csak az aktuális adatokat tartalmazza, ennek érdekében évente önellenőrzést végez.
Adatvédelmi elvárások
- A Tag és a Partner biztosítja, hogy az NIIF AAI működése során közöttük a személyes adatok kezelése a vonatkozó jogszabályoknak megfelelő módon történik. Így különösen:
- a személyes adatok kezelése csak törvényi felhatalmazás vagy felhasználói önkéntes, határozott és tájékozott hozzájárulásán alapul, amellyel beleegyezését fejezi ki az őt érintő személyes adatok kezelésébe.
- a Tag vagy a Partner által üzemeltetett föderációs szolgáltatás csak a működtetéséhez feltétlenül szükséges adatokat igényli a felhasználókról
- Mind az Tag, mind a Partner rendelkezik a személyes adatok kezelését megfelelően rendező adatkezelési szabályzattal, amely rendelkezik különösen:
- a kezelt személyes adatok köréről;
- az adatkezelés céljáról;
- az adatkezelés időtartamáról;
- az adatalanyokat érintő tiltakozási jog lehetőségéről.
- Mind a Tag, mind a Partner a mindenkor hatályos adatkezelési szabályzatukat, egy az NIIF AAI által fenntartott központi helyen elérhetővé teszik.
- A Tag biztosítja, hogy csak olyan saját szolgáltatást (Saját SP) regisztrál a Metadatába, amely
- tiszteletben tartja az NIIF AAI működtetését megalapozó alapelveket továbbá;
- betartja az Üzemeltetéssel kapcsolatos műszaki elvárások és feltételekben foglalt kötelezettségek, az ott meghatározott feltételeknek már az NIIF AAI-hez való csatlakozás pillanatában, továbbá az NIIF AAI tagsága során mindvégig megfelel;
- az üzemeltetéssel kapcsolatos műszaki elvárások és feltételekben foglalt kötelezettségeknek való folyamatos megfelelés érdekében feliratkozik az NIIF AAI Operátor által üzemeltetett levelezőlistára, valamint folyamatosan kapcsolatot tart az NIIF AAI Operátorral és az NIIF AAI többi résztvevőjével;
- biztosítja az azonosítási eljárások megfelelőségét és elérhetőségét;
- az Üzemeltetéssel kapcsolatos műszaki elvárások és feltételekben foglalt kötelezettségek elmulasztásából eredő károkért teljes körű felelősséggel tartozik;
- betartja az NIIF AAI működését szabályozó kötelező dokumentumok (Csatlakozási Szerződés, Szabályzat) vonatkozó rendelkezéseit.
- A Tag felelősséget vállal, hogy a Saját SP vállalt kötelezettségeinek eleget tesz, továbbá ezen kötelezettségeinek elmulasztásából eredő károkért teljes körű felelősséggel tartozik.
- Adatminőség
- z adatkezelés során a személyes adat felvételének és kezelésének nemcsak tisztességesnek és törvényesnek kell lennie, de az így rögzített adatnak pontosnak, teljesnek, és ha szükséges időszerűnek is kell lennie.
- személyes adat tárolási módjának alkalmasnak kell lennie arra, hogy az érintett felhasználót csak a tárolás céljához szükséges ideig lehessen azonosítani.
- z adatminőség biztosítása érdekében az Idp AAI adatbázis adatait authoritatív adatbázisban rögzített adatok alapján célszerű létrehozni, így az adatok folyamatosan frissülésével azok időszerűsége, pontossága nem vitatott.
- mennyiben nem az IdP AAI adatbázis nem autoratív adatbázis alapján működik az Tagnak meg kell tennie a szükséges lépéseket az adatminőség biztosítása érdekében.
Identitás kezeléssel kapcsolatos elvárások
- A Tag biztosítja, hogy a Felhasználó regisztrációs folyamata, továbbá az NIIF AAI regisztrációjának törlése megfelelően dokumentált legyen.
- Az Tag mindent megtesz annak érdekében, hogy az általa kiadott személyes adatok megfeleljenek az adatminőség törvényi követelményeinek, így azok pontosak és időszerűek legyenek.
- A Tag IdP AAI kapuja által szolgáltatott identitás-csoportokat (pl. hallgatók, oktatók) teljes módon kell nyilvántartani, így ennek megfelelően pl. nem csak egy csoportjuk számára szolgáltat TO DO
- A Tag a felhasználói identitáskezelés körében biztosítja, hogy a Felhasználók adataiban, ill. státuszában bekövetkezett változtatásoknak a változástól illetve a változás bejelentésétől számított 7 napon belül megjeleníti az NIIF AAI attribútumokban.
- Státusz adatok esetében a változást követő 7. napon;
- Személyi adatok esetében a változás bejelentéstől számított 7. napon;
- Szervezeti kapcsolódás adatait illetően a kapcsolódást elsődlegesen nyilvántartó rendszerben bekövetkező változástól számított 14. nap;
- Oktatással kapcsolatos adatok esetben az oktatási adatokat elsődlegesen nyilvántartó rendszerben bekövetkező változástól számított 30. napon.
- A Tag biztosítja, hogy az IdP AAI Kapu az attribútum specifikációban megkövetelt attribútumokat megvalósítsa.
A Tag és Partner egyéb kötelezettségei az NIIF AAI üzemeltetés érdekében
- A Tag az NIIF AAI megfelelő üzemeltetés érdekében biztosítja, hogy az IdP AAI Kapu a Felhasználó azonosítását követően kiadja az attribútumokat (ARP) az SP AAI Kapu részére.
- A Partner feltünteti a Resource Registry-ben a megkövetelt, ill. opcionális attribútumok körét, továbbá az NIIF AAI-ban történő részvétele során biztosítja, hogy az így megadott adatok mindig naprakészek legyenek.
AboutEduID.hu
Purpose of this document
This document is a collection of the information specified in several specific documents written in Hungarian. Since only Hungarian educational and research institutions are expected to be Federation Members (ie. operate an Identity Provider), this document focuses on rules what are relevant to (international) Federation Partners.
About the federation
Hungarian Research and Educational Federation (HREF) is a SAML2-based Identity Federation of Hungarian higher education and research institutions, public collections and other content providers. For the end-users, the federation aims to be transparent, therefore the login procedure is communicated as eduID login.
Contacts
The Federation is operated by NIIF Institute as a Federation Operator. Questions, concerns or any kind of requests about the Federation should be directed to any of the following addresses:
- aai@niif.hu
- Kristof Bajnok, NIIF Institute
- 18-22 Victor H. str
- H-1132 Budapest
- Hungary
News and information about the federation is published at http://eduid.hu (Hungarian only)
Policy and principles of interoperation
Basic principles
- The aim of the Federation is to allow the use of services of its Members and Partners, where authorisation is based on the user information originating from the users' Home Institutions.
- Home Institutions must only authenticate users having a known affiliation to them.
- IdPs and SPs must not give false or misleading information about themselves.
- User information provided by IdPs should be as accurate as possible. SPs must take into account that parts of the received information may be at the discretion of the user.
- User credentials (i.e. passwords) stored by IdPs must be protected and verified only through secure procedures.
- SPs must request only the user attributes which are absolutely necessary for their operation.
- SPs must not ask users for their federation passwords.
- SPs must handle personal data according to the local privacy laws.
- IdPs and SPs must cooperate in the investigation of possible abuse/fraud.
- IT systems running IdPs and SPs must be operated with due diligence.
Data protection
- Prior joining the federation, every entity needs to publish the Data Protection Policy under which it operates. This policy must be kept up-to-date.
- Whenever the Data Protection Policy changes, the Federation Operator must be notified.
- Transfer of personal data is only allowed when either
- authorised by law, or
- the user expressed his or her consent on the data transfer.
Rules of membership
The Federation is operated by the Federation Operator, that also operates the national research network. Further participants are Members and Partners that must have a signed contract with the Operator.
- The following institutions may be Members of the federation:
- Institutions of the higher education;
- Institutions of the Hungarian Research Academy and other research institutions;
- Institutions of secondary education;
- Public collections.
- Any organisation might join as a Partner.
- All Members and Partners of the Federation might provide services.
- A Partner might participate in the meeting of the Members' Board as an observer, without having rights to vote.
- Only Members are entitled to
- supply user identity information to the federation
- send representatives into the Members' Board with a right to vote.
Governance
The governance body of the federation is the Members' Board (MB). Every Federation Member may send one representative person to the Members' Board, who has one vote.
The working language of the MB is Hungarian. The Board publishes its decisions and guidelines at http://eduid.hu/dokumentumok in Hungarian, although whenever the topic is of interest of any international Partner, it shall be translated to English and the administrative contacts shall be notified.
- accept new Federation documents or modify existing ones,
- accept application of new Members and Partners
Partners may also send representatives for MB meetings, without voting rights.
Legal
The Federation itself is not a legal entity, Members and Partners establish a legal connection to the Federation Operator. Any legal claims between Members and/or Partners shall be directed to the organisation operating the Identity Provider or the Service Provider.
The Service Agreement between the Federation Operator and Partner is available here.
Technical information
Operational requirements
Attributes
Attribute Specification is maintained in a separate document.
As a brief summary, the following attributes are mandatory or recommended: | Mandatory attributes | Recommended attributes | |---| |eduPersonPrincipalName |displayName | |eduPersonTargetedID |mail | |eduPersonScopedAffiliation |eduPersonEntitlement | |schacHomeOrganizationType |
IdPs may implement other attributes.
Metadata
Metadata Specification is maintained in a separate document.
How to join
Production federation
In order to join the production federation as a Partner, you need to send the following information:
- SP metadata URL (HTTPS preferred)
- Name of the SP
- Brief description of the service
- Service URL
- Privacy policy URL
- Administrative and technical contact names and mail addresses (non-personal preferred)
- Required and optional attributes
- Logo URL (optional)
- Helpdesk URL (optional)
This information should be sent to the Federation Operator (see above) in email. Two copies of the signed Service Agreement (available at http://eduid.hu/documents) should be sent by traditional post, one copy will be returned after counter-signing.
After the application has been reviewed by the Federation Operator, it is forwarded to the Members' Board. It usually takes 3-5 working days for the Board to accept the application, after which the entity metadata is be added to the production federation metadata.
Testing metadata
It is recommended that a new SP should be registered to the testing federation at first, which is much easier and a fully online process.
The following information is necessary to enter into the testing metadata:
- SP metadata URL (HTTPS preferred)
- Name of the SP
- Administrative and technical contact names and mail addresses (non-personal preferred)
- Required and optional attributes
You can ask for test accounts in our Virtual Home Organization. During testing, you might want to use the production federation metadata, because the VHO is present in both metadata files.
You do not need to re-register your entity to proceed to the production federation. If we have all the necessary information, the starting of the joining process is at your discretion.
Shib2IdpRHELQuickStart
Ideális esetben az alábbi lépéseket végigjárva működő IdP-t kaphatunk RHEL, vagy ezzel rokonrendszereken.
Előkészületek
Tűzfal
- Be kell majd engedni a 443-as és a 8443-as portokat
Shibboleth IdP letöltése
cd /tmp
wget http://software.niif.hu/maven2/edu/internet2/middleware/shibboleth-identityprovider/2.2.1-slo10/shibboleth-identityprovider-2.2.1-slo10-bin.tar.gz
tar xzf shibboleth-identityprovider-2.2.1-slo10-bin.tar.gz
Telepíteni is fogjuk később, de előbb beállítjuk a környezetet. A kicsomagolt állományból is kell majd ezt-azt másolni, ezért vettük előre a folyamatot.
Tomcat
-
Telepítsünk Tomcat 6-ot
cd /etc/yum.repos.d wget 'http://www.jpackage.org/jpackage50.repo' yum update rpm -Uvh 'http://plone.lucidsolutions.co.nz/linux/centos/images/jpackage-utils-compat-el5-0.0.1-1.noarch.rpm' yum install tomcat6 tomcat6-webapps tomcat6-admin-webapps
-
Be kell másolni a letöltött Shibboleth pakkban található endorsed library-ket a tomcatnek mkdir /usr/share/tomcat6/endorsed cp /tmp/shibboleth-identityprovider-2.2.1-slo10/endorsed/*.jar /usr/share/tomcat6/endorsed/
A /etc/tomcat6/tomcat6.conf
állományba tegyük be az alábbi sort:
JAVA_ENDORSED_DIRS="/usr/share/tomcat6/endorsed"
-
A leendő shibboleth idp webalkalmazás paramétereit is adjuk meg
cd /etc/tomcat6/Catalina/localhost vim idp.xml
A fájl tartalma pedig a következő legyen (úgy tervezzük, hogy a /usr/local/shibboleth-idp alá telepítünk mindjárt)
<Context
docBase="/usr/local/shibboleth-idp/war/idp.war"
privileged="true"
antiResourceLocking="false"
antiJARLocking="false"
unpackWAR="false" />
Apache
A webszervernek meg kell mondani, hogy egyfelől hallgasson a 8443-as porton is, másfelől, hogy a /idp-re érkező kéréseket proxyzza tovább a tomcat felé
SSO URL (443-as port)
Be kell állítani a virtuális hosztot, amelyhez az IdP-t rendeltük. Először a 443-as portot konfiguráljuk. A 443-as porthoz tartozó tanúsítványok nem azonosak a 8443-as porthoz tartozóéval.
<VirtualHost _default_:443>
ServerName aai.example.org:443
SSLEngine On
SSLCertificateFile /etc/ssl/certs/aai.example.org.crt
SSLCertificateKeyFile /etc/ssl/private/aai.example.org.key
SSLCertificateChainFile /etc/ssl/certs/aai.example.org.crt
ProxyRequests Off
<Proxy ajp://localhost:8009>
Allow from all
</Proxy>
ProxyPass /idp ajp://localhost:8009/idp retry=5
</VirtualHost>
Ezen a porton valamilyen széles körben ismert tanúsítványt kell használni, mivel a felhasználók böngészőjének ismerniük kell(ene) a kibocsátót.
AA ill. Artifact (8443-as port)
Ezen keresztül az SP és az IdP közvetlenül kommunikálnak egymással. Ide arra a tanúsítványra van szükség, amely a föderációs metadatában szerepel - az aláírója nem érdekes.
A csatorna felépítésekor az IdP és az SP is autentikálja magát. Az SP autentikációját az Apache végzi, ami nem végez kibocsátó-ellenőrzést (optional_no_ca
). Ez utóbbit az IdP alkalmazás végzi el, ezért nagyon fontos, hogy a kliens tanúsítványát az Apache továbbadja az alkalmazásnak (ExportCertData
).
<VirtualHost _default_:8443>
ServerName aai.example.org:8443
SSLEngine On
SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:!SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
SSLCertificateFile /usr/local/shibboleth-idp/credentials/idp.crt
SSLCertificateKeyFile /usr/local/shibboleth-idp/credentials/idp.key
SSLVerifyDepth 10
SSLVerifyClient optional_no_ca
SSLOptions -StdEnvVars +ExportCertData
ProxyRequests Off
<Proxy ajp://localhost:8009>
Allow from all
</Proxy>
ProxyPass /idp ajp://localhost:8009/idp retry=5
</VirtualHost>
A virtuális hoszt engedélyezése után be kell tölteni az ssl
és proxy_ajp
modulokat, majd újra kell indítani az apache-ot.
Telepítés
cd /tmp/shibboleth-identityprovider-2.2.1-slo10
./install.sh
Utómunkálatok
Jogosultságok beállítása
Engedjük meg, hogy a tomcat írja a log ill. a metadata könyvtárat
chown -R tomcat:tomcat /usr/local/shibboleth-idp/logs /usr/local/shibboleth-idp/metadata
Naplófájlok rotálása
Az alapértelmezett logging.xml nem törli a régi állományokat, ezért ezek egy idő után megtöltik a diszket.
Erre a korrekt megoldás az (lenne), ha a Logback alrendszert utasítjuk, hogy az N (a példában 90) napnál régebbi fájlokat rotálja ki. Ehhez a logging.xml
-ben adjuk meg a maxHistory
paramétert az összes rollingPolic
y-nál, valahogy így:
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<FileNamePattern>/usr/local/shibboleth-idp/logs/idp-access-%d{yyyy-MM-dd}.log</FileNamePattern>
<maxHistory>4</maxHistory>
</rollingPolicy>
Sajnos azonban jelenleg a logback csak egy állományt töröl, a régi file-okat megtartja (pl. akkor is, ha több, mint egy napig nem futott az IdP. Amíg ez nincs megoldva, addig kerülő megoldás lehet cron-ból törölni a régi file-okat
sudo crontab -u tomcat -e
MAILTO=mail@example.com
#m h dom mon dow command
52 18 * * * find /var/log/shibboleth-idp/ -mtime +90 -delete
Ellenőrzés
Ahhoz, hogy kiderítsük, működik-e (ill. fut-e :) ) az IdP webalkalmazásunk, ahhoz böngészőben hívjuk meg az alábbi urlt: https://idp.example.org/idp/profile/Status, amennyiben az oldalon egy ok-t látunk, akkor az alkalmazásunk fut, és elkezdhetjük beállítani az attribútumok feloldását és kiadását.
Konfiguráció
Ha idáig rendben vagyunk, nyergeljünk át erre a szócikkre
NIIFSchema
NIIF LDAP Schema
Versioning
Current version: 2.3
Change log
-
changes in 2.3
- extend niifAuthenticatedObject with niifValidityStart and niifExpireTime attributes
-
changes since 2.1b2
- add niifAuthenticatedObject and its niifEduroamPassword
-
changes since 2.1b1
- updated schema files
-
changes since 2.0b5
- add niifCertificateSHA1Fingerprint
- add niifEduPersonArchiveCourse
- add niifEduPersonHeldCourse
- mark niifCertificateSubjectDN as obsolete
Schema files
- Sun DS format: 99-niifschema.ldif
- OpenLDAP format: niif-openldap.schema
- niifauthentication.ldif{:doenload="niifauthentication.ldif"}
ObjectClasses
niifPerson
niifPerson | |
---|---|
Parent | inetOrgPerson |
OID | 1.3.6.1.4.1.11914.0.0.0 |
Description | - |
Mandatory attributes | - |
Optional attributes |
|
niifEduPerson
niifEduPerson | |
---|---|
Parent | eduPerson |
OID | 1.3.6.1.4.1.11914.0.0.9 |
Description | - |
Mandatory attributes | - |
Optional attributes |
niifAuthenticatedObject
niifAuthenticatedObject | |
---|---|
Parent | - |
OID | 1.3.6.1.4.1.11914.0.0.10 |
Description | An object having extra passwords or time-limited validity |
Mandatory attributes | - |
Optional attributes |
Defined attributes
Attributes of niifPerson
niifUniqueID
niifUniqueID | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.3 |
Description | Unique ID of a person. |
Semantics | <unique-local-ID>@<organization-domain> The <organization-domain> part equals to the main internet domain of the organization (i.e.: 'sztaki.hu').The <unique-local-ID> part is a sequence of letters (case insensitive) and numbers. It can be freely chosen by the home organization provided that the ID is unique within the scope of the organization and one and only one ID is assigned to every single person. |
Values | nincs korlátozás |
# of values | single |
Availability | organizational |
Syntax | Directory String |
Examples | gmx3f0@bme.hu |
Notes | It is up to the local policy to define how the <unique-local-ID> is generated and how long does it represent a user. However, assigning the same ID to another person (after the first person entry has been removed from the directory) is deprecated.It is recommended to import the user ID into <unique-local-ID> from a comprehensive user database (like Neptun and ETR at Hungarian Universities) if such a database exists. |
Use in federation | - |
niifPrefix
niifPrefix | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.0 |
Description | OBSOLETED, use niifPersonPrefix |
Semantics | - |
Values | nincs korlátozás |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | - |
Notes | - |
Use in federation | - |
niifPersonPrefix
niifPersonPrefix | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.165 |
Description | Prefix of the person's name |
Semantics | A name should have only one prefix, multiple entitlements may be listed one after the other in the same value |
Values | nincs korlátozás |
# of values | single |
Availability | public |
Syntax | Directory String |
Examples | Prof. Dr. |
Notes | - |
Use in federation | HREF_attribútum_specifikáció#schacPersonalTitle |
niifStatus
niifStatus | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.1 |
Description | OBSOLETED, use niifPersonDegree |
Semantics | - |
Values | nincs korlátozás |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | - |
Notes | - |
Use in federation | - |
niifPersonDegree
niifPersonDegree | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.166 |
Description | Scientific degree of the person |
Semantics | Only the highest degree should be stored. |
Values | nincs korlátozás |
# of values | multi |
Availability | public |
Syntax | Directory String |
Examples | kandidátus |
Notes | May be specified in multiple languages by the use of language tags |
Use in federation | - |
niifTitle
niifTitle | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.2 |
Description | OBSOLETED, use niifPersonPosition |
Semantics | - |
Values | nincs korlátozás |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | - |
Notes | - |
Use in federation | - |
niifPersonPosition
niifPersonPosition | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.167 |
Description | Position of the person within a department or organization |
Semantics | - |
Values | nincs korlátozás |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | dékán |
Notes | May be specified in multiple languages by the use of language tags.When a person is in relationship with multiple departments or organizations, no exact match between a status and a particular organization can be defined within an entry. To solve this situation, some relation-representing entry may be used, eg. use of the schacPersonalPosition attribute, which defines an URN format for this purpose. |
Use in federation | - |
niifCertificateSubjectDN
niifCertificateSubjectDN | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.151 |
Description | Subject DN of the certificate of the entity. This attribute is OBSOLETED, use niifCertificateSHA1Fingerprint instead. |
Semantics | The value must describe a DN which identifies the certificate subject of the entity. |
Values | Unlike standard LDAP DN, this value must contain the same number of spaces between DN elements as it is tied in the certificate. |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | - |
Notes | Although it is possible for an entity to have more than one certificates at the same time, this kind of usage is deprecated.When used, this attribute must be indexed. This attribute may be applied to any kind of entities that can be certified with an X.509 certificate, including persons, servers, network nodes, etc. |
Use in federation | - |
niifCertificateSHA1Fingerprint
niifCertificateSHA1Fingerprint | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.173 |
Description | Fingerprint of a certificate which belongs to the subject. |
Semantics | Multiple fingerprints may be stored in this attribute, if a subject has multiple valid certificates. This attribute uses case insensitive matching rule. |
Values | SHA-1 hash in hexadecimal string format without any separator characters. |
# of values | multi |
Availability | - |
Syntax | IA5String |
Examples | fe6d5980e2c02912024054cec114ee53ebeb2e6c |
Notes | - |
Use in federation | - |
niifPersonDateOfBirth
niifPersonDateOfBirth | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.152 |
Description | Date of birth of the person |
Semantics | - |
Values | YYYYMMDD date format according to RFC 3339 'full-date' format |
# of values | single |
Availability | confidential |
Syntax | Directory String |
Examples | 19800316 |
Notes | It's recommended to use the schacDateOfBirth attribute instead, as it has the same syntax and semantics. |
Use in federation | HREF_attribútum_specifikáció#schacDateOfBirth,HREF_attribútum_specifikáció#schacYearOfBirth |
niifPersonActivityStatus
niifPersonActivityStatus | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.153 |
Description | Activity status |
Semantics | Describes whether the person is an active employee/student of the home organization |
Values | One of the term 'active' or 'inactive' |
# of values | single |
Availability | organizational |
Syntax | Directory String |
Examples | - |
Notes | - |
Use in federation | - |
niifActiveMemberOf
niifActiveMemberOf | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.168 |
Description | DN of a group entry to which the entity currently belongs. |
Semantics | - |
Values | nincs korlátozás |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | - |
Notes | As a special case, this attribute may be used to keep a record of a student's active major(s), but it's recommended to use niifEduPersonMajor instead. |
Use in federation | - |
niifPersonJoinDate
niifPersonJoinDate | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.169 |
Description | Date of joining to the organization |
Semantics | Date of joining to the organization. For students it may represent the first date of enrollment. |
Values | YYYYMMDD date format according to RFC 3339 'full-date' format |
# of values | single |
Availability | organizational |
Syntax | Integer |
Examples | 19980901 |
Notes | - |
Use in federation | - |
niifPersonQuitDate
niifPersonQuitDate | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.170 |
Description | Date of leaving the organization |
Semantics | - |
Values | YYYYMMDD date format according to RFC 3339 'full-date' format. |
# of values | single |
Availability | organizational |
Syntax | Integer |
Examples | 20030627 |
Notes | If this date is in the past, niifPersonActivityStatus must be 'inactive', and the user should be locked out. |
Use in federation | - |
niifPersonOrgID
niifPersonOrgID | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.154 |
Description | Organizational ID of a person |
Semantics | ID of a person in a comprehensive organizational user database if such a database exists. This ID shall be unique within the organization.It is strongly recommended to use the <unique-local-ID> part of the niifUniqueID as a value for niifPersonOrgID. |
Values | For integration with niifUniqueID, value must not contain the '@' mark. |
# of values | single |
Availability | - |
Syntax | Directory String |
Examples | - |
Notes | It is recommended to import the user ID into <unique-local-ID> from a comprehensive user database (like Neptun and ETR at Hungarian Universities) if such a database exists.This attribute is for facilitating the use of user ID's in intra-organizational applications in cases when standard uid attribute can not be applied for some reason. |
Use in federation | - |
niifPersonCityOfBirth
niifPersonCityOfBirth | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.155 |
Description | The city or settlement where the person was born |
Semantics | Name of the city or settlement where the person was born. If the place of birth is outside the borders of Hungary, the name may be given in Hungarian. |
Values | nincs korlátozás |
# of values | single |
Availability | confidential |
Syntax | Directory String |
Examples | Kolozsvár |
Notes | It's recommended to use the schacPlaceOfBirth attribute instead. |
Use in federation | - |
niifPersonCountryOfBirth
niifPersonCountryOfBirth | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.156 |
Description | The country where the person was born |
Semantics | Name of the country where the person was born. If the place of birth is outside the borders of Hungary, the name must be given in Hungarian. |
Values | nincs korlátozás |
# of values | single |
Availability | confidential |
Syntax | Directory String |
Examples | Románia |
Notes | It's recommended to use the schacPlaceOfBirth attribute instead. |
Use in federation | - |
niifPersonMothersName
niifPersonMothersName | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.157 |
Description | Name of the mother of the person |
Semantics | Maiden name of the mother of the person. |
Values | nincs korlátozás |
# of values | single |
Availability | confidential |
Syntax | Directory String |
Examples | - |
Notes | - |
Use in federation | - |
niifPersonIdentityNumber
niifPersonIdentityNumber | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.158 |
Description | Number of the Identity Card |
Semantics | Number of the Identity Card of the person or Passport Number for those who are non-Hungarian citizens |
Values | nincs korlátozás |
# of values | single |
Availability | confidential |
Syntax | Directory String |
Examples | 329906AA |
Notes | Every Hungarian citizen by the age of 14 receives an Identity Card. For foreigners, Passport Number should be used. This number should never be made public.Format of the code may vary as numbering scheme has been changed in the recent years.It's recommended to use the URN-formatted schacPersonalUniqueID attribute instead. |
Use in federation | - |
niifPersonResidentialAddress
niifPersonResidentialAddress | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.159 |
Description | Home address of the person |
Semantics | Permanent home address of the person. The postal code, the name of the city, street and apartment number shall be included. |
Values | nincs korlátozás |
# of values | single |
Availability | confidential |
Syntax | Directory String |
Examples | 1234 Budapest, Harap u. 3. |
Notes | - |
Use in federation | - |
Attributes of niifEduPerson
niifEduPersonFaculty
niifEduPersonFaculty | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.160 |
Description | Faculty of the person |
Semantics | Full name of the faculty the person belongs to. List of accredited faculties can be found here (in institutional order): http://www.mab.hu/doc/akkrint040106.doc (in Hungarian) |
Values | nincs korlátozás |
# of values | multi |
Availability | organizational |
Syntax | Directory String |
Examples | Villamosmérnöki és Informatikai Kar |
Notes | Local directory policy may mark this attribute as mandatory.It is recommended if an LDAP entry has niifEduPersonFaculty attribute set, it should also have an eduPersonFacultyDN attribute pointing to the entry of the faculty. |
Use in federation | - |
niifEduPersonFacultyDN
niifEduPersonFacultyDN | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.161 |
Description | Pointer to the faculty of the person |
Semantics | - |
Values | nincs korlátozás |
# of values | multi |
Availability | organizational |
Syntax | DN |
Examples | - |
Notes | This attribute has a meaning only if the person participates in education (eduPersonAffiliation=student or faculty)Local directory policy may mark this attribute as mandatory. |
Use in federation | - |
niifEduPersonMajor
niifEduPersonMajor | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.162 |
Description | Major(s) of the student |
Semantics | Majors are defined at http://www.mab.hu/listak2.html (in Hungarian) |
Values | nincs korlátozás |
# of values | multi |
Availability | organizational |
Syntax | Directory String |
Examples | műszaki informatikai |
Notes | This attribute has a meaning only if the person is a student (eduPersonAffiliation=student)Local directory policy may mark this attribute as mandatory for students. |
Use in federation | - |
niifEduPersonAcademicYear
niifEduPersonAcademicYear | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.163 |
Description | Current academic year of the student. This attribute is DEPRECATED. |
Semantics | - |
Values | Integer numbers from 1 to the number of years required for graduation |
# of values | multi |
Availability | confidential |
Syntax | Directory String |
Examples | - |
Notes | This attribute has a meaning only if the person is a student (eduPersonAffiliation = student)It is unclear that if a student has more than one majors, the number of which should be stored in this attribute and how a connection between major and year can be set up. As the concept of academic year gets lesser important (and not well-defined), depending on the value of this attribute is deprecated. |
Use in federation | - |
niifEduPersonAttendedCourse
niifEduPersonAttendedCourse | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.164 |
Description | Code of the courses the student attends to in the current semester |
Semantics | - |
Values | Course codes defined in the student calendar. |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | |
Notes | This attribute has a meaning only if the person is a student (eduPersonAffiliation = student), and the values should be taken from the student calendar. |
Use in federation | - |
niifEduPersonArchiveCourse
niifEduPersonArchiveCourse | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.171 |
Description | Code of the courses the student have ever attended |
Semantics | - |
Values | Course codes defined in the student calendar. |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | - |
Notes | This attribute has a meaning only if the person is a student (eduPersonAffiliation = student), and the values should be taken from the student calendar. |
Use in federation | - |
niifEduPersonHeldCourse
niifEduPersonHeldCourse | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.172 |
Description | Code of the courses which are associated with the faculty member or professor in the current semester. |
Semantics | - |
Values | Course codes defined in the student calendar. |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | - |
Notes | This attribute has a meaning only if the person is a faculty (eduPersonAffiliation = faculty), the values should be taken from the student calendar.For authorization decision reasons, courses from previous semester(s) might appear in this attribute if the local policy needs these additional values. |
Use in federation | - |
Attributes of niifAuthenticatedObject
niifEduroamPassword
niifEduroamPassword | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.4 |
Description | Clear text password for eduroam authentication |
Semantics | - |
Values | nincs korlátozás |
# of values | multi |
Availability | - |
Syntax | Octet String |
Examples | - |
Notes | SUP userPassword |
Use in federation | - |
niifValidityStart
niifValidityStart | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.5 |
Description | When to enable this account |
Semantics | - |
Values | nincs korlátozás |
# of values | single |
Availability | - |
Syntax | Generalized Time |
Examples | - |
Notes | - |
Use in federation | - |
niifExpireTime
niifExpireTime | |
---|---|
OID | 1.3.6.1.4.1.11914.0.1.6 |
Description | When to disable this account |
Semantics | - |
Values | nincs korlátozás |
# of values | single |
Availability | - |
Syntax | Generalized Time |
Examples | - |
Notes | - |
Use in federation | - |
Shib2SP
Az SP-t a shibboleth2.xml
állományon keresztül konfigurálhatjuk. Ebben a leírásban feltételezzük, hogy az SP konfigurációja a /etc/shibboleth
könyvtárban van.
Előkészületek
- Telepítsük a shibbolethet
- Válasszunk egy egyedi azonosítót, ún.
entityID
-t az SP számára. Ez az azonosító URL formájú, létező hosztnév, egy - alapértelmezés szerint - /shibboleth path-szal. Pl: https://lipton.aai.niif.hu/shibboleth. Megfelelő konfiguráció után az entityID-t meghívva válaszul az adott entitás metaadatát kapjuk válaszul.
Működő példa konfiguráció 1
<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
clockSkew="180">
<!--
By default, in-memory StorageService, ReplayCache, ArtifactMap, and SessionCache
are used. See example-shibboleth2.xml for samples of explicitly configuring them.
-->
<!--
To customize behavior for specific resources on Apache, and to link vhosts or
resources to ApplicationOverride settings below, use web server options/commands.
See https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPConfigurationElements for help.
For examples with the RequestMap XML syntax instead, see the example-shibboleth2.xml
file, and the https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRequestMapHowTo topic.
-->
<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
<ApplicationDefaults entityID="https://events.prace-ri.eu/shibboleth"
REMOTE_USER="eppn"
cipherSuites="ECDHE+AESGCM:ECDHE:!aNULL:!eNULL:!LOW:!EXPORT:!RC4:!SHA:!SSLv2">
<!--
Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
You MUST supply an effectively unique handlerURL value for each of your applications.
The value defaults to /Shibboleth.sso, and should be a relative path, with the SP computing
a relative value based on the virtual host. Using handlerSSL="true", the default, will force
the protocol to be https. You should also set cookieProps to "https" for SSL-only sites.
Note that while we default checkAddress to "false", this has a negative impact on the
security of your site. Stealing sessions via cookie theft is much easier with this disabled.
-->
<Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
checkAddress="false" handlerSSL="false" cookieProps="http">
<!--
Configures SSO for a default IdP. To allow for >1 IdP, remove
entityID property and adjust discoveryURL to point to discovery service.
(Set discoveryProtocol to "WAYF" for legacy Shibboleth WAYF support.)
You can also override entityID on /Login query string, or in RequestMap/htaccess.
-->
<SSO discoveryProtocol="SAMLDS" discoveryURL="https://mdx.eduid.hu/role/idp.ds">
SAML2 SAML1
</SSO>
<!-- SAML and local-only logout. -->
<Logout>SAML2 Local</Logout>
<!-- Extension service that generates "approximate" metadata based on SP configuration. -->
<Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
<!-- Status reporting service. -->
<Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>
<!-- Session diagnostic service. -->
<Handler type="Session" Location="/Session" showAttributeValues="false"/>
<!-- JSON feed of discovery information. -->
<Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
</Sessions>
<!--
Allows overriding of error template information/filenames. You can
also add attributes with values that can be plugged into the templates.
-->
<Errors supportContact="prace-indico-admin@niif.hu"
helpLocation="/about.html"
styleSheet="/shibboleth-sp/main.css"/>
<MetadataProvider type="Dynamic" ignoreTransport="true">
<Subst>https://mdx.eduid.hu/entities/$entityID</Subst>
<MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
</MetadataProvider>
<!-- Example of remotely supplied batch of signed metadata. -->
<!--
<MetadataProvider type="XML" validate="true"
uri="http://example.org/federation-metadata.xml"
backingFilePath="federation-metadata.xml" reloadInterval="7200">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="fedsigner.pem"/>
<DiscoveryFilter type="Blacklist" matcher="EntityAttributes" trimTags="true"
attributeName="http://macedir.org/entity-category"
attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
attributeValue="http://refeds.org/category/hide-from-discovery" />
</MetadataProvider>
-->
<!-- Example of locally maintained metadata. -->
<!--
<MetadataProvider type="XML" validate="true" file="partner-metadata.xml"/>
-->
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>
<!-- Use a SAML query if no attributes are supplied during SSO. -->
<AttributeResolver type="Query" subjectMatch="true"/>
<!-- Default filtering policy for recognized attributes, lets other data pass. -->
<AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>
<!-- Simple file-based resolver for using a single keypair. -->
<CredentialResolver type="File" key="events-shib.key" certificate="events-shib.cert"/>
<!--
The default settings can be overridden by creating ApplicationOverride elements (see
the https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride topic).
Resource requests are mapped by web server commands, or the RequestMapper, to an
applicationId setting.
Example of a second application (for a second vhost) that has a different entityID.
Resources on the vhost would map to an applicationId of "admin":
-->
<!--
<ApplicationOverride id="admin" entityID="https://admin.example.org/shibboleth"/>
-->
</ApplicationDefaults>
<!-- Policies that determine how to process and authenticate runtime messages. -->
<SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
<!-- Low-level configuration about protocols and bindings available for use. -->
<ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>
</SPConfig>
Működő példa konfiguráció 2
<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
logger="syslog.logger" clockSkew="180">
<!-- The OutOfProcess section contains properties affecting the shibd daemon. -->
<OutOfProcess logger="shibd.logger">
<!--
<Extensions>
<Library path="odbc-store.so" fatal="true"/>
</Extensions>
-->
</OutOfProcess>
<!-- The InProcess section conrains settings affecting web server modules/filters. -->
<InProcess logger="native.logger">
</InProcess>
<!-- Only one listener can be defined, to connect in process modules to shibd. -->
<UnixListener address="shibd.sock"/>
<!-- <TCPListener address="127.0.0.1" port="12345" acl="127.0.0.1"/> -->
<!-- This set of components stores sessions and other persistent data in daemon memory. -->
<StorageService type="Memory" id="mem" cleanupInterval="900"/>
<SessionCache type="StorageService" StorageService="mem" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
<ReplayCache StorageService="mem"/>
<ArtifactMap artifactTTL="180"/>
<!-- This set of components stores sessions and other persistent data in an ODBC database. -->
<!--
<StorageService type="ODBC" id="db" cleanupInterval="900">
<ConnectionString>
DRIVER=drivername;SERVER=dbserver;UID=shibboleth;PWD=password;DATABASE=shibboleth;APP=Shibboleth
</ConnectionString>
</StorageService>
<SessionCache type="StorageService" StorageService="db" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
<ReplayCache StorageService="db"/>
<ArtifactMap StorageService="db" artifactTTL="180"/>
-->
<!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->
<RequestMapper type="Native">
<RequestMap applicationId="default">
<!--
The example requires a session for documents in /secure on the containing host with http and
https on the default ports. Note that the name and port in the <Host> elements MUST match
Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element
below.
-->
<Host name="wiki.aai.niif.hu" authType="shibboleth"
requireSession="false" applicationId="wiki.aai"
redirectErrors="https://wiki.aai.niif.hu/index.php/Kezd%C5%91lap">
<Path name="secure" requireSession="true" />
</Host>
<Host name="www.aai.niif.hu" authType="shibboleth"
requireSession="false" applicationId="www.aai">
<Path name="secure" requireSession="true" />
</Host>
</RequestMap>
</RequestMapper>
<!--
The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined.
Resource requests are mapped by the RequestMapper to an applicationId that
points into to this section.
-->
<ApplicationDefaults id="default" policyId="default"
entityID="https://lipton.aai.niif.hu/shibboleth"
homeURL="https://lipton.aai.niif.hu/shib-error.php"
REMOTE_USER="eppn persistent-id targeted-id"
signing="false" encryption="false"
>
<!--
Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
You MUST supply an effectively unique handlerURL value for each of your applications.
The value can be a relative path, a URL with no hostname (https:///path) or a full URL.
The system can compute a relative value based on the virtual host. Using handlerSSL="true"
will force the protocol to be https. You should also add a cookieProps setting of "; path=/; secure"
in that case. Note that while we default checkAddress to "false", this has a negative
impact on the security of the SP. Stealing cookies/sessions is much easier with this disabled.
-->
<Sessions lifetime="28800" timeout="3600" checkAddress="false"
handlerURL="/Shibboleth.sso" handlerSSL="true"
exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
idpHistory="false" idpHistoryDays="7">
<!--
SessionInitiators handle session requests and relay them to a Discovery page,
or to an IdP if possible. Automatic session setup will use the default or first
element (or requireSessionWith can specify a specific id to use).
-->
<!-- Directly to the IdP -->
<SessionInitiator type="Chaining" Location="/Login" id="Intranet"
relayState="cookie" entityID="https://idp.niif.hu/shibboleth">
<SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" defaultACSIndex="5"/>
</SessionInitiator>
<!-- Discovery Service -->
<SessionInitiator type="Chaining" Location="/DS" id="DS"
relayState="cookie" acsByIndex="false"
isDefault="true" >
<SessionInitiator type="SAML2" template="bindingTemplate.html"
defaultACSIndex="3" />
<SessionInitiator type="Shib1" defaultACSIndex="5" />
<SessionInitiator type="SAMLDS" URL="https://ds.niif.hu/"/>
</SessionInitiator>
<SessionInitiator type="Chaining" Location="/SAML1DS" acsByIndex="false" relayState="cookie"
id="Saml1Only">
<SessionInitiator type="Shib1" defaultACSIndex="6"/>
<SessionInitiator type="SAMLDS" URL="https://ds.niif.hu" />
</SessionInitiator>
<!--
md:AssertionConsumerService locations handle specific SSO protocol bindings,
such as SAML 2.0 POST or SAML 1.1 Artifact. The isDefault and index attributes
are used when sessions are initiated to determine how to tell the IdP where and
how to return the response.
-->
<md:AssertionConsumerService Location="/SAML2/POST" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
<md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<md:AssertionConsumerService Location="/SAML2/ECP" index="4"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
<md:AssertionConsumerService Location="/SAML/POST" index="5"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
<md:AssertionConsumerService Location="/SAML/Artifact" index="6"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>
<!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
<LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
<LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
<LogoutInitiator type="Local"/>
</LogoutInitiator>
<!-- md:SingleLogoutService locations handle single logout (SLO) protocol messages. -->
<md:SingleLogoutService Location="/SLO/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<!-- md:ManageNameIDService locations handle NameID management (NIM) protocol messages. -->
<md:ManageNameIDService Location="/NIM/SOAP"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
<md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
<md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
<!--
md:ArtifactResolutionService locations resolve artifacts issued when using the
SAML 2.0 HTTP-Artifact binding on outgoing messages, generally uses SOAP.
-->
<md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
<!-- Extension service that generates "approximate" metadata based on SP configuration. -->
<Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
<!-- Status reporting service. -->
<Handler type="Status" Location="/Status" acl="127.0.0.1"/>
<!-- Session diagnostic service. -->
<Handler type="Session" Location="/Session"/>
</Sessions>
<!--
You should customize these pages! You can add attributes with values that can be plugged
into your templates. You can remove the access attribute to cause the module to return a
standard 403 Forbidden error code if authorization fails, and then customize that condition
using your web server.
-->
<Errors session="sessionError.html"
metadata="metadataError.html"
access="accessError.html"
ssl="sslError.html"
localLogout="localLogout.html"
globalLogout="globalLogout.html"
supportContact="root@localhost"
logoLocation="/shibboleth-sp/logo.jpg"
styleSheet="/shibboleth-sp/main.css"/>
<!-- Uncomment and modify to tweak settings for specific IdPs or groups. -->
<!-- <RelyingParty Name="SpecialFederation" keyName="SpecialKey"/> -->
<!-- Chains together all your metadata sources. -->
<MetadataProvider type="Chaining">
<MetadataProvider type="XML" uri="https://metadata.eduid.hu/current/href.xml"
backingFilePath="href.xml" reloadInterval="7200">
<SignatureMetadataFilter certificate="href-metadata-signer-2010.crt"/>
</MetadataProvider>
<MetadataProvider type="XML" uri="https://metadata.eduid.hu/current/niifi.xml"
backingFilePath="niifi.xml" reloadInterval="7200">
<SignatureMetadataFilter certificate="href-metadata-signer-2010.crt"/>
</MetadataProvider>
</MetadataProvider>
<!-- Chain the two built-in trust engines together. -->
<TrustEngine type="Chaining">
<TrustEngine type="ExplicitKey"/>
<TrustEngine type="PKIX"/>
</TrustEngine>
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" path="attribute-map.xml"/>
<!-- Use a SAML query if no attributes are supplied during SSO. -->
<AttributeResolver type="Query"/>
<!-- Default filtering policy for recognized attributes, lets other data pass. -->
<AttributeFilter type="XML" path="attribute-policy.xml"/>
<!-- Simple file-based resolver for using a single keypair. -->
<!-- <CredentialResolver type="File" key="example.key" certificate="example.crt"/> -->
<!-- Example of a second application (using a second vhost) that has a different entityID. -->
<!-- <ApplicationOverride id="admin" entityID="https://admin.example.org/shibboleth"/> -->
<ApplicationOverride id="wiki.aai" entityID="https://wiki.aai.niif.hu/shibboleth" >
<CredentialResolver type="File" key="wiki.aai.niif.hu.key"
certificate="wiki.aai.niif.hu.crt"/>
</ApplicationOverride>
<ApplicationOverride id="www.aai" entityID="https://www.aai.niif.hu/shibboleth" >
<CredentialResolver type="File" key="www.aai.niif.hu.key"
certificate="www.aai.niif.hu.crt"/>
</ApplicationOverride>
</ApplicationDefaults>
<!-- Each policy defines a set of rules to use to secure messages. -->
<SecurityPolicies>
<!--
The predefined policy enforces replay/freshness, standard
condition processing, and permits signing and client TLS.
-->
<Policy id="default" validate="false">
<PolicyRule type="MessageFlow" checkReplay="true" expires="60"/>
<PolicyRule type="Conditions">
<PolicyRule type="Audience"/>
<!-- Enable Delegation rule to permit delegated access. -->
<!-- <PolicyRule type="Delegation"/> -->
</PolicyRule>
<PolicyRule type="ClientCertAuth" errorFatal="true"/>
<PolicyRule type="XMLSigning" errorFatal="true"/>
<PolicyRule type="SimpleSigning" errorFatal="true"/>
</Policy>
</SecurityPolicies>
</SPConfig>
Minimális beállítások
Környezeti beállítások
A konfigurációs fájl első negyedében lévő szekciókban elsősorban a Shibboleth futásával kapcsolatos beállítások találhatók, amelyek alapértelmezett értékei legtöbbször megfelelőek az általunk elvárt működéshez.
OutOfProcess
InProcess
UnixListener
StorageService
SessionCache
ReplayCache
ArtifactMap
RequestMap
A RequestMap megadja azokat a címeket (Host és Path), amelyeket a Shibboleth SP kezelni fog. Szerkezete:
<RequestMap applicationId="default">
<Host name="wiki.aai.niif.hu" authType="shibboleth"
requireSession="false" applicationId="wiki.aai"
redirectErrors="https://wiki.aai.niif.hu/index.php/Kezd%C5%91lap">
<Path name="secure" requireSession="true" />
</Host>
<Host name="www.aai.niif.hu" authType="shibboleth"
requireSession="false" applicationId="www.aai">
<Path name="secure" requireSession="true" />
</Host>
</RequestMap>
A RequestMap több Host elemet is tartalmazhat, a Host elem 0 vagy több Path elemet tartalmazhat.
!!! danger "Figyelem"
Ha 1-nél nagyobb mélységű könyvtárat (pl. a `/shibtest/shibreq` nevűt) szeretnénk védeni, akkor **nem** adhatjuk meg a *name* paraméterben a "shibtest/shibreq" értéket, hanem egymásba ágyazott Path elemeket kell használni. A *name* paraméter nem tartalmazhat '/' karaktert.
Az egyes elemeknél paraméterekkel szabályozhatjuk, hogy az SP milyen módon kezelje a hostot vagy az útvonalat. A paraméterek felüldefiniálhatók. A legfontosabb paraméterek az alábbiak (ezek ugyanúgy használhatók Host-nál mint Path-nál):
requireSession
: ha értéke "true", akkor az SP csak akkor továbbítja a HTTP request-et az alkalmazás ill. a webszerver felé, ha sikerült létrehozni egy autentikált session-t. Ha "false", akkor az alkalmazás felelős azért, hogy létrehozza a Shibboleth session-t (ún. lazy session) Alapértelmezés: "false"exportAssertion
: ha értéke "true", akkor az SP átadja a teljes, IdP-től kapott Attribute Assertion-t az alkalmazásnak a SHIB_ATTRIBUTES HTTP mezőben (base64 kódolással). Alapértelmezés: "false"applicationId
: lehetőség van arra, hogy bizonyos helyekre érkező kérésekre az SP más és más módon próbáljon meg session-t létrehozni, ezt ún. Shibboleth Application-ben konfigurálhatjuk. Ha nem adunk meg értéket, akkor a "default" application-nél megadott értékek vonatkoznak majd a session-re.redirectError
: átirányítási hiba esetén a Shibboleth erre az oldalra irányít át - ennek az [[isPassive]] -ot használó oldalaknál van jelentősége
ApplicationDefaults
Ennél a szekciónál tudjuk megadni az általános, minden alkalmazásra érvényes alapbeállításokat. Ezek a beállítások természetesen minden egyes alkalmazás tekintetében felüldefiniálhatók.
Alapattribútumok
id
(kötelező): a alkalmazás elsődleges belső azonosítója. Az alapbeállíásoknál (tehát itt) elvárt érték:default
policyId
(kötelező): a vonatkozó id-jűSecurityPoilicies
szekcióra mutatentityID
(kötelező): egyedi azonosító, amely egyértelműen azonosít egy SP-t. A külső alkalmazások csak ezt az azonosítót látják, belső id-t...stb nem. Többnyire URL formátumú.homeURL
:REMOTE_USER
: egy prioritási listát adhatunk meg, melynek elemei azok az attribútumok, melyek közül az az első nem NULL értékű kerül beállításra a HTTP_REMOTE_USER változóbasigning
: az XML üzenetek aláírtságára vonatkozó elvárások állíthatók beencryption
: az XML üzenetek titkosítására vonatkozó elvárások állíthatók be
Sessions
Ennél a szekciónál állíthatjuk be, hogy az SP miként kezelje a Single Sign-on (SSO) folyamatának egyes részeit. Az alapparamétereken túl (session lejárati idő...stb) ún. handlerek találhatók benne. Természetesen az alapbeállítások alkalmazásonként felülírhatók az <ApplicationOverride>
résznél.
Handlerekről
A handlerek az SP-n belül működnek, de a fő folyamatoktól leválasztva. Egy-egy speciális feladatot látnak el - mintegy szkript jelleggel. Egy handler a megfelelő URL meghívásával érhető el. Ezen URL meghívásakor az SP felismeri, hogy mely handlert illeti az adott részfeladat megoldása, és átadja neki a feladat ellátásához szükséges paramétereket. Az SP-n belül egy "alaphandler" található, amely felel a handlereket illető feladatok kiosztásáért, ez jelenti majd a handlerek elérési útvonalában a gyökeret.
Alapattribútumok
handlerURL
: Az alaphandler elérési útja. Alapértelmezés szerint:"/Shibboleth.sso"
.handlerSSL
: Beállítható, hogy kizárólag titkosított csatornán keresztül történhessen a handlerekkel való kommunikáció. Alapértelmezés szerint:true
lifetime
: Beállítható az SP session maximális hossza. Alapértelmezés szerint ez 28800 másodperc. Fontos megjegyezni, hogy az SP session megszűnése nincs közvetlen hatással a Shibboleth által védett alkalmazás által generált sessionretimeout
:checkAddress
: Megadható, hogy az SP ellenőrizze-e, hogy a felhasználó IP címe egyezik-e az IdP által az asseirton-ben írttal. Alapértelmezés szerint:true
exportLocation
:idpHistory
: Igaz érték esetén a SP beállít egy cookie-et, melyhez értékül adja azt az IdP-t, amelynél sikeres autentikáció történt. Alapértelmezés szerint:false
idpHistoryDays
: Megadhatjuk azidpHistory
cookie érvényességi idejét napokban. Amennyiben nem kerül beállításra, akkor a cookie az adott munkamenet végén lejár
SessionInitiator
Ennél a szekciónál kerülnek beállításra azok a paraméterek, melyek meghatározzák, hogy az SP kihez-mihez irányítsa a felhasználót, mikor az érvényes session nélkül (tehát autentikáció előtt) próbálja elérni a Shibboleth által védett tartalmat.
Alapattribútumok
type
: Meghatározza a SessionInitiator típusát. A főbb típusokat lásd lejjebb.Location
: Az URL, amely meghívásakor az adott SessionInitiator handler-e aktivizálódik.id
: (opcionális) Az adott SessionInitiator-re lehet ezen id által hivatkozni egyéb beállításoknálentityID
: Az SP az itt megadott értékben szereplő IdP-hez irányítja az autentikálni kívánó felhasználótrelayState
: meghatározza, hogy...acsByIndex
: igaz érték esetén él a lehetőség, hogy a megfelelő AssertionConsumerService-hez ne teljes URI-val forduljunk, hanem elég legyen csak annak indexét megadnunk.defaultACSIndex
: azacsByIndex="true"
esetén beállítható, hogy alapértelmezés szerint mely indexxel rendelkező AssertionConsumerService-t használjuk
SessionInitiator főbb típusai
-
SAML2 SessionInitiator (Protocol Handler):
type"SAML2"
SAML2-es autentikációs folyamatot kezdeményez, és érti a SAML2 szabványon alapuló paramétereket. Mindenképp szükséges, hogy kapjon egy
entityID
paramétert, értékében egy valós IdP entityID-jával. -
SHIB1 SessionInitiator (Protocol Handler):
type"SHIB1"
Shibboleth 1.x-es autentikációs folyamatot kezdeményez, és SAML 1.1 szabványon alapuló paramétereket ért. Mindenképp szükséges, hogy kapjon egy
entityID
paramétert, értékében egy valós IdP entityID-jával. -
SAMLDS SessionInitiator (Discovery Handler):
type"SAMLDS"
Az
url
attribútum értékeként megadott helyre irányítja a böngészőt, ahol SAML2 Discovery Service-t vár. A SAML2DS ismeri az isPassive-ot. -
WAYF SessionInitiator (Discovery Handler):
type"WAYF"
Az
url
attribútum értékeként megadott helyre irányítja a böngészőt, ahol Shibboleth WAYF szolgáltatást vár. -
Chaining SessionInitiator:
type"Chaining"
Egy Chaining típusú SessionInitiator elem további SessionInitiator elemeket tartalmazhat, melyek felveszik a keret elem attribútumaiban meghatározott tulajdonságokat.
MetadataProvider
Ennél a szekciónál kell beállítani, hogy az SP milyen forrásokból jut hozzá a szükséges metaadatokhoz.
A források 3 fő típusa
-
XML MetadataProvider
type"XML"
SAML2 szabványos XML fájlt tölt be a rendszer. A fájl lehet lokális, vagy távoli, webszerveren keresztül elérhető. Leggyakrabban használt típus. Példa:
<MetadataProvider type="XML" uri="https://metadata.eduid.hu/current/href.xml" backingFilePath="href.xml" reloadInterval="7200"> <SignatureMetadataFilter certificate="href-metadata-signer-2020.crt"/> </MetadataProvider>
A tanúsítvány innen szerezhető be: https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt
-
Chaining MetadataProvider További
MetadataProvider
-(eke)t tartalmazhat. -
dinamikus, MDQ
<MetadataProvider type="MDQ" id="href-2020" ignoreTransport="true" baseUrl="https://mdx.eduid.hu/"> <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/> <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/> </MetadataProvider>
A tanúsítvány innen szerezhető be: https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt
ApplicationOverride
Amennyiben az SP több alkalmazást kezel, és ezek között az alkalmazások között vannak olyanok, melyeknek valamely tulajdonsága nem egyezik az SP alapértelmezettként megadott tulajdonságaival (jellemzően ilyen lehet pl. az entityID), akkor ezeket ebben a szekcióban felül lehet definiálni.
Kiegészítő beállítások
POST preservation
Ha legalább 2.2-es verziójú Shibboleth SP-t használunk, úgy lehetőségünk van egy olyan funkció beállítására, amely lehetővé teszi, hogy ha egy felhasználó valamilyen formba ír (pl. egy wikibe), akkor a küldés gomb megnyomásakor a shibboleth egy átmeneti helyen eltárolja a beírt adatokat. Ennek jelentősége, hogy ha írás közben lejárt volna a felhasználó sessionje, így alapértelmezés szerint a bejelentkező oldalra dobná a rendszer, ami által elveszne, amit begépelt, úgy bekapcsolt post preservation esetén ezek az adatok megmenekülnek, nem kell őket újra beírni.
A funkció bekapcsolásához a <Sessions>
elem attribútumaként kell megadni az alábbi két név-érték párt.
-
postData="ss:mem"
, az érték mondja meg, hogy a form adatait az SP mely, a konfigurációs fájl elején definiált Storage Service-en keresztül tárolja. Alapértelmezés szerint a memóriában, de lehetőség van külső tároló megadására is. További információ a Storage Service-kről -
postTemplate="/etc/shibboleth/postTemplate.html"
Hiányossága a funkciónak, hogy ha a form tartalmaz file
típusú input
mezőt, akkor nem fog működni.
HREF integráció
- Az SP-t regisztrálni kell a Resource Registry-ben
- Le kell tölteni a metadatához tartozó tanúsítványt a https://metadata.eduid.hu/current/ címről, és elmenteni a shibboleth kofigurációs fájljait tartalmazó könyvtárba
- A Metadata beállításoknál meg kell adni a HREF metadata elérhetőségét: https://metadata.eduid.hu/current/href.xml
- Az
attribute-map.xml
fájlban el kell távolítani a kommentjeleket azon attribútumok elől, melyeket az SP használni kíván. - Újra kell indítani a shibboleth démont.
Resource_Registry
!!! bug "Elavult információ"
**Figyelem:** ez a szócikk elavult, a Resource Registry megújult egy ideje!
Alapfogalmak
- Attribútum: felhasználóra vonatkozó tulajdonság. A föderációban használt attribútumok listája itt érhető el.
- SP: Service Provider - Szogáltatás: Webes alkalmazás, amelynek felhasználóit föderatívan valamilyen IdP által autentikáltatja
- IdP: Identity Provider - Azonosító szervezet: Feladata a felhasználó azonosítása, felhasználó attribútumainak kiadása SP-k részére
- Föderáció: olyan intézmények halmaza, amelyek között lehetséges az azonosítási-információk átadása. Az intézmények - szabályozott keretek között - megbíznak a másik intézmény által kiállított azonosítási-információkban.
- Entitás: föderációt alkotó elem (IdP, SP)
Áttekintés
A Resource Registry az alakuló magyarországi felsőoktatási és kutatási föderáció (HREF) központi eleme, mellyel a föderációban résztvevő szolgáltatások (SP-k) és azonosító szervezetek (IdP-k) adminisztrálását lehet egy letisztult környezetben, elosztott jogosultságokkal végezni. A rendszer az egyes entitásokért felelős adminisztrátorok számára készül.
A rendszer a svájci SWITCH Intézet által fejlesztett rendszer alapjaira épül, PHP nyelven íródott, adatbázisként MySQL-t használ.
Funkciók
A rendszer saját adatbázisból dolgozik, minden funkciójának kimenete ezeken az adatokon alapul.
-
Föderáció-szintű feladata, hogy a központi metaadatot óránként generálja, melyet a résztvevő "entitások" használnak, ezzel garantálva egyfelől a föderáció egységességét, másfelől a megfelelő formátumú metaadat alkalmazásával megteremtse a lehetőséget, hogy a föderáció kiegészítő alkalmazásai (Discovery Service), ill. nemzetközi szintű együttműködésben - bizonyos keretek közt - más föderációk is dolgozhassanak ebből.
-
Az attribútum-szabályzat szintén föderációs szinten állítható, melyeket kiegészítve, az egyes IdP-k megadhatják, hogy mely attribútumokat milyen feltételekkel adják ki, ill. az egyes SP-k is deklarálhatják, hogy milyen attribútumok megléte esetén tudnak egyáltalán működni, mindezt az egyes intézmények adatvédelmi felelősei által kontrolálva.
-
Egyénileg, az adott entitás adminisztrátorai által használhatók az egyes IdP-k, SP-k telepítését és konfigurálását megkönnyítő funkciók, melyek a megfelelő beállításokat webes felületen megadva letölthetővé teszik az ezen beállítások alapján automatikusan generált, és jó eséllyel minimális további kézi konfigurációt igénylő fájlokat. Fontos, hogy ezeket a fájlokat nem kötelező használni, ám segítséget jelenthetnek.
Shibboleth 2.x SP-hez:
shibboleth2.xml
Fontos, hogy ezt akkor lehet szinte egy az egyben használni, amennyiben az adott SP csak egy alkalmazást véd. Amennyiben több alkalmazás is igényel Shibbolethet egyazon hoszton, úgy kézzel kell szerkeszteni az xml-t.
-
attribute-map.xml
-
attribure-policy.xml
Ez a két fájl egy az egyben használható letöltés után, további konfigurációt alapesetben nem igényel.
Shibboleth 2.x IdP-hez:
attribute-resolver.xml
Ez csak egy keret fájl, a legtöbb olyan elem szerepel benne, amelyeket a helyi viszonyokra szabva már működhet az IdP, ám itt muszáj kézzel is szerkeszteni, pl. LDAP adatok...
attribure-filter.xml
A fájl egyből használható - további információk a fájl előállításának menetéről.
SimpleSamlPHP-hoz:
AttributeFilter.xml
A fájl egyből használható - további információk a fájl előállításának menetéről.
Bejelentkezés a rendszerbe
A Resource Registry a https://rr.eduid.hu címen érhető el, és bejelentkezni csak föderatív azonosítás után lehet. A nyitóképernyőn a bejelentkezési lehetőségen túl mindössze általános, nyilvános információk érhetők el a föderáció aktuális állapotával kapcsolatban, ill. a rendszer használatához található segítség.
A rendszerbe történő bejelentkezéshez elengedhetetlen, hogy a felhasználót azonosító IdP az alábbi attribútumokat átadja a Resource Registry-nek.
- eduPersonPrincipalName
- schacHomeOrganizationType
- eduPersonScopedAffiliation
- email - ez belépés után, manuálisan is beállítható
Szerepek a rendszerben
A Resource Registrybe csak föderatív azonosítás után lehet belépni.
Felhasználó
- Lehetősége van rá, hogy a föderációhoz szolgáltatást (SP-t) regisztráljon, amely jóváhagyás után élesedhet.
SP adminisztrátor
- Ő felelős egy, vagy több, már jóváhagyott SP-ért, ill. elbírálhat felhasználói SP ajánlásokat.
IdP adminisztrátor
- Az általa regisztrált és karbantartott IdP-ért felelős.
RR adminisztrátor
- A Resource Registry-n belül tevékenykedő felhasználók jogosultságaiért felelős, ő adhat hozzá egyes entitásokhoz újabb adminisztrátorokat, ill. bírálhat el IdP-ket, és SP-ket.
Alapértelmezés szerint, aki be tud lépni, a legegyszerűbb felhasználói jogosultságokat kapja, bármilyen magasabb szintű szerepkört RR adminisztrátor delegálhat számára, a magasabb jogkörrel járó felelősségi kört pontosan körülhatárolva. (Pl. A RR adminsiztrátor a felhasználót az őt azonosító IdP adminisztrátorává tehet, amely nyomán a felhasználó pontosan ezt az egy IdP-t hangolhatja, de felhasználói jogosultságokat már nem oszthat tovább)
Fontos, hogy az RR-ben az egyes szerepek egy-egy intézmény adminisztrálásához köthetők, ily módon megvalósítva az elosztott jogosultságkezelést. Egy példán keresztül bemutatva ez azt jelenti, hogy egy felhasználó ha szeretne SP-t felvenni a föderációba, akkor azt csak az őt azonosító intézmény hatókörébe teheti meg, ami azt is jelenti, hogy az adott intézményhez tartozó, RR adminisztrátor jogosultsággal rendelkező felhasználó hagyhatja ezt a regisztrációs-, vagy módosítási kérelmet jóvá. Ugyanez az adminisztrátor csak a saját intézményéhez tartozó entitásokra vonatkozóan oszthat, vagy vonhat vissza jogosultságokat.
Természetesen létezik Power User, aki mindent lát, mindenhez van jogosultsága, de csak nem várt esemény esetén aktivizálódik valahol az NIIF AAI környékén :), amúgy rendeltetésszerű működés esetén a szubszidiaritás elvét képviselve az intézményeké az őket érintő ügyekben a döntési jog.
Folyamatok
SP regisztráció
Bárki, akit a rendszer föderatív azonosítással beléptetett, kezdeményezheti egy SP föderációba történő felvételét, ehhez az „SP adminisztráció“ oldalon az „Új SP regisztrálása“ c. menüpontot kell választani. Varázsló segít a regisztrációban, melynek mindössze a telepített SP metaadatának nyilvánosan elérhető url-jét kell megadni (alapértelmezés szerint: https://#HOSTNAME#/Shibboleth.sso/Metadata), majd az automata a lehető legtöbb beállítási paramétert megpróbálja kiolvasni az xml-ből, és egyből beírni az adatbázisba az új SP adatai közé. Mivel minden adatot nem lehetséges az alapértelmezett metaadatból kinyerni, így a regisztráló felhasználónak néhány további adatot kell megadnia ahhoz, hogy véglegesíthesse az SP regisztrációs kérelmet. Ezeket hat csoportra lehet osztani.
-
Alapinformációk: itt kerülnek megadásra az alapvető, leíró információk, melyek az SP nevét, leírását tartalmazzák, ill. a legfontosabb azonosító, az entityID. Az adatok egy része (pl: entityID) kiderül már a metaadatból is, így a beviteli mezőt már az automata kitöltötte.
-
Itt tudjuk meghatározni első körben azt is, hogy az adott SP nyilvános, vagy belső SP legyen. Ennek szellemében kell a megadott feltételes mezőket kitöltenünk. Ha belső SP, akkor csak a legszükségesebb adatok megadása elvárt.
-
Kapcsolattartók: ha a metaadatból nem derül ki, akkor kézzel kell megadni technikai, adminisztratív, általános...stb. kapcsolattartó személyeket, akik adatai a központi metaadatban is szerepelni fognak.
-
SP Service Locations: különböző bindingok elérhetőségei – ezt az automata az esetek nagy hányadában jól kiolvassa a metaadatból, emberi módosítást a legritkább esetben igényel. Kivételt képez a NameIdFormat meghatározása, mely kapcsán három opció közül választhatunk.
- Tranziens opciót kell választanunk, ha SP-nk számára nem fontos, hogy ki a felhasználó, hiszen nem ez alapján dől el, hogy milyen erőforrásokat érhet el, hanem az alapján hogy milyen, a felhasználóra vonatkozó, pl. eduPersonScopedAffiliation attribútumot állnak az SP rendelkezésére.
- Perzisztens opciót kell választanunk, ha SP-nk számára fontos, hogy ki a felhasználó ÉS sz SP által védett alkalmazásaink is felkészültek arra, hogy persistent-idt fogadjanak, ezzel dolgozzanak.
- Nem meghatározott opciót kell választanunk, amennyiben az SP által védendő alkalmazás mind persistent, mind transient NameID fogadására alkalmas.
-
Megjegyzés Amennyiben most alakítjuk ki az AAI infrastruktúránkat, újonnan állítjuk be az SP-t annak érdekében, hogy valamilyen alkalmazást védjen, akkor ajánlott, hogy támogassa a perzisztens azonosítók használatát.
-
Tanúsítványok: az SP által használt tanúsítványokat kell PEM formátumban megadni – ehhez is segítséget nyújt varázsló helyben, amelynek az SP metadatájának URL-jét címét kell megadni, ami után az automata beolvassa a tanúsítvány(oka)t.
-
Kötelező attribútumok: itt lehetséges azon attribútumok megadása, melyek kiadása elvárt az IdP-től, amelyek nélkül az SP által védett alkalmazás nem használható.
-
Amennyiben egy attribútumot megkövetel az SP használatához, az azt jelenti, hogy az attribútum kiadása nélkül az SP nem lesz használható. Ha egy attribútumot ajánlottnak jelöl, akkor az IdP kiadja, amennyiben implementálta, ám az SP-nek e nélkül is működnie kell. Ha olyan attribútumot jelöl kötelezőnek, amely a föderációs szabály szerint csak ajánlott, vagy opcionális, úgy könnyen előfordulhat, hogy az IdP nem implementálta, így nem is tudja kiadni, aminek következtében a felhasználó nem fogha tudni használni az Ön SP-jét.
-
Ideális esetben nincs szükség külön szabályzásra, amennyiben mégis, úgy törekedjen rá, hogy minél kevesebb attribútumot szabályozzon külön!
-
Hallgatóság: megadhatók, milyen jellegű IdP-k érhetik el az adott SP-t, ill. amennyiben ez a szabályzás nem lenne elegendő, úgy egyesével is megadhatók IdP-k aszerint, hogy felhasználói használhatják-e az SP-t, vagy sem.
-
Amennyiben belső SP-t regisztráltunk, itt állíthatjuk be, hogy minden intézmény jelleget tiltunk, és egy kivételt megadunk: a saját IdP-nket. Ily módon más IdP nem is fog tudni erről az SP-ről, tehát annak ellenére, hogy szerepel a föderációs metaadatban, csak belső használatra lesz alkalmas.
SP módosítás
Egy jóváhagyott SP-t csak a megfelelő jogosultsággal rendelkező felhasználó tud módosítani. Általában egy-egy SP-hez tartozó adminisztrációs jogot az intézmény RR adminisztrátor jogkörrel rendelkező felhasználója osztja ki az adott SP jóváhagyásával egy ütemben.
A módosítás folyamata teljesen analóg a regisztrációéval, ami a funkciókat illeti.
FONTOS: Akár regisztráltunk, akár módosítottunk, a változásokat jóvá kell hagynia az Önt azonosító intézet RR adminisztrátorai közül valakinek. Amíg ezek a változtatások bekerülnek a föderációs metaadatba, az legfejjebb egy óra, ám amíg minden föderációs entitás frissíti a metaadatot, így értesül a változásról.
IdP regisztráció
A föderációba új IdP-t - mivel a regisztrálandó IdP-t üzemeltető kolléga még nem tud belépni a Resource Registry-be - egy, a föderációs adminisztrációért felelős kolléga tud regisztrálni. Ehhez szükséges, hogy az IdP, minden kapcsolódó programmal együtt telepítve legyen, és az alapértelmezett, telepítéskor generált metaadat egy meghatározott url-en elérhető legyen.
A telepítéshez - Shibboleth esetében - pl. a Shib2IdpInstall wikilapon található leírás szolgál segítségül. Attribútumokat, autentikációt konfigurálni nem kell, elegendő, ha a Teszt pontnál látjuk a megnyugtató ok
szöveget, és minimális beállításokat megejtettük
Amennyiben ez működik, úgy írni kell egy e-mailt az aai@niif.hu címre, valaki a föderációs adminisztrátorok közül regisztrálja az IdP-t, és a válasz e-mailben elküld két linket, amelyek tartalmaznak két linket az attribute-resolver.xml
és attribute-filter.xml
már testreszabott konfigurációs fájlokra mutatva. Ezeket letöltve, bemásolva az IdP-nek már működnie kell alapszinten, így már lehetségessé válik a Resource Registry-be történő belépés. Sikeres belépés után az intézményhez tartozó RR jogosultságokat átadjuk, s a továbbiakban mehet minden a maga utáján, intézményi szinten.
Nagyon fontos, hogy az IdP-n bármilyen módosítás azonnal érvénybe lép, így rossz beállítás esetén akár az IdP által hitelesíthető felhasználók belépése is ellehetetlenülhet.
A beállítási lehetőségek az alábbiak
-
Alapinformációk: IdP neve, leírása, jellege – technikai ismereteket nem igénylő, leíró jellegű információk
-
Technikai információk: EntityID, és különböző bindingok elérhetőségei – ezt az automata az esetek nagy hányadában jól kiolvassa a metaadatból, emberi módosítást a legritkább esetben igényel.
-
Tanúsítványok: az IdP által használt tanúsítványokat kell PEM formátumban megadni – ehhez is segítséget nyújt varázsló helyben, amelynek a webszerver címét kell megadni, ami után az automata beolvassa a tanúsítvány(oka)t.
-
Kapcsolattartók: ha a metaadatból nem derül ki, akkor kézzel kell megadni technikai, adminisztratív, általános...stb. kapcsolattartó személyeket, akik adatai a központi metaadatban is szerepelni fognak.
A további négy beállítás némi hozzáértést igényel, lévén az alapértelmezett metaadatból nem olvashatók ki. A rendszer ezeket az értékeket a föderációs szabályoknak, megállapodásoknak megfelelően készíti elő, legtöbb esetben nincs szükség módosításra, ám ha mégis, bármilyen speciális igény okán, akkor nagy odafigyeléssel kell beállítani.
- Támogatott attribútumok: beállítandó, hogy az IdP mely attribútumokat, milyen formában támogatja. A föderációs szinten kötelezőket mindenképp támogatnia kell.
- Általános attribútum kiadási szabályok: beállítható, hogy amennyiben egy SP az adott attribútumot kötelezően, ill. opcionálisan kiadandóként kéri, akkor az IdP hogyan viselkedjen. Ezek a szabályok általánosak, minden, a föderációban résztvevő SP-r vonatkoznak.
- Speciális attribútum kiadási szabályok: beállíthatók külön-külön egyes SP-kkel való viselkedés, amennyiben indokolt az általános szabályoktól való eltérés.
- Telepítési és környezeti információk: leíró információk, amelyek pl. hiba esetén segítséget adnak a hiba elhárítójának, hogy milyen rendszerrel lesz dolga. Emellett statisztikai célokat is szolgál.
Attribútumok kezelése
A föderációban használható attribútumok részletes listája a föderációs attribútum specifikációban található.
Az egyes attribútumokkal kapcsolatban négy irányból lehetséges beállításokat eszközölni
- Minden SP meghatározhatja, hogy mely attribútumok kiadását követeli meg, és melyek kiadását ajánlja (SP beállítások - Kötelező attribútumok menüpont)
- Minden SP meghatározhatja, hogy mely IdP-ktől hajlandó attribútumokat elfogadni (SP beállítások - Hallgatóság menüpont)
- Minden IdP meghatározhatja általánosságban, hogy ha egy SP tőle egy bizonyos attribútum kiadását megköveteli, vagy ajánlja, akkor azt az attribútumot kiadja-e, vagy sem. (IdP beállítások - Általános attribútum kiadási szabályok menüpont)
- Minden IdP meghatározhat SP-specifikus szabályokat, tehát egy-egy SP-re, vagy egy-egy SP egy-egy attribútumára vonatkozólag megadhat az általános beállításaitól eltérő szabályokat - pl. az eduPersonPrincipalName-t ha általában ajánlva kérik az SP-k, akkor kiadja, de XY SP-nek semmiképp nem adja ki. (IdP beállítások - Egyedi attribútum kiadási szabályok menüpont)
További információ az attribútumok implementációjáról, kapcsolódó fogalmakról A fenti beállítások eredőjeként generálódik az IdP-k által használandó XML alapú attirbútum filter fájl
A generált attribútum filter alapvetően tiltó jellegű, tehát az IdP pontosan azokat az attribútumokat és pontosan azoknak az SP-knek adhatja ki, melyek megadásra kerültek a beállításoknál, egyébként semmit.
Néhány példa a "leképződésre"
- Ha egy SP kiadásra ajánl egy attribútumot, de az IdP (akár az általános-, akár az egyedi attribútum kiadási szabálya miatt) nem adja ki azt, akkor az XML fájlban komment formájában jelenik meg, hogy ezt és ezt az attribútumot igényelné az SP, de nem kerül kiadásra
- Ha egy SP hallgatóságából kitilt egy IdP-t, akkor az IdP attribútum filterében az adott SP-re vonatkozólag nem jelenik meg semmi, amelynek következtében nem is kerül számára kiadásra semmi
XML alapú filter
- Shibboleth IdP-nél:
attribute-filter.xml
- simpleSAMLphp IdP-nél:
AttributeFilter.xml
A filter fájlok Resource Registry által előállított változatát használni nem kötelező, de fokozottan ajánlott, hiszen ezzel garantálható egyfelől, hogy az IdP-n keresztül autentikáló felhasználók azokat az SP-ket, melyeket el kell tudniuk érni, jól fogják, megfelelő attribútumokkal "a zsebükben" fogják tudni elérni, másfelől így tudnak érvényesülni a feljebb részletezett korlátozó szabályzások.
Adatvédelmi szempontok
Ha egy SP megváltoztatja attribútum igényeit pozitív irányba (új attribútumokat kér), úgy a változtatás csak akkor fog belekerülni az IdP-k attirbútum filterébe, amennyiben ezt a változtatást tudomásul veszi az IdP oldaláról az illetékes adatvédelmi felelős. Amennyiben egy SP-nél ilyen jellegű változás történik, a rendszer e-mailben értesíti az érintett IdP-k gazdáit, adatvédelmi felelőseit.
Gyakorlati ajánlás
Kihasználandó a Resource Registry által biztosított lehetőségeket ajánljuk, hogy az IdP-hez tartozó generált attribútum filter fájlt automatikusan töltsék le az IdP-k, bizonyos időközönként (óránként, naponta párszor...), hiszen ezekbe csak úgy kerülhet változtatás, ha azt az IdP adatvédelmi felelőse jóváhagyta, akkor viszont egyből átvezetődik a változtatás, nem szükséges kézzel letölteni, ill. újraindítani az IdP-t. (Shibboleth esetében be kell állítani egy kapcsolót, SSP-nél automatikusan újratölti a friss XML-t)
A filter elérhetősége
- Shibboleth IdP: https://rr.eduid.hu/gen_attribute-filter.php/href/IDP_NEVE/attribute-filter.xml
- simpleSAMLphp IdP: https://rr.eduid.hu/gen_attribute-filter-ssp.php/href/IDP_NEVE/attribute-filter.xml
Útmutató a beállításhoz
SSP_EntityCategories
Ez a lap a simpleSAMLphp EntityCategories moduljának továbbfejlesztett változatához tartozó beállításokat ismerteti. Reményeink szerint a modul valamikor a simpleSAMLphp alapcsomagjának is része lesz, ám amíg ez nem történik meg, addig az alábbiak szerint érdemes eljárni, ha használni szeretnénk.
A modul forrása: https://github.com/sitya/simplesamlphp-module-entitycategories.git
Fontos, hogy a modul nem helyettesíti a core:AttributeLimit, vagy a niif:AttributeLimit modult, valamelyikkel együtt használandó!
Telepítés composeren keresztül
cd /path/to/simplesamlphp
composer require simplesamlphp/simplesamlphp-module-entitycategories:dev-master
composer config repositories.simplesamlphp/simplesamlphp-module-entitycategories vcs https://github.com/sitya/simplesamlphp-module-entitycategories.git
composer update
Beállítás
Lévén egy AuthProc modullal van dolgunk, így a rendes authproc szekcióba kell elhelyeznünk valahol a sorban, a core:AttributeLimit, vagy niif:AttrobuteLimit előtt. Az alább részletezett alapbeállításokon túl (default, strict, allowRequestedAttributes
) az egyes entityCategory-k URI-jait kell megadni, mint egy tömb kulcsát, és a hozzátartozó tömb értékeiként pedig a megengedett attribútumok URN-jeit. Tetszőleges számú entityCategory-t megadhatunk, a korábbi beállítások elsősorban azt szabályozzák, hogy mi történjen akkor, olyan entitással van dolgunk, akinek nincs a metadatájában megadva EntityCategory, vagy ha van, nem illeszkedik az általunk explicit beállított listában található EntityCategory-k valamelyikére.
Működő példa
75 => array(
'class' => 'entitycategories:EntityCategory',
'default' => true,
'strict' => true,
'allowRequestedAttributes' => true,
'http://eduid.hu/category/registered-by-eduidhu' => array (),
'http://www.geant.net/uri/dataprotection-code-of-conduct/v1' => array (),
'http://refeds.org/category/research-and-scholarship' => array(
'urn:oid:2.16.840.1.113730.3.1.241', #displayName
'urn:oid:2.5.4.4', #sn
'urn:oid:2.5.4.42', #givenName
'urn:oid:0.9.2342.19200300.100.1.3', #mail
'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', #eduPersonPrincipalName
'urn:oid:1.3.6.1.4.1.5923.1.1.1.9', #eduPersonScopedAffiliation
),
),
80 => array(
'class' => 'niif:AttributeLimit',
'default' => true,
'bilateralSPs' => array(
'google.com' => array('mail'),
'urn:federation:MicrosoftOnline' => array('IDPEmail', 'ImmutableID'),
),
),
A fenti példa az alábbiakat végzi:
- a magyar föderáció által regisztrált entitások számára a Resource Registry-ben beállított attribútumok (
RequestedAttributes
) alapján történik az attribútum kiadás; - a GÉANT Code of Conduct entitás kategóriájú eduGAIN-es SP-k számára szintén
RequestedAttributes
alapján történik az attribútum kiadás; - a Research & Scholarship entitás kategóriájú eduGAIN-es SP-k számára kiadjuk a kategória által igényelt attribútumcsomagot
- az ilyen SP-k
RequestedAttributes
alapján módosíthatnak az attribútum igényeiken
- az ilyen SP-k
- a fenti kategóriáknak nem megfelelő SP-k közül kizárólag a bilateralSPs tömbben megadott entitásoknak adunk ki attribútumot.
!!! warning
Az *entitycategories:EntityCategory* modul *strict* beállítása esetén a lokálisan felvett SP-k esetén nem lesz figyelembe véve az *attributes* tömbelem! Ez azt jelenti, hogy a nem a központi metaadatokból származó SP-ket fel kell venni az *niif:AttributeLimit* modul listájába. Ebből fakadóan ilyen esetben nem is használhatjuk a *core:AttributeLimit* modult.
Opciók
default
Logikai kapcsoló, true/false
értékeket vehet fel. Amennyiben true
, úgy a beállított EntityCategory-k alatt megadott attribútumkészletet akkor is kiadjuk az adott EntityCategory-val érkező SP-nek, ha az attribútumokat explicit, a RequestedAttribute
-ok között nem kérte felsorolva. Ennek az R&S EntityCategorynál van különös jelentősége (a példában is ez szerepel), mert ott a specifikáció kimondja, hogy a meghatározott attributúmkészletet akkor is ki kell adni az R&S-t támogató IdP-nek, amennyiben nincsenek ezen attribútumok tételesen felsorolva, mint RequestedAttributes
.
strict
Logikai kapcsoló, true/false
értékeket vehet fel. Amennyiben true
, úgy csak és kizárólag a modul konfigurációjában megadott EntityCategory-val érkező SP-k számára kerülnek attribútumok kiadásra, "ismeretlen" EntityCategory-val bíró, és EntityCategory nélküli SP-k számára nem kerül kiadásra semmi.
allowRequestedAttributes
Logikai kapcsoló, true/false
értékeket vehet fel. Amennyiben true
, úgy megengedjük, hogy egy SP a hozzátartozó EntityCategory konfigurációjában megadott attribútumlistán túl kért attribútumot kiadásra RequestedAttributes
-on keresztül, false
esetén csak a listában szereplő attribútumok kiadását engedi a modul. Amennyiben az érték true
és a strict
értéke false
, úgy az "ismeretlen" EntityCategory-val bíró SP-k számára is a RequestedAttributes
alapján kerülnek kiadásra az attribútumok.
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
HREF_műszaki_előírások
A dokumentum célja, hogy a HREF Föderációhoz csatlakozó Tagok és Partnerek számára elvárásokat és ajánlásokat fogalmazzon meg, melyek a csatlakozáshoz szükséges identitás-menedzsment, valamint üzemeltetési területeket fednek le.
A dokumentumban a KÖTELEZŐ, TILOS, AJÁNLOTT, NEM AJÁNLOTT kifejezések értelmezése az alábbiak szerinti:
-
KÖTELEZŐ (ill. "KÖTELES", "kell") jelentése: a pontban leírtak betartása a föderációba vetett bizalom kiépítéséhez és megtartásához elengedhetetlenül szükségesek, ettől a résztvevők nem térhetnek el;
-
TILOS jelentése KÖTELEZŐ NEM, azaz a pontban leírtak szerint az intézmény nem járhat el;
-
az AJÁNLOTT pontoktól való eltéréseket az intézmények dokumentálni kötelesek.
-
NEM AJÁNLOTT jelentése: amennyiben az intézmény a pontban leírtak szerint jár el, ezt dokumentálni köteles.
1. Identitás-menedzsment
-
1.1. Az intézmény köteles adatkezelési elveit dokumentálni, azt a felhasználókkal megismertetni.
-
1.2. Az intézmény köteles a felhasználóiról általa ismert adatok forrását, karbantartásának módját, illetve ezen adatok becsült adatminőségét dokumentálni, és igény esetén ezt a dokumentációt a föderáció tagjainak rendelkezésére bocsátani.
-
1.3. Kötelező a felhasználónevek egyediségét biztosítani.
-
1.4. Egy természetes személyhez nem ajánlott több felhasználói azonosítót rendelni.
-
1.5. Nem ajánlott szerep felhasználók (dékán, igazgató) használata.
-
1.6. Attribútumok használata:
-
1.6.1. A megvalósított attribútumokat az IdP-nek az Attribútum Specifikációban leírt módon kell megvalósítani;
-
1.6.2. Az IdP-nek kötelező megvalósítania az alábbi attribútumokat:
- eduPersonTargetedID
- eduPersonPrincipalName
- eduPersonScopedAffialiation
-
1.6.3. Az IdP-nek ajánlott megvalósítania az alábbi attribútumokat:
- displayName
- sn
- givenName
-
1.6.4. Az IdP-nek kötelező biztosítania, hogy az eduPersonTargetedID és az eduPersonPrincipalName attribútumok ne legyenek újra kioszthatók.
-
-
1.7. Teszt felhasználók az alábbi megkötések mentén használhatóak:
-
1.7.1. minden teszt felhasználót egyértelműen azonosítani és dokumentálni kötelező (az érte felelős munkatárssal együtt),
-
1.7.2. teszt felhasználóval valós tranzakciót kezdeményezni tilos, kivéve, ha a tranzakcióban részt vevő SP a teszt felhasználó használatához hozzájárult,
-
1.7.3. ajánlott ezen felhasználókat a megfelelő homeOrganizationType értékkel megkülönböztetni.
-
-
1.8. Felhasználói azonosító adatokat (pl. jelszó) publikus hálózaton titkosítatlanul továbbítani (felhasználótól bekérni, adatbázisszerver felé kommunikálni) tilos.
-
1.9. A felhasználói jelszavakat ajánlott nem elektronikus formában kiosztani (pl. személyesen, vagy postai úton).
-
1.10. A felhasználók intézményhez fűződő viszonyában bekövetkezett változásokat 7 napon belül kötelező megjeleníteni az IdP adatbázisában és az eduPersonScopedAffiliation attribútum értékében.
- 1.10.1. Amennyiben az intézmény külső adatforrást (tanulmányi- ill. bérügyi rendszert) használ a felhasználói adatok tárolására, úgy ez a 7 napos korlát a hiteles adat elsődleges rendszerben történő megváltozásától számítandó.
2. Szolgáltatás-menedzsment
-
2.1. Az intézmény köteles a föderációs operátorral való kapcsolattartásra megfelelő szerepkört kialakítani. Ajánlott a kapcsolattartáshoz szerep e-mail címet megadni.
-
2.2. IdP-t üzemeltető intézmény köteles az IdP-vel kapcsolatban végfelhasználói támogatást nyújtani, és ezen támogatás elérhetőségéről a felhasználóit tájékoztatni.
-
2.3. Az intézmény köteles az általa üzemeltett IdP forgalmi adataiból anonimizált, legalább napi felbontású adatokat szolgáltatni a föderációs operátor számára föderációs célú statisztika készítésének céljából.
3. Üzemeltetési kérdések
-
3.1. A személyes adatokkal kapcsolatos tranzakciókról kötelező naplóállományt készíteni, és azt legalább 30 napig megőrizni.
-
3.1.1. Az intézmény ezeket a naplókat köteles a hatályos adatvédelmi szabályokkal összhangban kezelni.
-
3.2. Az AAI infrastruktúra komponensei esetén kötelező legalább 2048 bites kulcsok használata.
-
3.2.1. Biztosítani kell a privát kulcsok védelmét.
-
3.2.2. Amennyiben egy kulcs kompromittálódik, az intézmény köteles a föderációs operátort 24 órán belül értesíteni.
-
3.2.3. Ajánlott hosszú lejáratú, self-signed tanúsítványok használata.
-
-
3.3. Vonatkozó SAML szabványok
-
3.3.1. Kötelező az Interoperable SAML 2.0 Web Browser SSO Deployment Profile (http://saml2int.org) dokumentumban kötelezőnek megjelölt elemek támogatása
-
3.3.2. Ajánlott a SAML2 Single Logout profil támogatása HTTP-Redirect illetve SOAP binding felett.
-
-
3.4. Az IdP köteles minden végpontját HTTPS (SSL/TLS) protokollok segítségével védeni.
-
3.5. Az IdP minden SAML végpontjának az IdP-t üzemeltető intézmény tulajdonában álló DNS domainnek, vagy az alatt levő névnek kell lennie.
-
3.6. Az IdP által használt scope-oknak az IdP-t üzemeltető intézmény tulajdonában álló DNS domainnek, vagy az alatt levő névnek kell lennie.
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:
...
<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="teszt"
relayState="cookie" entityID="https://idp.sch.bme.hu/niif-teszt">
<SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
</SessionInitiator>
...
<MetadataProvider type="XML" file="maszat-idp.xml"/>
...
Shibboleth SP Metadata importálása OpenSSO-ba
A lementett XML-ből töröljük ki az <md:Extension>
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=<entityid>,ou=default,ou=OrganizationConfig,ou=1.0,ou=sunFMSAML2MetadataService,ou=services,
o=<realm>,ou=services,<basedn>
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 <Extensions/>
-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 <Extensions>
-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 <Extensions>
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:
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
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 (<saml:Attribute NameFormat="...">
). 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
...
<saml:Attribute Name="urn:mace:dir:attribute-def:mail">
<saml:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">hege@*********</saml:AttributeValue>
</saml:Attribute>
...
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
MTA_Sztaki_IdP
Tulajdonság | Érték |
---|---|
Intézmény (IdP) neve | MTA SZTAKI |
IdP szoftver | nincs megadva |
Technikai kapcsolattartó | Szabó Gyula, sys-admin@sztaki.hu |
Azonosítható felhasználók száma | 400 |
Hallgatók száma | 0 |
Alkalmazottak száma | 400 |
Külsősök száma | 0 |
Nem felhasználóhoz köthető bejegyzések száma | 20 |
Hallgatók felvételének folyamata | Nem alkalmazható |
Alkalmazottak felvételének folyamata | Új munkatárs intézetbe történő beléptetésekor a Személyügyi Osztály felelős munkatársa veszi fel a névtárba az elsődleges adatokat, megadva a belépő munkatárs nevét, szervezeti egységét, beosztását, a besorolás típusát (főállású/részmunkaidős, tudományos/nem tudományos munkatárs)) és az intézetbe való belépés idejét is. A belépő munkatársak mail címét, azonosítóját (uid) és elsődleges jelszavát a közvetlen munkahelyi vezető írásos témaszám igénylése alapján az alkalmazás adminisztrátor regisztrálja a névtárban. A munkatárs ezután azonosítható az IdP számára. |
Külsősök felvételének folyamata | A SZTAKI külön IdP-ben tartja nyilván a különböző projektekben résztvevő partnereket (SZTAKI Partners' IdP), ez az IdP nem része a HREF föderációnak. |
Hallgatók törlésének folyamata | Nem alkalmazható |
Alkalmazottak törlésének folyamata | A munkatárs kilépésekor a Személyügyi Osztály felelős munkatársa regisztrálja a névtárban a kilépés tényét és időpontját. Ennek eredményeként a kilépett munkatárs már nem tud bejelentkezni a rendszerekbe, így a SZTAKI IdP sem azonosítja. Ezt követően a kilépők adatait áthelyezzük egy archívumba, ahová a kereséseket nem engedjük be. |
Külsősök törlésének folyamata | HREF föderáció szempontjából érdektelen információ |
Felhasználó intézményhez való kapcsolatát leíró attribútum/érték | IdP-nk csak munkatársakat azonosít, így minden assertion eduPersonAffiliaton attribútuma employee értékkel van kiállítva. |
Egyes attribútumok származás helye ill. módosításra jogosultak | Új munkatárs intézetbe történő beléptetésekor a Személyügyi Osztály felelős munkatársa veszi fel a névtárba az elsődleges adatokat, megadva a belépő munkatárs nevét, szervezeti egységét, beosztását és az intézetbe való belépés idejét is.A belépő munkatársak mail címét, azonosítóját (uid) és elsődleges jelszavát a közvetlen munkahelyi vezető írásos témaszám igénylése alapján az alkalmazás adminisztrátor regisztrálja a névtárban.A mail szolgáltatáshoz kapcsolódó egyéni beállítások önálló szabályozására kifejlesztettünk egy web-es felületet, az IFAR-t (Integrált Felhasználói Adminisztrációs Rendszer). Ennek segítségével a munkatársak önállóan tudják változtatni jelszavaikat, kezelhetik leveleik átirányítását, ill. akár megadhatják a szabadság idején küldendő automatikus válasz szövegét is. Az önadminisztrációs felület ad lehetőséget az azonosított felhasználónak a szobaszáma, telefomszáma ill a mobil telefonszáma regisztrálására is. |
Jelszavak formai követelményei | A felhasználóknak legalább 6 karakter hosszú jelszavakat kell használniuk. A jelszóváltoztató felület ellenőrzi, hogy az új jelszó megfelel-e ennek a követelménynek.A teszt felhasználók jelszavai minimálisan 8 karaktert (kis- és nagybetűket, számokat, opcionálisan egyéb karaktereket) kell, hogy tartalmazzanak. |
Naplóállományok rendelkezésre állási ideje | Havonta |
Autentikációs backend | LDAP |
Autentikációs mód | Apache |
Vállalt rendelkezésre állás | Az Identity Provider funkciót egy nagy rendelkezésre állású klaszter biztosítja. A rendelkezésre állásnak nincs formálisan vállalt értéke, a havi rendelkezésre állási statisztikák szerint a megelőző 6 hónapban a SZTAKI IdP rendelkezésre állása 99,99% volt. |
Dunaújvárosi_Főiskola_IdP
Tulajdonság | Érték |
---|---|
Intézmény (IdP) neve | Dunaújvárosi Főiskola (idp2.duf.hu) |
IdP szoftver | nincs megadva |
Technikai kapcsolattartó | Kovács Csaba, cs.kovacs@mail.duf.hu; Botka István, boti@makacs.duf.hu |
Azonosítható felhasználók száma | 280 |
Hallgatók száma | 5200 |
Alkalmazottak száma | 130 |
Külsősök száma | 0 |
Nem felhasználóhoz köthető bejegyzések száma | 5 |
Hallgatók felvételének folyamata | Neptun rendszerben regisztrált hallgató adatai folyamatosan szinkronizálásra kerülnek a címtárral. |
Alkalmazottak felvételének folyamata | Minden oktató és nem oktató dolgozó a Netware eDirectoryba kerül felvételre a Humánerőforrás Igazgatóságon (HR szervezet). A címtárral való szinkronizásás a dolgozó számára ismertetett jelszómódosítási eljárás alkalmával történik meg. Ettől kezdve tudják használni a föderatív és belső szolgáltatásokat (Shibboleth, Eduroam, SSO). |
Külsősök felvételének folyamata | - |
Hallgatók törlésének folyamata | Végzett, vagy eltávozott hallgató aktív statusa törlésre kerül. A tanulmányi előadó eltávolítja az edupersonAffiliation: student attribútumot |
Alkalmazottak törlésének folyamata | A munkatárs kilépésekor a HR szervezeti előadó eltávolítja az edupersonAffiliation: employee attribútumot, az esetleg használt edupersonEntitlement értékeket. Inaktív felhasználói bejegyzését a címtárból egyelőre nem törlünk. (Kialakítandó az archiválási és törlési szabályozás.) |
Külsősök törlésének folyamata | - |
Felhasználó intézményhez való kapcsolatát leíró attribútum/érték | edupersonAffiliation: employee edupersonAffiliation: students edupersonAffiliation: member edupersonAffiliation attribútum vagy edupersonAffiliation: affiliate |
Egyes attribútumok származás helye ill. módosításra jogosultak | A felhasználók attribútumait - a jelszavukat leszámítva - kizárólag a névtár adminisztrációjára jogosult az Informatikai Szolgáltató Központ alkalmazásában álló rendszergazda módosíthatja. A userCertificate;binary attribútumot a tanúsítvány publikálásakor az NIIF CA hozza létre. |
Jelszavak formai követelményei | A felhasználók jelszómegadási szabálya: legalább 8 karakter hosszú, lehetőleg nem értelmes szóként ismert jelszavakat kell használniuk. A jelszóváltoztató felület ellenőrzi, hogy az új jelszó megfelel-e ezeknek a követelményeknek.A teszt felhasználóknak generált (kis- és nagybetűket, számokat, opcionálisan egyéb karaktereket) tartalmazó jelszavakat állítunk elő. |
Naplóállományok rendelkezésre állási ideje | Jelenleg nincs log rotálás |
Autentikációs backend | LDAP |
Autentikációs mód | Apache |
Vállalt rendelkezésre állás | Az Identity Provider funkciót egy virtuális szerverkörnyezetben (Vmware) futó szerver biztosítja. A rendelkezésre állásnak nincs meghatározott értéke (belső szolgáltatás). |
AA_Testing
The following shell script uses curl to query a SAML2 Attribute Authority.
You need a valid principal (eduPersonPrincipalName) and the X.509 credentials of an existing Service Provider to use this script.
Source
#!/bin/bash
basedir=$(dirname $0)
# URL of the Attribute Authority
AA_URI="https://hexaa.eduid.hu:8443/simplesaml/module.php/aa/attributeserver.php"
# Testing principal (subject)
Principal="bajnokk@niif.hu"
# HEXAA cert
AACert="$basedir/keys/hexaa.eduid.hu-aa.crt"
# EntityID and credentials of the SP on behalf of which
# the request is made
ReqSP="https://sp.hexaa.eduid.hu/test"
ReqCert="$basedir/keys/test.sp.hexaa.eduid.hu-fed.crt"
ReqKey="$basedir/keys/test.sp.hexaa.eduid.hu-fed.key"
usage () {
cat <<EOS
Usage: $0 [options]
Options:
-a uri Attribute Authority URI. Defaults to '$AA_URI'
-C certfile Attribute Authority metadata certificate in PEM format. Defaults to '$AACert'.
-p principal Testing principal (user name / subject). Defaults to '$Principal'.
-s entity EntityID of the SP on behalf of which the request is made. Defaults to '$ReqSP'
-k keyfile Key file in PEM format containing the key of the SP used for the request. Defaults to '$ReqKey'
-c certfile Cert file in PEM format containing the certificate of the SP used for the request. Defaults to '$ReqCert'
EOS
exit 3
}
# Get command line arguments
while getopts "a:p:s:k:c:h" opt; do
case $opt in
a)
AA_URI=$OPTARG
;;
C)
AACert=$OPTARG
;;
p)
Principal=$OPTARG
;;
s)
ReqSP=$OPTARG
;;
k)
ReqKey=$OPTARG
;;
c)
ReqCert=$OPTARG
;;
h)
usage
;;
\?)
usage
;;
esac
done
DATE=$(date --utc +%FT%TZ)
ReqID=$(hexdump -n 16 -e '4/4 "%08x" 1 "\n"' /dev/urandom)
read -r -d '' REQ_XML <<EOS
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<samlp:AttributeQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_$ReqID" IssueInstant="$DATE" Version="2.0">
<saml:Issuer>$ReqSP</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">$Principal</saml:NameID>
</saml:Subject>
</samlp:AttributeQuery>
</S:Body>
</S:Envelope>
EOS
#debug echo "$REQ_XML"
echo "$REQ_XML" | \
curl --silent --show-error --cacert $AACert --cert $ReqCert --key $ReqKey \
--header "Content-Type: text/xml;charset=UTF-8" --data @- $AA_URI
Validation of response
Signature validation:
xmlsec1 --verify --id-attr:ID "urn:oasis:names:tc:SAML:2.0:protocol:Response" --trusted-pem $aacert $response 2>/dev/null
Content validation:
xmllint --xpath "//*['Attribute'](local-name()#bkmrk-)[@Name'$attribute']/*[local-name()='AttributeValue']/text()" $response
IdP_whichone
A legfontosabb, hogy föderációs oldalról nincs különbség a Shibboleth és a SimpleSAML között, azaz bármelyik IdP bármelyik SP-vel képes együttműködni. Föderációs szempontból a különbség mindössze két apróság :
- Single Logout: A Shibboleth nem támogatja a Single Logout-ot, mert a fejlesztők úgy gondolják, hogy ezt nem lehet rendesen implementálni. A régi IdP-hez az NIIF csinált SLO-t, de ez nem került a hivatalos kiadásba és a friss verziókkal már nem működik. Az új IdP-kben van olyan funkcionalitás, hogy a logout-ot kezdeményező SP-ből és az IdP-ből kiléphet a felhasználó, de ez a többi SP-nél esetleg érvényes session-jét nem érinti. A SimpleSAMLphp támogatja az SLO-t, minden örökletes betegségével együtt.
- ECP: A Shibboleth támogatja az ECP profilt, ami akkor használható, ha nem webes kliensekkel akarjuk használni az IdP-t. Praktikusan az Office365 és néhány (nálunk nem használatos) grides alkalmazás tartozik ide. A SimpleSAML ECP támogatásán még dolgoznak, de addig is van arra megoldás, hogy ECP nélkül is lehessen Office365-öt használni.
Ezek a gyakorlatban nem fontos dolgok. Az érdemi döntési pont az, hogy melyik környezethez értetek jobban:
- ha Apache + PHP, akkor SimpleSAMLphp;
- ha Jetty + Java, akkor Shibboleth.
Az IdP-hez javasolt konfiguráció:
- Linux (tetszőleges)
- 2GB RAM, 2 VCPU
- felhasználók által ismert tanúsítvány
Shibboleth_troubleshooting
- Session creation error
- Invalid assertion consumer service URL
- Unauthorized identity provider
- Clock skew
- Unable to locate valid authentication statement
- HTTP Status 404
Lásd még: Internet2 Shibboleth wiki (angol)
!!! info
**Ha semmi sem segít...**
* Győződjünk meg róla, hogy nincs-e betelve a diszk
* Ellenőrizzük, hogy a rendszerórák szinkronban járnak-e
* Ellenőrizzük, hogy a böngészőben a cookie-k engedélyezve vannak-e
* Indítsuk újra a böngészőt
* Indítsuk újra az apache-ot és a shibd-t
Intézmény_átnevezés
Sok esetben merül fel az a kérdés, hogy eduID tagintézmény névváltozása esetén mi a teendő. Alább egy konkrét levelezés másolata következik, amely remélhetőleg általános információkat tartalmaz.
Kérdés
Kecskemét és Szolnok egyesítésével létrejött a Pallasz Athéné Egyetem. Mit kell ilyenkor tennünk? Mert a weboldalakat át kéne neveznem az új dominre. Kell csinálnom új IDP-t és új SP-ket? vagy csak SP-ket?
Szerződés
Ha a PAE jogutódja a KeFo-nak, akkor nem kell új szerződést kötni. Egyébként igen.
Átnevezni vagy nem átnevezni?
entityID
Az entitások átnevezése problémás, ezért azt célszerű kerülni. A legtöbb gond az eduPersonTargetedId-vel van, ugyanis az "targeted" azonosító, ami azt jelenti, hogy akár az IdP, akár az SP entityID-je megváltozik, az azonosító értéke is megváltozik, azaz a felhasználó "élettörténete" újraindul az SP-nél. Ráadásul az azonosítók kézi átállítása is meglehetősen körülményes. Kérdés, hogy mely általatok használt SP-k használnak eduPersonTargetedId-t. A Videotorium például igen, ill. lásd még a href.xml-ben a RequestedAttributes elemet. Mivel az entityID nem jelenik meg a felhasználóknak (normális esetben), emiatt nem valószínű, hogy bárki arra kötelezne titeket, hogy változtassátok meg.
További probléma az entityID megváltoztatásával, hogy a kereskedelmi adatbázis-szolgáltatók jellemzően kézzel tartják karban azt a listát, hogy mely intézmények számára elérhető a szolgáltatás, és az entityID változtatása miatt az intézményünk kikerülhet ezekből a listákból.
Scope
Az eduPersonPrincipalName és az eduPersonScopedAffiliation használja a scope-okat. Az minden további nélkül működik, hogy újabb scope-okat IS elkezdjetek használni (új felhasználóknál), de ha egy létező felhasználó scope-ját lecserélitek, akkor ő a fentihez hasonló módon új felhasználóként jelenik meg az összes SP-nél. És eduPersonPrincipalname-et és/vagy eduPersonScopedAffiliationt nagyon sok SP használ, valamint a legtöbb belső SP is valószínűleg úgy van konfigurálva, hogy scope alapon végezze az autorizációt. Az autorizációs szabályok (pl. require affiliation member@kefo.hu
vagy require eppn bekre.pal@kefo.hu
) szabályok módosítása triviális. Az élettörténet megtartása sajnos már alkalmazásspecifikus, jellemzően kézi adatbázisműveleteket igényel. Annyival egyszerűbb ez, mint az eduPersonTargetedId módosítása, hogy pontosan tudod az átírási szabályt, pl:
s/([^@]+)@kefo.hu/$1@pae.hu/
A tanácsom az, hogy nézzétek át, hogy mely SP-k esetén fontos az élettörténet megtartása, és ezeket kérjétek meg a fenti változtatásra. (Pl. ha vannak olyan HBONE-adminisztrációs szolgáltatások, amiket eddig kefo.hu-s azonosítóval használtál, akkor azok ilyenek.)
A mail cím megváltoztatása jellemzően nem jelent problémát. Azt érdemes észben tartani, hogy a Drupal megköveteli az e-mail címek egyediségét, azaz ha megváltozik az eppn, miközben nem változik a mail, akkor az "új" felhasználó létrehozása nem fog sikerülni.
IdP URL
Mellékhatások nélkül módosítható, hogy az IdP milyen URL-en azonosítsa a felhasználókat (vagy válaszoljon az AttributeQuery-kre, de ez nagyon ritka funkció). Ehhez a SingleSignOnService
és SingleLogoutService
végpontokat kell lecserélni a Resource Registry-ben a haladó beállítások között, valamint természetesen az IdP webszerverét megfelelően kell konfigurálni. Ez a módosítás kizárólag azt befolyásolja, hogy milyen URL jelenik meg a felhasználók böngészőjében, amikor azonosításra átirányítják őket az SP-k. Nyilván megfelelő SSL tanúsítvány is kell az új URL-re.
Discovery leírás
Ez is mellékhatások nélkül módosítható, és ez az, ami a leginkább szembetűnő a felhasználók számára. Ezt is a Resource Registry-ben, a Leírók-nál kell módosítani. (Légyszi küldjetek egy értesítést az info @ eduid.hu-ra, ha módosítjátok, mert a központi Discovery Service-t jelenleg még kézzel kell frissítenünk.)
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:
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.
HREF_attribútum_specifikáció
A specifikáció célja
A föderációban az IdP SAML attribútumokban ad meg adatokat a felhasználóról az SP-nek. Ahhoz, hogy az adatokban hordozott információ átadása pontos legyen, fontos, hogy a használt attribútumokat a két fél ugyanúgy értelmezze.
Az attribútumok pontos meghatározása az attribútumok sémájában található. A specifikációban az alábbi sémákat használtuk fel:
- person, organizationalPerson (X.521)
- inetOrgPerson (RFC2798)
- eduPerson (http://middleware.internet2.edu/eduperson/)
- SCHAC (http://www.terena.org/activities/tf-emc2/schacreleases.html)
- niifPerson, niifEduPerson (NIIFSchema)
A fenti dokumentumokban definiált attribútumoknak a föderációban való értelmezését határozza meg az Attribútum Specifikáció. Ez néhány esetben valamivel szűkebb, mint az eredeti definíció, azért, hogy az információt az SP-k pontosabban értelmezhessék.
A specifikációban felsoroltakon túl az IdP-k tetszőleges attribútumot megvalósíthatnak és kiadhatnak bilaterális megállapodás alapján.
Attribútumok használata
Meghatározások
- Implementáció (megvalósítás): egy IdP abban az esetben implementál egy attribútumot, ha az attribútumban hordozott információ a föderációs specifikációnak megfelelő szemantikai és formai követelmények szerint a rendelkezésére áll. Ez jelentheti azt, hogy a felhasználói adatbázisban a felhasználó bejegyzése tartalmazza ezt az attribútumot, de az attribútum más módon is előállhat (pl. statikusan vagy más attribútumokból dinamikusan generálva). Az implementáció részleteivel kapcsolatban a föderáció nem fogalmaz meg megkötést
- Attribútum kiadás: az attribútum átadása néhány (vagy a föderációban található összes) SP-nek.
Implementációs szintek
- Kötelező: az attribútumot kötelező az IdP-nek implementálni. (Nem kötelező kiadnia.)
- Ajánlott: az attribútumot ajánlott az IdP-nek implementálni, de ez néhány intézménynél lehetetlen vagy nehézségekbe ütközhet
- Opcionális: az attribútumot az IdP a saját döntése szerint megvalósíthatja.
- Fontos kiemelni, hogy amennyiben egy IdP implementál egy opcionális attribútumot, azt a specifikáció szerint KÖTELEZŐ megtennie, azaz követve a specifikáció szemantikai és szintaktikai előírásait.
SP attribútum-igények
Az SP-k a Resource Registry-ben, és ezen keresztül a metadata állományban jelezhetik, hogy egy attribútum számukra megkövetelt (required) vagy ajánlott (desired).
- Megkövetelt: az alkalmazás működéséhez elengedhetetlen az attribútum
- pl.
eduPersonPrincipalName
olyan alkalmazásokhoz, amelyek nincsenek felkészítve átlátszatlan (opaque) azonosítók kezelésére
- pl.
- Ajánlott: az alkalmazás működését megkönnyíti az attribútum
- pl. a
cn
attribútum átadásakor az alkalmazás nem kéri be a felhasználó teljes nevét regisztrációkor
- pl. a
Hibakezelés
Abban az esetben, ha egy IdP nem adja ki egy vagy több az SP számára elengedhetetlen attribútumot, az SP-nek KÖTELEZŐ a felhasználónak hibaüzenetet adnia. (Ugyanis egy SP csak abban az esetben jelölhet meg egy attribútumot megkövetelt attribútumnak, ha ez az alkalmazás működéséhez elengedhetetlen, minden egyéb esetben ajánlott-nak kell megjelölnie.) Azonban ez a hibaüzenet lehetséges, hogy a felhasználó számára nehezen értelmezhető (pl: Authorization Required).
Ezért az IdP-k számára AJÁNLOTT kiadni azokat az attribútumokat, amelyeket az SP-k megkövetelt-nek jelölnek meg.
Attribútumok listája
Lista
Kötelező attribútumok
eduPersonScopedAffiliation |
---|
schacHomeOrganizationType |
eduPersonPrincipalName |
Ajánlott attribútumok
eduPersonEntitlement |
Állandó felhasználói azonosítók
Bizonyos alkalmazások esetén szükséges alkalmazás-specifikus adatokat is tárolni. Ilyen példa lehet egy webes naptárnál a felhasználóhoz kötődő bejegyzések, vagy egy wikinél a felhasználó szerkesztései. Ezeket az alkalmazások valamilyen helyi adatbázisban tárolják, a kulcs a felhasználó és az adatbázis bejegyzés között pedig egy állandó azonosító.
Az állandó azonosítók lehetnek:
- statikusak: a felhasználó létrehozásakor megadott adattal megegyezők
- számítottak: a felhasználó valamelyik (vagy több) attribútumából algoritmikusan - általában hash eljárással - generáltak
- tároltak: ezek általában olyan azonosítók, amelyet az IdP egy adatbázisban elsődleges kulcsként használ, azaz
- a felhasználói attribútumok változása esetén is állandó marad
- egyediségük biztosított
Az azonosítók az alábbi tulajdonságokkal rendelkezhetnek:
- állandóság: az IdP-nek gondoskodnia kell arról, hogy a kiosztott azonosító a felhasználó intézménynél töltött életciklusa során állandó legyen.
- Amennyiben egy állandó(nak szánt) azonosító mégis megváltozik, az nagyon nehéz helyzetbe hozhatja mind a felhasználót, mind az alkalmazás üzemeltetőt. Erre megoldás lehet a SAML2 NameID Mapping, azonban ezt jelenleg a föderációban használt szoftverek csak részlegesen vagy egyáltalán nem támogatják.
- nem osztható ki újra (non-reassignable): az IdP-nek gondoskodnia kell arról, hogy egy felhasználó azonosítóját később nem osztja ki másik felhasználónak.
- Ennek algoritmikus biztosítása bizonyos esetekben nehézségekbe ütközhet (pl. hash ütközések, illetve bizonyos IdP-k kézzel osztanak azonosítókat), ezért jelen specifikáció csak azt követeli meg, hogy azonosító a gyakorlatban ne tegye lehetővé, hogy az alkalmazás oldalán a felhasználók összekeveredjenek. Különböző IdP-ktől jövő felhasználók azonosítói abban az esetben nem ütközhetnek, ha az azonosítónak része valamilyen, az IdP-re jellemző adat (scope vagy entityID).
- nem átlátszó (opaque): az ilyen azonosítók nem jellemzők a felhasználóra, az értékéből nem lehet következtetni a felhasználó személyére (pl. e-mail címére)
- Nem minden azonosító rendelkezik ilyen tulajdonsággal, azonban intézmények között adatvédelmi szempontból kifejezetten kívánatos, hogy egy azonosító ne legyen jellemző a felhasználó személyére. A nem átlátszó azonosítót nem célszerű a felhasználók felé megjeleníteni.
- célzott (targeted): az ilyen azonosítók minden SP-nél különbözőek, s így az SP-k - az IdP közreműködése nélkül - nem képesek profilt készíteni egy felhasználóról, ami adatvédelmi szempontból kívánatos.
- Nem minden azonosító rendelkezik ilyen tulajdonsággal.
Az állandó azonosító kiadható attribútumként, illetve a SAML Assertion NameID mezőjében. Bizonyos SP implementációk (pl. a Shibboleth 2.x) képesek arra, hogy az alkalmazás részére elfedjék azt, hogy az azonosító pontosan milyen attribútumban vagy NameID-ben érkezett, pl. úgy, hogy az azonosítót a REMOTE_USER változóban adják ki az alkalmazás számára.
NameID formátumok - melyiket válasszam?
A föderáció elvárja, hogy az IdP-k támogassák mind a tranziens NameID formátumot, mind a célzott, átlátszatlan azonosítót (melyek lehetnek tároltak vagy számítottak). A tárolt azonosítót célszerű SAML2 perszistens NameID-ként kiadni, a számított azonosító azonban csak az eduPersonTargetedID attribútumban adható ki, mivel nem rendelkezik a perszisztens NameID szemantikájával.
A Shibboleth IdP implementáció esetén a számított azonosítókról a tárolt azonosítókra való áttérés nem változtatja meg a kiadott azonosítókat, ezért az SP-k számára ez az áttérés transzparens.
Ha SP-t üzemeltetünk, akkor célszerű már az üzemeltetés kezdetén eldönteni, hogy melyik formátum mellett tesszük le a voksunkat (ez elsősorban az SP által védett alkalmazás képességeitől függ), mert menet közben átállni körülményes, sok energiát igényel. A problémára reméljük könnyebb lesz a megfelelő választ megtalálni az alábbi kérdés átgondolásával: Szükséges-e az SP számára, hogy egy-egy felhasználójához tartozzon egy-egy állandó azonosító?
- Ha nem, akkor egyértelmű a választás: tranziens formátumot kell használni.
- Ha igen, és nem szükséges, hogy az állandó azonosító a felhasználóra jellemző legyen, ill. az SP mögötti alkalmazás felkészült ilyen azonosító fogadására ( az alkalmazás szempontjából mindegy, hogy milyen úton, tehát eduPersonTargetedID attribútumként, vagy perzisztens NameID-ként érkezik az érték az SP-hez ), akkor az SP-nek Nem kell meghatároznia, hogy milyen NameID formátumot támogat, hiszen ezesetben
- a) Ha az IdP nem támogatja a tárolt azonosítókat, akkor a tranziens NameID mellé az eduPersonTargetedID attribútumban ki fogja adni a számított (és célzott) azonosítót.
- b) Ha az IdP támogatja a tárolt azonosítókat, akkor azt perzisztens NameID-ként fogja kiadni (illetve, ha az SP kéri az eduPersonTargetedID attribútumot, az IdP képes ugyanezt a tárolt értéket ilyen formában is kiadni).
- Az alkalmazáshoz mindkét esetben ugyanaz az érték jut el, mint felhasználói azonosító.
- Ugyanaz, mint a 2., kivéve, hogy magasabb szintű felhasználókezelést (például SAML NameID menedzsmentet) is szeretne az SP használni, akkor kizárólag perzisztens NameID-t kell kérnie. A HREF föderáció jelenleg nem rendelkezik a magasabb szintű SAML protokollokról, ezért ezek használata kizárólag az adott SP és IdP közötti megállapodáson alapulhat.
- Ha szükséges, hogy az állandó azonosító a felhasználóra jellemző legyen, őt egyértelműen azonosítsa, akkor a választás tranziens NameID, amely mellé meg kell követelni az eduPersonPrincipalName kiadását.
A HREF föderációban az IdP-k részéről elvárt, hogy a fenti 1-2. megoldásokat támogassák. A 3-4. esetében minden további nélkül előfordulhat, hogy az IdP és SP közötti kommunikáció hibát jelez, mert valamelyik fél nem támogatja a másik fél által megkövetelt / biztosított azonosító formátumot...
!!! info
Egy SP a [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry)-ben jelezheti, hogy milyen NameID formátumokat támogat. Ha kizárólag perzisztens NameID formátumot támogat, akkor vagy kap az IdP-től ilyet, vagy hiba lép fel a válasz feldolgozása során.
eduPersonTargetedID
eduPersonTargetedID | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonTargetedID OID: 1.3.6.1.4.1.5923.1.1.1.10 |
Rövid leírás | Nem átlátszó, célzott azonosító, amely nem osztható ki újra |
Implementáció | kötelező |
Részletes leírás | Lásd: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID , ill. a fenti megjegyzést az implementációs szinttel kapcsolatban. Az SP a kapott értéket fel kell, hogy dolgozza, nem adhatja XML formátumban tovább az alkalmazásnak. A benne szereplő ún. qualifier-ek közül az IdP azonosítóját (NameQualifier ) és természetesen magát az azonosítót kötelező szerepeltetni az alkalmazás számára átadott azonosítóban. Javasolt az egyes mezőket '!' karakterrel elválasztani egymástól.Az IdP-nek biztosítania kell, hogy egy felhasználó számára kiosztott azonosító valóban perzisztens legyen, tehát gondoskodnia kell az attribútum-értékek biztos tárolásáról - például egy megfelelő mentési tervvel üzemeltetett relációs adatbázisban.Az eduPersonTargetedID nem osztható ki újra. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Az attribútum értékének a SAML2 szabványban definiált NameID formátumúnak kell lennie; az azonosító (nem számítva az XML attribútumokat) legfeljebb 256 karakterből állhat. |
Példa | Az IdP ilyen formában adja ki az azonosítót:<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://idp.example.org/idp/shibboleth" SPNameQualifier="https://sp.example.org/shibboleth">84e411ea-7daa-4a57-bbf6-b5cc52981b73</saml2:NameID>Az alkalmazás ilyen formában kapja meg az azonosítót:https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73 |
eduPersonPrincipalName
eduPersonPrincipalName | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonPrincipalName OID: 1.3.6.1.4.1.5923.1.1.1.6 |
Rövid leírás | Állandó, nem célzott, nem újra kiosztható egyedi azonosító |
Implementáció | kötelező |
Részletes leírás | Formátum: <egyedi_lokális_azonosító>@ |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Adatgazda | intézmény |
Példa | gipsz.jakab@example.org |
niifPersonOrgID
niifPersonOrgID | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonPrincipalName OID: 1.3.6.1.4.1.11914.0.1.154 |
Rövid leírás | Állandó egyedi azonosító intézményen belüli, ill. e-learning használatra |
Implementáció | opcionális |
Részletes leírás | Bizonyos esetekben adatvédelmi szempontok miatt szükség lehet arra, hogy a felhasználó intézményen belüli azonosítója (pl. Neptun kódja) és az egyéb alkalmazásokban használt uid különböző legyen.Ezen attribútum intézmények közötti átadása csak abban az esetben javasolt, ha e-learning rendszerek miatt meg kell osztani a tanulmányi azonosítót. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
schacPersonalUniqueCode
schacPersonalUniqueCode | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.25178.1.2.14 |
Rövid leírás | Állandó egyedi azonosító interföderációs környezetben való használatra |
Implementáció | opcionális |
Részletes leírás | - |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | Directory String |
Példa | urn:schac:personalUniqueCode:hu:bme.hu:Neptun:gmx3f0 |
Felhasználói tulajdonságokat leíró attribútumok
sn
sn | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:sn OID: 2.5.4.4 |
Rövid leírás | A felhasználó vezetékneve |
Implementáció | opcionális |
Részletes leírás | A felhasználó vezetékneve. Amennyiben több vezetékneve van a felhasználónak, akkor ezeket egyetlen értékben kell tárolni. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Példa |
givenName
givenName | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:givenName OID: 2.5.4.42 |
Rövid leírás | A felhasználó keresztneve |
Implementáció | opcionális |
Részletes leírás | Amennyiben több keresztneve van a felhasználónak, ezeket egyetlen értékben kell tárolni. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Példa |
displayName
displayName | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:displayname OID: 2.16.840.1.113730.3.1.241 |
Rövid leírás | A felhasználó megjelenítendő neve |
Implementáció | ajánlott |
Részletes leírás | A felhasználó neve abban a formában, ahogy a felhasználó, vagy a felhasználó intézménye meg kívánja jeleníteni. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Példa | Gipsz Jakab Aladár |
Elnevezés | URI: urn:mace:dir:attribute-def:mail OID: 0.9.2342.19200300.100.1.3 |
Rövid leírás | A felhasználó email címe |
Implementáció | ajánlott |
Részletes leírás | A felhasználó értesítési e-mail címe. Az így átadott email címről az intézmény biztosítja, hogy |
Lehetséges értékek | Létező e-mail cím |
Értékek száma | multi |
Szintaktika | Lásd: [RFC 2822](http://www.faqs.org/rfcs/rfc2822.html) |
Példa | gipsz.jakab@example.org |
preferredLanguage
preferredLanguage | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:preferredLanguage OID: 2.16.840.1.113730.3.1.39 |
Rövid leírás | Előnyben részesített nyelv |
Implementáció | opcionális |
Részletes leírás | A felhasználó által elsődlegesen használni kívánt, általa előnyben részesített nyelv |
Lehetséges értékek | RFC 2068 Language Tags szekcióban meghatározott formátumú nyelvkódok |
Értékek száma | single |
Szintaktika | Directory String |
Példa | hu |
schacDateOfBirth
schacDateOfBirth | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.25178.1.2.3 |
Rövid leírás | A felhasználó születési dátuma |
Implementáció | opcionális |
Részletes leírás | - |
Lehetséges értékek | YYYYMMDD (RFC 3339 'full-date') formátumú dátum |
Értékek száma | single |
Szintaktika | Directory String |
Példa | 19700101 |
schacYearOfBirth
schacYearOfBirth | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.25178.1.0.2.3 |
Rövid leírás | A felhasználó születési éve (amennyiben csak az évre van szükség, egyébként ajánlott a schacDateOfBirth használata) |
Implementáció | opcionális |
Részletes leírás | - |
Lehetséges értékek | YYYY formátumú év |
Értékek száma | single |
Szintaktika | Directory String |
Példa | 1970 |
schacPersonalTitle
schacPersonalTitle | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.25178.1.2.8 |
Rövid leírás | A felhasználó személyes megszólítása. |
Implementáció | opcionális |
Részletes leírás | A felhasználó nevéhez kapcsolódó megszólítás, mely a teljes név elé fűzhető. A címtárban tárolható a niifPersonPrefix attribútumban is. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Példa |
niifPersonMothersName
niifPersonMothersName | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.157 |
Rövid leírás | Felhasználó anyja neve |
Implementáció | opcionális |
Részletes leírás | A felhasználó anyjának születési neve a felhasználó hivatalos irataiban. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Példa | Kőkori Vilma |
niifPersonResidentalAddress
niifPersonResidentalAddress | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.159 |
Rövid leírás | A felhasználó állandó lakcíme |
Implementáció | opcionális |
Részletes leírás | - |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Példa | 1111 Budapest, Villányi út 155. |
homePostalAddress
homePostalAddress | |
---|---|
Elnevezés | URI: nincs megadva OID: 0.9.2342.19200300.100.1.39 |
Rövid leírás | A felhasználó ideiglenes lakcíme |
Implementáció | opcionális |
Részletes leírás | - |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | Directory String |
Példa | 1111 Budapest, Villányi út 155. |
telephoneNumber
telephoneNumber | |
---|---|
Elnevezés | URI: nincs megadva OID: 2.5.4.20 |
Rövid leírás | A felhasználó vezetékes telefonszáma |
Implementáció | opcionális |
Részletes leírás | - |
Lehetséges értékek | A telefonszámot az ITU-T E.123 szabvány szerint kell tárolni. A melléket a / jellel elválasztva jelölhető. |
Értékek száma | multi |
Szintaktika | Directory String |
Példa |
mobile
mobile | |
---|---|
Elnevezés | URI: nincs megadva OID: 0.9.2342.19200300.100.1.41 |
Rövid leírás | A felhasználó mobilszáma |
Implementáció | opcionális |
Részletes leírás | - |
Lehetséges értékek | A telefonszámot az ITU-T E.123 szabvány szerint kell tárolni. |
Értékek száma | multi |
Szintaktika | Directory String |
Példa | +36 30 123 1234 |
eduPersonNickName
eduPersonNickName | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.5923.1.1.1.2 |
Rövid leírás | A felhasználó beceneve |
Implementáció | opcionális |
Részletes leírás | Az a becenév, amelyet a felhasználó általában használ (pl. online fórumokon). Nem egyedi, a hossza és a tartalma sem kötött, nem állandó, ezért az alkalmazásnak mindenképpen ellenőriznie kell, mielőtt - esetleg - lokális felhasználónévként figyelembe veszi. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Adatgazda | felhasználó |
Példa |
cn
cn | |
---|---|
Elnevezés | URI: nincs megadva OID: 2.5.4.3 |
Rövid leírás | A felhasználó teljes neve |
Implementáció | opcionális |
Részletes leírás | A felhasználó vezetéknevének és keresztnevének valamilyen módon történő, szóközzel elválasztott összefűzése. Használata intézményenként és országonként eltérő. Jellemző, hogy több értékben különböző módokon előállított értékeket is tartalmaz.Helyette a displayName használata javasolt. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | Directory String |
Példa |
jpegPhoto
jpegPhoto | |
---|---|
Elnevezés | URI: nincs megadva OID: 0.9.2342.19200300.100.1.60 |
Rövid leírás | Kis méretű fotó a felhasználóról JPEG formátumban |
Implementáció | opcionális |
Részletes leírás | - |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
labeledUri
labeledUri | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.250.1.57 |
Rövid leírás | Felhasználóhoz tartozó URI-k |
Implementáció | opcionális |
Részletes leírás | A felhasználó által megadott, vagy rá valamilyen formában jellemző URI-k (gyakran URL-ek) gyűjteménye, mint pl. a személyes honlapjának címe. Minden azonosítóhoz opcionálisan kapcsolható szöveges leírás. |
Lehetséges értékek | Az URL-t urlencode-olva kell tárolni (RFC 2079). |
Értékek száma | multi |
Szintaktika | Directory String |
Példa |
Felhasználó és az intézmény viszonyát leíró attribútumok
eduPersonScopedAffiliation
eduPersonScopedAffiliation | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonScopedAffiliation OID: 1.3.6.1.4.1.5923.1.1.1.9 |
Rövid leírás | Felhasználó és intézmény közti viszony leírása |
Implementáció | kötelező |
Részletes leírás | <viszony>@<\scope>
|
Lehetséges értékek | A következő értékek egyike: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, valamint a Scope |
Értékek száma | multi |
Szintaktika | Directory String |
Adatgazda | intézmény |
Példa |
eduPersonEntitlement
eduPersonEntitlement | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonEntitlement OID: 1.3.6.1.4.1.5923.1.1.1.7 |
Rövid leírás | A felhasználó által jogosan használt erőforrás(ok) |
Implementáció | ajánlott |
Részletes leírás | Azon erőforrások listája, melyet a felhasználó használhat. Sok erőforrást minden felhasználó elérhet, néhányat csak korlátozott kör - ez utóbbi esetben válik fontossá ez az attribútumInfoAz eduPersonEntitlement attribútumnak csak azon értékeit szabad kiadni az SP-nek, amelyek rá vonatkoznak. Ennek meghatározása kézi adminisztráció esetén igen nehéz lehet, ezért erre célszerű valamilyen adminisztrációs felületet használni. (Sajnos jelenleg nem létezik ilyen alkalmazás.) |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | Directory String |
Adatgazda | intézmény |
Példa | urn:geant:niif.hu:niif:entitlement:vhoadmin |
schacHomeOrganizationType
schacHomeOrganizationType | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:schacHomeOrganizationType OID: 1.3.6.1.4.1.25178.1.2.10 |
Rövid leírás | Az intézmény jellege |
Implementáció | kötelező |
Részletes leírás | |
Lehetséges értékek | urn:schac:homeOrganizationType:hu:{university,nren,library,vho,school,business,other,test} |
Értékek száma | single |
Szintaktika | URN |
Adatgazda | intézmény |
ou
ou | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:ou OID: 2.5.4.11 |
Rövid leírás | Az intézményen belüli egység teljes neve (organizationalUnit) |
Implementáció | opcionális |
Részletes leírás | Azon egység (tanszék, intézet, könyvtár, stb) neve, amelyhez a felhasználó tartozik. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Példa | Automatizálási és alkalmazott informatikai tanszék |
eduPersonOrgUnitDN
eduPersonOrgUnitDN | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonOrgUnitDN OID: 1.3.6.1.4.1.5923.1.1.1.4 |
Rövid leírás | A felhasználóhoz tartozó szervezeti egység azonosítója |
Implementáció | opcionális |
Részletes leírás | A felhasználóhoz tartozó szervezeti egység (pl. tanszék, intézet, könyvtár, ...) intézményen belüli egyedi, esetleg hierarchikusan képzett azonosítója.Amennyiben az adott felhasználó több egységhez is besorolható, ez az attribútum több értéket is tartalmazhat. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | DN |
Adatgazda | intézmény |
eduPersonPrimaryOrgUnitDN
eduPersonPrimaryOrgUnitDN | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonPrimaryOrgUnitDN OID: 1.3.6.1.4.1.5923.1.1.1.8 |
Rövid leírás | A felhasználóhoz hozzárendelhető elsődleges szervezeti egység azonosítója. |
Implementáció | opcionális |
Részletes leírás | Az eduPersonOrgUnitDN-ben tárolt egység-azonosítók közül azon elem, amelyhez a felhasználó elsődlegesen köthető. |
Lehetséges értékek | Egy olyan azonosító, mely szerepel az eduPersonOrgUnitDN értékei között. |
Értékek száma | single |
Szintaktika | DN |
Adatgazda | intézmény |
Oktatásban használt attribútumok
niifEduPersonAttendedCourse
niifPersonAttendedCourse | |
---|---|
Elnevezés | URI: urn:geant:niif.hu:dir:attribute-def:niifEduPersonAttendedCourse OID: 1.3.6.1.4.1.11914.0.1.164 |
Rövid leírás | Felhasználó által hallgatott tárgy kódja |
Implementáció | opcionális |
Részletes leírás | Azon tantárgyak kódja, amelyet a felhasználó az adott félévben hallgat.Oktatási intézmény esetén JAVASOLT az attribútumot implementálni és az intézményen belüli SP-k számára kiadni. Adatvédelmi szempontból JAVASOLT az értékeket úgy szűrni, hogy az SP csak a számára releváns tárgyak kódját kapja meg. |
Lehetséges értékek | A tanulmányi rendszerben meghatározott tantárgykódok |
Értékek száma | multi |
Szintaktika | Directory String |
Adatgazda | intézmény |
Példa |
niifEduPersonArchiveCourse
niifEduPersonArchiveCourse | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.171 |
Rövid leírás | A felhasználó által valaha hallgatott kurzusok |
Implementáció | opcionális |
Részletes leírás | Azon tantárgyak kódja, amelyet a felhasználó valaha hallgatott az adott intézményben. |
Lehetséges értékek | A tanulmányi rendszerben meghatározott tantárgykódok |
Értékek száma | multi |
Szintaktika | Directory String |
Adatgazda | intézmény |
niifEduPersonHeldCourse
niifEduPersonHeldCourse | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.172 |
Rövid leírás | A felhasználó által aktuálisan oktatott tárgyak |
Implementáció | opcionális |
Részletes leírás | Azon tantárgyak kódja, amelyet a felhasználó az adott félévben (esetleg előző félévben) oktatott. |
Lehetséges értékek | A tanulmányi rendszerben meghatározott tantárgykódok |
Értékek száma | multi |
Szintaktika | Directory String |
Adatgazda | intézmény |
niifEduPersonMajor
niifEduPersonMajor | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.162 |
Rövid leírás | A hallgató főszakja |
Implementáció | opcionális |
Részletes leírás | A hallgató főszakja - a mab.hu oldalán található lista alapján |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | Directory String |
Adatgazda | intézmény |
Példa |
niifEduPersonFaculty
niifEduPersonFaculty | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.160 |
Rövid leírás | Kar neve |
Implementáció | opcionális |
Részletes leírás | Teljes neve annak a karnak, amelyhez a hallgató tartozik |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | Directory String |
Adatgazda | intézmény |
Példa | Villamosmérnöki és Informatikai Kar |
niifEduPersonFacultyDN
niifEduPersonFacultyDN | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.161 |
Rövid leírás | A hallgató karának DN-je |
Implementáció | opcionális |
Részletes leírás | - |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | DN |
Adatgazda | intézmény |
niifEduPersonStudentCategory
niifEduPersonStudentCategory | |
---|---|
Elnevezés | URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.174 |
Rövid leírás | Tanuló/hallgató képzési szintjének meghatározása |
Implementáció | opcionális |
Részletes leírás | A hallgató képzési szintjének pontosabb meghatározása (az eduPersonScopedAffiliation kiegészítése) |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | Directory String |
Adatgazda | intézmény |
Attribútum_kiadás
!!! bug "Elavult információ"
**Figyelem**: a Shibboleth szoftver ezen változata már nem támogatott. Az új verziókhoz a leírások itt találhatók:
* [Shibboleth2_IdP](https://help.edu.hu/books/aai/page/shibboleth2-idp)
* [Shibboleth2_SP](https://help.edu.hu/books/aai/page/shibboleth2-sp)
Az Attribute Release Policy (ARP) határozza meg, hogy az attribútum feloldás után rendelkezésre álló attribútumok közül mely attribútumokat lehet az SP-nek kiadni. Egy ARP vonatkozhat a teljes IdP-re ("site" ARP), illetve az azonosított felhasználóra is. A site-ARP-k általában a arps/arp.site.xml állományban, a felhasználói ARP-k pedig az arps/arp.user.$PRINCIPAL.xml állományban találhatók, ahol $PRINCIPAL megegyezik a REMOTE_USER változóban megkapott értékkel.
Működő példa
<?xml version="1.0" encoding="UTF-8"?>
<AttributeReleasePolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:mace:shibboleth:arp:1.0"
xsi:schemaLocation="urn:mace:shibboleth:arp:1.0 shibboleth-arp-1.0.xsd" >
<Description>Not The Simplest Possible ARP.</Description>
<Rule>
<Description>Mindenkire vonatkozó szabályok</Description>
<Target>
<AnyTarget/>
</Target>
<Attribute name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation">
<AnyValue release="permit"/>
</Attribute>
<Attribute name="urn:mace:dir:attribute-def:eduPersonOrgDN">
<AnyValue release="permit"/>
</Attribute>
</Rule>
<Rule>
<Description>NIIFI által üzemeltetett SP-kre vonatkozó szabályok</Description>
<Target>
<Requester matchFunction="urn:mace:shibboleth:arp:matchFunction:regexMatch">.*\.n?iif\.hu\/.*</Requester>
</Target>
<Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName">
<AnyValue release="permit"/>
</Attribute>
<Attribute name="urn:mace:dir:attribute-def:mail">
<AnyValue release="permit"/>
</Attribute>
<Attribute name="urn:mace:dir:attribute-def:cn">
<AnyValue release="permit"/>
</Attribute>
<Attribute name="urn:mace:dir:attribute-def:eduPersonEntitlement">
<Value release="permit"
matchFunction="urn:mace:shibboleth:arp:matchFunction:regexMatch">
^urn:niif.hu:services:aai:entitlement:.*
</Value>
</Attribute>
</Rule>
</AttributeReleasePolicy>
ARP feldolgozás menete
- Meghatározza, hogy melyik ARP file-okat kell feldolgozni.
- Meghatározza, hogy melyek azok a szabályok, amelyek az attribútum lekérdezéshez kapcsolódnak
- Minden ARP szabály, amely alapértelmezettnek vannak megjelölve, automatikusan bekerül az ARP-be, anélkül, hogy az illesztési függvényeket (matchFunction) végrehajtaná
- Minden nem alapértelmezett szabály illesztési függvénye alapján megállapítja, hogy a providerId alapján vonatkozik-e a kérést indító félre.
- Attribútum filter létrehozása
- Minden attribútumhoz megállapítja a vonatkozó Rule-ok listáját
- Ebből a listából az összes olyan attribútum értéket kiveszi, amelyre deny szabály vonatkozik
- Ha egy szabály úgy rendelkezik, hogy minden érték kiadható, akkor az egyes értékekre vonatkozó deny szabályok szűkítik a kiadható értékek listáját. Ha egy szabály az attribútumok összes értékének kiadását megtiltja, akkor az egyes értékekre vonatkozó engedélyek figyelmen kívül lesznek hagyva.
ARP Rule
Az ARP szabályok különböző illeszkedési vizsgálatok segítségével megállapítják, hogy egy SP-nek egy-egy attribútum milyen feltételekkel adható ki.
matchFunction
Ez az attribútum adja meg, hogy milyen illesztési eljárást kell használni az illeszkedési vizsgálatnál. Lehetséges értékei:
- urn:mace:shibboleth:arp:matchFunction:stringMatch: true, ha két karakterlánc pontosan megegyezik (ez az alapértelmezett illesztési függvény)
- ugyanezt jelenti: urn:mace:shibboleth:arp:matchFunction:exactShar
- urn:mace:shibboleth:arp:matchFunction:stringNotMatch: true, ha két karakterlánc eltér
- urn:mace:shibboleth:arp:matchFunction:regexpMatch: true, ha a karakterlánc megfelel a paraméterként megadott reguláris kifejezésnek
- urn:mace:shibboleth:arp:matchFunction:regexpNotMatch: true, ha a karakterlánc nem felel meg a paraméterként megadott reguláris kifejezésnek
- urn:mace:shibboleth:arp:matchFunction:anyValueMatch: tetszőleges nem üres string esetén true
Target
A Target elemnek kétféle gyermeke lehet:
**AnyTarget**
: minden SP-re vonatkozik a szabály (az azonosítatlan SP-kre is!)**Requester**
: a szabály akkor kerül az effective ARP-be, ha az SP providerId-je illeszkedik
Attribute
Egy Rule 0 vagy több Attribute elemet tartalmazhat. Tartalmaznia kell egy name
paramétert, amely az attribútum teljes neve (általában URN, lásd az attribútum feloldás leírását). Az elemnek kétféle gyermeke lehet:
**AnyValue**
: az attribútum bármely értékére vonatkozik a szabály**Value**
: ebben az esetben kötelezően szerepel egy**release**
paraméter, melynek értéke permit vagy deny lehet. Itt is opcionálisan megadható a**matchFunction**
paraméter.
Constraint
A Constraint-ek használatával attribútumok kiadását más attribútumok értékéhez is köthetjük, így pl. megtehetjük, hogy a "hozzajarulasBeszerezve" nevű attribútum true
értékéhez kössük az attribútumok kiadását.
A megkötések konfigurációjához lásd: https://spaces.internet2.edu/display/SHIB/ArpConstraint
Tesztelés
A Shibboleth IdP-hez tartozik egy resolvertest névre hallgató program, amellyel ellenőrizhetjük az attribútumok kiadását is. 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 --idpXml=file:///etc/shibboleth-idp/idp.xml --user=bajnokk
(Azonosítatlan SP-nek kiadott attribútumok)
<Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
AttributeName="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<AttributeValue Scope="niif.hu">employee</AttributeValue>
</Attribute>
<Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
AttributeName="urn:mace:dir:attribute-def:eduPersonOrgDN"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<AttributeValue>o=niifi,o=niif,c=hu</AttributeValue>
</Attribute>
Példa 2.:/usr/local/shibboleth-idp/bin/resolvertest --idpXml=:///etc/shibboleth-idp/idp.xml --user=bajnokk --requester=https://dev.aai.niif.hu/shibboleth
(Azonosított SP-nek kiadott attribútumok.)
...
<Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<AttributeValue Scope="niif.hu">bajnokk</AttributeValue>
</Attribute>
...
Hivatkozások
- https://spaces.internet2.edu/display/SHIB/IdPARPConfig
- https://spaces.internet2.edu/display/SHIB/AttributeReleaseRule
- https://spaces.internet2.edu/display/SHIB/ArpConstraint
- ShARPE ARP Editor
ShibSPInstallDebian
Ez egy elavult lap, használd ezt helyette!
A Debian 4.0 (Etch) már tartalmazza a Shibboleth SP-t (és függőségeit), ezért csak a megfelelő csomagokat kell telepítenünk.
-
Ez igaz, csakhogy a debianos liblog4cpp4 nem thread-safe, ezért a shibd nagyobb terhelésnél elhasal! A probléma javítása folyamatban van...
root@hal:~# <b>apt-get install libapache2-mod-shib opensaml-schemas</b> Csomaglisták olvasása... Kész Függőségi fa építése... Kész Az alábbi extra csomagok kerülnek telepítésre: libicu36 liblog4cpp4 libsaml5 libshib-target5 libshib6 libxalan110 libxerces27 libxml-security-c12 Javasolt csomagok: xalan Az alábbi ÚJ csomagok lesznek telepítve: libapache2-mod-shib libicu36 liblog4cpp4 libsaml5 libshib-target5 libshib6 libxalan110 libxerces27 libxml-security-c12 opensaml-schemas 0 frissített, 10 újonnan telepített, 0 eltávolítandó és 18 nem frissített. Letöltés az archívumokból: 12,7MB Kicsomagolás után 39,6MB lemezterületet használok fel Folytatni akarod [Y/n]? <b>y</b>
A telepítés után az Apache webszervert újra kell indítani.
ShibTest
Ha már úgy gondoljuk, hogy készen vagyunk
- az IdP beállításaival
- az SP beállításaival
- és a közöttük érvényes metadata állomány létrehozásával, akkor itt az idő, hogy teszteljük, jól működik-e a nagy egész.
Erre jó kis eszköz a Shibenv. Segítségével kilistázhatjuk a felhasználói attribútumokat, a webszerver változókat, illetve a teljes megkapott SAML Response-t (amennyiben az exportAssertion="true"
be van állítva; ezt a tesztelés idejére érdemes beállítani).
Hibaelhárítás
!!! warning "A szócikk vagy fejezet még megírásra vár"
Shibboleth hibaüzenet
Lásd: Shibboleth troubleshooting
Nincsenek attribútumok
Megtörténik-e a session létrehozás?
Van session
Nincs session
Hiányoznak bizonyos attribútumok
Lehetséges okok:
- Hiányzik a felhasználó attribútuma a felhasználói adatbázisból
- Az IdP-nek nincs joga lekérdezni az adatbázisból az attribútumot (pl. LDAP ACI)
- Az IdP nem oldja fel az attribútumot
- Az IdP nem adja ki az attribútumot az SP-nek.
- Az SP nem fogadja el az attribútumot az IdP-től
- Az IdP nem ismeri fel az SP-t (hiba az IdP és az SP kölcsönös SSL autentikációjában), és csak az autentikálatlan SP-knek kiadható attribútumokat adja ki.
Szövetségi_alapon_történő_felhasználó_azonosítás_Huntéka_könyvtári_alkalmazásokban
Könyvtári alkalmazás használati esetei
Könyvtári és föderatív azonosságok
A könyvtári alkalmazás olvasói nyilvántartásában szereplő és a föderatív azonosítás szolgáltatónál lévő azonosságokat a könyvtári alkalmazásban célszerűen össze kell kapcsolni. Ez az identitás összekapcsolás mindig feltételezi a felhasználó aktív közreműködését, e nélkül az identitások összekapcsolása nem jöhet létre.
Egy föderatív azonosítással elérhető, SP-vel védett Online könyvtári beiratkozás szolgáltatásnál ez egy tájékoztató szöveg megjelenése és tudomásul vétele után történik meg, a már hagyományos módon beiratkozott, az alkalmazás olvasói nyilvántartásában már szereplő olvasók “könyvtári identitását” viszont külön eljárással kell összekapcsolni az IdP által azonosítottakkal.
Ha a könyvtári alkalmazásban már létezik webes azonosítás, akkor célszerű egy olyan komponenst beilleszteni, ahol a felhasználó mind a könyvtári azonosságát (könyvtári azonosító - jelszó), mind a föderatív azonosságát tudja bizonyítani, és a komponens összeköti a két azonosítót a kapcsoló táblában (account linking). A tájékoztató szöveg megjelenítése és annak elfogadása ekkor történhet meg.
Az MTA SZTAKI könyvtára esetében a felhasználók nem tudtak bejelentkezni a webes felületen, az identitás összekapcsolást segítő kulcs az email cím lehetett, ez alapján az összerendelések nagy tömegét elvégezhettük, a maradék azonosítót pedig kézzel, további adatok összehasonlításával, vagy közvetlenül az olvasó megkeresésével lehetett elvégezni.
Identitások összekapcsolása
A könyvtári rendszert fel kell készíteni a szövetségi azonosítás során használt azonosítójukkal érkező felhasználók fogadására. Ehhez szükség van egy kapcsoló táblára, ahol a könyvtári azonosítót és a föderált azonosítókat tároljuk.ű
Bejelentkezés során bármely eduid-vel azonosítja a felhasználót a szóbanforgó Home IdP, az alkalmazás kikeresi a megfelelő könyvtári alkalmazásbeli azonosítót, és a továbbiakban az alkalmazás ezt használja a munkamenet során.
Beiratkozás
Ha a felhasználó olyan azonosítóval jön a Home IdP-től, ami nincs egyetlen alkalmazás azonosítóhoz sem kapcsolva, a beiratkozás folyamatát kell végrehajtani.
A beiratkozás folyamán létre kell hozni az olvasó táblában az új olvasót, és a Home IdP-től kapott személyes adatokkal fel kell tölteni az olvasó rekordot.
A “Föderált azonosító” kapcsolótáblában létre kell hozni a könyvtári azonosítót és a föderált azonosítót összerendelő rekordot.
Kiiratkozás
Felhasználó kiiratását az OIOSAML.java nem támogatja, az azonosító lejáratásával lehet a felhasználó jogosultságait korlátozni. Tervezésnél meg kell fontolni, hogy egy-egy IdP által azonosított felhasználó beiratásánál mennyi az az idő, amíg az olvasót aktívnak szeretnénk tudni. Megvizsgálva néhány könyvtár Használati szabályzatát a megoldás megfelel az általános gyakorlatnak. A könyvtárak beiratkozáskor kiállított olvasójegyét bizonyos időre szóló érvényességgel (általában 1 év) állítják ki, ha az olvasó ennek elteltével nem hosszabbítja meg olvasójegye érvényességét, az lejár.
Azonosítás és attribútumok átadása
A LoginFilter által védett URL-re irányuló kéréskor a SAML Assertion és az általa hordozott attribútumok a dk.itst.oiosaml.sp.UserAssertion objektumból lekérdezhetőek. Ezen objektum csak a védett URL-eken érhető el a dk.itst.oiosaml.sp.UserAssertionHolder.get() metódus meghívásával.
Ha csak a login funkciót védjük SAML SP-vel, érdemes a user session-be átmenteni a szükséges attribútumokat, ha azokat más funkciókkal is el kell érni.
Attribútum mappingről igény szerint a fejlesztés során kell gondoskodnunk, az OIOSAML.java nem támogat ilyen funkciót.
Példa az eduPersonPrincipalName attribútum kinyeréséről:
UserAssertion ua = UserAssertionHolder.get();
String eppn = ua.getAttribute(“urn:oid:1.3.6.1.4.1.5923.1.1.1.6 ”);
A rendszerfejlesztéshez kapcsolódó dokumentáció az alábbi URL-en található:
[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/developers.html]
Attribútumok frissítése
Hogy a könyvtári rendszerben nyilvántartott olvasók adatai naprakészek legyenek, a Home IdP-től származó attribútumokat nem csak a beiratkozáskor, hanem a mindennapi használatkor is igénybe vehetjük.
Az IdP-től kapott attribútumokat a könyvtári alkalmazás ellenőrzi, és ha az adott attribútum még nem szerepel a nyilvántartásában, azt rögzíti.
Az alkalmazás saját szabály-rendszere döntheti el, hogy a meglévő értékeket lecseréli az Home IdP-től kapottal, vagy csak hozzáadja új értékként a már meglévőhöz.
Kijelentkezés
SP által kezdeményezett SLO
Az alkalmazásból történő kijelentkezést a session-változók törlésével kell megoldani, és biztosítani kell a Single Logout folyamat elindítását. Az OIOSAML.java esetében ezt a saml/Logout URL-re történő redirect-tel lehet kezdeményezni.
HttpSession session = req.getSession(false);
res.sendRedirect("saml/Logout");
IdP által kezdeményezett SLO
Ha a Single Logout-ot a felhasználó egy másik alkalmazásnál kezdeményezte, és kérte, hogy valamennyi aktív alkalmazásból léptesse ki a rendszer, az IdP a könyvtári alkalmazásnak egy Logout Request-et küld a böngésző átirányításának segítségével. A kérésről a SAML SP-n kívül az alkalmazásnak is tudnia kell, hogy a felhasználó session-jén a kilépést érvényre juttassa. Ezt a SAML SP SLO endpoint-jai elé tett filter segítségével lehet a legegyszerűbben végrehajtani.
LogoutFilter.java
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import org.apache.log4j.Logger;
/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {
/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);
public LogoutFilter() {
}
/**
* @see Filter#destroy()
*/
public void destroy() {
}
/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}
/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}
web.xml
...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...
Rendszer architektúra
OIOSAML.java, mint SP komponens
Telepítés
Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:
- Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába
- Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:
<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>
<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>
<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>
A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.
A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.
Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.
Konfiguráció
Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.
Telepítés után a következő módosításokat érdemes megtenni a fileban:
oiosaml-sp.assurancelevel=0
Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.
oiosaml-sp.uri.home=../
Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.
A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:
https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html
Meta-adat kezelés
A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.
Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.
Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.
Discovery Service
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.
Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.
Telepítése az oiosaml.java-discovery..war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery. változók használhatóak.
A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található: https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html
Metadata frissítés
A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.
Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.
Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.
A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.
Shib3IdpProd
Shibboleth 3 IdP éles szolgáltatás építése
Linux rendszer-szolgáltatás Debian-on
Az alábbi parancsokat root felhasználóként futtassuk.
mkdir /opt/jetty-home
useradd -d /opt/jetty-home -U -r -s /bin/false jetty
chown jetty:jetty jetty-home
echo "JETTY_USER=\"jetty\"
JETTY_HOME=/opt/jetty-distribution-9.2.<legutóbbi stabil verzió>
JETTY_BASE=/opt/jetty-shibboleth-idp" > /etc/default/jetty
cp /opt/jetty-distribution-9.2.<legutóbbi stabil verzió>/bin/jetty.sh /etc/init.d/jetty
update-rc.d jetty defaults
- Az 1-3. sorban elkészítjük a jetty nevű rendszerszintű felhasználót, akinek a nevében fut a szolgáltatás.
- A 4-6. sorban a szolgáltatás Debian-specifikus beállítóállományába veszünk fel beállításokat. A JETTY_HOME helyen található a letöltés után kicsomagolt Jetty alkalmazás-konténer. A JETTY_BASE helyen a Shibboleth 3 IdP alkalmazáshoz beállított Jetty példány helyezkedik el.
- A 7-8. sorban a rendszer-szolgáltatások könyvtárába másoljuk az indító script-et és bekapcsoljuk az önműködő indulást.
Dokumentáció
UApprove
!!! warning
Ez jelen formájában egy elavult lap, hamarosan frissítésre kerül
uApprove
Felépítés
Az uApprove a SWITCH.ch által fejlesztett alkalmazás, ami a Shibboleth2 IdP-vel együttműködve képes a felhasználótól attribútum-kiadás hozzájárulást kérni.
A uApprove két részből áll. Egy szervlet filterből (IdP plugin), ami a Shibboleth2 IdP webalkalmazásba beépülve elkapja és elemzi a kéréseket, illetve egy különálló webalkalmazásból (Viewer), ami a felhasználói hozzájárulást kéri el.
A felhasználói hozzájárulásnak két szintje van: a globális felhasználási feltételek elfogadása, illetve minden SP esetén egy ún. digitális identitás elfogadása. Ez utóbbi felület lehetőséget ad a felhasználó számára hogy lássa az adott SP felé kiadandó attribútumait, és beleegyezzen azok kiadásába.
A hozzájárulások XML fájlban vagy relációs adatbázisban is tárolhatók. A uApprove lehetőséget ad arra, hogy az SP-hez történő hozzáféréseket naplózza, az attribútum-kiadástól függetlenül (tehát elég az IdP plugin komponenst használni ahhoz hogy a naplózás működjön - ezt Monitoring módnak hívjuk).
uApprove viewer webalkalmazás telepítése
cd uApprove-2.1.4/
unzip viewer-2.1.4-bin.zip
sudo cp viewer-2.1.4/conf-template/* /path/to/uApprove/uApprove
sudo cp -r viewer-2.1.4/webapp /path/to/tomcat/webapps/uApprove
A uApprove közös konfiguráció a common.properties fájlban található:
storageType = Database
databaseConfig = /path/to/uApprove/database.properties
#storageType = File
#flatFile = /path/to/uApprove/uApprove-log.xml
# A globális felhasználási feltételeket tároló fájl
# Ebben az XML-ben több verzió is tárolható,
# verzióváltás esetén a felhasználónak újra el kell fogadnia.
termsOfUse = /path/to/uApprove/terms-of-use.xml
# Kommunikáció titkosításához
SharedSecret = some-very-random-string
database.properties (a támogatott RDBMS a MySQL):
driver = com.mysql.jdbc.Driver
url = jdbc:mysql://localhost:3306/*dbname*
user = *username*
password = *password*
sqlCommands = /path/to/ArpViewer/mysql.commands
viewer.properties:
# amennyiben a böngésző nem küld lokalizációs információt, ezen beállítás jut érvényre
useLocale = HU_hu
# felajánljuk-e a felhasználónak az sp-től független beleegyezést
globalConsentPossible=true
loggingConfig = /path/to/uApprove/logging.xml
attribute-list: az attribútumok sorrendezését és egyes nem kívánt attribútumok (pl transientid) elrejtését állíthatjuk be benne. Az attribútumnevek a Shibboleth2 attribute-resolver.xml -ben deklaráltaknak kell megfeleljenek.
web.xml (/path/to/tomcat/webapps/uApprove/WEB-INF):
<context-param>
<param-name>Config</param-name>
<param-value>
/path/to/uApprove/viewer.properties;
/path/to/uApprove/common.properties;
</param-value>
</context-param>
IdP plugin beállítása
Csomagoljuk ki a plugint és másoljuk a konfigurációt illetve a szükséges library fájlokat a helyükre
cd uApprove-2.1.4/
unzip idp-plugin-2.1.4-bin.zip
sudo cp idp-plugin-2.1.4/conf-template/* /path/to/uApprove
sudo cp idp-plugin-2.1.4/lib/* /path/to/idp-setup/src/main/webapp/WEB-INF/lib/
Ezután szerkesszük az IdP web.xml konfigurációját
<web-app>
...
<filter>
<filter-name>uApprove IdP plugin</filter-name>
<filter-class>ch.SWITCH.aai.uApprove.idpplugin.Plugin</filter-class>
<init-param>
<param-name>Config</param-name>
<param-value>
/path/to/uApprove/idp-plugin.properties;
/path/to/uApprove/common.properties;
</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>uApprove IdP plugin</filter-name>
<url-pattern>/profile/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
</web-app>
Ezután a Shibboleth IdP setup.sh szkriptjével készítsük el a webarchívumot (idp.war), amit telepítsünk újra.
A uApprove IdP plugin egyedi beállításai az idp-plugin.properties-ben találhatóak:
# Azon SP-hez amihez nem akarunk ArpFiltert használni
spBlacklist = /path/to/config/sp-blacklist
# SP logolás
LogProviderAccess = false
# Csak SP logolás
MonitoringOnly = false
# ArpViewer alkalmazás helye
uApproveViewer = https://idp.example.org/uApprove/Controller
# Támogassuk-e a passzív authentikációt
isPassiveSupport = false
Attribútumnevek beállítása
Az attribútumnevek helyes megjelenítéséhez az ArpViewer a Shibboleth2 IdP attribute-resolver.xml fájlt használja. Ebben a fájlban kell beállítani a lokalizált attribútumneveket a következőképpen:
Shibboleth2 IdP conf/attribute-resolver.xml:
<resolver:AttributeDefinition id="postalAddress"
xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="postalAddress">
<resolver:Dependency ref="myLDAP" />
<resolver:DisplayName xml:lang="en">Business postal address</resolver:DisplayName>
<resolver:DisplayName xml:lang="hu">Hivatalos postai cím</resolver:DisplayName>
<resolver:DisplayDescription xml:lang="en">Business postal address: Campus or office address</resolver:DisplayDescription>
<resolver:DisplayDescription xml:lang="hu">Az intézmény hivatalos postai címe</resolver:DisplayDescription>
Megjegyzés: a Resource_Registry által előállított attribute-resolver.xml template fájl tartalmazza az attribútumok magyar nyelvű leírásait.
ArpFilter before the profile servlet - support for other authentication modules
Lásd: ArpFilterProposal (angol)
URN
Registrations in the urn:geant:niif.hu Namespace
GEANT has delegated the operation of urn:geant:niif.hu namespace to NIIFI -> KIFÜ. KIFÜ administers the Uniform Resource Name namespace urn:geant:niif.hu, which enables all scientific institutions in Hungary to assign unique, permanent and globally valid names to different resources. The exact use of the entries is not prescribed. GÉANT primarily wants to promote standardization within the scientific community and especially the interoperability of middleware with the namespace.
If you want to request a delegation, please send an email to urn@niif.hu.
Namespaces administered by KIFÜ
Namespace | Purpose | Date Registered | Registry link/email |
---|---|---|---|
urn:geant:niif.hu:niif | Namespace supporting KIFÜ systems | 10 March 2010 | urn@niif.hu |
- | - | - | - |
Shib2IdpRHEL
Előkészületek
entityID
Tanúsítvány
JDK
https://wiki.shibboleth.net/confluence/display/SHIB2/JVMTuning
[idp2:~/java]$ sudo_ssh rpm -Uvh jdk-6u7-linux-i586.rpm
Preparing... ########################################### [100%]
1:jdk ########################################### [100%]
Unpacking JAR files...
rt.jar...
jsse.jar...
charsets.jar...
tools.jar...
localedata.jar...
plugin.jar...
javaws.jar...
deploy.jar...
A többi rpm-mel nem törődünk.
Shibboleth Security Provider
Be kell másolni a lib/shib-jce-1.0.jar
állományt a $JAVA_HOME/jre/lib/ext
könyvtárba. Ha az ext/
könyvtár nem létezik, akkor hozzuk létre.
cp lib/shib-jce-1.0.jar $JAVA_HOME/jre/lib/ext
Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a $JAVA_HOME/jre/lib/security/java.security
fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort:
security.provider.7=edu.internet2.middleware.shibboleth.DelegateToApplicationProvider
- Megj.: a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!
Bouncy Castle JCE
A JVM-mel jövő Java Cryptography Engine (JCE) nem támogatja az összes kriptográfiai algoritmust, amelyre az Identity Providernek szüksége lehet (pl. XML Digital Signature, XML Encryption). A Bouncy Castle JCE ezek mellett még olyan algoritmusokat is tartalmaz (általában hatékonyabb és szabványosabb formában), amelyek benne vannak a Java JCE-ben.
Ehhez először le kell tölteni a Bouncy Castle JCE-t. A JCE állományok a Provider oszlopban, a "Signed Jar Files" részben találhatók. (A nevük bcprov-jdk-VERZIO.jar
.) Letöltés után a .jar fájlokat a $JAVA_HOME/jre/lib/ext
könyvtárba kell tenni.
wget http://www.bouncycastle.org/download/bcprov-jdk15-141.jar
cp bcprov-jdk15-141.jar $JAVA_HOME/jre/lib/ext
Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a $JAVA_HOME/jre/lib/security/java.security
fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort:
security.provider.8=org.bouncycastle.jce.provider.BouncyCastleProvider
- Megj.: a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!
Tomcat
Tomcat 6-ot fogunk használni, AJP connectorral
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare
#XXX-TODO useradd tomcat
cd /usr/local
tar xzf ~/apache-tomcat-6.0.18.tar.gz
ln -s apache-tomcat-6.0.18 tomcat
cd tomcat
mv conf /etc/tomcat ; ln -s /etc/tomcat conf
mv logs /var/log/tomcat; ln -s /var/log/tomcat logs
mkdir /var/lib/tomcat
mv temp /var/lib/tomcat; ln -s /var/lib/tomcat/temp .
mv webapps /var/lib/tomcat; ln -s /var/lib/tomcat/webapps .
mv work /var/lib/tomcat; ln -s /var/lib/tomcat/work .
chown -R tomcat:tomcat /etc/tomcat /var/log/tomcat /var/lib/tomcat
Konfiguráció
A /etc/tomcat/server.xml
-ben módosítani kell a 8009-es porton figyelő Connectort az alábbira:
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009"
protocol="AJP/1.3" redirectPort="8443"
enableLookups="false" tomcatAuthentication="false"
address="127.0.0.1"/>
Init script
Az alábbi házi készítésű init script használható a tomcat elindításához:
#!/bin/bash
#
# chkconfig: - 85 15
# processname: tomcat
# description: Start up the Tomcat servlet engine.
# Source function library.
. /etc/init.d/functions
PATH=/bin:/usr/bin:/sbin:/usr/sbin
export JAVA_HOME=/usr/java/default
CATALINA_HOME="/usr/local/tomcat"
TOMCAT_USER=tomcat
# Max. heap size: 512 MB
# Memory allowed for the permanent generation object space: 256 MB
export JAVA_OPTS="-Xmx512m -XX:MaxPermSize=256m"
if [`id -u` -ne 0 ](); then
echo "You need root privileges to run this script"
exit 1
fi
case "$1" in
start)
if [-f $CATALINA_HOME/bin/startup.sh ]();
then
echo $"Starting Tomcat"
su -c "$CATALINA_HOME/bin/startup.sh" -s /bin/bash $TOMCAT_USER
fi
;;
stop)
if [-f $CATALINA_HOME/bin/shutdown.sh ]();
then
echo $"Stopping Tomcat"
su -c "$CATALINA_HOME/bin/shutdown.sh" -s /bin/bash $TOMCAT_USER
fi
;;
restart)
$0 stop
sleep 2;
$0 start
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
;;
esac
exit $?
A következő parancsok hatására a Tomcat automatikusan elindul bootoláskor:
chkconfig --add tomcat
chkconfig tomcat on
Shibboleth_SP
Telepítési leírások
Konfigurációs leírások
- SP alkalmazás konfigurációja
- Attribútumok használata
- Naplózási beállítások
- Alkalmazás levédése Shibboleth-tel
- Lazy Session használata
AAIGettingStarted
AAI Getting Started
ElsevierSP
Speciális eduPersonTargetedID kiadásának beállítása
Shibboleth IdP alatt
vim [/path/to]/shibboleth-idp/conf/attribute-resolver.xml
Szúrjuk be az alábbi attribútumdefiníciót, ahol
- a
scope
értéke az intézményi scope (ugyanaz, amit pl. az eduPersonPrincipalName attribútum előállításakor is használ) - a
sourceAttributeID
értéke a persistent nameID-t előállító attribútum id-je
<!-- Buggy edupersonTargetedId required for Elsevier: -->
<resolver:AttributeDefinition id="elsevierId" xsi:type="Scoped" scope="niif.hu" sourceAttributeID="persistentId"
xmlns="urn:mace:shibboleth:2.0:resolver:ad" >
<resolver:Dependency ref="storedIdConnector" />
<resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="buggy-eduPersonTargetedID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder" />
</resolver:AttributeDefinition>
vim [/path/to]/shibboleth-idp/conf/attribute-filter.xml
Fontos, hogy amennyiben az ajánlásnak megfelelően a Resource Registry által előállított attribute filtert használjuk, akkor ne ezt a dinamikusan frissülő fájlt szerkesszük, hanem az attribute-filter-local.xml-t, és ebben a fájlban végezzük el az alábbi módosításokat.
-
Szúrjuk be az alábbi részletet, amely megmondja, hogy az Elsevier SP számára mely attribútumok adandók ki:
<AttributeFilterPolicy id="buggy-eptid"> <PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://sdauth.sciencedirect.com/" /> <AttributeRule attributeID="elsevierId"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> <AttributeRule attributeID="eduPersonScopedAffiliation"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy>
-
A
releaseIDsToAnyone
alapértelmezett szabályt módosítsuk az alábbiakra:<!-- Release IDs to anyone --> <AttributeFilterPolicy id="releaseIDsToAnyone"> <PolicyRequirementRule xsi:type="basic:NOT"> <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://sdauth.sciencedirect.com/" /> </PolicyRequirementRule> <AttributeRule attributeID="transientId"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> <AttributeRule attributeID="persistentId"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy>
Ez utóbbi módosításra azért van szükség, hogy a mindenki számára kiadható szabványos persistentID ne csapja felül ez Elsevier számára kiadandót.
SimpleSAMLphp alatt
vim [/path/to]/simplesaml/metadata/saml20-sp-remote.php
Beállítjuk, hogy csak az elsevier SP-je esetén az attribútum előállítás és kiadás folyamatát toldja meg még egy lépéssel. Ehhez szükséges, hogy a fenti fájlba vegyük fel állandó elemként az Elsevire SP metadatájának kiegészítéseként az alábbi PHP tömböt. Fontos, hogy a tömb egyes elemei előtt szereplő számok magasabbak legyenek, mint az IdP általános feloldási szabályainál megadott számok, de alacsonyabbak, mint a jellemzően a folyamat végén beállított 'name2oid' mappelések.
$metadata['https://sdauth.sciencedirect.com/']['authproc'] = array (
96 => array(
'class' => 'core:TargetedID'
),
97 => array(
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonTargetedID',
'pattern' => '/^.*$/',
'replacement' => '${0}@intezmenyiScope.hu',
),
);
A fenti kódrészlet annyit teszi, hogy újragenerálja az alapértelmezett eduPersonTargetedID-t egyszerű formában (csak a stringet, a NameID-s xml struktúra nélkül), majd mögé teszi az intézményi scope-ot. Fontos, hogy a megoldás feltételezi azt, hogy az Elsevier SP metadatájának további részei betöltésre kerülnek pl. a metarefresh modul által.
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
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
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.
AAI_szolgáltatási_IP
eduID szolgáltatási IP-k
193.224.92.0/24 |
---|
193.225.14.128/25 |
2001:738:0:431::/64 |
EduidFedStats
Ezen az oldalon a föderációban résztvevő IdP-k történő becsatornázásáról lehet olvasni.
- eduID statisztikák:
- statisztikai projektről bővebben, angolul: FederationStats
Általában
Egy IdP-nek naponta egyszer kell beküldenie az összesített, előző napra vonatkozó statisztikáit. A beküldendő fájl az alábbi módon épül fel:
ENTITYID https://idp.niif.hu/idp/shibboleth APIKEY 0123....... DATE 2009-03-18 STAT AUTH 68 logins STAT USER_COUNT 16 unique userids STAT SSO_TO_SERVICE 1 | urn:geant:niif.hu:niifi:sp:register.ca.niif.hu 12 | https://repo.niif.hu/shibboleth 1 | https://sandbox.aai.niif.hu/shibboleth 5 | https://sysmonitor.hbone.hu/shibboleth 10 | https://www.ki.iif.hu/shibboleth 1 | https://noc6.vh.hbone.hu/shibboleth 21 | https://webadmin.iif.hu/shibboleth 3 | https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth 7 | https://ugyeletes.vh.hbone.hu/shibboleth 2 | https://noc.grid.niif.hu/shibboleth 1 | https://wiki.voip.niif.hu/shibboleth 2 | https://netmonitor.hbone.hu/shibboleth 2 | https://idp.sch.bme.hu:443/opensso/sp/test
A fájl szerkezetileg két részre osztható. Az első három sorban kerül megadásra, hogy a statisztika miről szól (az idp entityID-ja, egy speciális 40 karakteres azonosítója és a dátum), a továbbiakban pedig az egyelőre három különböző statisztika típusra vonatkozó értékek.
- AUTH: az adott napon történt autentikációk száma
- USER_COUNT: az adott napon autentikált felhasználók száma
- SSO_TO_SERVICE: SP-k szerinti bontásban mutatja, hogy az adott napon egy-egy SP-hez hány felhasználót irányított az IdP
Teendők
- Kivonatoló python szkript letöltése. Jelenleg Shibboleth-hez és simpleSAMLphp-hez készítettük el.
- A beküldendő fájlt elkészítő szkript letöltése - ugyanaz Shibboleth-hez is és impleSAMLphp-hez is, lévén a forrás, melyből dolgoznak (a fenti szkript kimenete) ugyanaz.
- Az utóbbi szkript elején meg kell adni a beállításokat.
PARSER_COMMAND="/opt/shibboleth-idp/bin/audit_r7.py" //Az első lépésben letöltött szkript elérési útvonala
SOURCEDIR="/opt/shibboleth-idp/logs" //A statisztika alapját képző logok elérési útvonala
TARGETDIR="/tmp" //Munkakönyvtár - itt hozza létre a beküldendő fájlokat a szkript, majd beküldés után törli is őket innen
ENTITYID="idp-entity-id" //Az idp entityID-je
APIKEY="aaa..." //A 40 karakteres egyedi azonosító. Ezt az első beküldés előtt meg kell kérni: aai@niif.hu
LOCATION2PUT="ttp://eduid.hu/stats/import_stats" //Az eduID statisztikái ezen az url-en keresztül kerülnek fogadásra
//Az alábbi két sorban az audit logokat tartalmazó fájlnév mintáját adjuk meg - ez idp-nként változhat, az alábbi példa egy Shibboleth IdP-re vonatkozik
DATE=`date -d "yesterday" +"%Y-%m-%d"`
SOURCEFILE="$SOURCEDIR/idp-audit-$DATE.log"
Mindezek után az utóbbi szkriptet célszerű betenni egy cronjobba, mindennapi futtatással. Érdemes kora hajnali időpontot megadni, hisz ekkor már elérhetők az előző napi statisztikák, és az adott nap munkaidőben pedig már tudjuk nézegetni a beküldött adatokat :)
Alternatív megoldás
Shibboleth-hez választható cstamas python szkriptje is, amely által kihagyható a shell szkriptes ügyeskedés, és minden egy python configon keresztül adható meg.
- Szkript: Audit_shib_cstamas.py
- Példa konfig: Audit_shib_cstamas.cfg
Használata:
review
./Audit_shib_cstamas.py -lupe -d 2010-11-28 --config Audit_shib_cstamas.cfg /tmp/idp-audit-2010-11-28.log
upload
./Audit_shib_cstamas.py -lupe -d 2010-11-28 --config Audit_shib_cstamas.cfg --up /tmp/idp-audit-2010-11-28.log
Természetesen a megfelelő beállítások után ezt is napi rendszerességgel kell lefuttatni.
Erre ime egy megoldas, ez cronjobbal vagy valami alternativ utemezovel indithato.
#!/bin/sh
set -e
cd /ahol-a-script-van
# vagy a scriptet berakod a pathba es teljes utvonallal hivatkozol a konfigra
for i in /usr/local/shibboleth-idp-2.2.0-slo9/logs/idp-audit-201*log
do
d=$(echo $i | cut -b 53-62)
# XXX a cut -nak a datumot kell kiszednie a fajlnevbol, igy valtoztatas szukseges
./Audit_shib_cstamas.py -lupe -d $d --config Audit_shib_cstamas.cfg --up $i
gzip -v9 $i
sleep 5
done
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
!!! warning "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
Föderáció
Az Identitás Föderáció olyan intézmények halmaza, amelyek között lehetséges az identitás-információk átadása. Az intézmények - szabályozott keretek között - megbíznak a másik intézmény által kiállított identitás-információkban.
A Föderáció a pont-pont bizalmi kapcsolati modell általánosítása. Ekkor nem szükséges egy intézménynek minden egyes társintézménnyel külön megállapodást kötnie, hanem a szövetséghez csatlakozással automatikusan létrejön közöttük a lehetőség az identitás-információk átadására. Általában lehetőség van arra, hogy egy intézmény több Föderációhoz is kapcsolódjon, ill. külön bilaterális megállapodásai legyenek.
Célja
A föderációk célja, hogy az identitás információk egyébként autonóm rendszerek között átjárhatók legyenek. Ez a következő előnyökkel járhat:
- redundáns felhasználó-adminisztráció elkerülése: az identitáshoz kapcsolódó adatoknak elegendő egy helyen rendelkezésre állni; nem kell "idegen", "külsős" felhasználókat felvenni az intézményi adatbázisba
- Single Sign-on: a felhasználónak elég egyszer megadni az azonosító adatait, a többi rendszer automatikusan megszerzi az identitáshoz kötődő információkat. Ez egyrészt kényelmesebb a felhasználónak, másrészt megkönnyíti a több faktoros (pl. smartcard) azonosítási módszerek bevezetését.
Szerepek
A legtöbb föderációs modell lehetővé teszi azt, hogy egy intézmény egyszerre több szereppel is részt vegyen egy föderációban.
Identitás szolgáltatók (Identity Provider, IdP)
A felhasználók adatait az identitás szolgáltató tárolja. Az identitás szolgáltató funkciói: Azonosítás
- Felhasználó azonosítása
- Felhasználó azonosítással kapcsolatos információk átadása a tartalomszolgálatóknak (SP)
- Tartalomszolgáltatóktól érkező azonosítási kérések (AuthRequest) feldolgozása
Attribútumok kiadása
- Felhasználóhoz köthető attribútumok meghatározása
- A tartalomszolgáltató számára hozzáférhető felhasználói adatok átadása a tartalomszolgáltatónak (közvetlenül ill. a felhasználón keresztül)
Felhasználó menedzsment
- Felvétel / törlés
- Attribútumok, role-ok kezelése
- Jelszó ill. adatmódosítás
Tartalom / erőforrás szolgáltatók (Service Provider, SP)
A tartalomszolgáltatók védett tartalmakat szolgáltatnak a felhasználók számára. Általában nincsenek közvetlenül a felhasználókhoz kapcsolatos adataik, ezért nem szükséges a felhasználókat adminisztrálniuk sem.
A tartalomszolgáltató funkciói (a funkciók föderációs modelltől függően ezektől eltérhetnek):
- azonosított kapcsolat létrehozása az identitás szolgáltató segítségével (általában HTTP átirányítás használatával)
- az identitás szolgáltatótól kapott adatok értelmezése
- az identitás szolgáltatótól kapott adatok alapján meghatározni, hogy a felhasználó jogosult-e a művelet végrehajtására (autorizáció)
Metadata adminisztráció
A szolgálatókhoz kötődő háttérinformációkat (pl. tanúsítvány, név, scope, stb.) sok esetben a föderációs szoftver számára is elérhetővé kell tenni, ez esetben Metadata használatáról beszélünk. Adminisztrációja általában központilag történik, és push vagy pull módszerrel jut el a föderációba bevont számítógépekhez.
Speciális szolgáltatás a "Where Are You From?" (WAYF) szolgáltatás, amely a felhasználó számára lehetőséget ad, hogy az identitás szolgáltatóját kiválassza. Ez a szolgáltatás a föderációs metadata állomány(ok)ra épül.
Föderációs alapelvek
- A föderáció célja, hogy a felhasználók úgy vehessenek igénybe szolgáltatásokat - amennyiben erre jogosultak -, hogy a saját intézményük azonosítja őket.
- Az IdP és az SP egyértelműen azonosítja magát, amikor üzenetet váltanak egymással.
- Az IdP csak valós személyeket azonosít (teszt felhasználókat csak meghatározott módon, korlátozásokkal szabad azonosítani)
- Az IdP csak abban az esetben azonosít egy felhasználót, ha az illető valamilyen - ismert - viszonyban van (volt) az intézménnyel.
- Az IdP és az SP nem ad meg magáról hamis, félrevezető információt.
- Az IdP minden tőle telhetőt megtesz annak érdekében, hogy a kiadott információ a lehető legpontosabb legyen. Az SP tisztában van vele, hogy bizonyos információkat a felhasználók maguk is szerkeszthetnek.
- Az IdP gondoskodik róla, hogy a felhasználót azonosító információk (pl. jelszó) védett módon legyenek tárolva, ill. a felhasználók ezt biztonságosan adhassák meg.
- Az SP csak a működéséhez minimálisan szükséges adatmennyiséget igényli a felhasználóról.
- Az SP nem kérheti a felhasználót, hogy adja meg az IdP-nél érvényes jelszavát. Jelszó az SP-nek nem adható ki (kivéve speciális esetben egyszer használatos vagy rövid lejáratú jelszavak).
- Az SP az IdP-től származott információt harmadik félnek nem adja tovább.
- Felhasználói visszaélések esetén az IdP és az SP együttműködik egymással.
- Az IdP és az SP az informatikai rendszereit az elvárható gondossággal üzemelteti.
Technológiák
Szabályozás
A lazán csatolt modellek (pl. az OpenID) nem igényelnek központi szabályozást, de a magasabb biztonság-igényű, nagy bizalmat igénylő modellek esetén szükséges az, hogy a föderációban résztvevő intézmények kidolgozzák (esetleg szerződésbe is foglalják) az együttműködés feltételeit.
A megállapodás pl. az alábbi területeket érintheti
- Felhasználó-kezelés (pl. lejárt azonosítók inaktívvá tétele, password policy)
- Felhasználói adatok védelme (privacy követelmények)
- Felhasználó-azonosítási technológiák, ezek elnevezése
- Scope-ok kiosztása
- Felhasználói attribútumok használatának a feltételei (pl. milyen feltételekkel mondhatja egy intézmény XY-ról, hogy ő egy oktató?)
- Metadata információk karbantartása
- Új intézmény csatlakozásának feltételei (IdP, ill. SP szerepben)
- Audit, nemmegfelelőségi szankciók
- Költségviselés szabályai
- stb.
SamlSign
Parancssoros eszköz, melyhez debian alatt az opensaml2-tools
csomagot kell telepíteni. A program kétféle üzemmódban képes működni: metaadat aláírása és metaadat ellenőrzése.
Metaadat aláírása
samlsign -s -k /path/to/mainkey.key -f /path/to/metadatatosign.xml
Alapértelmezés szerint a samlsign az eredményeket az alapértelmezett kimenetre írja ki (STDOUT), így célszerű ezt egy új fájlba átirányítani:
samlsign -s -k /path/to/mainkey.key -f /path/to/metadatatosign.xml > /path/to/metadatasigned.xml
Metaadat ellenőrzése
samlsign -c /path/to/maincert.crt -f /path/to/metadatatosign.xml
Samlsign legfontosabb kapcsolói
- -s ez határozza meg, hogy aláírunk, vagy ellenőrzünk. Ha megadtuk kapcsolóként, akkor a program megpróbálja aláírni a megadott xml fájlt, ha nem, akkor ugyanezt a fájlt ellenőrizni fogja.
- -f az ellenőrzendő/aláírandó fájl elérhetősége abszolút útvonallal megadva
- -k a privát kulcs elérhetősége abszolút útvonallal megadva
- -c az ellenőrzésre használt publikus kulcs elérhetősége abszolút útvonallal megadva
- További részletes leírás a samlsign man oldalán
További fontos tudnivalók
A samlsign nem szereti a metadatában szereplő Organization
-nel kapcsolatos adatokat, mivel ilyen tag-ekben kötelezően megadandó xml:lang
attribútumot lang
-ra alakítja át, ami által viszont nem lesz érvényes (valid) maga a metaadat, így pl. a shibboleth sem fog tudni vele mit kezdeni. A megoldás (nem szép, de hasznos): az aláírás előtt álló metaadatokból ki kell szedni az Organization
-nel kapcsolatos adatokat. Ezek után már gond nélkül aláírja és az eredmény is érvényes lesz.
Apró trükk a privát kulcs kinyerésére jks
-ből
Tekintettel arra, hogy a keytool
nem teszi lehetőve a privát kulcs kihalászását JavaKeystore-ból, így külső segítséget kell igénybe vennünk. A segédalkalmazás ExportPrivateKey
névre hallgat, és innen letölthető egy darab zip fájl. Használata rendkívül egyszerű:
java -jar ExportPrivateKey.zip {jks fájl elérhetősége} JKS {jks jelszó} {alias} {célfájl}
Ezek után a létrehozott kulccsal már használhatjuk is a samlsign-t.
FedReqDef
- KÖTELEZŐ: az együttműködés minimális feltételeinek biztosítása érdekében egy intézmény vagy szolgáltató nem csatlakozhat a föderációhoz, ha a követelményt nem elégíti ki. A kötelező követelmények megszegése az intézmény kizárását eredményezheti.
- AJÁNLOTT: a követelmény nem teljesítése gondokat okozhat más intézményekkel vagy szolgáltatókkal történő együttműködésben, ezért csak alapos okkal lehet a követelménytől eltekinteni. A föderációhoz csatlakozáskor a nem teljesített AJÁNLOTT követelményeket meg kell vizsgálni, és dokumentálni kell.
- OPCIONÁLIS: a követelmény teljesítése az intézmény döntésére van bízva.
- KELL: lásd KÖTELEZŐ
- LEHETSÉGES: lásd OPCIONÁLIS
- TILOS: TODO
- NEM JAVASOLT: TODO
HREFContract
A HREF Föderáció nem jogi személy, így a szerződést formálisan a Föderációs Operátor és a Tag illetve a Partner kötik. A csatlakozáshoz szükséges egy egyoldalú szándéknyilatkozat aláírása is.
A dokumentumok letölthetők eduid.hu/dokumentumok oldalról.
A szerződés az alábbi dokumentumokra hivatkozik:
- Szószedet: a szerződésben és a vonatkozó dokumentumokban használt fogalmak meghatározása. Glossary
- Alapelvek: a HREF Föderáció működésének alapvető szabályai Federation Policy
- Műszaki előírások:
- IdP műszaki követelmények; IdP Operation Requirements
- SP műszaki követelmények; SP Operation Requirements
- Szolgáltatási szint megállapodás: a Föderációs Operátor szolgáltatásai és ezek vállalt paraméterei. Service Level Agreement
- Attribútum specifikáció: a felhasználói attribútumok cseréjét meghatározó leírás. Attribute Specification
- Metadata specifikáció: a metaadatok használatának és értelmezésének szabályai. Metadata Specification
- Föderációs szolgáltatások: a föderáció Tagjai és Partnerei által a Föderációban üzemeltetett szolgáltatások. Definition of Federated Services
Metadata
Ahhoz, hogy a föderációban résztvevő entitások biztonságosan tudjanak kommunikálni egymással, szükség van egy metaadat állományra. Ez a metaadat állomány szinte mindig humán felügyelettel jön létre, mivel a szervezetek közötti bizalmi kapcsolat technikai leképzésének ez az elsődleges eleme. (Másodlagos leképzésnek nevezhetjük az attribútum policy IdP és SP oldali megvalósítását.)
SAML 2.0 metaadatok
Pontos szabvány: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
A metadata állomány az alábbi fontosabb információkat tartalmazza
- Érvényesség, aláírás
- Identity Providerek
- Attribute authorityk
- Service Providerek
- IdP-k és SP-k tanúsítványai
- IdP-khez és SP-khez kapcsolódó szervezeti és kontakt információk
Metadata érvényesége és hitelessége
IdP
AA
SP
Tanúsítványok
Kontakt információk
Példák
Egy IdP-hez tartozó metadata
A meglehetősen komplex eseteket leszámítva általában az Identity Provider és az Attribute Authority egyetlen entitásként kezelhető.
<EntityDescriptor entityID="https://idp.niif.hu/shibboleth">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
<Extensions>
<shibmd:Scope>niif.hu</shibmd:Scope>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIFAzCCA+ugAwIBAgICAl8wDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCSFUx
DTALBgNVBAoTBE5JSUYxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVz
MRUwEwYDVQQDEwxOSUlGIFJvb3QgQ0EwHhcNMDcwMzMwMTA0OTQ5WhcNMDgwMzI5
MTA0OTQ5WjCB1zELMAkGA1UEBhMCSFUxEDAOBgNVBAoTB05JSUYgQ0ExEDAOBgNV
BAgTB0h1bmdhcnkxETAPBgNVBAcTCEJ1ZGFwZXN0MUIwQAYDVQQKEzlOYXRpb25h
bCBJbmZvcm1hdGlvbiBJbmZyYXN0cnVjdHVyZSBEZXZlbG9wbWVudCBJbnN0aXR1
dGUxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMRQwEgYDVQQDEwtpZHAubmlpZi5o
dTEeMBwGCSqGSIb3DQEJARYPcG9sYWtvdmlAaWlmLmh1MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDFuOD6yq3NlMaQoR6qyRlET1WyGT+hllH+1qXIHHwag2gL
KYByQpBXPva3uSsswn3Rjmv2G/9ifX8sUadflM/MDoCLRoq9umJkcwmOHEp1fMfa
7Gx9isEeVNYO0taN9Lol5EQL6rdZMSmwAZ17DCTNs48tPdzm7ys5EOe+bHHA3wID
AQABo4IB3DCCAdgwEQYJYIZIAYb4QgEBBAQDAgZAMA4GA1UdDwEB/wQEAwIE8DAa
BgNVHREEEzARgQ9wb2xha292aUBpaWYuaHUwggFZBgNVHR8EggFQMIIBTDCBvKBb
oFmkVzBVMQswCQYDVQQGEwJodTENMAsGA1UEChMETklJRjEgMB4GA1UECxMXQ2Vy
dGlmaWNhdGUgQXV0aG9yaXRpZXMxFTATBgNVBAMTDE5JSUYgUm9vdCBDQYECAN6i
WaRXMFUxCzAJBgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0
aWZpY2F0ZSBBdXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMIGKoCmg
J4YlaHR0cDovL3d3dy5jYS5uaWlmLmh1L25paWYtY2EtY3JsLmNybIECAN6iWaRX
MFUxCzAJBgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZp
Y2F0ZSBBdXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMB8GA1UdIwQY
MBaAFIxuIeJxr6Aqp7Dk/rx+o/0PoOOIMBkGA1UdIAQSMBAwDgYMKwYBBAHdCgEB
DAEAMA0GCSqGSIb3DQEBBQUAA4IBAQB262jS0aGJZrOg1Q6IVSodTnokgliojgWy
1FAojS6ML0w7T0eA1PnqX42eSfQFB2Nh71dBUmw6i++iHdQ1gyxOHIelSDb4JFOB
PoZ+3flwySXu42QgVjJZ46fEMsq2EM0PQV8p9pgBEjlG+6ifAEgJmKBnP+WCzQJ7
3rugtu+q8KKQ0oxP0bWLYGllJ6tKLa4gJ1P/oLe6uX+GWP+P3bZfMpOq9Tu2MU+r
l/gnG2rTSOBe7AEngRmeDfKKeFiSsg1cGxorxQJoEzBZksKUa0nlA9xtd30sUQFX
OI2/Xo2ihYFcpzu551S6+mutZNHqKgOT7uID/TCHr5R0Q1h7CPCS
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<ArtifactResolutionService index="1"
Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="https://idp.niif.hu:8443/shibboleth-idp/Artifact"/>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
Location="https://idp.niif.hu/shibboleth-idp/SSO"/>
</IDPSSODescriptor>
<AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
<Extensions>
<!-- This is a Shibboleth extension to express attribute scope rules. -->
<shibmd:Scope>niif.hu</shibmd:Scope>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIFAzCCA+ugAwIBAgICAl8wDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCSFUx
DTALBgNVBAoTBE5JSUYxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVz
MRUwEwYDVQQDEwxOSUlGIFJvb3QgQ0EwHhcNMDcwMzMwMTA0OTQ5WhcNMDgwMzI5
MTA0OTQ5WjCB1zELMAkGA1UEBhMCSFUxEDAOBgNVBAoTB05JSUYgQ0ExEDAOBgNV
BAgTB0h1bmdhcnkxETAPBgNVBAcTCEJ1ZGFwZXN0MUIwQAYDVQQKEzlOYXRpb25h
bCBJbmZvcm1hdGlvbiBJbmZyYXN0cnVjdHVyZSBEZXZlbG9wbWVudCBJbnN0aXR1
dGUxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMRQwEgYDVQQDEwtpZHAubmlpZi5o
dTEeMBwGCSqGSIb3DQEJARYPcG9sYWtvdmlAaWlmLmh1MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDFuOD6yq3NlMaQoR6qyRlET1WyGT+hllH+1qXIHHwag2gL
KYByQpBXPva3uSsswn3Rjmv2G/9ifX8sUadflM/MDoCLRoq9umJkcwmOHEp1fMfa
7Gx9isEeVNYO0taN9Lol5EQL6rdZMSmwAZ17DCTNs48tPdzm7ys5EOe+bHHA3wID
AQABo4IB3DCCAdgwEQYJYIZIAYb4QgEBBAQDAgZAMA4GA1UdDwEB/wQEAwIE8DAa
BgNVHREEEzARgQ9wb2xha292aUBpaWYuaHUwggFZBgNVHR8EggFQMIIBTDCBvKBb
oFmkVzBVMQswCQYDVQQGEwJodTENMAsGA1UEChMETklJRjEgMB4GA1UECxMXQ2Vy
dGlmaWNhdGUgQXV0aG9yaXRpZXMxFTATBgNVBAMTDE5JSUYgUm9vdCBDQYECAN6i
WaRXMFUxCzAJBgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0
aWZpY2F0ZSBBdXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMIGKoCmg
J4YlaHR0cDovL3d3dy5jYS5uaWlmLmh1L25paWYtY2EtY3JsLmNybIECAN6iWaRX
MFUxCzAJBgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZp
Y2F0ZSBBdXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMB8GA1UdIwQY
MBaAFIxuIeJxr6Aqp7Dk/rx+o/0PoOOIMBkGA1UdIAQSMBAwDgYMKwYBBAHdCgEB
DAEAMA0GCSqGSIb3DQEBBQUAA4IBAQB262jS0aGJZrOg1Q6IVSodTnokgliojgWy
1FAojS6ML0w7T0eA1PnqX42eSfQFB2Nh71dBUmw6i++iHdQ1gyxOHIelSDb4JFOB
PoZ+3flwySXu42QgVjJZ46fEMsq2EM0PQV8p9pgBEjlG+6ifAEgJmKBnP+WCzQJ7
3rugtu+q8KKQ0oxP0bWLYGllJ6tKLa4gJ1P/oLe6uX+GWP+P3bZfMpOq9Tu2MU+r
l/gnG2rTSOBe7AEngRmeDfKKeFiSsg1cGxorxQJoEzBZksKUa0nlA9xtd30sUQFX
OI2/Xo2ihYFcpzu551S6+mutZNHqKgOT7uID/TCHr5R0Q1h7CPCS
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
Location="https://idp.niif.hu:8443/shibboleth-idp/AA"/>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
</AttributeAuthorityDescriptor>
</EntityDescriptor>
Egy SP-hez tartozó metadata
<EntityDescriptor entityID="https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIEmjCCA4KgAwIBAgICArwwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCSFUx
DTALBgNVBAoTBE5JSUYxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVz
MRUwEwYDVQQDEwxOSUlGIFJvb3QgQ0EwHhcNMDcxMTMwMTMwNzE4WhcNMDgxMTI5
MTMwNzE4WjBvMQswCQYDVQQGEwJIVTEQMA4GA1UEChMHTklJRiBDQTEOMAwGA1UE
CxMFSEJPTkUxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMSUwIwYDVQQDExxycmQt
bWEucGVyZnNvbmFyLnZoLmhib25lLmh1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC2x6Hpjr4yB6EDkXUHNMlHz250kqWBXf/UI6TziV5rvMjvS8pdFnsZcIt1
coT03Fu4wzs6N8gtC5uW7f3JaBsG32sYZUorWcbecpgVy5ttcIqTM1RnxUsOktsM
RuBz7qYAQ1/B9VvBH7P7DeREgIGm7Skel/Q3Qhl4oG9PtFe1wQIDAQABo4IB3DCC
AdgwEQYJYIZIAYb4QgEBBAQDAgbAMA4GA1UdDwEB/wQEAwIE8DAaBgNVHREEEzAR
gQ9wb2xha292aUBpaWYuaHUwggFZBgNVHR8EggFQMIIBTDCBvKBboFmkVzBVMQsw
CQYDVQQGEwJodTENMAsGA1UEChMETklJRjEgMB4GA1UECxMXQ2VydGlmaWNhdGUg
QXV0aG9yaXRpZXMxFTATBgNVBAMTDE5JSUYgUm9vdCBDQYECAN6iWaRXMFUxCzAJ
BgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZpY2F0ZSBB
dXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMIGKoCmgJ4YlaHR0cDov
L3d3dy5jYS5uaWlmLmh1L25paWYtY2EtY3JsLmNybIECAN6iWaRXMFUxCzAJBgNV
BAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZpY2F0ZSBBdXRo
b3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMB8GA1UdIwQYMBaAFIxuIeJx
r6Aqp7Dk/rx+o/0PoOOIMBkGA1UdIAQSMBAwDgYMKwYBBAHdCgEBCQEAMA0GCSqG
SIb3DQEBBQUAA4IBAQAVuG4+KUxQZcYCedQmW6Ih83gqMS7inxfBFeadc4Ts1egY
Wf6Y4CoEOrsdI7FmC7CCccarDaMC6PVJg1WlDV01LMGM2+6rcoMeMs/J5pCFTDhn
c6MPz6KedRcMvVJajY+BZvJPG9CNpyxdiUf/aDa28yRryVM0Jbm6BOFH+UrVHlVw
w2JxlmsHtk1fNmEU7gluzwo3FEZrx8nnLWkeTfMzz/iM+dudNm4sL99uGNEWGNFf
tLi+R35McE7CfyNNfOvlskZX++dSX/Re8CERTo3wZrHmFKIoOnJzo6v48d2tEbw0
a15Yl93MJCNlC5BUyvUMqKDLmHhTxmgO+HIaV7Kf
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<AssertionConsumerService index="1" isDefault="true"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
Location="https://rrd-ma.perfsonar.vh.hbone.hu/Shibboleth.sso/SAML/Artifact"/>
<AssertionConsumerService index="2"
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
Location="https://rrd-ma.perfsonar.vh.hbone.hu/Shibboleth.sso/SAML/POST"/>
</SPSSODescriptor>
</EntityDescriptor>
Shibboleth 1.3
A Shibboleth (mind az SP, mind az IdP) a metaadatokat kizárólag a másik féllel kapcsolatban használja, tehát a saját konfigurációjával kapcsolatban figyelmen kívül hagyja.
Az 1.3-as verzió kizárólag lokális állományokkal dolgozik (ez változni fog a 2.0-ban).
Scope
A Shibboleth 1.3 kiterjesztette a SAML2 metadata struktúrát egy saját, Scope
mezővel. Ez a "scope" igazából egy postfix tagot definiál, melynek segítségével bizonyos attribútumok értelmezési helye jól meghatározható.
Erre jó példa az eduPersonPrincipalName
attribútum, mely a felhasználó egyedi azonosítóját adja meg. Ez az azonosító két részből áll:
- egy intézményen belüli egyedi azonosítóból (pl.
bajnokk
) - az intézmény azonosítójából, a scope-ból (pl.
niif.hu
)
Ha a metadatában használjuk a Scope
mezőt, akkor az SP ellenőrizni tudja, hogy az IdP jogosult-e ilyen scope-pal rendelkező attribútumot kiadni.
Szintén gyakran használt scope-os attribútum az eduPersonScopedAffiliation
.
Metadata eszközök
Több metadata állomány használata
Mind az IdP, mind az SP képes arra, hogy több metadata állományt használjon. Így például különvehetjük az SP-ket az IdP-ktől, ill. több föderációban lehet benne a provider.
A metadata állományok tartalma összeadódik.
!!! danger "Figyelem"
Ugyanaz az **`entityId`** (más néven [[providerId]]) nem szerepelhet többször! Az **`entityId`**-knek az összes használt metadata állományra nézve egyedinek kell lennie.
Metadata állományok frissítése
A metadata állományok központi helyről való letöltésére a Siterefresh és a Metadatatool eszközök valók.
Az átszerkesztett/új metadata állományt mind az IdP, mind az SP automatikusan beolvassa, újraindítás nem szükséges.
Nem SAML 2.0 metaadatokat használó alkalmazások
simpleSAMLphp
Az újabb verziók már támogatják az XML formátumú metaadatokat, de az SSP moduljai szeretik még mindig a flatfile formátumot használni. Van egy metarefresh nevű modul, ami képes webről leszedni a metaadatokat, ellenőrizni az aláírást, és flatfile formátumú metaadatokat generálni. Fontos momentum, hogy figyelembe veszi a *<RequestedAttribute>*
elementet, ezáltal megoldható az IdP-k attribútum kiadási szabályzatának automatikus frissítése is.
!!! warning "A szócikk vagy fejezet még megírásra vár"
Switch WAYF
!!! warning "A szócikk vagy fejezet még megírásra vár"
HREFUseCaseStub
NIIF AAI felhasználási lehetőségek
Szolgáltatások | Hallgatóknak | Oktatóknak | Adminisztratív személyzet részére |
---|---|---|---|
Internetelérés nem csak az anyaintézményben | + | + | + |
Online könyvtári szolgáltatások | + | + | + |
Online elérhető szakmai folyóiratok | + | + | + |
Tudás adatbázisok (tananyagok) | + | + | |
Statisztikai adatbázisok | + | + | |
Speciális keresési szolgáltatások | + | + | + |
Hírszolgáltatások | + | + | + |
Elektronikus oktatási (e-learning) szolgáltatások | + | + | + |
Tanulmányi rendszerek | + | + | |
Elektronikus vizsgáztatási rendszerek | + | + | |
Számlázási, könyvelési szolgáltatások | + | ||
Erasmusos diákok VHO-s azonosítása | + | ||
Külföldi oktatóknak biztosított szolgáltatások VHO-s azonosítása | + | + | |
Közösségépítő szolgáltatások (Sample Use Case) | + | + | |
Hallgatói önkormányzatok saját szolgáltatásai | + | ||
Utazás iroda által nyújtott szolgáltatások | + | + | + |
Online rendelhető termékekre diák vagy oktatói kedvezmények (pl. jegyrendelés (mozijegy, koncert stb.) | + | + | |
Kollégiumokkal kapcsolatos szolgáltatások (adatbázis, jelentkezés stb.) | + | + | |
HR szolgáltatások | + | + | |
Projektszemléletű jogosultságok kezelése | + | + | + |
Telekommunikációs és informatikai szolgáltatások (pl. tárhely, domain név) | + | + | |
Marketing szolgáltatások, online felmérések | + | + | + |
Egyéb |
AAIInterop-Shib2SimpleSAMLphp
!!! bug "Elavult információ"
**Figyelem**: ez a szakasz vagy szócikk elavult információkat tartalmazhat!
Shibboleth2 IdP - SimpleSAMLphp SP Interoperabilitás
SAML2.0 Single Sign on
HTTP-Post
- Működik
- A SimpleSAMLphp nem támogatja a NameID titkosítását, csak az egész assertion titkosítását (FIXME)
- ezért be kell állítani hogy a NameID-t ne titkosítsa az IdP, ugyanígy kényszeríteni kell az Attribute Push használatát is
<RelyingParty id="https://papigw.aai.niif.hu/simplesaml"
provider="https://papigw.aai.niif.hu/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential">
<ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
encryptNameIds="never" includeAttributeStatement="true"/>
</RelyingParty>
- A SimpleSAMLphp SP metaadatába kézzel kell beletenni az aláíró és titkosító publikus kulcsokat, mivel a kiexportált metaadat ezeket nem tartalmazza (ráadásul a php-s konfigurációban szereplő certificate/privatekey paramétereket nem lehet abszolut elérési úttal hivatkozni, mindenképp a cert/ könyvtárban kell lenniük)
HTTP-Artifact
- A SimpleSAMLphp nem támogatja a HTTP-Artifact bindingot (és általában a SOAP-ot használó bindingokat)
Attribute push
- Működik
Attribute pull
- A SimpleSAMLphp nem támogatja az AttributeRequest protokollt (a SOAP binding miatt)
NameIDFormat
- Általában urn:oasis:names:tc:SAML:2.0:nameid-format:transient
SAML2.0 Single Log out
- A SimpleSAMLphp támogatná az SLO-t, de a shibboleth2 IdP nem. A metaadatnál panaszkodik is hogy a Shibboleth metadata nem tartalmaz SingleLogoutService-t.
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](https://wiki.shibboleth.net/confluence/display/SHIB2/FlowsAndConfig)
* You have [successfully installed and configured Shibboleth SP](https://wiki.shibboleth.net/confluence/display/SHIB2/Installation) 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
!!! danger "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](#bkmrk-administering-drupal-with-strict-sessions) how to give your own user administrator rights.
Example Shibboleth configuration
!!! note
this example uses lazy sessions.
/etc/shibboleth/shibboleth2.xml snippet:
<RequestMapper type="Native">
<RequestMap applicationId="default">
<Host name="your.host.name">
<Path name="location_of">
<Path name="your_Drupal">
<Path name="installation" authType="shibboleth" requireSession="false" />
</Path>
</Path>
</Host>
</RequestMap>
</RequestMapper>
Apache config file snippet (ie. /etc/apache2/sites-enabled/your.host.name
, or you can even use .htaccess
without the <Location>
tags):
<Location /location_of/your_Drupal/installation>
AuthType Shibboleth
ShibRequireSession Off
ShibUseHeaders On
require shibboleth
</Location>
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:
<Sessions lifetime="28800" timeout="3600" checkAddress="false"
handlerURL="/Shibboleth.sso" handlerSSL="false"
exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
idpHistory="false" idpHistoryDays"7">
<SessionInitiator type="Chaining" Location"/Login" isDefault="true" id="Intranet"
relayState="cookie" entityID"https://idp.example.org/shibboleth">
<SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" defaultACSIndex="5"/>
</SessionInitiator>
<!-- other things -->
<LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
<LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
<LogoutInitiator type="Local"/>
</LogoutInitiator>
<!-- other things -->
</Sessions>
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.
!!! danger "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 fromstudent
toalum
), - 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.
!!! danger "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](#bkmrk-dynamic-rules-default) 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
:
<!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
<LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
<!-- The following line should be commented out to make Drupal logout work,
as long as your IdPs do not support SAML2 logout -->
<!--LogoutInitiator type="SAML2" template="bindingTemplate.html"/-->
<LogoutInitiator type="Local"/>
</LogoutInitiator>
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.
!!! danger "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](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPContentSettings) 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
Shib3IdpAuth
Shibboleth 3 Identity Provider (IdP) hitelesítés
Shibboleth 3 OpenLDAP címtárhoz kapcsolása
Szerkesszük az {idp.home}/conf/ldap.properties állományt az alábbiak szerint
...
## Connection properties ##
idp.authn.LDAP.ldapURL = ldap://ldap.intezmenyneve.hu:389
idp.authn.LDAP.useStartTLS = false
...
idp.authn.LDAP.bindDN = cn=pelda-admin-felhasznalo,dc=intezmenyneve,dc=hu
idp.authn.LDAP.bindDNCredential = jelszo
# Format DN resolution, used by directAuthenticator, adAuthenticator
# for AD use idp.authn.LDAP.dnFormat=%s@domain.com
idp.authn.LDAP.dnFormat =uid=%s,ou=people,dc=intezmenyneve,dc=hu
...
!!! info
A Shibboleth Identity Provider 2-es és 3-as verziója közötti egyik fontos különbség az LDAP hitelesítés átalakítása és natív könyvtárak használata a korábbi JAAS helyett.
Dokumentáció: https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration
Shib2IdpAttrib
Az attribútum feloldást az IDP_HOME/conf
könyvtárban található attribute-resolver.xml
névre hallgató fájlban konfigurálhatjuk. A fájl szerkezetét tekintve négy részből áll.
Attribute-resolver alapbeállítások
Ezeket általában nem kell állítgatni, megfelelőek az alapbeállítások
<AttributeResolver xmlns="urn:mace:shibboleth:2.0:resolver" xmlns:resolver="urn:mace:shibboleth:2.0:resolver"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pc="urn:mace:shibboleth:2.0:resolver:pc"
xmlns:ad="urn:mace:shibboleth:2.0:resolver:ad" xmlns:dc="urn:mace:shibboleth:2.0:resolver:dc"
xmlns:enc="urn:mace:shibboleth:2.0:attribute:encoder" xmlns:sec="urn:mace:shibboleth:2.0:security"
xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver classpath:/schema/shibboleth-2.0-attribute-resolver.xsd
urn:mace:shibboleth:2.0:resolver:pc classpath:/schema/shibboleth-2.0-attribute-resolver-pc.xsd
urn:mace:shibboleth:2.0:resolver:ad classpath:/schema/shibboleth-2.0-attribute-resolver-ad.xsd
urn:mace:shibboleth:2.0:resolver:dc classpath:/schema/shibboleth-2.0-attribute-resolver-dc.xsd
urn:mace:shibboleth:2.0:attribute:encoder classpath:/schema/shibboleth-2.0-attribute-encoder.xsd
urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd">
<!-- ... -->
</AttributeResolver>
Attribútumok definiálása
Az attribútum-definíciós szakasz igazából egyfajta egységesítése és előkészítése különböző forrásokból kinyerhető és később továbbítható adatoknak. Egy attribútum definiálásakor meg kell adni az alapként szolgáló <AttributeDefinition>
elemet három attribútumával:
<resolver:AttributeDefinition id="cn" xsi:type="simple:Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad">
- id - az attribútum egyedi neve (nagyon fontos a jó névválasztás :)
- xsi:type - értéke lehet
Simple
vagyScoped
, de mivel a második nem szabványos, így törekedni kellene aSimple
használatára - xmlns - alapértelmezett értéke:
urn:mace:shibboleth:2.0:resolver:ad
Az <AttributeDefinition>
elemen belül meg kell adni az attribútum függőségét és az attribútum kódolási tulajdonságait
Attribútumok függősége
Egy attribútum függhet bármilyen más, az attribute-resolver.xml fájlban definiált elemtől, legyen az másik <AttributeDefinition>
, vagy <DataConnector>
. Egy attributum több más elemtől is függhet. Az egyetlen attribútuma a forrás elem azonosítója.
<resolver:Dependency ref="ID_DEPENDENCY1" />
Attribútumok kódolási tulajdonságai
Egy attribútumhoz többféle kódolási mechanizmust megadhatunk, melyek meghatározzák, hogy az attribútum kiadásakor milyen formátum(ok)ban lesz elérhető az aktuális attribútum értéke. Ha nem adunk meg kódolási mechanizmust, alapértelmezetten SAML2String
alapon kódol. Egy kódolás megadása az <AttributeEncoder>
elem segítségével történik. A szükséges attribútumok
- xsi:type - értéke a kódolás típusa
- xmlns - alapértelmezett értéke:
urn:mace:shibboleth:2.0:resolver:encoder
- name - a megadott típuson belüli azonosító
- friendlyName - :)
Példa
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="oid:1.3.6.1.4.1.5923.1.1.1.7"
friendlyName="commonName" />
Kapcsolódások adattárakhoz
Ahhoz, hogy megkaphassuk az egyes attribútumokhoz tartozó értéket, valamilyen adattárból (adatbázis, címtár) kell őket kinyernünk, hiszen ekkor még csak a sikeres azonosítás után tartunk, és csak a felhasználói nevet tudjuk, amivel az azonosítás megtörtént. Fontos, hogy az egyes kapcsolódások definiálásakor erre a felhasználói névre a $requestContext.principalName
néven hivatkozhatunk, amely kiindulópontként szolgálhat lekérdezéseinkhez.
Kapcsolódás címtárhoz
1. Konnektor definiálása
Új adatbáziskapcsolat létrehozásához definiálnunk kell a konnektort <DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc">
az alábbi attribútumokkal
Attribútumok, melyeket kötelező megadni
- id - egyedi azonosító, mellyel az attribútum definicióknál elérhetjük a konnektort
- ldapURL - a címtár elérési útja. Több is megadható vesszőkkel elválasztva, ekkor a megadott sorrend alapján addig próbálkozik, amíg valahol nem tud csatlakozni
- baseDN - a címtárban való kereséshez tartozó BaseDN
- principal - a címtár bind-olására használandó felhasználói név
- principalCredential - a címtár bind-olására használandó felhasználói névhez tartozó jelszó
<resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="UNIQUE_ID"
ldapURL="LDAP_URL"
baseDN="BASE_DN"
principal="PRINCIPAL_NAME"
principalCredential="PRINCIPAL_CREDENTIAL">
<!-- Ide kerülnek majd az további konfigurációs beállítások a következő lépések alapján -->
</resolver:DataConnector>
2. Az LDAP lekérdezés definiálása
<resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="UNIQUE_ID"
ldapURL="LDAP_URL"
baseDN="BASE_DN"
principal="PRINCIPAL_NAME"
principalCredential="PRINCIPAL_CREDENTIAL">
<FilterTemplate>
<![CDATA[
(uid=${requestContext.principalName})
]]>
</FilterTemplate>
<!-- Ide kerülhet a lekérdezési eredmény mezőneveinek és értékeinek felüldefiniálása -->
</resolver:DataConnector>
Kapcsolódás relációs adatbázisokhoz
1. Konnektor definiálása
Új adatbáziskapcsolat létrehozásához definiálnunk kell a konnektort <DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc">
az alábbi attribútumokkal
Attribútumok, melyeket kötelező megadni
- id - egyedi azonosító, mellyel az attribútum definicióknál elérhetjük a konnektort
Attribútumok, melyeket opcionálisan megadhatók
- readOnlyConnection - logikai érték, mely meghatározza, hogy az adatbázis csak olvasható, vagy esetleg írható is. Alapértelmezés szerint
true
, azaz csak olvasható - queryUsesStoredProcedure - logikai érték, mely meghatározza, hogy az 5. lépésnél bemutatott módon definiált SQL lekérdezések használhatnak-e előre meghatározott eljárásokat. Alapértelmezés szerint nem, azaz
false
- cacheResults - logikai érték, mely meghatározza, hogy a lekérdezés eredménye eltárolható-e a felhasználó munkamenetének lejártáig. Alapértelmezés szerint igen, azaz
true
<resolver:DataConnector xsi:typ="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="UNIQUE_ID">
<!-- Ide kerülnek majd az további konfigurációs beállítások a következő lépések alapján -->
</resolver:DataConnector>
2. Függőségek definiálása
Opcionális
3. Másodlagos adatkapcsolat definiálása
Opcionális
4/a. Idp által natívan vezérelt adatbáziskapcsolatok beállítása
Az Idp alkalmazás által vezérelt kapcsolathoz definiálnunk kell egy <ApplicationManagedConnection>
elemet az alábbi (mind kötelezően megadandó) attribútumokkal
- jdbcDriver - a JDBC meghajtó teljes elérési útvonala
- jdbcURL - URL, melyen elérjük az adatbázist
- jdbcUserName - adatbázis eléréséhez tartozó felhasználó
- jdbcPassword - a fenti felhasználóhoz tartozó jelszó
Példa MySQL adatbázis eléréséhez
<resolver:DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="UNIQUE_ID">
<!-- Ide kerülhetnek a függőségek a másodlagos adatkapcsolatokkal kapcsolatos beállítások -->
<ApplicationManagedConnection jdbcDriver="com.mysql.jdbc.Driver"
jdbcURL="jdbc:mysql://localhost:3306/DATABASE_NAME?autoReconnect=true"
jdbcUserName="DATABASE_USER"
jdbcPassword="DATABASE_USER_PASSWORD" />
<!-- Ide kerülnek majd az további konfigurációs beállítások a következő lépések alapján -->
</resolver:DataConnector>
4/b. Konténer által vezérelt adatbáziskapcsolatok beállítása
5. SQL lekérdezés definiálása
<resolver:DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="UNIQUE_ID">
<!-- Ide kerülhetnek a függőségek a másodlagos adatkapcsolatokkal kapcsolatos beállítások -->
<ContainerManagedConnection resourceName="RESOURCE_NAME" />
<QueryTemplate>
<![CDATA[
SELECT * FROM PEOPLE WHERE userid='$requestContext.principalName'
]]>
</QueryTemplate>
<!-- Ide kerülhet a lekérdezési eredmény mezőneveinek és értékeinek felüldefiniálása -->
</resolver:DataConnector>
6. Lekérdezési eredmény mezőneveinek és értékeinek felüldefiniálása
Opcionális
Alapértelmezés szerint a lekérdezések eredményét mezőnevenként és a hozzákapcsolódó értékként egy-egy attribútumba szervezi a konnektor, melyet lehetőségünk van felüldefiniálni, ehhez a <Column>
elemet használhatjuk az alábbi atttribútumokkal
Kötelező megadni
*columnName - az lekérdezés eredményének mezője, mellyel kapcsolatban módosításokat hajtanánk végre
Az alábbiak közül minimum egyet kötelező megadni
- attributeID - az attribútum azonosítója, melyhez hozzárendeljük az eredményt
- type - az eredmény típusa. A következők közül választhatunk: BigDecimal, Boolean, Byte, ByteArray, Date, Double, Float, Integer, Long, Object, Short, String, Time, Timestamp, URL
<resolver:DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="UNIQUE_ID">
<!-- Ide kerülhetnek a függőségek a másodlagos adatkapcsolatokkal kapcsolatos beállítások ill. a kapcsolatvezérló beállítások -->
<QueryTemplate>
<![CDATA[
SELECT * FROM people WHERE userid='$requestContext.principalName'
]]>
</QueryTemplate>
<Column columnName="firstname" attributeID="fname" />
<Column columnName="personid" type="String" />
</resolver:DataConnector>
7. Összegzés
Működő példa a fentieket összegezve
<!-- ###### ###### ###### ### -->
<!-- Data Connectors -->
<!-- ###### ###### ###### ### -->
<resolver:DataConnector id="vhoMySQLsurname" xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc">
<ApplicationManagedConnection
jdbcDriver="com.mysql.jdbc.Driver"
jdbcURL="jdbc:mysql://localhost:3306/VHOtools?autoReconnect=true"
jdbcUserName="DATABASE_USER"
jdbcPassword="DATABASE_USER_PASSWORD" />
<QueryTemplate>
<![CDATA[
SELECT uniqueID FROM vho_Users WHERE username = '$requestContext.principalName'
]]>
</QueryTemplate>
<Column columnName="uniqueID" attributeID="uid" />
</resolver:DataConnector>
Principal Connectors
Ezt sem kell babrálni :)
<!-- ###### ###### ###### ### -->
<!-- Principal Connectors -->
<!-- ###### ###### ###### ### -->
<resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="shibTransient"
nameIDFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
<resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="saml1Unspec"
nameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
<resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="saml2Transient"
nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
Attribútum
HREF_metadata_specifikáció
A föderációs metaadat célja, hogy a föderációban részt vevő intézmények illetve entitások technikai, bizalmi és adminisztratív adatait egy helyre gyűjtse. A metaadatok formátuma megfelel a SAML2 metaadat szabványnak.
Biztonsági megfontolások
Mivel a metadata tartalmazza a föderációban részt vevő tagok és komponensek technikai információit, ezért a benne tárolt információkkal kapcsolatban figyelembe kell venni a következő biztonsági megfontolásokat:
- Téves vagy kompromittálódott adatok eltávolítása esetén a sérülékenységi ablak megegyezik a metadata gyorstárazhatósági (
cacheDuration
) idejével, amennyiben a támadó nem képes blokkolni a központi metaadatok elérhetőségét (DOS) - Amennyiben a támadó képes blokkolni a központi metaadatok elérhetőségét, a sérülékenységi ablak a legutolsó letöltött metadata állomány érvényességéig (
validUntil
paraméterében meghatározott ideig) tart. - Amennyiben a metaadatok érvényességi ideje lejár, az entitás nem képes azonosítani a többi föderációs résztvevőt, ezért nem tud föderációs szolgáltatást (pl. IdP esetén azonosítási szolgáltatást) nyújtani.
Metaadatban tárolt információk
- Bizalom a metaadatban
- a metaadat integritásvédelmét és hitelességét egy digitális aláírás biztosítja.
- a metaadat visszavonhatóságát a lejárati idő (
validUntil
) biztosítja, ami jelenleg 3 nap. - az egyes rendszerek gyorstárazhatják a metaadatot, de legalább naponta egyszer kötelesek a hiteles állományt frissíteni.
- az aláírási procedúrát a Metaadat_aláírásának_módja fejezet írja le.
- Tanúsítványok
- kötelező legalább 1024 bites kulcspárt használni
- az entitások által használt tanúsítvánnyal kapcsolatban a föderáció nem tesz különleges megkötést, sőt: ajánlott hosszú lejáratú self-signed tanúsítványok használata
- További információk
- minden szöveges mezőt legalább két nyelven: magyarul és angolul ki kell tölteni
- kötelezően kitöltendőek az intézményi, adminisztratív információk (
Organization
illetveContactPerson
elemek) - ajánlott megadni egy helpdesk URL-r, ahova hiba esetén a felhasználók fordulhatnak (
errorURL
attribútum) - SP-k esetén további kötelező elemek
AttributeConsumingService
, ami megadja a kért attribútumokatRequestedAttributes
- itt az attribútum informális neve is szerepeljenServiceName
,ServiceDescription
az SP szolgáltatás neve és leírása
- a szolgáltatás elérhetősége, amin a szolgáltatás bemutatkozik (extension)
- adatkezelési szabályzatra mutató URL (extension)
- IdP-k esetén
- a scope csak az adott intézmény kezelésében levő domain név lehet (Shibboleth extension)
- lehetőség van további adatok megadására is
- logó
- gps koordináták, IP cím tartomány
- különböző tagek, például a szolgáltatás publikus-e, vagy épp bevezetés alatt áll-e
Metaadat kiterjesztések használata
Ezen kiegészítő adatok tárolására az internet2 szabványtervezetet készít, ennek a sémának a jelenlegi verziója megtalálható itt.
A kiegészítő séma névtere: urn:oasis:names:tc:SAML:2.0:metadata:ui
. Az alábbi táblázatban ezen névtérben definiált legfontosabb elemeket foglaljuk össze:
element név | szemantika | értékekre vonatkozó megkötések |
---|---|---|
GeolocationHint | szélesség és hosszúság érték, a + előjel az északi szélességet illetve keleti hosszúságot jelöli | 47.47359,19.052891 |
InformationURL | az entitásról további információkat (pl. helpdesk) szolgáltató oldal. | |
PrivacyStatementURL | Az SP adatvédelmi nyilatkozátnak elérhetősége (URL) | Engedélyezett formátumok: HTML, PDF |
Logo | Az IdP/SP logójának elérhetősége | Formátummal kapcsolatban lásd Logo |
IPHint | (Csak az IdP-knél) az intézmény hálózati tartománya(i). IdP felderítés esetén előválasztás lehetséges ennek alapján. | CIDR, több érték is megadható |
DomainHint | (Csak az IdP-knél) az intézmény által felügyelt domain név. IdP felderítés esetén előválasztás lehetséges ennek alapján. | Több érték is megadható |
Logo
- formátum: URL egy transzparens hátterű PNG, vagy transzparens hátterű GIF képre
- méretezés
- javasolt oldalarány 1:1 vagy 16:9
- maximális méret 200x200px
- ajánlott egy 16x16px-es verziót is megadni
- attribútumok
xml:lang
: lokalizációs információhref
: opcionális linkheight
: opcionális magasság érték pixelbenwidth
: opcionális szélesség érték pixelben
Egy IdP példa
<EntityDescriptor entityID="https://idp.niif.hu/shibboleth"
xmlns:mdui="urn:oasis:names:tc:SAML:2.0:metadata:ui">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
<Extensions>
<shibmd:Scope>niif.hu</shibmd:Scope>
<mdui:DiscoHints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<mdui:GeolocationHint>47.518356,19.055437</mdui:GeolocationHint>
<mdui:DomainHint>niif.hu</mdui:DomainHint>
<mdui:DomainHint>iif.hu</mdui:DomainHint>
</mdui:DiscoHints>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<!-- endpoints, nameidformats -->
</IDPSSODescriptor>
<ContactPerson contactType="technical">
<SurName>NIIF AAI</SurName>
<EmailAddress>aai@niif.hu</EmailAddress>
</ContactPerson>
<ContactPerson contactType="support">
<SurName>NIIF AAI</SurName>
<EmailAddress>aai@niif.hu</EmailAddress>
</ContactPerson>
<ContactPerson contactType="administrative">
<SurName>NIIF AAI</SurName>
<EmailAddress>aai@niif.hu</EmailAddress>
</ContactPerson>
</EntityDescriptor>
Egy SP példa
<EntityDescriptor entityID="https://rr.aai.niif.hu/shibboleth"
xmlns:mdui="urn:oasis:names:tc:SAML:2.0:metadata:ui">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol">
<Extensions>
<mdui:UIInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<mdui:PrivacyStatementURL>https://rr.aai.niif.hu/privacy-policy</mdui:PrivacyStatementURL>
<mdui:InformationURL>https://rr.aai.niif.hu/about</mdui:InformationURL>
</mdui:UIInfo>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="encryption">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<!-- endpoints -->
<AttributeConsumingService index="1">
<ServiceName xml:lang="hu">HREF Resource Registry</ServiceName>
<ServiceName xml:lang="en">HREF Resource Registry</ServiceName>
<ServiceDescription xml:lang="hu">Resource Registry - a föderáció adminisztrációs alkalmazása http://rr.aai.niif.hu/</ServiceDescription>
<ServiceDescription xml:lang="en">Resource Registry - federation administration tool http://rr.aai.niif.hu/</ServiceDescription>
<RequestedAttribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" isRequired="true"/>
<RequestedAttribute FriendlyName="surname" Name="urn:oid:2.5.4.4" isRequired="true"/>
<RequestedAttribute FriendlyName="givenName" Name="urn:oid:2.5.4.42" isRequired="true"/>
<RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" isRequired="true"/>
<RequestedAttribute FriendlyName="schacHomeOrganizationType" Name="urn:oid:1.3.6.1.4.1.25178.1.2.10" isRequired="true"/>
<RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" isRequired="true"/>
</AttributeConsumingService>
</SPSSODescriptor>
<Organization>
<OrganizationName xml:lang="hu">NIIF - Nemzeti Információs Infrastruktúra Fejlesztési Intézet</OrganizationName>
<OrganizationName xml:lang="en">NIIF Institute - National Information Infrastructure Development</OrganizationName>
<OrganizationDisplayName xml:lang="hu">NIIF - Nemzeti Információs Infrastruktúra Fejlesztési Intézet</OrganizationDisplayName>
<OrganizationDisplayName xml:lang="en">NIIF Institute - National Information Infrastructure Development</OrganizationDisplayName>
<OrganizationURL xml:lang="hu">http://www.niif.hu</OrganizationURL>
<OrganizationURL xml:lang="en">http://www.niif.hu/en</OrganizationURL>
</Organization>
<ContactPerson contactType="administrative">
<SurName>NIIF AAI</SurName>
<EmailAddress>aai@niif.hu</EmailAddress>
</ContactPerson>
<ContactPerson contactType="technical">
<SurName>NIIF AAI</SurName>
<EmailAddress>aai@niif.hu</EmailAddress>
</ContactPerson>
<ContactPerson contactType="support">
<SurName>NIIF AAI</SurName>
<EmailAddress>aai@niif.hu</EmailAddress>
</ContactPerson>
</EntityDescriptor>
Metaadat aláírásának módja
Aláíró kulcs és tanúsítványok
HREF-2011
- Az aláíró kulcsot smart cardon, pin kóddal védve tároljuk.
- Az aláírás on-line történik, a kártya pin kódját az aláíró szoftver indításakor az AAI adminisztrátor adja meg, a jelszó nem kerül tárolásra az aláírást végző rendszeren (sem másutt).
HREF-2020
- 4096 bites, SHA-384 RSA aláíró kulcs.
- Az aláírás on-line történik, több telephelyes tartalékolt infrastruktúrával.
Aláírási folyamat
Az aláíratlan metaadat frissítése:
- Az aláíratlan metaadat a https://rr.eduid.hu oldalról ütemezetten, minden óra 15. és 45. percében letöltésre kerül.
- A letöltött metaadat XML séma ellenőrzése ellenőrzése.
- A metadat feltöltése az objektum tárolóba.
Aláírás ellenőrzése explicit tanúsítvánnyal
A föderáció entitásai a föderációs metaadat hitelességéről a digitális aláírás ellenőrzésével győződhetnek meg. Az explicit ellenőrzés esetén a [http://metadata.eduid.hu/current/](http://metadata.eduid.hu/current/)
URL-ről kell letölteni a metadata fájlokat.
Ajánlott a tanúsítvány lejárati idejét figyelmen kívül hagyni.
HREF-2011
- A HREF-2011 tanúsítvány a https://metadata.eduid.hu oldalról érhető el.
SHA-1 | FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66 |
---|---|
Serial Number | 1 |
Version | 3 |
C | HU |
O | NIIF Institute |
OU | eduID Federation Operator |
CN | Metadata Signer |
emailAddress | aai@niif.hu |
Érvényesség kezdete | 2011.10.05. |
Érvényesség vége | 2031.09.30. |
HREF-2020
- A HREF-2020 tanúsítvány a https://metadata.eduid.hu oldalról érhető el.
SHA-1 | C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61 |
---|---|
Serial Number | 80:21:EF:F0:BA:16:04:BD |
Version | 1 |
C | HU |
ST | Budapest |
L | Budapest |
O | Governmental Agency for IT Development |
OU | eduID Federation Operator |
CN | Metadata Signer |
emailAddress | info@eduid.hu |
Érvényesség kezdete | 2020.06.13. |
Érvényesség vége | 2025.06.14. |
Aláíró kulcs cseréje
- A kulccsere koordinálása a
href-tech
levelezőlistán keresztül történik. - Kulcs visszavonásakor (kompromittálódás gyanúja esetén) a régi aláíró kulcs azonnal eltávolításra kerül, kontrollált kulcscsere esetén az aláírás párhuzamosan történik a régi és az új kulccsal.
Metaadat elérése
A HREF föderációban többféle metaadat-forrás áll rendelkezésre, melyeket a http://metadata.eduid.hu -ról lehet elérni. Fontos megemlíteni, hogy a metadata letöltésénél nem indokolt az SSL használata, ezért - amennyiben lehetséges -, érdemes a metadata URL-eket nem titkosított HTTP protokoll segítségével letölteni.
A metadata elérés URL-je a következő: http://metadata.eduid.hu/${alairo_kulcs_kibocsatas_eve}/${metadata_forras}.xml
.
A metadata források jelenleg a következők lehetnek:
href.xml |
Az éles föderációban részt vevő, és a föderáció kritériumait teljesítő entitások. |
---|---|
href-test.xml |
A HREF föderáció tesztrendszerei. Bármely, a föderációban részt vevő intézmény tehet be teszt-entitást ebbe a halmazba, ezért ezen metaadat-forrás csak tesztelési célra használható. |
href-pending.xml |
A HREF föderáció "előszobája". Az újonnan csatlakozó intézmények IdP-je először itt lesz elérhető. |
href-edugain.xml |
A HREF föderációból az eduGAIN konföderációba kiajánlott entitások. Ide csak olyan entitások kerülhetnek be, melyek megfelelnek a föderációs kritériumoknak, és képesek az eduGAIN konföderációval való együttműködésre. Ezen entitások be kell hogy olvassák az eduGAIN metaadatot is. |
edugain.xml |
Az eduGAIN konföderáció metaadata, a HREF aláíró kulccsal aláírva. |
intézmény-specifikus |
Az intézmény-specifikus metaadat fájlok (pl.: bme.xml, ceu.xml, stb.), melyeket a föderáció kérésre biztosítja, tetszőleges entitások halmazba gyűjtésével. |
MDX-alapú elérés
Az MDX, azaz MetaDataeXchange protokolt erőforrás optimalizálás céljából találták ki, hogy ne kelljen egyes IdP-knek és SP-knek indokolatlanul nagy XML fájlokat feldolgozniuk és tárolniuk, mikor a felhasználóiknak jó eséllyel a fájlokban tárolt entitások töredékére van csak szükségük. Ezért az egyes entitásokat be lehet úgy állítani, hogy csak akkor töltsék le az adott entitás metaadatát, mikor arra szükség van (az első letöltés után természetesen helyben tároldóik a metaadat a cacheDuration
-ben megadott ideig).
A HREF föderációban teszt jelleggel működik és elérhető MDX-kiszolgáló: http://mdx.eduid.hu. A megfelelő beállításokhoz itt érhető el segédlet.
Az MDX kiszolgáló eltérő kulcsot és tanúsítványt használ. Jelenleg az MDX elérés még csak teszt jelleggel működik, az élesüzemre váltáskor a HREF-2020 tanúsítvánnyal fog működni.
A jelenlegi tanúsítvány innen tölthető le: http://metadata.eduid.hu/current/mdx-test-signer-2015.crt
HREF-2015
SHA-1 | 91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43 |
---|---|
Serial Number | AA:90:7C:D9:0C:D5:64:8D |
Version | 3 |
C | HU |
ST | - |
L | Budapest |
O | NIIFI |
OU | AAI |
CN | eduID MDX metadata signer |
emailAddress | aai@niif.hu |
Érvényesség kezdete | 2015.10.13. |
Érvényesség vége | 2034.12.12. |
AAI_AzureADasAuthsource
Amennyiben Azure AD-ban tároljuk a felhasználói adatokat, úgy lehetőség van azt azonosítási forrásként is használni. A SimpleSAMLphp oldalon leírt telepítés után az alábbiak elvégzésére van szükség:
(ez csak egy példakonfiguráció, természetesen el lehet ettől térni)
Teendők SimpleSAMLPHP (SSP) oldalon
Keressük ki az Azure AD-ból a Tenant ID-t. A beállítás során erre TenantID-val fogunk hivatkozni, oda minden esetben ezt az azonosítót kell behelyettesíteni. Az azonosítót jelenleg a https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview oldalon keresztül lehet beszerezni (Forrás: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-to-find-tenant)
A DOMAIN helyére a használni kívánt scope-ot szükséges behelyettesíteni (pl intezmeny.hu)
config/authsources.php fájlba
'default-sp' => [
'saml:SP',
// The entity ID of this SP.
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => null,
// The entity ID of the IdP this SP should contact.
// Can be NULL/unset, in which case the user will be shown a list of available IdPs.
'idp' => 'https://sts.windows.net/_TenantID_/',
// The URL to the discovery service.
// Can be NULL/unset, in which case a builtin discovery service will be used.
'discoURL' => null,
'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
'simplesaml.nameidattribute' => 'eduPersonTargetedID',
/*
* The attributes parameter must contain an array of desired attributes by the SP.
* The attributes can be expressed as an array of names or as an associative array
* in the form of 'friendlyName' => 'name'. This feature requires 'name' to be set.
* The metadata will then be created as follows:
* <md:RequestedAttribute FriendlyName="friendlyName" Name="name" />
*/
/*
'name' => [
'en' => 'A service',
'no' => 'En tjeneste',
],
'attributes' => [
'attrname' => 'urn:oid:x.x.x.x',
],
'attributes.required' => [
'urn:oid:x.x.x.x',
],
*/
],
config/config-metarefresh.php fájlba
$config = [
'sets' => [
'azure' => [
'cron' => ['hourly'],
'sources' => [
[
'src' => 'https://login.microsoftonline.com/_TenantID_/federationmetadata/2007-06/federationmetadata.xml',
],
],
'expireAfter' => 34560060, // Maximum 4 days cache time (3600*24*4)
'outputDir' => 'metadata/metarefresh-azure',
'outputFormat' => 'flatfile',
],
],
];
metadata/saml20-idp-hosted.php
A
'authproc' => [
10 => [
'class' => 'core:AttributeMap',
'azure2name'
],
15 => [
'class' => 'core:AttributeCopy',
'eduPersonPrincipalName' => 'schacPersonalUniqueCode',
],
16 => ['class' => 'core:PHP', 'code' => ' $attributes[= "urn:schac:personalUniqueCode:int:esi:_DOMAIN_:" . $attributes["schacPersonalUniqueCode"]("schacPersonalUniqueCode"][0])[0];
',
],
18 => [
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonPrincipalName',
'pattern' => '/^.*$/',
'replacement' => '${0}@_DOMAIN_',
'target' => 'eduPersonPrincipalName'
],
20 => [
'class' => 'core:AttributeAdd',
'eduPersonEntitlement' => array('urn:mace:dir:entitlement:common-lib-terms')
],
22 => [
'class' => 'core:AttributeAdd',
'schacHomeOrganization' => array('_DOMAIN_')
],
23 => [
'class' => 'core:AttributeAdd',
'schacHomeOrganizationType' => array('urn:schac:homeOrganizationType:eu:higherEducationalInstitution')
],
// Azure AD-ban célszerű az affilation-t (intézményhez való viszonyt, pl hallgató, oktató, dolgozó) security group alapján meghatározni. Ezeknek az objektum azonosítóját át fogja adni az Azure AD, amit könnyen kicserélhetünk a kívánt affilation-re:
31 => [
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonAffiliation',
'pattern' => '/^_eduID_Dolgozó_GroupID_$/', // _eduID_Dolgozó_GroupID_ értéket cseréljük a megfelelő Objektum ID-ra
'replacement' => 'faculty',
],
32 => [
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonAffiliation',
'pattern' => '/^_eduID_Hallgató_GroupID_$/', // _eduID_Hallgató_GroupID_ értéket cseréljük a megfelelő Objektum ID-ra
'replacement' => 'student',
],
33 => [
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonAffiliation',
'pattern' => '/^_eduID_Admin_GroupID_$/', // _eduID_Admin_GroupID_ értéket cseréljük a megfelelő Objektum ID-ra
'replacement' => 'staff',
],
34 => [
'class' => 'core:AttributeAdd',
'eduPersonAffiliation' => array('member'),
],
35 => [
'class' => 'core:AttributeCopy',
'eduPersonAffiliation' => 'eduPersonScopedAffiliation'
],
36 => [
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonScopedAffiliation',
'pattern' => '/^.*$/',
'replacement' => '${0}@$_DOMAIN_',
],
50 => [
'class' => 'core:TargetedID',
'identifyingAttribute' => 'eduPersonPrincipalName',
'nameId' => TRUE,
],
60 => [
'class' => 'core:AttributeMap',
'name2oid'
],
75 => [
'class' => 'entitycategories:EntityCategory',
'default' => true,
'strict' => false,
'allowRequestedAttributes' => true,
'http://eduid.hu/category/registered-by-eduidhu' => [],
'http://www.geant.net/uri/dataprotection-code-of-conduct/v1' => [
'urn:oid:2.16.840.1.113730.3.1.241', # displayName
'urn:oid:2.5.4.4', # sn
'urn:oid:2.5.4.42', # givenName
'urn:oid:0.9.2342.19200300.100.1.3', # mail
'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', # eduPersonPrincipalName
'urn:oid:1.3.6.1.4.1.5923.1.1.1.9', # eduPersonScopedAffiliation
'urn:oid:1.3.6.1.4.1.5923.1.1.1.1', # eduPersonAffiliation
],
'http://refeds.org/category/research-and-scholarship' => [
'urn:oid:2.16.840.1.113730.3.1.241', # displayName
'urn:oid:2.5.4.4', # sn
'urn:oid:2.5.4.42', # givenName
'urn:oid:0.9.2342.19200300.100.1.3', # mail
'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', # eduPersonPrincipalName
'urn:oid:1.3.6.1.4.1.5923.1.1.1.9', # eduPersonScopedAffiliation
'urn:oid:1.3.6.1.4.1.5923.1.1.1.1', # eduPersonAffiliation
],
],
90 => 'core:AttributeLimit',
],
'simplesaml.nameidattribute' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
'attributeencodings' => array(
'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw', /* eduPersonTargetedID with oid NameFormat. */
),
'sign.logout' => true
];
attributemap/azure2oid.php
<?php
$attributemap = [
// displayName
'http://schemas.microsoft.com/identity/claims/displayname' => 'urn:oid:2.16.840.1.113730.3.1.241',
// eppn
'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
// givenName
'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname' => 'urn:oid:2.5.4.42',
// cn
'://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname' => 'urn:oid:2.5.4.3',
// surname
'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname' => 'urn:oid:2.5.4.4',
// mail
'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress' => 'urn:oid:0.9.2342.19200300.100.1.3',
// o & organisation
'http://schemas.microsoft.com/identity/claims/tenantid' => 'urn:oid:2.5.4.10',
];
attributemap/azure2name.php
<?php
$attributemap = [
// eppn
'http://schemas.microsoft.com/identity/claims/objectidentifier' => 'eduPersonPrincipalName',
// mail
'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress' => 'mail',
// displayName
'http://schemas.microsoft.com/identity/claims/displayname' => 'displayName',
// givenName
'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname' => 'givenName',
// cn
'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname' => 'sn',
// affiliation
'http://schemas.microsoft.com/ws/2008/06/identity/claims/groups' => 'eduPersonAffiliation',
];
Teendők Azure AD oldalon
- A https://portal.azure.com/ oldalon jelentkezzünk be egy adminisztrátori fiókkal
- Válasszuk az "App registrations"-t
- "New registration"
- "Redirect URI (optional)" -nál adjuk meg a telepített SSP default SP címét. Pl: https://idp.DOMAIN/simplesaml/module.php/saml/sp/metadata.php/default-sp
- "Token configuration" # > "Add optional claim"> "Token type"-nál válasszuk a "SAML"-t és jelöljük ki az összes attribútumot, majd, "Add"
- "Add groups claim", majd mentsük el
- Állítsuk be az API persmissions-t az alábbi alapján:
Teszt
Metadata_Specification
Information about the entities of the Federation is maintained in a signed XML document, called the federation metadata.
Metadata publishing rules
The metadata file is available both at http://metadata.eduid.hu/current/href.xml and https://metadata.eduid.hu/current/href.xml, however the unencrypted method is preferred. The file is stored on a highly available file server.
The metadata file is re-published every 4 hours or whenever the entity information changes (eg. entities are added or modified). Entities are expected to refresh metadata information regularly, although the cacheDuration
attribute is currently not in use (for interoperability reasons).
Trust in metadata
The information inside the metadata file must not be trusted after the date specified in the validUntil
field of the topmost EntitiesDescriptor
is expired. The expiration time is is set to 7 days after the instant of the signature.
Verification of the metadata file
The contents of the metadata file must be trusted only if the signature of the Federation Operator can be validated.
The Federation Operator uses a self-signed certificate for signing the metadata file, therefore the signing key must be explicitly trusted. Properties of the signing certificate:
- DN:
C=HU, O=NIIF Institute, OU=eduID Federation Operator, CN=Metadata Signer/emailAddress=aai@niif.hu
- MD5 fingerprint:
21:8C:BE:B4:D1:D6:12:C4:67:9F:16:FA:93:36:F6:A4
- SHA1 fingerprint:
FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66
- Availability: from
Oct 5 08:18:46 2011 GMT
untilSep 30 08:18:46 2031 GMT
The certificate used for signing can be downloaded from https://metadata.eduid.hu/2011/href-metadata-signer-2011.crt , which link should lead to a page without certificate warnings with most browsers. It is recommended to request the signing certificate from the Federation Operator by using some other verifiable transport as well (such as PGP-signed email).
Signing procedure
Information about the entities is retrieved from the Resource Registry by using strong server authentication. If the contents of the metadata changes, it is saved to a version control system and the 'diff' is sent to a public mailing list (href-metadata-changes)
The signing operation is done by a PIN-protected hardware token.
Signing key change or revocation
Changes of the signing key/certificate is always negotiated with the technical contacts of all federation entities.
Authenticating peer entities
It is recommended for all entities to use self-signed certificates, however, even if an entity uses a certificate signed by an external CA, it shall not be assumed that peers use any kind of PKI path validation or revocation checking.
Entity certificate change or revocation
An entity should change its signing certificate by allowing a time frame, when both the old and the new certificate is available in the metadata.
If an entity certificate is compromised, the Federation Operator must be notified immediately. The certificate is removed from the metadata and either replaced by a new one or the entity is removed from the metadata file. On such an incident, all technical contacts are notified to do an immediate metadata refresh to shorten the attack window.
Metadata extensions
Extension elements must be either interpreted according to their specification or ignored completely (while they are valid XML).
Non-federation metadata sets
The federation signing engine is able to produce files other than the federation metadata (called metadata sets). These files are available at https://metadata.eduid.hu/current/, all signed with the same credentials as the federation metadata, therefore it is easy to add them as an auxiliary metadata source.
href-test.xml
: staging federation metadata. Any federation member may register entities in this set.href-edugain.xml
: entities that are exported to eduGAIN confederation. This file is consumed by eduGAIN MDS only. As eduGAIN follows an opt-in policy, only those entities are present in this set, whose administrators explicitly requested to be published in eduGAIN.edugain.xml
: entities that are imported from eduGAIN confederation (minus Hungarian entities). If an entity wants to collaborate with eduGAIN entities from other federations, it needs to load this file.<institution>.xml
: institution-specific metadata sets, which are maintained by the administrators of the institution. SPs inside this set are not required to be accepted by the federation, thus they are assumed to be used within the institution only.
Although an entity might appear in multiple sets, the entity information (including the entityID) must be the same across all sets. It is not allowed to register the same entity into multiple institution sets; the federation set must be used instead.
Metadata registration
Entity metadata management is performed by using Resource Registry, no direct editing is supported.
Depending on the access level, the following administrative tasks may be performed:
- Federation administrators are entitled to:
- register new institutions
- manage Institutional Administrators
- manage Partner SPs
- add or remove IdPs
- manage production federation set and eduGAIN export set (see the section about metadata sets above)
- Institutional Administrators are entitled to:
- register new SPs and place them to the institutional metadata and/or staging federation metadata sets
- manage the SPs of the institution
- request the inclusion of an SP to the federation metadata or the eduGAIN export from the Federation Operator
- add or remove SP administrators
- add or remove Privacy Administrators
- manage the IdP(s) of the institution
- SP administrators are entitled to:
- manage the SPs, which are assigned to them
- Privacy Administrators are entitled to:
- manage attribute release rules of the IdP of the institution
Accordingly, all partner SP metadata management is performed by the Federation Operator, by the request of the Techical/Administrative Contact of the Partner.
JoiningEduGAIN
Metaadatok
Az eduGAIN csatlakozáshoz a csatlakozó entitásnak - akár IdP, akár SP - ismernie kell az eduGAIN-ben résztvevő többi entitást. Ezt vagy a hagyományos módszerrel, az eduGAIN aláírt metaadatainak betöltésével lehet elérni, vagy az igény szerinti metaadat-kiszolgáló (MDX) használatával.
Hagyományos XML állomány
Töltse be és rendszeresen frissítse az általunk aláírt eduGAIN metadatát: http://metadata.eduid.hu/current/edugain.xml. Az aláírókulcs megegyezik a többi metadata setet aláíró kulccsal (https://metadata.eduid.hu/href-metadata-signer-2011.crt). Félreértések elkerülése végett a magyar entitások az újra aláírt eduGAIN metaadatok között nem szerepelnek, hogy ne legyen duplikáció.
Ennél a módszernél fel kell készülni arra, hogy a metaadat-frissítés hosszadalmas, több percet igénylő folyamat lehet. Néhány jellemző probléma:
- Shibboleth SP el- vagy újraindításakor több percen keresztül
ListenerException
hiba jelentkezik. - SimpleSAMLphp esetén a metarefresh kifut a rendelkezésre álló memóriából, vagy tovább fut, mint a
max_execution_timeout
vagy a webszerver beállításai ezt lehetővé tennék.
Igény szerinti metaadat kiszolgálás
Ebben az esetben a metaadatokat csak akkor töltjük le, ha éppen szükség van rájuk. Részletes leírás itt: MDX.
Ennek a módszernek előnye, hogy sokkal kevesebb erőforrást igényel a szerveren. Az alapértelmezés szerinti gyorstárazási idő is jóval rövidebb, mint a hagyományos esetben, így a változások valamivel hamarabb érvényre jutnak.
Egyidejű használat
Mind a Shibboleth, mind a SimpleSAMLphp lehetővé teszi, hogy a hagyományos fájl-alapú és az MDX alapú metaadat forrásokat egyidőben használjuk. Például:
- helyi statikus metaadat-állományokat használunk,
- a magyar entitásokat hagyományos módon, az eduGAIN-es entitásokat MDX-szel akarjuk letölteni.
Ilyen esetben az MDX metaadat-forrást célszerű utolsó helyre tenni a sorban. Ekkor az metaadat-kérés csak akkor hajtódik végre, ha az entitás egyik statikus forrásban sem található meg.
HOWTO: SimpleSAMLphp metaadatforrások egyidejű használata.
IdP csatlakozása az eduGAIN-hez
Az IdP-nek értelmeznie kell SP-k attribútum-igényeit. Erre erősen ajánlott az EntityCategory alapú attribútum kiadást használni, kiegészítve a metadata-alapú (RequestedAttributes) attribútum kiadási mechanizmussal.
- SimpleSAMLphp: a javasolt megoldásról bővebben erre.
- Shibboleth: natívan ismeri mindkét attribútumkiadási mechanizmust:
A metaadatok, illetve az attribútum-kiadás megfelelő konfigurációja után az IdP csatlakozását az IdP technikai kapcsolattartója kezdeményezi a föderációs adminfelületen (https://rr.eduid.hu), ügyelve arra, hogy az entitáshoz beállított logó is https-en keresztüli url-en legyen elérhető, ill. rögzítésre kerüljenek a különböző leíró dokumentumok angol nyelvű változataira mutató url-ek is.
SP csatlakozása az eduGAIN-hez
A metaadatok megfelelő konfigurációja után az SP adminisztrátora a Resource Registry-ben állíthatja be, hogy az SP az eduGAIN-ben publikálásra kerüljön.
A Discovery felület integrációjával kapcsolatban lásd az MDX leírás vonatkozó részét!
Entitás kategóriák
Amennyiben nemzetközi együttműködésben vesz részt az SP, az entitás kategóriák használatával megkönnyíthetjük, hogy az IdP-k az igényelt attribútumokat kiadják.
Az entitás kategóriák beállítását az SP kapcsolattartója az info@eduid.hu címen kezdeményezheti.
Research & Scholarship
Amennyiben a szolgáltatás a kutatást vagy az oktatást támogatja, beállítható a Research & Scholarship entitás kategória. Részletes szabályok: https://refeds.org/category/research-and-scholarship
GÉANT Data Protection Code of Conduct
Az entitás kategória részletes szabályai itt találhatóak: https://wiki.edugain.org/Recipe_for_a_Service_Provider . Fontos kiemelni, hogy ez a kategória az entitás metaadatainak részletes kitöltését (https://rr.eduid.hu) igényli, valamint egy olyan angol nyelvű adatvédelmi szabályzat meglétét, amely hivatkozik a http://www.geant.net/uri/dataprotection-code-of-conduct/v1 dokumentumra.
Shibenv-PHP-Lazy
http://shib.kuleuven.be/download/sp/test_scripts/shibenv.php.txt alapján:
<html>
<head>
<title>Shibboleth Attributes - <?php echo $_SERVER["SERVER_NAME"]; ?></title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<script language"JavaScript" type="text/JavaScript">
<!--
function decodeAttributeResponse() {
var textarea = document.getElementById("attributeResponseArea");
var base64str = textarea.value;
var decodedMessage = decode64(base64str);
textarea.value = tidyXml(decodedMessage);
textarea.rows = 15;
document.getElementById("decodeButtonBlock").style.display='none';
}
function tidyXml(xmlMessage) {
//put newline before closing tags of values inside xml blocks
xmlMessage = xmlMessage.replace(/([^>])</g,"$1\n<");
//put newline after every tag
xmlMessage = xmlMessage.replace(/>/g,">\n");
var xmlMessageArray = xmlMessage.split("\n");
xmlMessage="";
var nestedLevel=0;
for (var n=0; n < xmlMessageArray.length; n++) {
if ( xmlMessageArray[n].search(/<\//) > -1 ) {
nestedLevel--;
}
for (i=0; i<nestedLevel; i++) {
xmlMessage+=" ";
}
xmlMessage+=xmlMessageArray[n]+"\n";
if ( xmlMessageArray[n].search(/\/>/) > -1 ) {
//level status the same
}
else if ( ( xmlMessageArray[n].search(/<\//) < 0 ) && (xmlMessageArray[n].search(/</) > -1) ) {
//only increment if this was a tag, not if it is a value
nestedLevel++;
}
}
return xmlMessage;
}
var base64Key = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
function decode64(encodedString) {
var decodedMessage = "";
var char1, char2, char3;
var enc1, enc2, enc3, enc4;
var i = 0;
//remove all characters that are not A-Z, a-z, 0-9, +, /, or =
encodedString = encodedString.replace(/[^A-Za-z0-9\+\/\=]/g, "");
do {
enc1 = base64Key.indexOf(encodedString.charAt(i++));
enc2 = base64Key.indexOf(encodedString.charAt(i++));
enc3 = base64Key.indexOf(encodedString.charAt(i++));
enc4 = base64Key.indexOf(encodedString.charAt(i++));
char1 = (enc1 << 2) | (enc2 >> 4);
char2 = ((enc2 & 15) << 4) | (enc3 >> 2);
char3 = ((enc3 & 3) << 6) | enc4;
decodedMessage = decodedMessage + String.fromCharCode(char1);
if (enc3 != 64) {
decodedMessage = decodedMessage + String.fromCharCode(char2);
}
if (enc4 != 64) {
decodedMessage = decodedMessage + String.fromCharCode(char3);
}
} while (i < encodedString.length);
return decodedMessage;
}
// -->
</script>
</head>
<body>
<!-- bk beszuras kovetkezik -->
<?php
$myServer = 'https://' . $_SERVER['HTTP_HOST'];
$SessionInitiator = $myServer . "/Shibboleth.sso/WAYF/HREF";
$myUrl = (isset($_SERVER['HTTPS']) ? 'https' : 'http') . '://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
// $myUrl: ahova vissza kell majd juttatnia a Shibboleth-nek
if (!$_SERVER['HTTP_SHIB_IDENTITY_PROVIDER'])
// igy dontjuk el, hogy van-e session
{
echo "<p><b><a href=\"$SessionInitiator?target=$myUrl\">Kattints ide a Shibboleth-es belepeshez</a></b></p>";
}
else
{
$LogoutUrl = $myServer . "/Shibboleth.sso/Logout";
echo "<p><b>Van Shib session, oh yeah. </b></p>";
echo "<p><a href=\"$LogoutUrl?return=$myUrl\">Kattints ide</a>, ha <i>errol az SP-rol</i> ki akarsz jelentkezni</p>";
}
echo "<hr>";
?>
<!-- bk beszuras vege -->
<b>-all SHIB headers-</b> (<code>HTTP_SHIB_ATTRIBUTES</code> is not shown in this list)
<?php
echo '<table>';
foreach ($_SERVER as $key => $value)
{
$fkey='_'.$key;
if ( strpos($fkey,'SHIB')>1 && $key!="HTTP_SHIB_ATTRIBUTES")
# if ( strpos($fkey,'SHIB')>1 )
{
echo '<tr>';
echo '<td>'.$key.'</td><td>'.$value.'</td>';
echo '</tr>';
}
}
echo '<tr><td>(REMOTE_USER)</td><td>'.$_SERVER['REMOTE_USER'].'</td></tr>';
echo '<tr><td>(HTTP_REMOTE_USER)</td><td>'.$_SERVER['HTTP_REMOTE_USER'].'</td></tr>';
echo '<tr><td>HTTP_SHIB_LOGOUTURL</td><td>'.$_SERVER['HTTP_SHIB_LOGOUTURL']
.'<a href="/Shibboleth.sso/Logout?return='.$_SERVER['HTTP_SHIB_LOGOUTURL']
.'%3Freturn%3Dhttps%3A%2F%2Fshib.kuleuven.be%2Flogout.shtml">[logout]</a> </td></tr>';
echo '</table>';
?>
<br/>
attribute response from the IdP (<code>HTTP_SHIB_ATTRIBUTES</code>):<br/>
<textarea id="attributeResponseArea" onclick="select()" rows="1" cols="130">
<?php echo $_SERVER["HTTP_SHIB_ATTRIBUTES"]; ?></textarea><br/>
<span id="decodeButtonBlock"><input type="button" id="decodeButton"
value="decode base64 encoded attribute response using JavaScript"
onClick="decodeAttributeResponse();"><br/></span>
<br/>
<small>
notes:<br/>
The AAP throws away invalid values (eg an unscopedAffiliation of value "myBoss@<yourdomain>"
or a value with an invalid scope which scope is checked)<br/>
The raw attribute response (<code>HTTP_SHIB_ATTRIBUTES</code>) is NOT filtered by the AAP and should
therefore be disabled for most applications (<code>exportAssertion=false</code>).<br/>
</small>
<br/>
<hr/>
<br/>
<b>$_REQUEST</b>
<?php
echo '<table>';
foreach ($_REQUEST as $key => $value)
{
echo '<tr>';
echo '<td>'.$key.'</td><td>'.$value.'</td>';
echo '</tr>';
}
echo '</table>';
?>
<br/>
<hr/>
<br/>
<b>$_SERVER</b>
<?php
echo '<table>';
foreach ($_SERVER as $key => $value)
{
echo '<tr>';
echo '<td>'.$key.'</td><td>'.$value.'</td>';
echo '</tr>';
}
echo '</table>';
?>
<br/>
<hr/>
<br/>
<b>$_SESSION</b>
<?php
echo '<table>';
foreach ($_SESSION as $key => $value)
{
echo '<tr>';
echo '<td>'.$key.'</td><td>'.$value.'</td>';
echo '</tr>';
}
echo '</table>';
?>
<br/>
<hr/>
<br/>
</body>
</html>
GoogleAuth
Alapok
A wikiben részletezett többi megoldáshoz képest ez a fejezet kilóg a sorból, hiszen ez a megoldás "a federáción" belül csak egy Identity Providert használ - a google központi kapuját. Ezt bárki használhatja a saját szolgáltatásában (SP) történő felhasználó-hitelesítésére, természetesen annyi megszorítás van, hogy az adott felhasználóknak rendelkezniük kell Google Accounttal (gmail-es e-mail címmel).
A google ekkor 2.0-ás szabványú OpenID protokoll szerint működő OpenID IdP-ként viselkedik, emellett támogatja az OpenID Attribute Exchange 1.0 alapú attribútum kiadást, így ha a felhasználó az autentikáció során hozzájárul a felsorolt adatainak az SP részére történő kiadásához, akkor azt a google ki is adja. (A kiadható attribútumok köre korántsem teljes, lévén jelenleg egyedül az e-mail cím kiadatására van lehetősége az SP-nek)
Beállítás
Az autentikációhoz használt google-végpont a
https://www.google.com/accounts/o8/id
címen érhető el, a megfelelő paramétereket ide kell átadni.
Rendelkezésre álló paraméterek
openid.ns | Kötelező - a használandó OpenID protokollt definiálja, ajánlott érték: "http://specs.openid.net/auth/2.0" |
---|---|
openid.claimed_id | Opcionális - a kérelem típusát azonosítja, ajánlott érték: "http://specs.openid.net/auth/2.0/identifier_select" |
openid.identity | Opcionális, egy alternatív azonosítót definiál, ajánlott érték: "http://specs.openid.net/auth/2.0/identifier_select" |
openid.return_to | Kötelező - azt az oldalt definiálja, amelyre a google visszairányít az autentikáció után. Támogatott http és https protokollú visszatérő oldal egyaránt. |
openid.realm | Opcionális - azt a domaint definiálja, amelyre a felhasználót a google-el autentikáltatni szeretnénk. Alapértelmezés szerint az openid.return_to-nál megadott honlapra mutat. Amennyiben megadásra kerül, akkor a domainnek mindenképp egyeznie kell az openid.return_to domainnevével. |
openid.assoc_handle | Opcionális - részletes ismetető: http://openid.net/specs/openid-authentication-2_0.html#associations |
openid.mode | Kötelező - a kérés módját adja meg, a két lehetséges érték: "checkid_immediate" (szinkron kommunikáció) "checkid_setup" (aszinkron kommunkikáció) |
openid.ns.ext1 | Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "http://openid.net/srv/ax/1.0" |
openid.ext1.mode | Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "fetch_request" |
openid.ext1.type.email | Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "http://axschema.org/contact/email" |
openid.ext1.required | Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "email" (Jelenleg csak az email attribútum elérhető) |
Minta kérés
Az alábbi kérés igényli az email-cím attribútum kiadását is
https://www.google.com/accounts/o8/ud
?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select
&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select
&openid.return_to=http%3A%2F%2Fwww.example.com%2Fcheckauth
&openid.realm=http%3A%2F%2Fwww.example.com%2F
&openid.assoc_handle=ABSmpf6DNMw
&openid.mode=checkid_setup
&openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0
&openid.ext1.mode=fetch_request
&openid.ext1.type.email=http%3A%2F%2Faxschema.org%2Fcontact%2Femail
&openid.ext1.required=email
Minta válasz sikeres autentikáció esetén
http://www.example.com:8080/checkauth
?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
&openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fud
&openid.response_nonce=2008-09-18T04%3A14%3A41Zt6shNlcz-MBdaw
&openid.return_to=http%3A%2F%2Fwww.example.com%3A8080%2Fcheckauth
&openid.assoc_handle=ABSmpf6DNMw
&openid.signed=op_endpoint%2Cclaimed_id%2Cidentity%2Creturn_to%2Cresponse_nonce%2Cassoc_handle%2Cext1.mode%2Cext1.type.email%2Cext1.value.email
&openid.sig=s%2FgfiWSVLBQcmkjvsKvbIShczH2NOisjzBLZOsfizkI%3D
&openid.identity=https%3A%2F %2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%3DACyQatixLeLODscWvwqsCXWQ2sa3RRaBhaKTkcsvUElI6tNHIQ1_egX_wt1x3fAY983DpW4UQV_U
&openid.claimed_id=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%3DACyQatixLeLODscWvwqsCXWQ2sa3RRaBhaKTkcsvUElI6tNHIQ1_egX_wt1x3fAY983DpW4UQV_U
&openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0
&openid.ext1.mode=fetch_response
&openid.ext1.type.email=http%3A%2F%2Faxschema.org%2Fcontact%2Femail
&openid.ext1.value.email=fred.example%40gmail.com
Minta választ sikertelen autentikáció esetén
http://www.example.com/checkauth
?openid.mode=cancel
&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
Válaszok feldolgozása
A megfelelő kérés elküldése után a rendszer átirányít a google autentikációs oldalára, ahol a felhasználónak meg kell adnia google accounttal kapcsolatos adatait, majd sikeres bejelentkezés után jóvá kell hagynia, hogy a SP részére a google átadja az információt, hogy bejelentkezett ill. az egyéb attribútumokat, melyeket adott esetben az SP igényelt. Pozitív válasz esetén a google beállítva a megfelelő értékeket meghívja a visszatérő oldalt, ahol a megfelelő GET paraméterek feldolgozásával már SP-hatáskörben irányíthatók tovább a felhasználók.
Külső hivatkozások
Pont-pont_bizalmi_kapcsolati_modell
Két intézmény egymással közvetlenül köt megállapodást az identitás-információk átadásáról. Ez lehet egy föderáción belüli megállapodás kiterjesztése, ill. teljesen új megállapodás. Mindkét intézmény működhet identitás szolgáltatóként és tartalomszolgáltatóként is.
A pont-pont modell hátránya az adminisztrációs többletteher, mivel az együttműködő intézménnyel közvetlenül kell megállapodni. Leggyakrabban akkor használják, ha egy projektben szükség van 1-2 partnerrel külön megállapodást kötni (ekkor a partnereknek nem kell a föderációban részt venniük).
- Kutatói föderációkban piaci szereplők általában nem vehetnek részt mint azonosítási szolgáltatók. Előfordulhat, hogy egy projektben - ahol megosztott közös erőforrásokat kell használni több intézmény munkatársainak - piaci és kutató intézmény dolgozik együtt, ilyenkor jó megoldás lehet a közvetlen megállapodás
Eszközök
- uApprove: User-consent (beleegyezési nyilatkozat) eszköz
- SamlSign: Metaadat aláíró és ellenőrző eszköz
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](https://help.edu.hu/books/aai/page/single-logout-in-shibboleth-idp) 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-basedGit 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"
orsigning="false"
, as described in the SLO documentation
- Don't forget to set
- 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:
<LogoutInitiator type="Chaining" Location="/BackChannelLogout" relayState="cookie">
<LogoutInitiator type="SAML2" outgoingBindings=" " />
<LogoutInitiator type="Local"/>
</LogoutInitiator>
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
!!! warning "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 browser 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. Bach-channel is much more convenient for them, though.
Test with Application Notification
!!! warning "TODO"
Contribution is welcome!
Try it with various browsers
!!! warning "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
Shibboleth2_IdP
Telepítési leírások
- Shibboleth 2 IdP telepítése (Debian + Tomcat6)
- Shibboleth 2 IdP telepítése (RHEL5/CENTOS5 + Tomcat6)
- OpenSUSE-specifikus kiegészítések
- Shibboleth 2 IdP klaszterezése
Konfigurációs leírások
- Felhasználók azonosítása
- Attributumok feloldása
- Attributumok kiadása
- Perzisztens azonosító használata Shibboleth 2 IdP-ben
- Alkalmazásszerverhez delegált adatbázis kapcsolat kezelés (connection pooling) Shibboleth 2 IdP-ben
- Belépő oldal optimalizálása mobilra
Kiegészítő programok konfigurációs leírásai
Shibboleth fejlesztések(angolul) / Shibboleth IdP development (in English)
- Single Logout in Shibboleth
- Single Logout demo description
- X.509 authentication with LDAP
- Using Shibboleth SSO with webmail applications
MDX
Az MDX, azaz MetaDataeXchange protokolt erőforrás optimalizálás céljából találták ki, hogy ne kelljen egyes IdP-knek és SP-knek indokolatlanul nagy XML fájlokat feldolgozniuk és tárolniuk, mikor a felhasználóiknak jó eséllyel a fájlokban tárolt entitások töredékére van csak szükségük. Ezért az egyes entitásokat be lehet úgy állítani, hogy csak akkor töltsék le az adott entitás metaadatát, mikor arra szükség van (az első letöltés után természetesen helyben tároldóik a metaadat a cacheDuration
-ben megadott ideig). Az MDX kiszolgáló az alábbi szabvány szerint tudja visszaadni egy-egy entitás metaadatát: https://mdx.eduid.hu/entities/{urlencoded}$entityID
, pl: https://mdx.eduid.hu/entities/https%3A%2F%2Fdev.aai.niif.hu%2Fshibboleth
Dinamikus metadata kiszolgálás a HREF-ben
Az MDX kiszolgáló a https://mdx.eduid.hu alatt szolgáltat, és a href és az edugain metadata halmazokat tartalmazza.
Mindkét kiszolgáló ugyanazzal a kulccsal írja alá a lekért metaadat-állományt.
- A tanúsítvány letölthető innen: https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt
- SHA-1 lenyomata:
C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61
.
Fontos tudnivaló Discovery Service használattal kapcsolatban
Lévén az MDX-et használó SP-knél nem áll rendelkezésre folyamatosan az összes potenciális IdP listája, így a beépített Discovery Service-ek nem működnek. Ha MDX-et használunk, akkor valamilyen külső Discvery Service-t kell használnunk. A HREF-ben a https://discovery.eduid.hu a központi Discovery Service.
Emellett maga az MDX kiszolgáló is biztosít Discovery Service felületet, ehhez akár Shibboleth SP-nél, akár simpleSAMLphp SP-nél a konfigurációban az alábbi URL-t kell megadni, mint Discovery Service: https://mdx.eduid.hu/role/idp.ds . Ez a Discovery Service tartalmazza a hazai eduID-ben, valamint az eduGAIN-ben levő összes IdP-t. (És, ellentétben a hagyományos https://discovery.eduid.hu/edugain szolgáltatással, ez tartlamazza a magyar VHO-t is VHO IdP néven.)
MDX használata kliens oldalon
SimpleSAMLphp
Az 1.14-es kiadástól kezdve a SimpleSAMLphp tartalmazza az dinamikus metadata lekérdezés funkciót, amely mind IdP, mind SP szerepben egységes módon használható. A config/config.php állományban metadata.sources szekcióban kell elhelyezni az alábbi blokkot:
'metadata.sources' => array(
array('type' => 'flatfile'), // ez a *-hosted metadata konfiguráció betöltése miatt szükséges
array(
'type' => 'mdx',
'server' => 'https://mdx.eduid.hu',
'cachedir' => '/var/simplesamlphp/mdx-cache', //opcionális, de ajánlott
'cachelength' => 86400, //opcionális,
'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61' //opcionális
),
),
A dinamikus és a statikus metadataforrások egyidejű használatára egy példa: SimpleSAMLMixedMetadata
Shibboleth SP
- Le kell tölteni a /etc/shibboleth alá az aláíró tanúsítványát innen: https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt
- Az alábbi blokkot be kell szúrni a
/etc/shibboleth/shibboleth2.xml
fájlba
<MetadataProvider type="Dynamic" ignoreTransport="true">
<Subst>https://mdx.eduid.hu/entities/$entityID</Subst>
<MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
</MetadataProvider>
Shibboleth IdPv3
- Le kell tölteni a
${idp.home}/credentials/
alá az aláíró tanúsítványát innen: https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt - A
conf/metadata-providers.xml
fájlt kell szerkeszteni az alábbi módon:
<MetadataProvider
xmlns="urn:mace:shibboleth:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd"
id="dynamicMDQ" xsi:type="DynamicHTTPMetadataProvider">
<!--
Require a validUntil XML attribute on the EntityDescriptor element
and make sure its value is no more than 14 days into the future
-->
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P14D" />
<!-- Verify the signature on the metadata file -->
<MetadataFilter xsi:type="SignatureValidation" requireSignedMetadata="true"
certificateFile="${idp.home}/credentials/href-metadata-signer-2020.crt" />
<!-- The MetadataQueryProtocol element specifies the base URL for the query protocol. -->
<MetadataQueryProtocol>https://mdx.eduid.hu/</MetadataQueryProtocol>
</MetadataProvider>
Alkalmazások_samlizálást_segítő_teszt_IdP_simplesamlPHP_segítségével
-
Telepítünk egy SSP egyedet valamelyik szerverünkre.
-
Engedélyezzük a userpass auth forrás modult.
touch modules/exampleauth/enable
-
Elrendezzük a metadatákat.
-
Az authsources.php file-t valahogy így alakítjuk ki:
<?php
$config = array(
// This is a authentication source which handles admin authentication.
'admin' => array(
// The default is to use core:AdminPassword, but it can be replaced with
// any authentication source.
'core:AdminPassword',
),
'multi' => array(
'multiauth:MultiAuth',
/*
* The available authentication sources.
* They must be defined in this authsources.php file.
*/
'sources' => array('projekt1', 'projekt2'),
),
'projekt1' => array(
'exampleauth:UserPass',
'tesztuser1:tesztuser1' => array(
'eduPersonPrincipalName' => array('tesztuser1@example.com'),
'uid' => array('tesztuser1'),
'cn' => "Nemecsek Ernő",
'sn' => "Nemecsek",
'givenName' => "Ernő",
'mail' => "devnull@example.com",
'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
'schacDateOfBirth' => "19751221",
'schacPlaceOfBirth' => "Budapest",
'niifPersonMothersName' => "Törőcsik Mari",
'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
),
'tesztuser2:tesztuser2' => array(
'eduPersonPrincipalName' => array('tesztuser2@example.com'),
'uid' => array('tesztuser2'),
'cn' => "Nemecsek Ernő 2",
'sn' => "Nemecsek",
'givenName' => "Ernő",
'mail' => "devnull@example.com",
'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
'schacDateOfBirth' => "19751221",
'schacPlaceOfBirth' => "Budapest",
'niifPersonMothersName' => "Törőcsik Mari",
'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
),
),
'projekt2' => array(
'exampleauth:UserPass',
'tesztuser1:tesztuser1' => array(
'eduPersonPrincipalName' => array('tesztuser1@example.com'),
'uid' => array('tesztuser1'),
'cn' => "Nemecsek Ernő",
'sn' => "Nemecsek",
'givenName' => "Ernő",
'mail' => "devnull@example.com",
'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
'schacDateOfBirth' => "19751221",
'schacPlaceOfBirth' => "Budapest",
'niifPersonMothersName' => "Törőcsik Mari",
'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
),
'tesztuser2:tesztuser2' => array(
'eduPersonPrincipalName' => array('tesztuser2@example.com'),
'uid' => array('tesztuser2'),
'cn' => "Nemecsek Ernő 2",
'sn' => "Nemecsek",
'givenName' => "Ernő",
'mail' => "devnull@example.com",
'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
'schacDateOfBirth' => "19751221",
'schacPlaceOfBirth' => "Budapest",
'niifPersonMothersName' => "Törőcsik Mari",
'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
),
),
);
Shibenv-JSP
Eredeti forrás: http://shib.kuleuven.be/download/sp/test_scripts/shibenv.jsp.txt
<html>
<head>
<title>Shibboleth Attributes - <% out.println( request.getHeader("host") ); %></title>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<script language="JavaScript" type="text/JavaScript">
<!--
function decodeAttributeResponse() {
var textarea = document.getElementById("attributeResponseArea");
var base64str = textarea.value;
var decodedMessage = decode64(base64str);
textarea.value = tidyXml(decodedMessage);
textarea.rows = 15;
document.getElementById("decodeButtonBlock").style.display='none';
}
function tidyXml(xmlMessage) {
//put newline before closing tags of values inside xml blocks
xmlMessage = xmlMessage.replace(/([^>])</g,"$1\n<");
//put newline after every tag
xmlMessage = xmlMessage.replace(/>/g,">\n");
var xmlMessageArray = xmlMessage.split("\n");
xmlMessage="";
var nestedLevel=0;
for (var n=0; n < xmlMessageArray.length; n++) {
if ( xmlMessageArray[n].search(/<\//) > -1 ) {
nestedLevel--;
}
for (i=0; i<nestedLevel; i++) {
xmlMessage+=" ";
}
xmlMessage+=xmlMessageArray[n]+"\n";
if ( xmlMessageArray[n].search(/\/>/) > -1 ) {
//level status the same
}
else if ( ( xmlMessageArray[< 0 ) && (xmlMessageArray[n](n].search(/<\//)).search(/</) > -1) ) {
//only increment if this was a tag, not if it is a value
nestedLevel++;
}
}
return xmlMessage;
}
var base64Key = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
function decode64(encodedString) {
var decodedMessage = "";
var char1, char2, char3;
var enc1, enc2, enc3, enc4;
var i = 0;
//remove all characters that are not A-Z, a-z, 0-9, +, /, or =
encodedString = encodedString.replace(/[^A-Za-z0-9\+\/\=]/g, "");
do {
enc1 = base64Key.indexOf(encodedString.charAt(i++));
enc2 = base64Key.indexOf(encodedString.charAt(i++));
enc3 = base64Key.indexOf(encodedString.charAt(i++));
enc4 = base64Key.indexOf(encodedString.charAt(i++));
char1 = (enc1 << 2) | (enc2 >> 4);
char2 = ((enc2 & 15) << 4) | (enc3 >> 2);
char3 = ((enc3 & 3) << 6) | enc4;
decodedMessage = decodedMessage + String.fromCharCode(char1);
if (enc3 != 64) {
decodedMessage = decodedMessage + String.fromCharCode(char2);
}
if (enc4 != 64) {
decodedMessage = decodedMessage + String.fromCharCode(char3);
}
} while (i < encodedString.length);
return decodedMessage;
}
// -->
</script>
</head>
<body>
<u><b>-all SHIB headers-</b></u> (`HTTP_SHIB_ATTRIBUTES` and `Shib-Attributes` are not shown in this list)<br/>
<table>
<%
java.util.Enumeration eHeaders = request.getHeaderNames();
while(eHeaders.hasMoreElements()) {
String name = (String) eHeaders.nextElement();
if ( ( name.matches(".*Shib.*") || name.matches(".*shib.*") ) && !name.equals("HTTP_SHIB_ATTRIBUTES") && !name.equals("Shib-Attributes")) {
Object object = request.getHeader(name);
String value = object.toString();
out.println("<tr><td>" + name + "</td><td>" + value+"</td></tr>");
}
}
%>
</table>
<br/>
attribute response from the IdP (`Shib-Attributes` or `HTTP_SHIB_ATTRIBUTES`):<br/>
<textarea id="attributeResponseArea" onclick="select()" rows="1" cols="130"><%
String attributesString=null;
if ( request.getHeader("Shib-Attributes")!=null ) attributesString=request.getHeader("Shib-Attributes");
else if ( request.getHeader("HTTP_SHIB_ATTRIBUTES")!=null ) attributesString=request.getHeader("HTTP_SHIB_ATTRIBUTES");
out.println( attributesString );
%></textarea><br/>
<span id="decodeButtonBlock">
<input type="button" id="decodeButton" value="decode base64 encoded attribute response using JavaScript"
onClick="decodeAttributeResponse();"><br/></span>
<br/>
<hr/>
<br/>
<%
out.print("request.getRemoteUser: "+request.getRemoteUser()+"<br/>");
out.print("REMOTE_USER: "+request.getHeader("REMOTE_USER")+"<br/>" );
out.print("HTTP_REMOTE_USER: "+request.getHeader("HTTP_REMOTE_USER")+"<br/>" );
%>
<br/>
<hr/>
<br/>
<u>REQUEST PARAMETERS (GET/POST)</u><br/>
<table>
<%
java.util.Enumeration eParameters = request.getParameterNames();
while(eParameters.hasMoreElements()) {
String name = (String) eParameters.nextElement();
Object object = request.getParameter(name);
String value = object.toString();
out.println("<tr><td>" + name + "</td><td>" + value+"</td></tr>");
}
%>
</table>
<br/>
<hr/>
<br/>
<u>ALL HEADERS</u><br/>
<table>
<%
// already initiated at top of script
// java.util.Enumeration eHeaders = request.getHeaderNames();
// reset to beginning of Enumeration
eHeaders = request.getHeaderNames();
while( eHeaders.hasMoreElements() ) {
String name = (String) eHeaders.nextElement();
Object object = request.getHeader(name);
String value = object.toString();
out.println("<tr><td>" + name + "</td><td>" + value+"</td></tr>");
}
%>
</table>
<br/>
<hr/>
<br/>
<u>SESSION</u><br/>
<table>
<%
out.println("SESSION_ID: "+session.getId()+"<br/>");
java.util.Enumeration eSession = session.getAttributeNames() ;
while(eSession.hasMoreElements()) {
String name = (String) eSession.nextElement();
Object object = session.getAttribute(name);
String value = object.toString();
out.println("<tr><td>" + name + "</td><td>" + value+"</td></tr>");
}
%>
</table>
<br/>
<hr/>
<br/>
</body>
</html>
MetadataTrust
Ez a szócikk a Metadata bizalmi kérdéseivel foglalkozik. A föderációk üzemeltetéhez hozzátartozik a föderációs metadata állomány karbantartása is. A föderációban való bizalom technikai értelemben megegyezik a metadatába vetett bizalommal, így ezen bizalom fenntartása rendkívül fontos.
További információkkal szolgál a Trust Management oldal a Shibboleth wikin.
Központi metadata bizalmi modellek
Alapvetően kétféle módon lehet biztosítani a metadata hitelességét:
- aláírás + lejárati idő
- hiteles helyről letöltés (SSL/TLS) + gyorstárazási idő
Előbbi módszer esetén a szállítási protokoll biztonsága nem szükséges (tehát a metadata nem hiteles helyről is beszerezhető - pl. http, email, ...), a digitális aláírás ellenőrzésével a hitelesség megállapítható.
A lejárati idő - validUntil
ebben az esetben kulcsfontosságú, hiszen egy lejárati idő nélküli metadatát nem lehetséges visszavonni (egy rosszindulatú támadó egy régi metadata példányt később bármikor felhasználhat), így az esetleg kompromittált entitások az egész föderáció biztonságát veszélyeztethetik.
Utóbbi módszer használata esetén a föderációs entitások kötelesek a metadatát egy központi helyről, biztonságos csatornán (pl. https megfelelő tanúsítvány-ellenőrzéssel) adott időközönként letölteni. Ezt a frissítési időközt határozza meg a gyorstárazási idő, a cacheDuration
.
Metadata bizalom a HREF Föderációban
A HREF Föderációban a metadata biztonságát digitális aláírás és 72 órás lejárati idő együttes alkalmazása biztosítja. A metadata óránként generálódik a Resource_Registry-ben, és aláírásra kerül a metadata aláíró kulccsal.
Aláírás ellenőrzése az aláíró kulcs tanúsítványának segítségével
Az aláírás ellenőrizhető a metadata aláíró kulcs tanúsítványányának segítségével, mely elérhető a https://metadata.eduid.hu/href-metadata-signer-2011.crt címről.
Shibboleth IdP illetve SP használata esetén a metadata állomány ellenőrzésére az ún. MetadataFilter használatos, mely az aláírást ellenőrzi a tanúsítvány segítségével.
Shibboleth 2 IdP esetén
Metadata provider beállítása:
<MetadataProvider id="href" xsi:type="FileBackedHTTPMetadataProvider"
xmlns="urn:mace:shibboleth:2.0:metadata"
metadataURL="http://rr.aai.niif.hu/metadata/href-metadata.xml"
backingFile="/path/to/metadata/href-metadata.xml" >
<MetadataFilter xsi:type="ChainingFilter">
<MetadataFilter xsi:type="RequiredValidUntil"
maxValidityInterval="604800" />
<MetadataFilter xsi:type="SignatureValidation"
trustEngineRef="shibboleth.MetadataTrustEngine"
requireSignedMetadata="true" />
</MetadataFilter>
</MetadataProvider>
Illetve a hozzá tartozó TrustEngine
konfiguráció:
<!-- Trust engine used to evaluate the signature on loaded metadata. -->
<security:TrustEngine id="shibboleth.MetadataTrustEngine"
xsi:type="security:StaticExplicitKeySignature">
<security:Credential id="MyFederation1Credentials" xsi:type="security:X509Filesystem">
<security:Certificate>/path/to/href-metadata-signer-2011.crt</security:Certificate>
</security:Credential>
</security:TrustEngine>
Shibboleth 2 SP esetén
<MetadataProvider type="XML"
url="http://metadata.eduid.hu/current/href.xmll"
backingFilePath="href.xml">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="604800"/>
<MetadataFilter type="Signature" certificate="href-metadata-signer-2011.crt"/>
</MetadataProvider>
SimpleSAMLphp esetén
SimpleSAMLphp használata esetén a metarefresh modul használható a metadata időzített letöltésére és ellenőrzésére. Ezzel kapcsolatban további információkat tartalmaz a SimpleSAMLphp HREF integráció fejezet.
Az aláíró kulcs visszavonása
A fent leírt modell egyetlen problémája az aláíró kulcs kezelésében rejlik. Az aláíró kulcs visszavonása ugyanis csak a rendszeren kívül történhet, egy új kulcs bevezetéséhez az összes partner rendszerében meg kell változtatni az ellenőrzést. Sőt, az átmeneti időben mindkét kulcs használata szükséges lehet (két különböző metadatán).
Amennyiben az aláíró kulcs kompromittálódik, az azonnali visszavonása és egy új kulcs használata esetén azok a rendszerek, melyek még a régi tanúsítványt használták, a metadata lejárati idő letelte után működésképtelenné válnak.
CA használata
Ezen problémák kiküszöbölhetőek egy CA használatával. Ekkor ugyanis az aláíró kulcs tanúsítványát a CA aláírhatja, a partnerek pedig magát a CA tanúsítványt jelölhetik megbízhatónak.
A metadata aláírásakor ebben az esetben nem elég csak az aláíró tanúsítványt beágyazni (Signature/KeyInfo/X509Certificate
elembe), hanem a CA tanúsítványát is el kell helyezni az aláírt metadatába.
Tanúsítvány visszavonása
CA használata esetén a tanúsítvány visszavonási listák (CRL) illetve on-line ellenőrzés (OCSP) is alkalmazható az aláíró tanúsítvány érvényességének megállapítására. Ezen kívül - mivel magát a tanúsítványt nem kell külön csatornán eljuttatni a partnerekhez -, alkalmazhatóak rövidebb lejáratú (pár hónap, maximum egy év) tanúsítványok is.
Hitelesség ellenőrzése
A metadata aláírásának ellenőrzése ebben az esetben a beágyazott tanúsítvánnyal történik, az aláírás hitelesítése után pedig megtörténik a megfelelő, megbízhatónak jelölt CA-ra történő PKI ellenőrzés.
Shibboleth IdP esetén
A fenti IdP konfigurációs példában a TrustEngine
konfigurációt kell megváltoztatni, hogy PKIX validációt végezzen. Fontos, hogy a CRL fájl folyamatosan frissítésre kerüljön, ugyanis a Shibboleth nem ad lehetőséget ezen fájl távoli elérésére.
<security:TrustEngine xsi:type="security:StaticPKIXSignature"
id="shibboleth.MetadataTrustEngine">
<ValidationInfo xsi:type="PKIXFilesystem" xmlns="urn:mace:shibboleth:2.0:security"
id="HREFCA" VerifyDepth="1" >
<Certificate>/path/to/trusted/ca-cert.pem</Certificate>
<CRL>/path/to/trusted/ca-crl.pem</CRL>
</ValidationInfo>
</security:TrustEngine>
!!! danger "Figyelem"
A fenti konfigurációs kódrészlet nem alkalmazható a CRL rendszeres, időzített letöltése és előzetes tesztelés nélkül!
Shibboleth SP esetén
A fenti Shibboleth SP példában a SignatureMetadataFilter
-t kell módosítani az alábbiak szerint
<SignatureMetadataFilter verifyName="false">
<TrustEngine type="StaticPKIX">
<CredentialResolver type="File">
<Certificate>
<Path>ca-cert.pem</Path>
</Certificate>
<CRL>
<Path>ca-crl.pem</Path>
</CRL>
</CredentialResolver>
</TrustEngine>
</SignatureMetadataFilter>
Az újabb Shibboleth SP verziókban lehetőség van a CRL URL-ről történő letöltésére is, ezzel kapcsolatban további információk.
!!! danger "Figyelem"
A fenti konfigurációs kódrészlet nem alkalmazható előzetes tesztelés nélkül!
SimpleSAMLphp esetén
!!! warning "A szócikk vagy fejezet még megírásra vár"
Külön eszközzel
Az NIIF által fejlesztett metadata aláíró/ellenőrző eszköz támogatja a CA tanúsítványok használatát és a PKI validációt (MDSigner forrás).
Shib2IdpCluster
Shibboleth 2.1 IdP klaszterezése
Klaszter terminológia
Node
- egy, a szolgáltatást futtató csomópont
Klaszter
- kívülről nem megkülönböztethető nodeok összessége
Szerver
- fizikai (vagy virtuális) gép, amely a nodeokat futtatja (egy gépen lehet több node is)
Failover
- amennyiben egy csomópont kiesik, egy másik csomópont automatikusan és transzparensen átveszi a munkáját
High availability
- amennyiben egy csomópont kiesik, nem veszhet el adat, a kliensek nem veszik észre a kiesést
Load balancing
- a terhelés elosztása az egyes csomópontok között
Terracotta
A Shibboleth2 IdP a Terracotta szoftvert támogatja a klaszter építéséhez. A Terracotta képes arra, hogy a különböző nodeokon futó Shibboleth IdP-k között a session és egyéb információkat (például artifact map, authnrequest replay map, stb.) szinkronban tartsa.
A Terracotta kliens-szerver architektúrában működik. A kliensek a JVM-ben futó instrumentált osztályokból, osztálybetöltőből és zármenedzserből állnak, a szerverek pedig biztosítják a klaszterezett adatok perzisztens tárolását és a csomópont-független elérést. Amennyiben egy JVM-ben szükség van egy távoli JVM-ben létrehozott klaszterezett objektumra, akkor ezt az első elérésnél a Terracotta kliens elkéri a távoli szervertől. Emiatt teljesítmény okokból érdemes az azonos felhasználóhoz tartozó kéréseket mindig ugyanahhoz a csomóponthoz küldeni. A HTTP-Artifact profil használata esetén ez nem garantálható, ezért ajánlott a HTTP-Post profil használata.
Shibboleth IdP és Terracotta
A Shibboleth IdP-ben a következő adatok klaszterezését kell megvalósítani: artifact, session, replay, transientId, loginContext. Ezeket az adatokat a Shibboleth StorageService tárolja.
A Terracotta telepítéséhez és beállításához ez a wikioldal nyújt segítséget.
- Terracotta letöltése, kicsomagolása
- tűzfalbeállítások (TCP/9510 kliens->szerver és TCP/9530 szerver->szerver portok engedélyezése)
- minden csomóponton azonos JVM verziót használjunk a Terracotta szerverben és kliensben is
- tim-vector integrációs modul telepítése
- Shibboleth IdP-hez Terracotta konfiguráció szerkesztése [[Shib2IdpTerracottaConfiguration]] alapján
- csomópontok definiálása (szervernév, hosztnév, logok helye)
- terracotta szerver futtatása
- boot jar készítése (Terracotta kliens)
- boot jar használata a webkonténer JVM-nél
- FONTOS: JVM frissítés után újra kell generálni a boot jart!
JVM beállítások:
JAVA_OPTS="-Dtc.install-root=$TC_INSTALL_DIR \
-Dtc.config=$SHIB_IDP_HOME/conf/tc-config.xml \
-Xbootclasspath/p:$TC_INSTALL_DIR/lib/dso-boot/dso-boot-hotspot_$jvm_spec_ver.jar"
2.1.2 -es IdP verzióhoz a következő konfigurációs rész is szükséges az instrumented-classes szekcióba:
<include>
<class-expression>org.opensaml.xml.util.LazyList</class-expression>
<honor-transient>true</honor-transient>
</include>
A Terracotta log- és adatfájljainak /var alatti tárolását a következőképpen végezhetjük el:
Könyvtárak létrehozása megfelelő jogosultságokkal
mkdir /var/{lib,log}/terracotta/{client,server}
chown tomcat55.nogroup /var/{lib,log}/terracotta/client
chown nobody.nogroup /var/{lib,log}/terracotta/server
Terracotta tc-config.xml -ben a data,stats,logs opciók átírása értelem szerint.
Magas rendelkezésre állás beálítása
A következő konfigurációs részt a tc-config.xml elején kell elhelyezni. Ez engedélyezi a kliens-szerver és szerver-szerver újrakapcsolódást, ezzel kivédve az apró hálózati kimaradások okozta problémákat. Sajnos mindkét beállítás megnöveli a failover idejét.
<tc-properties>
<!-- server-to-server reconnect -->
<property name="l2.nha.tcgroupcomm.reconnect.enabled" value="true" />
<property name="l2.nha.tcgroupcomm.reconnect.timeout" value="15000" />
<!-- client-to-server reconnect -->
<property name="l2.l1reconnect.enabled" value="true" />
<property name="l2.l1reconnect.timeout.millis" value="15000" />
</tc-properties>
Debian initszkript a Terracotta szerver indításához
- /etc/init.d/terracotta néven mentsük el root tulajdonossal a következő szkriptet, majd adjunk rá execute jogot:
#!/bin/sh
TC_USER=nobody
TC_GROUP=nogroup
PIDFILE=/var/run/terracotta.pid
if [`id -u` -ne 0 ](); then
echo "You need root privileges to run this script"
exit 1
fi
if [-f /etc/default/terracotta ](); then
. /etc/default/terracotta
fi
if [-z "$TC_INSTALL_DIR" -o ! -d "$TC_INSTALL_DIR" ](); then
echo "No TC_INSTALL_DIR specified or invalid TC_INSTALL_DIR"
exit 1
fi
if [-z "$TC_CONFIG_PATH" -o ! -f "$TC_CONFIG_PATH" ](); then
echo "No TC_CONFIG_PATH specified or invalid TC_CONFIG_PATH"
exit 1
fi
if [-z "$NODENAME" ](); then
echo "No NODENAME specified"
exit 1
fi
export JAVA_HOME
JAVA_OPTS="-server -Xms512m -Xmx512m -XX:+HeapDumpOnOutOfMemoryError $JAVA_OPTS"
TC_START_OPTS="$JAVA_OPTS \
-Dcom.sun.management.jmxremote \
-Dtc.install-root=$TC_INSTALL_DIR \
-cp $TC_INSTALL_DIR/lib/tc.jar \
com.tc.server.TCServerMain -n $NODENAME -f $TC_CONFIG_PATH"
TC_STOP_OPTS="-Dtc.install-root=$TC_INSTALL_DIR \
-cp $TC_INSTALL_DIR/lib/tc.jar \
com.tc.admin.TCStop -n $NODENAME"
. /lib/lsb/init-functions
. /etc/default/rcS
check_stopped () {
return `/sbin/start-stop-daemon --test --start --pidfile "$PIDFILE" \
--user $TC_USER --startas "$JAVA_HOME/bin/java" \
>/dev/null`
}
start () {
log_daemon_msg "Starting Terracotta server node ($NODENAME)..."
if check_stopped; then
/sbin/start-stop-daemon -S -v --make-pid --pidfile "$PIDFILE" \
--chuid $TC_USER:$TC_GROUP --background \
--exec $JAVA_HOME/bin/java -- $TC_START_OPTS
else
log_progress_msg "(already running)"
fi
log_end_msg 0
}
stop () {
log_daemon_msg "Stopping Terracotta server node ($NODENAME)..."
if $JAVA_HOME/bin/java $TC_STOP_OPTS; then
log_progress_msg "(shutdown command sent)"
else
log_progress_msg "(could not send shutdown command)"
fi
sleep 5
if check_stopped; then
log_progress_msg "(cleaning persistent store)"
rm -r /var/lib/terracotta/server/*
log_end_msg 0
else
log_progress_msg "(stopping in progress)"
fi
}
force_stop () {
log_daemon_msg "Killing Terracotta server node ($NODENAME)..."
/sbin/start-stop-daemon -K --pidfile $PIDFILE -x $JAVA_HOME/bin/java
}
case "$1" in
start)
start
;;
stop)
stop
;;
force-stop)
force_stop
;;
restart)
stop
sleep 10
start
;;
*)
echo "Usage terracotta start|stop|force-stop|restart"
exit 1;;
esac
exit $?
- A konfiguráció az /etc/default/terracotta fájlban található:
NODENAME=terracotta-node-name
TC_CONFIG_PATH=/path/to/shibboleth-idp/conf/tc-config.xml
JAVA_HOME=/path/to/jvm
TC_INSTALL_DIR=/path/to/terracotta
Monitoring (JMX, Munin, Nagios)
- JMX: Java Management Extensions
- A Terracotta támogatja a JMX-en keresztüli monitorozást és bevatkozást
- alapértelmezésképp jmxmp protokollon keresztül
- másoljuk be a jmxremote_optional.jar -t a terracotta lib/ könyvtárából egy üres könyvtárba
- indítsuk a jconsole-t a következő paranccsal: jconsole -J-Djava.endorsed.dirs=.
- kapcsolódjunk a
service:jmx:jmxmp://<tc-szerver-node>:9520
url-re
- usernév/jelszavas authentikáció esetén rmi protokollon keresztül is elérhetjük a tc szervert
- alapértelmezésképp jmxmp protokollon keresztül
- Check_jmx szkriptek nagioshoz és muninhoz
Fontosabb Terracotta MBean attribútumok
- org.terracotta:type=Terracotta Server,name=DSO
- LiveObjectCount (int)
- ClientLiveObjectCount (string)
- org.terracotta.internal:type=DSO Client,name=Client Transactions,subsystem=Transactions,clients=Clients,node=...
- AvgModifiedObjectsPerTransaction (int)
- AvgNewObjectsPerTransaction (int)
- ObjectCreationRateBySecond (int)
- ReadTransactionCount (int)
- WriteTransactionCount (int)
- org.terracotta.internal:type=Terracotta Server,name=Terracotta
Server
* Active (bool)
* PassiveStandby (bool)
* PassiveUninitialized (bool)
* HealthStatus (String)
* State (string)
* StartTime (timestamp)
* Shutdownable (bool)
Nagios Terracotta szerver check
#!/bin/sh
TERRACOTTA_SERVER_NODES="papigw.aai.niif.hu sandbox.aai.niif.hu"
TERRACOTTA_CLIENT_COUNT=2
TERRACOTTA_SERVER_COUNT=2
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
TC_HOME=/usr/local/terracotta-2.7.2
TC_MONITORING=/home/hege/terracotta/terracotta-monitoring/terracotta_monitoring.jar
ACTIVE_NODES=""
STANDBY_NODES=""
CLUSTER_STATUS=""
function check_health() {
TC_HEALTH=`echo "$1" | awk "/$2.health/{print "'$2}'`
if [ "x$TC_HEALTH" = "xOK" ]; then
return 0
else
echo TERRACOTTA CRITICAL - node $2 down
exit 2
fi
}
function check_active_count() {
ACTIVE_NODES=`echo "$1" | awk '/ACTIVE-COORDINATOR/{print $1}' | sed 's/\.state://'
ACTIVE_COUNT=`echo "$1" | awk 'BEGIN {cnt=0} /ACTIVE-COORDINATOR/{cnt++} END {print cnt}'`
CLUSTER_STATUS="$CLUSTER_STATUS, active nodes: $ACTIVE_NODES"
if [ "0$ACTIVE_COUNT" -eq 1 ]; then
return 0
else if [ "0$ACTIVE_COUNT" -gt 1 ]; then
echo TERRACOTTA CRITICAL - multiple ACTIVE nodes $CLUSTER_STATUS
else
echo TERRACOTTA_CRITICAL - no ACTIVE nodes $CLUSTER_STATUS
fi
exit 2
fi
}
function check_standby_count() {
STANDBY_NODES=`echo "$1" | awk '/PASSIVE-STANDBY/{print $1}' | sed 's/\.state://'`
STANDBY_COUNT=`echo "$1" | awk 'BEGIN {cnt=0} /PASSIVE-STANDBY/{cnt++} END {print cnt}'`
CLUSTER_STATUS="$CLUSTER_STATUS, standby nodes: $STANDBY_NODES"
if [ "0$STANDBY_COUNT" -eq $(($TERRACOTTA_SERVER_COUNT-1)) ]; then
return 0
else
echo TERRACOTTA CRITICAL - not enough STANDBY node $CLUSTER_STATUS
exit 2
fi
}
function check_client_count() {
CLIENTCOUNT=`echo "$1" | awk '/clientcount/{print $2}'`
CLIENT_NODES=`echo "$1" | awk '/client.*address/{print $2}'`
CLUSTER_STATUS="$CLUSTER_STATUS, client nodes: $CLIENT_NODES"
if [ "0$CLIENTCOUNT" -eq $TERRACOTTA_CLIENT_COUNT ]; then
return 0
else
echo TERRACOTTA WARNING - client count is $CLIENTCOUNT $CLUSTER_STATUS
exit 1
fi
}
OUTPUT=`$JAVA_HOME/bin/java -jar $TC_MONITORING $TERRACOTTA_SERVER_NODES 2>/dev/null`
check_active_count "$OUTPUT"
for i in $TERRACOTTA_SERVER_NODES; do
check_health "$OUTPUT" "$i"
done
check_standby_count "$OUTPUT"
check_client_count "$OUTPUT"
echo TERRACOTTA OK - cluster is running $CLUSTER_STATUS
if [ "0$1" == "0--verbose" -o "0$1" == "0-v" ]; then
echo -e "\n\n$OUTPUT"
fi
Munin plugin a terracotta szerver memóriahasználatának méréséhez
A check_jmx csomagban található jmx_ munin plugin mellé másoljuk oda a jmxremote_optional csomagot (sun.com-ról letölthető), majd végezzük el a következő módosítást:
JMXQUERY="java -cp $RDIR/jmxquery.jar:$RDIR/jmxremote_optional-1.0.1_04-b58.jar \
org.munin.JMXQuery $SERVICE $RDIR/$CONFIGNAME"
Ezután a következő konfigurációt hozzuk létre terracotta_objectcount.conf néven:
graph_title Terracotta clustered object count
graph_category Terracotta
graph_order terracotta_objectcount
terracotta_objectcount.label cluster object count
terracotta_objectcount.jmxObjectName org.terracotta:type=Terracotta Server,name=DSO
terracotta_objectcount.jmxAttributeName LiveObjectCount
Majd symlinkeljük be a jmx_ szkriptet a munin pluginok közé jmx_terracotta_objectcount néven, és adjuk meg a munin-node.conf -ban a jmx hozzáférési paramétereket:
[jmx_*]
env.jmxurl service:jmx:jmxmp://localhost:9520
Tomcat monitorozása muninnal
A Tomcat JVM JMX elérésének engedélyezéséhez az /etc/default/tomcat5.5 fájlban a következő plusz kapcsolókat kell megadni:
CATALINA_OPTS="${CATALINA_OPTS} \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=8083 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false"
Ezután a 8083 -as porton jmxrmi protokollon keresztül lehet elérni a menedzsment ágenst. A check_jmx pluginhoz a következő környezeti beállítást kell hozzárendelni az /etc/munin/plugin-conf.d/munin-node fájlban:
[jmx_catalina_*]
env.jmxurl service:jmx:rmi:///jndi/rmi://localhost:8083/jmxrmi
Terracotta 2.7.3 ismert hibák
Log file flood
Az L2 újracsatlakozás engedélyezése esetén egy elvesztett kapcsolat után hiába áll helyre a helyes működés, a szerver szemetel a logba:
2009-06-24 14:48:38,304 [ConnectionEstablisher] WARN com.tc.net.protocol.transport.ClientMessageTransport -
ConnectionID(0.0e84473d1e744f4db1d539db88633a30): Timeout of 10000 milliseconds occured
2009-06-24 14:48:39,305 [ConnectionEstablisher] INFO com.tc.net.protocol.transport.ClientMessageTransport -
ConnectionID(0.0e84473d1e744f4db1d539db88633a30): Attaching new connection: [...]
Ez egy ismert probléma: http://jira.terracotta.org/jira/browse/CDV-1252 a javítás elkészült, azonban a 2.7.3 -ba még nem került be.
Workaround-ként ki lehet kapcsolni az l2 újracsatlakozást a konfigurációban. Ilyenkor azonban rövid hálózati megszakadás is teljes node újraindítást fog okozni.
Terracotta 3.2.1 ismert hibák
Még nincs :)
Troubleshooting
- Mindig ellenőrizni kell a logfájlokat! Ha egy szerver folyton írja a logfájlját, az általában rossz jel és elárvult kliensre utal ("Could not find communication stack..." üzenet).
- A teljes klaszter újraindítása után kötelező újraindítani a klienseket (Tomcat), ugyanis a Terracotta nem fogja engedni újra csatlakozni. Ezt egyébként a szerver logfájlban jelzi is.
- Nem érdemes egyszerre indítani a két Terracotta szervert, annak könnyen összeakadás lehet a vége, ha nem tudnak dönteni egymás között.
- ilyenkor az egyik szerver felszólítja a másik szervert a megállásra, ilyenkor azonban a diszken tárolt állapot megmarad, amit egy start parancs kiadása után nem hajlandó felhasználni a szerver processz.
- a megoldás az initszkript 'restart' parancsa (vagy két egymás utáni start, ugyanis második kísérletre már hajlandó elindulni 'dirty' adatokkal is).
- Az
/etc/nagios/check_terracotta --verbose
parancs a teljes klaszter állapotát visszaadja (szerverek és kliensek is). - Ha egy probléma nem oldható meg csak az egyik szerver és a kliensek újraindításával, akkor a teljes klasztert újra kell indítani: mindkét szerver leállítása és a perzisztens adatok gondos törlése után egyesével újraindíthatóak a szerverek majd az aktív szerver indulása után a kliensek (Tomcat).
Kliens library
- a Tomcat webkonténerben fut
- a
/var/log/terracotta/client/log*/terracotta-client.log
fájlba logol - JVM váltáskor, frissítéskor újra kell generálni! Ezt a
/usr/local/terracotta/bin/make-boot-jar.sh
szkripttel lehet megtenni, előtte törölni kell a/usr/local/terracotta/lib/dso-boot
könyvtár tartalmát.
Szerver processz
- külön processzként fut
- a
/var/log/terracotta/server/log*/terracotta-server.log
fájlba logol - a
/var/lib/terracotta/server/
könyvtárban tárol saját adatokat, amit kézzel történő tiszta újraindítás előtt törölni kell
Nagios riasztások és megoldásuk
-
Túl kevés a kliens (client count is xxx)
- OK: a Tomcat kliens megállt vagy megszakadt a kommunikáció a szerverrel.
- Megoldás: a kliens listában nem szereplő Tomcat-et újra kell indítani.
-
Nincs passzív node (not enough passive node)
- OK: az egyik Terracotta szerver épp adatot szinkronizál a másiktól és ezért
passive-uninitialized
állapotban van. - Megoldás: pár percet érdemes várni, amíg a szinkronizáció befejeződik. Ha nem oldódik meg a probléma magától, akkor újra kell indítani a Terracotta szerver processzt.
- OK: az egyik Terracotta szerver épp adatot szinkronizál a másiktól és ezért
-
Nem elérhető egy node (node xxx is down)
- OK: az egyik Terracotta szerver nem elérhető.
- Megoldás: újra kell indítani.
Adminisztrációs feladatok
JVM frissítése
A következő leírás meglehetősen az NIIF Intézet saját infrastruktúrájára specifikus, de talán más környezetekben is felhasználható.
Lépések összefoglalása
- Terheléselosztóból a frissítendő node-ot kivenni
- Tomcat, Terracotta leállítása a frissítendő node-on
- JVM beállítások (
/etc/java-6-openjdk/security
, ill. esetleg/usr/lib/jvm/java-6-openjdk/jre/lib/security
) elmentése. Ez fontos azért, mert bizonyos JVM upgrade-ek (legalábbis a múltban) felülírták a tanúsítvány tárat, és ez nehezen javítható hibához vezetett (pl. az LDAP-hoz nem tudott kapcsolódni az IdP) - JVM frissítés
- Boot jar generálás
- (Ha megváltozott a jar): Tomcat konfigban a boot jar átírása az újra
- Ellenőrzés, hogy megváltozott-e a cacerts ($JAVA_HOME/lib/security/cacerts). Ha igen, akkor írjuk felül az elmentett változattal
- Terracotta, majd utána Tomcat indítás
- (Az LVS magától visszateszi a megjavuló klaszter node-ot, de erről nem árt meggyőződni)
Shell parancsok
ldir2:~# ipvsadm -d -t idp.niif.hu:8443 -r idp1.aai.niif.hu:8443
ldir2:~# ipvsadm -d -t idp.niif.hu:https -r idp1.aai.niif.hu:https
ldir2:~# watch "ipvsadm -L -t idp.niif.hu:https && ipvsadm -L -t idp.niif.hu:8443"
idp1:~$ sudo /etc/init.d/tomcat6 stop
idp1:~$ sudo /etc/init.d/terracotta stop
idp1:~$ tar czf security.tgz /etc/java-6-openjdk/security
idp1:~$ sudo aptitude safe-upgrade
idp1:~$ sudo env JAVA_HOME=/usr/lib/jvm/java-6-openjdk /usr/local/terracotta/platform/bin/make-boot-jar.sh \
-f /etc/shibboleth-idp/tc-config.xml
idp1:~$ sudo vim /etc/default/tomcat6
idp1:~$ sudo /etc/init.d/terracotta start
idp1:~$ sudo /etc/init.d/tomcat6 start
Shib2IdpTerracottaConfiguration
Shibboleth 2 Terracotta konfiguráció
Shibboleth 2.1.2 IdP -hez
<?xml version="1.0" encoding="UTF-8"?>
<tc:tc-config xmlns:tc="http://www.terracotta.org/config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.terracotta.org/config http://www.terracotta.org/schema/terracotta-4.xsd">
<!--
Terracotta configuration file for Shibboleth.
Complete documentation on the contents of this file may be found here:
http://terracotta.org/web/display/docs/Configuration+Guide+and+Reference
-->
<tc-properties>
<!-- server-to-server reconnect -->
<property name="l2.nha.tcgroupcomm.reconnect.enabled" value="true" />
<property name="l2.nha.tcgroupcomm.reconnect.timeout" value="15000" />
<!-- client-to-server reconnect -->
<property name="l2.l1reconnect.enabled" value="true"/>
<property name="l2.l1reconnect.timeout.millis" value="15000" />
</tc-properties>
<servers>
<!-- START Terracotta server definitions -->
<server name="idp1" host="idp1.aai.niif.hu">
<dso>
<persistence>
<mode>permanent-store</mode>
</persistence>
</dso>
<logs>/var/log/terracotta/server/logs</logs>
<data>/var/lib/terracotta/server/data</data>
<statistics>/var/lib/terracotta/server/stats</statistics>
</server>
<server name="idp2" host="idp2.aai.niif.hu">
<dso>
<persistence>
<mode>permanent-store</mode>
</persistence>
</dso>
<logs>/var/log/terracotta/server/logs</logs>
<data>/var/lib/terracotta/server/data</data>
<statistics>/var/lib/terracotta/server/stats</statistics>
</server>
<!-- END Terracotta server definitions -->
<ha>
<mode>networked-active-passive</mode>
<networked-active-passive>
<election-time></election-time>
</networked-active-passive>
</ha>
</servers>
<system>
<configuration-model>production</configuration-model>
</system>
<clients>
<logs>/var/log/terracotta/client/logs-%i</logs>
<statistics>/var/lib/terracotta/client/stats-%i</statistics>
<modules>
<module name="tim-vector" version="2.3.1" group-id="org.terracotta.modules"/>
</modules>
</clients>
<application>
<dso>
<additional-boot-jar-classes>
<include>javax.security.auth.Subject</include>
<include>javax.security.auth.Subject$SecureSet</include>
<include>javax.security.auth.x500.X500Principal</include>
<include>javax.security.auth.kerberos.KerberosPrincipal</include>
</additional-boot-jar-classes>
<roots>
<root>
<root-name>storageService</root-name>
<field-name>edu.internet2.middleware.shibboleth.common.util.EventingMapBasedStorageService.store</field-name>
</root>
</roots>
<instrumented-classes>
<include>
<class-expression>edu.vt.middleware.ldap.jaas.LdapPrincipal</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.authn.UsernamePrincipal</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.vt.middleware.ldap.jaas.LdapCredential</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.authn.AuthenticationException</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>org.opensaml.util.storage.AbstractExpiringObject</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.TransientIdEntry</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.authn.LoginContextEntry</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.authn.LoginContext</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.authn.ShibbolethSSOLoginContext</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.authn.Saml2LoginContext</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.session.impl.AuthenticationMethodInformationImpl</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>org.opensaml.util.storage.ReplayCacheEntry</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.session.impl.SessionManagerEntry</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.common.session.impl.AbstractSession</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.session.impl.SessionImpl</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>edu.internet2.middleware.shibboleth.idp.session.impl.ServiceInformationImpl</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>org.opensaml.common.binding.artifact.BasicSAMLArtifactMapEntry</class-expression>
<honor-transient>true</honor-transient>
</include>
<include>
<class-expression>org.opensaml.xml.util.LazyList</class-expression>
<honor-transient>true</honor-transient>
</include>
</instrumented-classes>
<locks>
<autolock auto-synchronized="false">
<method-expression>* edu.vt.middleware.ldap.jaas.LdapPrincipal.*(..)</method-expression>
<lock-level>write</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.authn.LoginContext.set*(..)</method-expression>
<lock-level>write</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.authn.LoginContext.get*(..)</method-expression>
<lock-level>read</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.authn.ShibbolethSSOLoginContext.set*(..)</method-expression>
<lock-level>write</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.authn.ShibbolethSSOLoginContext.get*(..)</method-expression>
<lock-level>read</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.authn.Saml2LoginContext.set*(..)</method-expression>
<lock-level>write</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.authn.Saml2LoginContext.get*(..)</method-expression>
<lock-level>read</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.common.session.impl.AbstractSession.set*(..)</method-expression>
<lock-level>write</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.common.session.impl.AbstractSession.get*(..)</method-expression>
<lock-level>read</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.SessionImpl.set*(..)</method-expression>
<lock-level>write</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.SessionImpl.get*(..)</method-expression>
<lock-level>read</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.AuthenticationMethodInformationImpl.set*(..)</method-expression>
<lock-level>write</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.AuthenticationMethodInformationImpl.get*(..)</method-expression>
<lock-level>read</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.ServiceInformationImpl.set*(..)</method-expression>
<lock-level>write</lock-level>
</autolock>
<autolock auto-synchronized="false">
<method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.ServiceInformationImpl.get*(..)</method-expression>
<lock-level>read</lock-level>
</autolock>
</locks>
</dso>
</application>
</tc:tc-config>
Shib2IdpARP
Az attribútumok kiadását az IDP_HOME/conf
könyvtárban található attribute-filter.xml
névre hallgató fájlban konfigurálhatjuk.
Attribute-filter alapbeállítások
Ezeket általában nem kell állítgatni, megfelelőek az alapbeállítások
<AttributeFilterPolicyGroup id="ShibbolethFilterPolicy" xmlns="urn:mace:shibboleth:2.0:afp"
xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic" xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:afp classpath:/schema/shibboleth-2.0-afp.xsd
urn:mace:shibboleth:2.0:afp:mf:basic classpath:/schema/shibboleth-2.0-afp-mf-basic.xsd
urn:mace:shibboleth:2.0:afp:mf:saml classpath:/schema/shibboleth-2.0-afp-mf-saml.xsd">
<!-- ... -->
</AttributeFilterPolicyGroup>
Kiadási szabálycsoportok megadása
Egy kiadási szabálycsoportot a <AttributeFilterPolicy>
elemmel definiálhatunk, melynek kötelező aleleme egy <PolicyRequirementRule xsi:type="MATCHING_RULE_TYPE">
elem, amely meghatározza, hogy a szabály mely attribútumok esetén aktivizálódjon. A működése kifejezetten egyszerű, a kiadási szabály akkor lesz aktív, mikor a PolicyRequirementRule
elem attribútumában meghatározott egyezési feltétel igaz értéket ad.
Egy kiadási szabálycsoport (attribute filters) meghatározhatja egy sor attribútum számára, hogy mikor, milyen feltételek teljesülése mellett adhatók ki értékeik.
Egy kiadási szabály megadása
Egy attribútumra vonatkozó szabályt a <AttributeRule>
elemmel határozunk meg, melynek kötelező attrubútuma annak az attribútumnak az azonosítója, melyre a szabályokat vonatkoztatni szeretnénk, és egy elem, amely meghatározza, hogy milyen illeszkedés esetében aktív a szabály.
Példa I.
<AttributeRule attributeID="transientId">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
Egy attribútumra vonatkozó szabályban természetesen további finomításokat megadhatunk.
Példa II.
<AttributeRule attributeID="eduPersonAffiliation">
<PermitValueRule xsi:type="basic:OR">
<Rule xsi:type="basic:AttributeValueString" value="faculty" ignoreCase="true"/>
<Rule xsi:type="basic:AttributeValueString" value="student" ignoreCase="true"/>
<Rule xsi:type="basic:AttributeValueString" value="staff" ignoreCase="true"/>
<Rule xsi:type="basic:AttributeValueString" value="alum" ignoreCase="true"/>
<Rule xsi:type="basic:AttributeValueString" value="member" ignoreCase="true"/>
<Rule xsi:type="basic:AttributeValueString" value="affiliate" ignoreCase="true"/>
<Rule xsi:type="basic:AttributeValueString" value="employee" ignoreCase="true"/>
<Rule xsi:type="basic:AttributeValueString" value="library-walk-in" ignoreCase="true"/>
</PermitValueRule>
</AttributeRule>
Magyarázat: a kiadási szabály, akkor adja ki az eduPersonAffiliation
attribútumot, amennyiben annak értéke egyezik a felsoroltak valamelyikével (OR
szabály - tehát elég, hogy egyikkel egyezzen).
Az alábbi listában található egyezési szabályok alkalmazhatók egy-egy <PermitValueRule>
megadásakor:
- ANY - Always evaluates to true
- AND - Evaluates to true if all contained rules are true
- OR - Evaluated to true if any contained rule is true
- NOT - Evaluates to true if the contained rule evaluates to false
- AttributeRequesterString - Evaluates to true if the attribute requester's entity ID matches a given string
- AttributeIssuerString - Evaluates to true if the attribute issuer's entity ID matches a given string
- PrincipalNameString - Evaluates to true if the user's principal name matches a given string
- AuthenticationMethodString - Evaluates to true if the method used to authenticate the user matches a given string
- AttributeValueString - Evaluates to true if the value of a given attribute matches a given string
- AttributeScopeString - Evaluates to the true if the scope of a value of a given attribute matches a given string
- AttributeRequesterRegex - Evaluates to true if the attribute requester's entity ID matches a given regular expression
- AttributeIssuerRegex - Evaluates to true if the attribute issuer's entity ID matches a given regular expression
- PrincipalNameRegex - Evaluates to true if the user's principal name matches a given regular expression
- AuthenticationMethodRegex - Evaluates to true if the method used to authenticate the user matches a given regular expression
- AttributeValueRegex - Evaluates to true if the value of a given attribute matches a given regular expression
- AttributeScopeRegex - Evaluates to the true if the scope of a value of a given attribute matches a given regular expression
- Script - Evaluates a scriptlet to determine if the rule evaluates to true
- AttributeRequesterInEntityGroup - Evaluates to true if the attribute requester is defined within a given entity group in SAML metadata
- AttributeIssuerInEntityGroup - Evaluates to true if the attribute issuer is defined within a given entity group in SAML metadata
- AttributeScopeMatchesShibMDScope - Evaluates to true the scope of an attribute value matches the scope defined in the attribute issuer's metadata.
ShibIdpSLO
- ÁTIRÁNYÍTÁS Single Logout in Shibboleth IdP
FedDev
Föderáció létrehozásával kapcsolatos lap.
- Föderáció
- Károkozási táblázat
- Döntési táblázat
- Metadata specifikáció
- Attribútum specifikáció
- Föderációs operátor szolgáltatásai
- Naplózás a föderációban
- HREFPolicyStub
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)
- Kivételek előfordulhatnak, például nem kapnak member viszonyt:
- 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
Attribute_Conversion_for_simpleSAMLphp
This page describes the features of Attribute Conversion and Filtering library for simpleSAMLphp
Introduction
eduGAIN uses Bridging Elements for interconnecting federations. To provide attribute translation and filtering services, an attribute 'mangling' library was developed for the Java-based bridging elements. As simpleSAMLphp can also be used as an eduGAIN bridging element, the conversion and filtering library was ported to PHP.
Beyond eduGAIN, you can use this module for every IdP or SP operating mode (shib13 SP/IdP, saml2 SP/IdP) of simpleSAMLphp in order to provide more powerful attribute conversion and filtering capabilities.
Download and support
You can download the module from here. The module is in beta stage, it needs broader community review. It is not yet recommended for production environments.
If you have any questions regarding the module, please write to 'aai aT niif _dOt hu.
For changelogs please visit the project repository.
Compatibility
eduGAIN
This library is intended to be configuration-compatible with the eduGAIN Attribute_Conversion_for_eduGAIN Java library. The module can read the eduGAIN converter and filter engine XML configuration files and should operate the same way as the Java one.
Configuration files
The eduGAIN attribute converter and filter module defines its own XML schema for attribute conversion and attribute filtering purposes. See the Attribute_Conversion_for_eduGAIN page for more information on attribute rules.
Using the module
This module has a working name edugain
. As this module only addresses the attribute translation part of the 'eduGAIN-problem', it might be renamed later.
Enabling the simpleSAMLphp module
This module depends on the xsl php extensions (more specifically, the XSLTProcessor class), so make sure it is properly configured.
The module can be enabled by creating an empty file named modules/edugain/default-enable
.
simpleSAMLphp module configuration
EduGAIN is available for simpleSAMLphp as an authentication processing filter: edugain:Attributes. The Attributes processing filter takes the following configuration properties:
'authproc' => array(
50 => array(
'class' => 'edugain:Attributes',
'mode' => 'idp',
'converterconfig' => '/path/to/AttributeConverter.xml',
'filterconfig' => '/path/to/AttributeFilter.xml',
'cache' => true
)
)
Configuration parameters for the module
- class (required): defines the eduGAIN filter for simpleSAMLphp.
- mode (required): configures the way this module operates (
idp
orsp
). See below for more information on operating modes - converterconfig (optional): configures the path of the attribute converter configuration xml file.
- filterconfig (optional): configures the path of the attribute filter configuration xml file.
- cache (optional, default: true): enables or disables the internal configuration cache. See the Configuration_cache section below for more.
!!! info
If either `converterconfig` or `filterconfig` is omitted, than the relevant part of the module (conversion or filtering respectively) is disabled. Note that **disabling filter means you let all the attributes through**.
Operating modes
EduGAIN module can operate in two modes, idp or sp. This mode affects two behaviors: the conversion-filtering order, and the provider matching.
- in idp mode, attribute filter is run after conversion, and the RemoteProvider match is done against the SP (or R-BE in eduGAIN bridged environment) which initiated the SSO session .
- in sp mode, attribute filter is run before conversion, and the RemoteProvider match is done against the IdP (or H-BE in eduGAIN bridged environment) which released the attributes to our simpleSAMLphp SP.
Configuration file
The simpleSAMLphp eduGAIN module reads the eduGAIN XML configuration format and transforms it into php arrays using XSL transformation. The submodules (edugain:SplitMerge and edugain:Filter) are configured automatically by the edugain:Attributes class.
PHP configuration interface for these filters are not supported at the moment and may be subject to change, so please use the XML configuration.
Configuration cache
The XML reading is very time-consuming but conversion and filtering rules should be evaluated on every request. Because of that, the eduGAIN module can cache the XML configuration into a serialized PHP array, which is stored locally in a directory named cache
. If the XML file is not updated since the last cache file generation then the cache is used and the XML parsing part is skipped. Cache file name is computed according to the following:
md5(full_configuration_file_path).cache.php
!!! info
Enabling the cache is strongly recommended in production environments.
Differences between the Java and the PHP implementations
- There is no CustomRule for attribute conversion. One can use simpleSAMLphp authentication processing filter API to implement arbitrary conversion rules.
- LocalProvider matching is unsupported in simpleSAMLphp. Unfortunately when simpleSAMLphp is in bridging mode (using the SP module to protect an IdP), the IdP processing filters do not see the peer entity of the SP module. However, you can achieve the correct behavior by putting one edugain:Attributes processing filter in the SP configuration and use RemoteProvider matches to filter and convert attributes there.
- You don't need to use a separate attribute name mapper, because simpleSAMLphp contains built-in name2oid,oid2name, name2urn and urn2name methods, which provide the same functionality.
- Regular expressions are somewhat different in PHP. The eduGAIN module uses perl-compatible regular expressions (see preg_match documentation for details).
HREF_alapelvek_és_alapvető_szabályok
Föderációs alapelvek
- A föderáció célja, hogy a felhasználók úgy vehessenek igénybe szolgáltatásokat - amennyiben erre jogosultak -, hogy a saját intézményük azonosítja őket.
- Az IdP csak abban az esetben azonosít egy felhasználót, ha az illető valamilyen - ismert - viszonyban van az intézménnyel.
- Az IdP és az SP nem ad meg magáról hamis, félrevezető információt.
- Az IdP minden tőle telhetőt megtesz annak érdekében, hogy a kiadott információ a lehető legpontosabb legyen. Az SP tisztában van vele, hogy bizonyos információkat a felhasználók maguk is szerkeszthetnek.
- Az IdP gondoskodik róla, hogy a felhasználót azonosító információk (pl. jelszó) védett módon legyenek tárolva, ill. a felhasználók ezt biztonságosan adhassák meg.
- Az SP csak a működéséhez minimálisan szükséges adatmennyiséget (attribútumokat) igényli a felhasználóról.
- Az SP nem kérheti a felhasználót, hogy adja meg az IdP-nél érvényes jelszavát.
- Az SP-nél történő adatkezelés a törvényi előírások szerint működik.
- Felhasználói visszaélések vizsgálatában az IdP és az SP együttműködik egymással.
- Az IdP és az SP az informatikai rendszereit az elvárható gondossággal üzemelteti.
Szabályok
Adatvédelmi szabályok
- A Tag és a Partner biztosítja, hogy a HREF Föderáció működése során közöttük a személyes adatok kezelése a vonatkozó jogszabályoknak megfelelő módon történik. Így a személyes adatok kezelése csak törvényi felhatalmazáson vagy felhasználói önkéntes, határozott és tájékozott hozzájárulásán alapul, amellyel beleegyezését fejezi ki az őt érintő személyes adatok kezelésébe.
- Mind a Tag, mind a Partner rendelkezik a személyes adatok kezelését megfelelően rendező adatkezelési szabályzattal, amely rendelkezik különösen:
- a kezelt személyes adatok köréről;
- az adatkezelés céljáról;
- az adatkezelés időtartamáról;
- az adatalanyokat érintő tiltakozási jog lehetőségéről.
- Mind a Tag, mind a Partner a mindenkor hatályos adatkezelési szabályzatukat elérhetővé teszik.
Üzemeltetési szabályok
- Az üzemeltetéssel kapcsolatos szabályokat, valamint a megkövetelt és ajánlott eljárásokat külön dokumentumok részletezik: en_US IdP üzemeltetési szabályok, SP üzemeltetési szabályok
- A Föderációs Operátor jogosult ellenőrizni a vonatkozó szabályok betartását.
- A Tag és a Partner gondoskodik arról, hogy a metaadatok kezelése a metadata specifikációnak megfelelően történjen, így:
- a Tag a Resource Registry használatával gondoskodik arról, hogy az őt érintő föderációs metaadatok naprakészek legyenek,
- a metaadatokat a specifikációnak megfelelő gyakorisággal frissítik és ellenőrzik.
- A felhasználói attribútumok átadása során az IdP és a SP az attribútum specifikáció előírásait betartják.
Adatkezeléssel kapcsolatos szabályok
- Az Azonosító Szervezet biztosítja, hogy a felhasználó regisztrációs folyamatai dokumentáltak legyenek.
- Csak olyan felhasználó azonosítható, akinek az intézményhez való viszonya egyértelműen megállapítható.
- Adatminőség
- A személyes adat tárolási módjának alkalmasnak kell lennie arra, hogy az érintett felhasználót csak a tárolás céljához szükséges ideig lehessen azonosítani.
- Az adatminőség biztosítása érdekében az IdP AAI Kapu számára hozzáférhetővé tett felhasználói adatokat célszerű autoritatív adatbázisban rögzített adatok alapján létrehozni, így a rendszeres frissítéssel azok időszerűsége, pontossága nem vitatott.
- Amennyiben az IdP AAI Kapu adatbázisa nem autoritatív adatbázis alapján működik, a Tagnak meg kell tennie a szükséges lépéseket az adatminőség biztosítása érdekében.
- Az Azonosító Szervezet törekszik arra, hogy a HREF Föderáció szolgáltatásai minden jogosult felhasználója számára elérhetővé váljon.
- Az Azonosító Szervezet biztosítja, hogy az IdP AAI Kapu az attribútum specifikációban megkövetelt attribútumokat megvalósítsa.
Tagsággal kapcsolatos szabályok
A HREF Föderáció infrastruktúrájának üzemeltetője az országos kutatói hálózatot működtető Föderációs Operátor. A HREF Föderáció további résztvevői egy már megkötött csatlakozási szerződés alapján a Tagok és a Partnerek.
- A föderáció Tagjai az alábbi intézmények lehetnek:
- felsőoktatási intézmények;
- akadémiai intézmények, kutatással foglalkozó intézmények;
- oktatással foglalkozó intézmények;
- közgyűjtemények.
- A föderáció Partnere tetszőleges szervezet lehet
- A föderáció Tagjai és Partnerei jogosultak a föderációban szolgáltatásokat üzemeltetni
- A Partner a Tagok Tanácsa ülésein megfigyelőként részt vehet, azonban szavazati joggal nem rendelkezik.
- Csak Tagok jogosultak:
- felhasználói adatokat szolgáltatni;
- a Tagok Tanácsába szavazati joggal rendelkező képviselőt küldeni.
Shib2SPConfig
Az Shibboleth 2 SP-t a shibboleth.xml
állományon keresztül konfigurálhatjuk. Ebben a leírásban feltételezzük, hogy az SP konfigurációja a /etc/shibboleth
könyvtárban van.
Alapszerkezet
Mindenekelőtt megmutatjuk a shibboleth.xml
fájl alapszerkezetét, majd alább az egyes szerkezeti elemeket részletesen is tárgyaljuk, majd a fejezet végén egy teljes, működő konfigurációt mutatunk be.
<SPConfig xmlns="urn:mace:shibboleth:sp:config:2.0"
xmlns:conf="urn:mace:shibboleth:sp:config:2.0"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
logger="shibboleth/syslog.logger" clockSkew="180">
<Extensions/>
<OutOfProcess logger="shibboleth/shibd.logger"/>
<InProcess logger="shibboleth/native.logger"/>
<Listener/>
<StorageService/>
<SessionCache/>
<ReplayCache/>
<ArtifactMap/>
<RequestMapper/>
<ApplicationDefaults id="default" policyId="default"
entityID="https://sp.example.org/shibboleth"
homeURL="https://sp.example.org/index.html"/>
<SecurityPolicies/>
</SPConfig>
Látható, hogy a szerkezet keretét egy <SPConfig>
elem adja, ez fogja közre a különböző összetevők részletes konfigurációit. Az <SPConfig>
opcionális attribútumai
-
logger
Annak a konfigurációs fájlnak a helyét adhatjuk meg, amelyben a loggolási tulajdonságok kerültek definiálásra. Alapértelmezés szerint ez ashibboleth/shid.logger
fájl. -
clockSkew
A legtöbb elosztott rendszerhez hasonlóan a Shibbolethnél is nagyon fontos, hogy szinkronban legyenek a rendszerben résztvevő elemek órái. Mivel komoly sebezhetőséget jelentene, ha a szerverek közti üzeneteken nem lenne megjelölve a feladás időpontja, ezért ezek az üzenetek időbélyeggel ellátottak, s minden rendszer elem csak egy bizonyos időnél nem régebbi üzenetekkel hajlandó foglalkozni. Ezt az értéket tudjuk itt megadni. Alapértelmezés szerint 3 perc, azaz 180 másodperc az értéke.
Összetevők
<Extensions>
<OutOfProcess>
<InProcess>
<Listener>
<StorageService>
<SessionCache>
<ReplayCache>
<ArtifactMap>
<RequestMapper>
A RequestMap megadja azokat a címeket (Host és Path), amelyeket a Shibboleth SP kezelni fog. Szerkezete:
<RequestMap applicationId="default">
<Host name="www.example.org">
<Path name="secure" authType="shibboleth" requireSession="true"/>
</Host>
<Host name="admin.example.org" applicationId="admin" authType="shibboleth" requireSession="true">
<AccessControl>
<Rule require="affiliation">faculty@osu.edu student@osu.edu</Rule>
</AccessControl>
</Host>
</RequestMap>
A RequestMap több Host elemet is tartalmazhat, a Host elem 0 vagy több Path elemet tartalmazhat.
!!! danger "Figyelem"
Ha 1-nél nagyobb mélységű könyvtárat (pl. a `/shibtest/shibreq` nevűt) szeretnénk védeni, akkor **nem** adhatjuk meg a *name* paraméterben a "shibtest/shibreq" értéket, hanem egymásba ágyazott Path elemeket kell használni. A *name* paraméter nem tartalmazhat '/' karaktert.
Az egyes elemeknél paraméterekkel szabályozhatjuk, hogy az SP milyen módon kezelje a hostot vagy az útvonalat. A paraméterek felüldefiniálhatók. A legfontosabb paraméterek az alábbiak (ezek ugyanúgy használhatók Host-nál mint Path-nál):
requireSession
: ha értéke "true", akkor az SP csak akkor továbbítja a HTTP request-et az alkalmazás ill. a webszerver felé, ha sikerült létrehozni egy autentikált session-t. Ha "false", akkor az alkalmazás felelős azért, hogy létrehozza a Shibboleth session-t (ún. lazy session) Alapértelmezés: "false"applicationId
: lehetőség van arra, hogy bizonyos helyekre érkező kérésekre az SP más és más módon próbáljon meg session-t létrehozni, ezt ún. Shibboleth Application-ben konfigurálhatjuk. Ha nem adunk meg értéket, akkor a "default" application-nél megadott értékek vonatkoznak majd a session-re.
<ApplicationDefaults>
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 aredirectErrors="SAJÁT KEZDŐLAPOM"
direktívát. - Bizonyosodjunk meg róla, hogy az oldalt lazy session-nel védjük
Kód
<!-- START: isPassive script-->
<script type="text/javascript" language="javascript">
<!--
// Written by Lukas Haemmerle <lukas.haemmerle@switch.ch>, SWITCH
// Check for session cookie that contains the initial location
if(document.cookie && document.cookie.search(/_check_is_passive=/) >= 0){
// If we have the opensaml::FatalProfileException GET arguments
// redirect to initial location because isPassive failed
if (
window.location.search.search(/errorType/) >= 0
&& window.location.search.search(/RelayState/) >= 0
&& window.location.search.search(/requestURL/) >= 0
) {
var startpos = (document.cookie.indexOf('_check_is_passive=')+18);
var endpos = document.cookie.indexOf(';', startpos);
window.location = document.cookie.substring(startpos,endpos);
}
} else {
// Mark browser as being isPassive checked
document.cookie = "_check_is_passive=" + window.location;
// Redirect to Shibboleth handler
window.location = "/Shibboleth.sso/DS?isPassive=true&target=" + encodeURIComponent(window.location);
}
</script>
<!-- END: isPassive script-->
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.
Alkalmazások_illesztése
- Drupal shib_auth module (angolul / in English)
- Drupal illesztése Shibboleth-hez (elavult)
- MediaWiki illesztése Shibboleth-hez
- Webmail szoftverek illesztése Shibboleth-hez
- Moinmoin illesztése Shibboleth-hez
- Könyvtári rendszerek illesztése
- Office 365 illesztése Shibboleth IdP-hez
Shib2IdPMobileLogin
A Shibboleth autentikációs képernyője tetszőlegesen testre szabható. A fájl a war/idp.war
-ban található. Módosításhoz ki kell csomagolni, módosítani a login.jsp
-t majd visszacsomagolni.
Lévén egyre többen használunk webes szolgáltatásokat mobilon keresztül, jó szolgálatot tehet, ha a Shibboleth belépő oldala is optimalizált a kis kijelzőkre és nem kell a nagy fehérségben matatnunk, hogy rámutassunk a felhasználónév mezőre...
Az alábbi, Shibboleth 2.3-hoz készült, módosított login.jsp a jQuery mobile környezetét használja a megjelenítéshez, így a legtöbb mobilon ugyanúgy kell megjelennie. A kód természetesen tovább szabható, formálható. Fontos, hogy javascript nélkül is működik, csak nem lesz szép.
<%@ taglib uri="urn:mace:shibboleth:2.0:idp:ui" prefix="idpui" %>
<%
String ua=request.getHeader("User-Agent").toLowerCase();
if(ua.matches(".*(android|avantgo|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\\/|plucker|pocket|psp|symbian|treo|up\\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino).*")||ua.substring(0,4).matches("1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\\-(n|u)|c55\\/|capi|ccwa|cdm\\-|cell|chtm|cldc|cmd\\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\\-s|devi|dica|dmob|do(c|p)o|ds(12|\\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\\-|_)|g1 u|g560|gene|gf\\-5|g\\-mo|go(\\.w|od)|gr(ad|un)|haie|hcit|hd\\-(m|p|t)|hei\\-|hi(pt|ta)|hp( i|ip)|hs\\-c|ht(c(\\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\\-(20|go|ma)|i230|iac( |\\-|\\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\\/)|klon|kpt |kwc\\-|kyo(c|k)|le(no|xi)|lg( g|\\/(k|l|u)|50|54|e\\-|e\\/|\\-[a-w])|libw|lynx|m1\\-w|m3ga|m50\\/|ma(te|ui|xo)|mc(01|21|ca)|m\\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\\-2|po(ck|rt|se)|prox|psio|pt\\-g|qa\\-a|qc(07|12|21|32|60|\\-[2-7]|i\\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\\-|oo|p\\-)|sdk\\/|se(c(\\-|0|1)|47|mc|nd|ri)|sgh\\-|shar|sie(\\-|m)|sk\\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\\-|v\\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\\-|tdg\\-|tel(i|m)|tim\\-|t\\-mo|to(pl|sh)|ts(70|m\\-|m3|m5)|tx\\-9|up(\\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|xda(\\-|2|g)|yas\\-|your|zeto|zte\\-")) {
%>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1">
<title>mobil login page</title>
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0a4.1/jquery.mobile-1.0a4.1.min.css" />
<script type="text/javascript" src="http://code.jquery.com/jquery-1.5.min.js"></script>
<script type="text/javascript" src="http://code.jquery.com/mobile/1.0a4.1/jquery.mobile-1.0a4.1.min.js"></script>
<style>
.errMsg {text-align: center; color: red;}
</style>
</head>
<body>
<div data-role="page" data-theme="b" id="editor">
<div data-role="header" data-position="inline">
<h1>NIIF IdP - mobile login</h1>
</div>
<div data-role="content">
<% if ("true".equals(request.getAttribute("loginFailed"))) { %>
<div data-role="fieldcontain">
<p class="errMsg">Authentication Failed</p>
</div>
<% } %>
<% if(request.getAttribute("actionUrl") != null){ %>
<form action="<%=request.getAttribute("actionUrl")%>" method="post" data-ajax="false">
<% }else{ %>
<form action="j_security_check" method="post">
<% } %>
<div data-role="fieldcontain">
<label for="j_username">Username:</label>
<input type="text" name="j_username" id="j_username" value="" />
</div>
<div data-role="fieldcontain">
<label for="j_password">Password:</label>
<input type="password" name="j_password" id="j_password" value="" />
</div>
<div data-role="fieldcontain" style="text-align:center">
<input type="submit" value="Login" data-role="button" data-inline="true" data-theme="b" />
</div>
</form>
</div>
</div>
</body>
</html>
<%
} else {
%>
<!DOCTYPE html>
<html>
<link rel="stylesheet" type="text/css" href="<%= request.getContextPath()%>/login.css"/>
<head>
<title>Shibboleth Identity Provider - Example Login Page</title>
</head>
<body id="homepage">
<img src="<%= request.getContextPath()%>/images/logo.jpg" alt="Shibboleth Logo"/>
<h1>Example Login Page</h1>
<p>This login page is an example and should be customized. Refer to the
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPassLoginPage" target="_blank"> documentation</a>.
</p>
<div class="loginbox">
<div class="leftpane">
<div class="content">
<p>The web site described to the right has asked you to log in and you have chosen <FILL IN YOUR SITE> as your home institution.</p>
<% if ("true".equals(request.getAttribute("loginFailed"))) { %>
<p><font color="red"> Credentials not recognized. </font> </p>
<% } %>
<% if(request.getAttribute("actionUrl") != null){ %>
<form action="<%=request.getAttribute("actionUrl")%>" method="post">
<% }else{ %>
<form action="j_security_check" method="post">
<% } %>
<table>
<tr><td width="40%"><label for="username">Username:</label></td><td><input name="j_username" type="text" /></td></tr>
<tr><td><label for="password">Password:</label></td><td><input name="j_password" type="password" /></td></tr>
<tr><td></td><td><button type="submit" value="Login" >Continue</button></td></tr>
</table></form>
</div>
</div>
<div class="rightpane">
<div class="content">
<div id="spName"><idpui:serviceName/></div>
<!-- pick the logo. If its between 64 & max width/height display it
If its too high but OK wide clip by height
If its too wide clip by width.
We should not clip by height and width since that skews the image. Too high an image will just show the top.
-->
<idpui:serviceLogo minWidth="64" minHeight="64" maxWidth="350" maxHeight="147" cssId="splogo">
<idpui:serviceLogo minWidth="64" minHeight="64" maxWidth="350" cssId="clippedsplogoY">
<idpui:serviceLogo minWidth="64" minHeight="64" cssId="clippedsplogoX"/>
</idpui:serviceLogo>
</idpui:serviceLogo>
<div id="spDescription">
<idpui:serviceDescription>You have asked to login to <idpui:serviceName/></idpui:serviceDescription>
</div>
</div>
</div>
</div>
</body>
</html>
<% } %>
Shib3IdpARP
Shibboleth 3 IdP attribútum szűrés beállítása
Vonatkozó állományok:
{idp.home}/conf/attribute-filter.xml
{idp.home}/conf/idp.properties
Az {idp.home}/conf/attribute-filter.xml
állomány már tartalmaz néhány egyszerű példa beállítást. Az alábbi módosítások lehetővé teszik, hogy az attribútum feloldó által feloldott sn és givenName attribútumok az SP-k számára elérhetők legyenek. Bővítsük az állományt az alábbiak szerint.
<afp:AttributeFilterPolicyGroup id="ShibbolethFilterPolicy"
xmlns:afp="urn:mace:shibboleth:2.0:afp"
xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:afp http://shibboleth.net/schema/idp/shibboleth-afp.xsd
urn:mace:shibboleth:2.0:afp:mf:basic http://shibboleth.net/schema/idp/shibboleth-afp-mf-basic.xsd
urn:mace:shibboleth:2.0:afp:mf:saml http://shibboleth.net/schema/idp/shibboleth-afp-mf-saml.xsd">
<!-- ... további tartalom ... -->
<!-- ezeket az attribútumokat minden SP megkapja -->
<afp:AttributeFilterPolicy id="mindensp">
<afp:PolicyRequirementRule xsi:type="basic:ANY"/>
<afp:AttributeRule attributeID="sn">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
<afp:AttributeRule attributeID="givenName">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
<!-- ezeket az attribútumokat csak a megadott SP kapja meg -->
<afp:AttributeFilterPolicy id="intezmenysp1">
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://sp1.intezmenyneve.hu/shibboleth"/>
<afp:AttributeRule attributeID="description">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
</afp:AttributeFilterPolicyGroup>
- A 14. sor szerint minden SP-re vonatkozik a szabály.
- A 16, 19. sorban megadott attribútumokat a 14. sor alapján minden SP látja.
- A 26. sorban megadott SP-re vonatkozóan rendelkezünk.
- A 28. sor szerint ez az SP megkapja a description attribútumot.
Dokumentáció:
- https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterConfiguration
- https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterPolicyConfiguration
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
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
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
HREFJoin
Az eduID föderációhoz való csatlakozás folyamata
- A csatlakozni kívánó tag/partner jelzi csatlakozási szándékát a Föderációs Operátor felé.
- Mind jogilag, mind technikailag előkészül a csatlakozáshoz: Föderáció alapelvek, Műszaki előírások IdP-k számára, Műszaki előírások SP-k számára.
- Egyeztetés után elküldi az aláírt szerződést, ill. nyilatkozatot, és ezzel párhuzamosan elérhetővé teszi a csatlakozás előtti ellenőrzéskor átnézendő dokumentumokat. Különösen fontos, hogy megadja az azonosítható felhasználók számát és elérhetővé tegye az adatkezelési szabályzatát.
- A Föderációs Operátor elkészíti a Tag számára a szükséges HEXAA jogosultságokat
- A Föderációs Operátor elvégzi az előzetes ellenőrzést (a különálló és benyújtandó dokumentumokat és a Resource Registry-be felvitt adatokat), majd ennek eredményértől tájékoztatja a Tagok Tanácsát
- Tagok Tanácsa dönt a csatlakozni kívánó tag/partner kérelméről
- A Föderációs Operátor - pozitív TT döntés esetén - aláírva visszaküldi a szerződést, és beteszi a föderációs éles metaadatba az új entitást. Negatív válasz esetén a hiányosságok ismertetése mellett lehetőséget biztosít azok a pótlására, javítására.
Azonosító szervezet (IdP) felvétele a föderációba
- A Föderációs Operátor az intézményi adminisztrátorral egyeztetve rögzíti a Resource Registry-be az IdP adatait. Egyúttal a Föderációs Operátor az IdP-t hozzáadja a föderációs tesztmetaadathoz, ezáltal az intézményi adminisztrátor, amennyiben helyesen konfigurálta az IdP-t, be fog tudni lépni a Resource Registrybe.
- A Tagok Tanácsa dönt az IdP felvételi kérelméről. Pozitív döntés esetén a Föderációs Operátor hozzáadja az éles föderációs metaadathoz az IdP-t.
Intézményi (tagi) szolgáltatás (SP) felvétele a föderációba
- Egy intézményi adminisztrátor (akinek a HEXAA-ban megfelelő, a Resource Registryhez szükséges intézményi admin joggköre van) a Resource Registry-ben rögzíti az SP minden szükséges adatát.
- Az SP a föderációs metaadatba a Föderációs Operátor számára történt jelézés után kerülhet. Technikailag a Föderációs Operátor engedélyezi a föderációs metaadatba történő megjelenést.
Külső (partner) szolgáltatás (SP) felvétele a föderációba
- A Föderációs Operátor a Resource Registry-ben rögzíti az SP minden szükséges adatát.
- A Tagok Tanácsa pozitív döntése után a Föderációs Operátor engedélyezi az új SP föderációs metaadatba történő megjelenését.
- Az SP-n a későbbiekben szükségessé váló módosításokat a Föderációs Operátor végzi el.
Sirtfi
Security Incident Response Trust Framework for Federated Identity (SIRTFI)
A SIRTFI kezdeményezést a REFEDS (the Research and Education FEDerations group) koordinálja, célja, hogy a föderációs és különösen a föderációközi együttműködéshez kapcsolódó incidenskezelés számára kereteket szabjon, a föderációban résztvevő felek számára egy magasabb biztonsági szintet adjon azáltal, hogy a SIRTFI-nak megfelelő entitások kapcsán biztosak lehetnek az alábbiakban:
- az intézményi üzemeltető az adott entitáshoz kapcsolódó biztonsági frissítéseket, mind operációs rendszer, mind kapcsolódó szoftverek, mind pedig a föderációs együttműködést megvalósító middleware tekintetében a lehető leggyorsabban telepíti,
- biztosított intézményi szinten az incidenskezeléshez kapcsolódó kompetencia, mellyel párhuzamosan az intézmény föderációs szinten (a metadatán keresztül) megjelöl egy speciális elérhetőséget, melyen keresztül az esetleges biztonsági incidensek kapcsán biztosan felvehető a kapcsolat a kompetens intézményi személlyel,
- az adott entitáshoz kapcsolódóan megfelelő naplózás történik, szükség esetén visszakereshetők az esetleges incidensekhez kapcsolódó alapvető információk,
- az adott intézmény rendelkezik AUP-val és biztosítja, hogy felhasználói be is tartják.
Fontos, hogy a SIRTFI-képesség metadatában való jelzése önbevallás útján történik, tehát föderációs szinten nem kerül vizsgálatra, hogy az intézmény az állításának megfelelően ténylegesen bír-e a fenti listában jelzett kompetenciákkal. Az eduID entitások kapcsán a Resource Registry-ben állítható be a SIRTFI-képesség.
Attribute_Specification
Purpose of this document
In a federation, information about the user is represented in SAML attributes transferred from the Identity Provider to the Service Provider. It is important for both parties to interpret the data in the same way.
Exact definitions of the attributes are maintained in their defining schemas. Within this specification, we use the following schemas:
- person, organizationalPerson (X.521)
- inetOrgPerson (RFC2798)
- eduPerson (http://middleware.internet2.edu/eduperson/, version 200806)
- SCHAC (http://www.terena.org/activities/tf-emc2/schacreleases.html, version 1.4.1)
- niifPerson, niifEduPerson (NIIFSchema)
This Attribute Specification provides an interpretation of the defined attributes for their use within the federation. It might be somewhat more specific than the original definition, in order to let the SPs get more specific information about the user.
Beyond the specification, parties may bilaterally agree on any other attributes.
Use of attributes
Terms
- An attribute is implemented, if the information is available according to the semantics of the specification. Releasing an implemented attribute is simply a policy decision of the IdP.
- An attribute is released, when the data is transferred from the IdP to an SP. Not all available information is sent out normally, only the attributes that are relevant for the SP.
Levels of implementation
- Mandatory: every IdP must implement the attribute.
- Recommended: it is recommended for every IdP to implement the attribute, however, it is understood that it might be impossible or very complex for certain IdPs
- Optional: an IdP may freely implement the attribute, however, the implementation must follow this specification.
Attribute Requirements of the SP
SPs can indicate attribute requirements among the information provided to Resource Registry. This information also shows up in the federation metadata. From the point of view of the SP, an attribute can be:
- Required: the information is a requirement for the proper operation of the SP application
- i.e.
eduPersonPrincipalName
is often required for applications, which are not prepared for handling opaque identifiers.
- i.e.
- Desired: the information can add extra functionality to the application or can provide better user experience
- i.e. when
displayName
is transferred, the user is not prompted to supply his or her common name.
- i.e. when
Attributes
Summary
Mandatory attributes
eduPersonTargetedID |
---|
eduPersonScopedAffiliation |
schacHomeOrganizationType |
Recommended attributes
eduPersonEntitlement |
Optional attributes
Attributes describing user properties | Attributes describing institutional relationship | Attributes for educational use |
---|---|---|
sn | ou | niifEduPersonAttendedCourse |
givenName | eduPersonOrgUnitDN | niifEduPersonArchiveCourse |
preferredLanguage | eduPersonPrimaryOrgUnitDN | niifEduPersonHeldCourse |
schacDateOfBirth | niifEduPersonMajor | |
schacYearOfBirth | niifEduPersonFaculty | |
schacPersonalTitle | niifEduPersonFacultyDN | |
niifPersonMothersName | niifEduPersonStudentCategory | |
niifPersonResidentalAddress | ||
homePostalAddress | ||
telephoneNumber | ||
mobile | ||
eduPersonNickName | ||
cn | ||
jpegPhoto | ||
labeledUri |
Persistent user identifiers
For most services, it is necessary to store application-specific data, such as user edits for a wiki page. This data is stored in a database, which is local to the SP, while the key between the user and the database entry is the persistent user identifier.
Persistent identifiers can be:
- computed: the identifier is generated run-time from one or more attributes of the user (usually by some cryptographic hashing algorithm).
- stored: the identifier is stored in the user's digital identity at the IdP, thus it is persistent even when other user information is changed. Uniqueness of the identifier must be preserved.
Identifiers can hold the following properties:
- persistence: IdPs must ensure that the identifier does not change during the life-cycle of the user at the institution.
- non-reassignable: IdPs must ensure that an identifier of a user will not be reassigned to another user.
- opacity: opaque identifiers do not refer to any personal data
- targeted: targeted identifiers are different for each SP, thus the SPs are unable to build common user profile without the cooperation of the IdP. Such identifiers are preferred from privacy reasons.
Persistent identifiers can be transferred in SAML attributes or in NameID of a SAML Assertion. Certain SP implementations (such as Shibboleth 2.x) can hide the details of the transfer, and can provide a persistent identifier in REMOTE_USER header.
List of attributes
In this specification, only mandatory and recommended attributes are specified. The Hungarian version of the Attribute Specification contains descriptions of the optional attributes as well. If you have any questions regarding the optional attributes, please contact the Federation Operator.
eduPersonTargetedID
eduPersonTargetedID | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonTargetedID OID: 1.3.6.1.4.1.5923.1.1.1.10 |
Rövid leírás | Opaque, targeted, non-reassignable identifier |
Implementáció | kötelező |
Részletes leírás | See: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID An SP must process the received value, it must not forward unparsed XML value to the application. As a minimum, the unique identifier and the IdP NameQualifier must be included in the parsed value, which is forwarded to the application. It is recommended to separate fields (such as qualifier values) with an exclamation mark ('!'). |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Must be a SAML2 persistent NameID; the unique identifier part must not be longer than 256 ASCII characters. |
Adatgazda | intézmény |
Példa | An IdP sends the attribute on the wire such as:<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"The application at the SP receives the attribute as the following:https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73 |
eduPersonPrincipalName
eduPersonPrincipalName | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonPrincipalName OID: 1.3.6.1.4.1.5923.1.1.1.6 |
Rövid leírás | Persistent, non-targeted, non-reassignable personal identifier |
Implementáció | kötelező |
Részletes leírás | Format: <local_id> @<scope> where: <local_id> : arbitrary persistent key which unambiguously maps to a person within an institution.<scope> : local security domain. It must have a format as a DNS domain, and ends with a resolvable domain name, which is possessed by the identity provider institution. (Note: the scope as a whole may not be resolved from DNS.)Note: eduPersonPrincipalName is sensitive personal data, it is often equal to the mail address of the person. It is recommended to use it only within the institution's domain. For federation use, opaque, targeted identifiers are more privacy preserving.eduPersonPrincipalName must not be reassignedAs some applications do not support special characters in identifiers, eduPersonPrincipalName MUST only contain the following characters: alpanumeric characters, dot ('.'), hyphen ('-') and underscore ('_'). |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Adatgazda | intézmény |
Példa | gipsz.jakab@example.org |
displayName
displayName | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:displayname OID: 2.16.840.1.113730.3.1.241 |
Rövid leírás | Display name of the person |
Implementáció | ajánlott |
Részletes leírás | Full name of the person in a form the user (or his or her institution) probably wants to be shown.For international use, please note that Hungarian names are usually in the form of Surname Givenname, and names often contain accented or other non-ascii characters. But also note that this document does not specify the exact name order. |
Lehetséges értékek | nincs korlátozás |
Értékek száma | single |
Szintaktika | Directory String |
Példa | Gipsz Jakab Aladár |
Elnevezés | URI: urn:mace:dir:attribute-def:mail OID: 0.9.2342.19200300.100.1.3 |
Rövid leírás | Mail address of the person |
Implementáció | ajánlott |
Részletes leírás | Notification email address of the person. The institution asserts that |
Lehetséges értékek | Valid email address |
Értékek száma | multi |
Szintaktika | See also: [RFC 2822](http://www.faqs.org/rfcs/rfc2822.html) |
Adatgazda | intézmény |
Példa | gipsz.jakab@example.org |
eduPersonScopedAffiliation
eduPersonScopedAffiliation | |
---|---|
OID | 1.3.6.1.4.1.5923.1.1.1.9 |
Description | Describes the relationship between the person and the institution |
Semantics | <affiliation> @<scope> <affiliation> : the following values are permitted
<scope> : local security domain. It must have a format as a DNS domain, and ends with a resolvable domain name, which is possessed by the identity provider institution.(Note: the scope as a whole may not be resolved from DNS.)\n\nSee also: http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation |
Values | One of the following: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, followed by the scope |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | |
Notes | - |
Use in federation | - |
eduPersonEntitlement
eduPersonEntitlement | |
---|---|
Elnevezés | URI: urn:mace:dir:attribute-def:eduPersonEntitlement OID: 1.3.6.1.4.1.5923.1.1.1.7 |
Rövid leírás | URI (either URN or URL) that indicates a set of rights to specific resources. |
Implementáció | ajánlott |
Részletes leírás | List of resources what the user is entitled to use at the SP. The trust between the two parties must be established out of band.An IdP should give only the values which are relevant for the SP |
Lehetséges értékek | nincs korlátozás |
Értékek száma | multi |
Szintaktika | Directory String |
Adatgazda | intézmény |
Példa | urn:geant:niif.hu:niif:entitlement:vhoadmin |
schacHomeOrganizationType
schacHomeOrganizationType | |
---|---|
OID | 1.3.6.1.4.1.25178.1.2.10 |
Description | Type of the Home Organisation |
Semantics | |
Values | urn:schac:homeOrganizationType:hu:{university,nren,library,vho,school,business,other,test} |
# of values | multi |
Availability | - |
Syntax | Directory String |
Examples | - |
Notes | - |
Use in federation | - |
SSP2
Az alábbi lapon megkíséreljük összefoglalni a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő SimpleSAMLphp (SSP) alkalmazást állítsunk üzembe.
Telepítés
Először is nagyvonalakban leírásra kerülnek az előkészületek ezt követően pedig maga a szoftver telepítése és beállítása.
Előkészületek
Ahhoz, hogy problémamentesen telepíthessük SSP alkalmazásunkat, az alábbi szoftverkomponenseknek kell működniük szerverünkön.
- A következő könyvtárakat kiegészítőket telepíteni kell:
wget openssl unzip build-essential libldap2-dev libldap-common
- PHP futtatására alkalmas webszerver
- PHP környezet (>=8.0)
- A következő PHP kiterjesztéseket engedélyezni kell
posix, date , dom , fileinfo , filter , hash , json , libxml , mbstring , openssl , pcre , session , simplexml , sodium , SPL, zlib, ldap
- Adatbázisból történő autentikáció esetén a megfelelő adatbázis-csatolót
mysqli, pdo, pdo_mysql
- RADIUS szerveren keresztül történő autentikáció esetén:
radius
- Információk, certek:
-
Bár a szoftver képes futni mariadb, és redis nélkül, ezek vagy hasonló megoldások használata éles környezetben ajánlott.
- Amennyiben ezeket szándékozunk használni database connection stringgel kell rendelkezni, redis elérhetőséggel és jelszóval rendelkezni.
- Az adatbázis szerkezetének kialakítása a használt moduloktól függ, a leggyakoribb a consent modul, ott van is dokumentáció az adatbázis inicializálásáról.
-
Szükséges 2 certpár, az egyik az apachenak a másik az SSP-nek ezutóbbi lehet önalárírt, és nem ajánlott ugyan azt használni.
-
Composer
A composer PHP csomagkezelőt is telepíteni kell (akár forrásból, akár csomagból), hogy telepíteni lehessen a SimpleSAMLphp futásához szükséges PHP library-ket.
Telepítés
Elvégezhető composerrel például a /var/
mappában:
composer create-project simplesamlphp/simplesamlphp:2.1.3
Mappaszerkezet módosítása:
mv simplesamlphp simplesamlphp-prod #Tetszőleges átnevezés
mkdir -p simplesamlphp-prod/cert
mkdir -p /var/simplesamlphp-prod/log/stats/
mkdir -p /var/simplesamlphp-prod/mdx-cache/
chown -R www-data:www-data /var/simplesamlphp-prod/mdx-cache/
chown -R www-data:www-data /var/simplesamlphp-prod/log/
chown -R www-data:www-data /var/simplesamlphp-prod/metadata/
Composerrel a szükséges modulok telepítése (például LDAP, REDIS, vagy consent):
composer require simplesamlphp/simplesamlphp-module-ldap:v2.3.2
composer require predis/predis:2.2.2
composer require simplesamlphp/simplesamlphp-module-consent:1.3.2
Ezzel a telepítés, és a szükséges kiegészítők telepítése megtörtént.
Apache konfigurálás
A webről csak a /var/simplesamlphp-prod/public
könyvtárat kell elérni. Tilos a teljes simplesamlphp könyvtárat a DocumentRoot alá tenni!
Alias /simplesaml /var/simplesamlphp-prod/public
<Directory /var/simplesamlphp-prod/public>
Require all granted
</Directory>
Simplesamlphp Alapbeállítások
Konfigurációs fájlok
Amennyiben korábbi verziókat használtunk,
jó megközelítés lehet diff segítségével ellenőrizni a különbségeket a korábbi config.php
fileunk és a config.php.dist
között.
Ha ilyennel nem rendelkezünk akkor lehet rögtön alapul venni a config.php.dist
-et és hasonlóképp a metadata-templates mappát.
Konfigurációs fájlok szerkesztése
Baseurlpath beállítása
- Állítsuk be a baseurlpath opciót. Mutasson a telepítés URL-jére, ahol a SimpleSAMLphp elérhető:
'baseurlpath' => 'https://your.canonical.host.name/simplesaml/',
Adminisztrációs adatok beállítása
-
Az "admin" felhasználó jelszavát, mellyel webes felületen keresztül be tud lépni a települő SSP-be.
'auth.adminpassword' => 'ujjelszotirdide',
-
Titkosítási feladatokhoz szükséges "salt", azaz véletlenszerűen összeálló karaktersorozat
'secretsalt' => 'randombytesinsertedhere',
A karaktersorozat előállításában segíthet az alábbi parancs:
tr -c -d '0123456789abcdefghijklmnopqrstuvwxyz' </dev/urandom | dd bs=32 count=1 2>/dev/null;echo
-
Elérhetőségeket, amely adatok bekerülnek majd a generált metaadatba
'technicalcontact_name' => 'Gipsz Jakab', 'technicalcontact_email' => 'jakab.gipsz@example.org',
-
Nyelv és időzóna adatok
'language.default' => 'hu', 'timezone' => 'Europe/Budapest',
Az alapadatok megadása után mentsük és zárjuk be a config.php-t.
Naplózás beállítása
Alapértelmezetten a SimpleSAMLphp a syslog-ba irányítja a naplózást.
Ha fájlba akarunk naplózni, akkor a megfelelő könyvtárhoz biztosítsunk írás jogot a webszerver felhasználónak, és ne felejtsünk el gondoskodni a naplófájlok rotálásáról!
-
Naplózási szint beállítása a config/config.php-ban
'debug' => array( 'saml' => true, 'backtraces' => true, 'validatexml' => false, ), 'logging.level' => SimpleSAML\Logger::DEBUG, 'logging.handler' => 'file',
A "SimpleSAML\Logger::DEBUG" a legrészletesebb naplózási beállítás, éles rendszernél nem ajánlott csak hiba keresés esetén.
Modulok engedélyezése
'module.enable' => [
'exampleauth' => true,
'saml' => false, //
'core' => null, // Alapértelmezett érték
'ldap' => true, // 2.x verzióban külön telepíteni és engedélyezni kell az ldap modult.
'admin' => true, // Ezt szükséges engedélyezni hogy elérhessük az adminisztrációs felületet
],
Tanúsítvány készítése
Nem ajánlott a SimpleSAMLphp-hoz és webszerverhez ugyanazt a tanúsítvány használni!
-
A SimpleSAMLphp alapértelmezetten a tanúsítványt a cert mappában keresi.
-
Az alábbi paranccsal egy 10 éves self-signed tanúsítvány generálunk a SimpleSMALphp számára.
openssl req -new -newkey rsa:3072 -x509 -days 3652 -nodes -out cert/saml-example-org.crt -keyout cert/saml-example-org.key
A fingerprint az alábbi módon kérdezhető le a legegyszerűbben
openssl x509 -fingerprint -noout -in cert/saml-example-org.crt
Telepítés kész
Amennyiben elkészültünk a fenti lépésekkel, úgy a https://service.example.org/simplesaml/admin címen elérjük a telepített SSP-nk webes adminfelületét.
Identity Provider (IdP) beállítás
Alapbeállítások
IdP engedélyezése: a config/config.php fájlban kell a saml20 idp-t "true"-re állítani.
'enable.saml20-idp' => true,
Metaadat alapok
A beállítandó IdP alapvető paraméterei a metadata/saml20-idp-hosted.php
fájlban állíthatók. Az alábbi kódrészlet egy minimális, de már működő példát mutat.
<?php
$metadata['https://example.org/saml-idp'] = [
/*
* The hostname for this IdP. This makes it possible to run multiple
* IdPs from the same configuration. '__DEFAULT__' means that this one
* should be used by default.
*/
'host' => '__DEFAULT__',
/*
* The private key and certificate to use when signing responses.
* These can be stored as files in the cert-directory or retrieved
* from a database.
*/
'privatekey' => 'example.org.pem',
'certificate' => 'example.org.crt',
/*
* The authentication source which should be used to authenticate the
* user. This must match one of the entries in config/authsources.php.
*/
'auth' => 'example-ldap',
];
A fentebb hivatkozott certeket korábban létrehoztuk, de az example-ldap auth forrást még nem:
LDAP autentikáció
Javasolt az LDAP-ban egy olyan bejegyzést létrehozni az IdP számára, amely olvasni tudja a felhasználóknak a föderációban használt attribútumait. Az azonosítás alapértelmezett módon a felhasználó nevében történő újra bind-olással történik, így a jelszóhoz nem kell hozzáférést adni.
Ahhoz, hogy megadhassuk az LDAP-hoz tartozó beállításokat, a config/authsources.php
fájlt kell szerkesztenünk. Az alábbi kódrészletet elegendő beszúrni, és az egyes változóknak a helyi LDAP-nak megfelelő adatokat értékül adni.
'example-ldap' => [
'ldap:Ldap',
/**
* The connection string for the LDAP-server.
* You can add multiple by separating them with a space.
*/
'connection_string' => 'ldap.example.org',
/**
* Whether SSL/TLS should be used when contacting the LDAP server.
* Possible values are 'ssl', 'tls' or 'none'
*/
'encryption' => 'ssl',
/**
* The LDAP version to use when interfacing the LDAP-server.
* Defaults to 3
*/
'version' => 3,
/**
* Set to TRUE to enable LDAP debug level. Passed to the LDAP connector class.
*
* Default: FALSE
* Required: No
*/
'debug' => false,
/**
* The LDAP-options to pass when setting up a connection
* See [Symfony documentation]
*/
'options' => [
/**
* Set whether to follow referrals.
* AD Controllers may require 0x00 to function.
* Possible values are 0x00 (NEVER), 0x01 (SEARCHING),
* 0x02 (FINDING) or 0x03 (ALWAYS).
*/
'referrals' => 0x00,
'network_timeout' => 3,
],
/**
* The connector to use.
* Defaults to '\SimpleSAML\Module\ldap\Connector\Ldap', but can be set
* to '\SimpleSAML\Module\ldap\Connector\ActiveDirectory' when
* authenticating against Microsoft Active Directory. This will
* provide you with more specific error messages.
*/
'connector' => '\SimpleSAML\Module\ldap\Connector\Ldap',
/**
* Which attributes should be retrieved from the LDAP server.
* This can be an array of attribute names, or NULL, in which case
* all attributes are fetched.
*/
'attributes' => null,
/**
* Which attributes should be base64 encoded after retrieval from
* the LDAP server.
*/
'attributes.binary' => [
'jpegPhoto',
'objectGUID',
'objectSid',
'mS-DS-ConsistencyGuid'
],
/**
* The pattern which should be used to create the user's DN given
* the username. %username% in this pattern will be replaced with
* the user's username.
*
* This option is not used if the search.enable option is set to TRUE.
*/
'dnpattern' => 'uid=%username%,ou=people,dc=example,dc=org',
/**
* As an alternative to specifying a pattern for the users DN, it is
* possible to search for the username in a set of attributes. This is
* enabled by this option.
*/
'search.enable' => false,
/**
* An array on DNs which will be used as a base for the search. In
* case of multiple strings, they will be searched in the order given.
*/
'search.base' => [
'ou=people,dc=example,dc=org',
],
/**
* The scope of the search. Valid values are 'sub' and 'one' and
* 'base', first one being the default if no value is set.
*/
'search.scope' => 'sub',
/**
* The attribute(s) the username should match against.
*
* This is an array with one or more attribute names. Any of the
* attributes in the array may match the value the username.
*/
'search.attributes' => ['uid', 'mail'],
/**
* Additional filters that must match for the entire LDAP search to
* be true.
*
* This should be a single string conforming to [RFC 1960]
* and [RFC 2544]. The string is appended to the search attributes
*/
'search.filter' => '(&(objectClass=Person)(|(sn=Doe)(cn=John *)))',
/**
* The username & password where SimpleSAMLphp should bind to before
* searching. If this is left NULL, no bind will be performed before
* searching.
*/
'search.username' => null,
'search.password' => null,
],
Megfelelő beállítások után a dinamikusan generált metadata a /saml2/idp/metadata.php
útvonalon érhető el.
Tesztelés
A usereknek már nincs adminisztrációs felület azonban adminként még be lehet lépni amennyiben a core modulok között engedélyeztük az admin felületet: https://service.example.org/simplesaml/admin/
A belépést követően a teszt fülre kattintva tesztelhetjük az authentikációs forrásokat:
https://idp.niif.hu/simplesaml/module.php/admin/test
Kézi metadata csere, élesített SP-vel
Az IdP metadata valamint metadata eszközök megtalálhatók a következő oldalon (admin fiók szükséges): https://idp.example/simplesaml/module.php/admin/federation
Amennyiben az SP is simplesamlphp használhatjuk a fentihez hasonló elérési úton található SimplesSAMLphp SP Metadatát, ez php formátumban van, ellenkező esetben pl shibboleth sp meg kell keresnünk a metaadat XML-t majd a fentebb említett federation oldalon található XML →simplesamlphp metadata konvertert használni.
Az így kapott php formátumú metaadatokat pedig be kell illeszteni az IdP-n a metadata/saml20-sp-remote.php
fileba a következő példához hasonlóképp:
<?php
$metadata['https://sp.example.org/simplesaml/module.php/saml/sp/metadata.php/default-sp'] = [
'AssertionConsumerService' => 'https://sp.example.org/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
'SingleLogoutService' => 'https://sp.example.org/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp',
];
A másik (SP) oldalon amennyiben szintén simplesamlphp van, az idp metaadatokat hasonlóképp hasonlóképp érjük el majd illesszük be a metadata/saml20-idp-remote.php fileba.
<?php
$metadata['https://example.org/saml-idp'] = [
'SingleSignOnService' => 'https://example.org/simplesaml/saml2/idp/SSOService.php',
'SingleLogoutService' => 'https://example.org/simplesaml/saml2/idp/SingleLogoutService.php',
'certificate' => 'example.pem',
];
A certet a config php-ban beállított certdir-ben keresi (alapértelmezetten /cert) Amennyiben más SP-t használunk az idp XML metadatájára lesz szükség amely szintén föderáció fül alatt érhető el (https://idp.example/simplesaml/module.php/admin/federation), és az SPn-nek releváns dokumentációt kell követni.
Service Provider (SP) beállítás
Alapbeállítások
A telepített alkalmazásunk által kezelt SP-ket a config/authsources.php fájlban tudjuk beállítani. A SimpleSAMLphp a tanúsítvány fájlokat a korábban létrehozott cert mappában fogja keresni, a fájlokat elég relatív elérési úttal megadni.
<?php
$config = [
/* This is the name of this authentication source, and will be used to access it later. */
'default-sp' => [
'saml:SP',
'entityID' => 'https://myapp.example.org/',
'privatekey' => 'saml.pem',
'certificate' => 'saml.crt',
'idp' => 'https://example.org/saml-idp', //Alapértelmezett IdP beállítása
],
];
Tesztelés
A fent elvégzett alapbeállítások után már tudjuk tesztelni a, hogy a felépített IdP - SP kapcsolat működik-e.
SP oldalon nyissuk meg a admin teszt felületet:
https://idp.niif.hu/simplesaml/module.php/admin/test
Itt kattintsunk a default SP-re
HREF-integráció
Metadata beállítása (IdP és SP is)
Javasolt dinamikus metaadatforrást (MDX) használni, opcionálisan kiegészítve statikus állományokkal. Részletes leírás itt: SimpleSAMLMixedMetadata()
IdP
Amennyiben van SSP alapú IdP-nk, melyet szeretnénk a föderáció részévé tenni, úgy a teendők a következők.
-
(Az adminisztratív teendőktől itt most eltekintünk, a csatlakozás folyamata itt van leírva)
-
Kell küldeni egy levelet a info@eduid.hucímre, benne néhány mondat mellett az IdP metaadatának URL-jével (https://example/org/simplesaml/module.php/saml/idp/metadata)
-
Ha minden rendben megy, akkor az IdP bekerül a Resource_Registry-be, ezáltal a föderációs metaadatba is.
-
Az előző pontban leírt módon be kell állítani a központi metadata feldolgozását.
-
Amennyiben a föderációs metaadatban már szerepel a mi IdP-nk is, úgy a föderáció valamelyik, tesztelési célokat szolgáló SP-jénél ki is próbálhatjuk a bejelentkezést.
-
Fontos, hogy a föderációs Discovery Service óránként generálja újra az IdP-k listáját, így ennyi idő mindenképp szükséges, hogy az új IdP megjelenjen itt, az egyes SP-k pedig két óránként töltik újra a metaadatot, így előfordulhat, hogy azonnal nem fog minden működni, de néhány óra alatt várhatóan beindul. :)
-
Tesztelésre használható oldal: https://attributes.eduid.hu
-
Ahhoz, hogy a Resource Registry-be is be tudjunk lépni és az IdP további, a föderációra vonatkozó beállításait meg tudjuk ejteni, ehhez az IdP-nek ki kell adnia az alábbi attribútumokat:
- mail - ez belépés után, manuálisan is beállítható
- eduPersonPrincipalName
schacHomeOrganizationType(az attribútumot hamarosan kivezetjük a kötelező attribútumok közül)- eduPersonScopedAffiliation
Attribútumok kezelése
Beállított IdP-nk alapértelmezés szerint azokat az attribútumokat adja ki, melyeket a metaadat alapján az SP kért (Lásd a metadatában a RequestedAttribute elemeket), és egyúttal alapból meg tudta szerezni a felhasználói adatbázisból, esetünkben az LDAP-ból. Mivel néhány attribútum nem szerepel az LDAP-ban, hanem az IdP-ben kell előállítani, így pár helyen módosítanunk kell az alapértelmezett konfiguráción.
A metadata/saml20-idp-hosted.php
fájlba szerkesszük be az alábbi kódrészlet értelemszerűen módosított változatát. Az 'auth' => 'example-ldap',
sor alatt kezdjük. Fontos, hogy egyúttal a config.php authproc.idp
részét kikommentezzük, nehogy az ottani sorszámokkal megadott default feladatok bekavarjanak.
'AttributeNameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
'userid.attribute' => 'uid', // Itt adjuk meg, hogy mely, az LDAPból származó attribútum alapján fogja az IdP kiszámítani az eduPersonTargetedID-t
'authproc' => array(
10 => array(
'class' => 'core:AttributeMap',
'uid' => 'eduPersonPrincipalName'
//Itt az 'uid' az az attribútum az LDAP-ban, amely a felhasználó azonosítóját tartalmazza, mert ebből képezzük az eduPersonPrincipalName-t.
),
# 20 => array(
# 'class' => 'core:AttributeAdd',
# 'schacHomeOrganizationType' => array('urn:schac:homeOrganizationType:hu:university')
# //Kötelező statikus attribútum az [[HREFAttributeSpec#schacHomeOrganizationType|intézmény jellegének]] megfelelően
# ),
30 => array(
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonPrincipalName',
'pattern' => '/^.*$/',
'replacement' => '${0}@intezmenydomain.hu',
// Itt adjuk hozzá az intézményi scope-ot az eduPersonPrincipalName már meglévő értékéhez
),
40 => array(
'class' => 'core:AttributeAlter',
'subject' => 'eduPersonAffiliation',
'pattern' => '/^.*$/',
'replacement' => '${0}@intezmenydomain.hu',
// Itt adjuk hozzá az intézményi scope-ot az eduPersonAffiliation már meglévő értékéhez
),
50 => array(
'class' => 'core:AttributeMap',
'eduPersonAffiliation' => 'eduPersonScopedAffiliation'
// Az LDAP-ból eduPersonAffiliation-ként érkező attribútumból föderációs elvárásoknak megfelelően eduPersonScopedAffiliationt készítünk
),
60 => array(
'class' => 'core:AttributeAdd',
'eduPersonScopedAffiliation' => array('member@intezmenydomain.hu')
// Az eduPersonScopedAffiliation-ben tesztelés céljából kiadhatjuk member értéket,
// így ha LDAP-ból nem jön érték, akkor is láthatjuk, hogy működik az attribútum kiadás
),
61 => array(
'class' => 'core:TargetedID',
'nameId' => TRUE,
),
// Itt állítjuk be, hogy az IdP előállítson és kiadhasson állandóazonosítóként eduPersonTargetedID-t, ha kérik
70 => array('class' => 'core:AttributeMap',
'name2oid'
// Az LDAP-os attribútum nevekből itt kreálunk szabványos urn:oid formátumúakat
),
80 => 'core:AttributeLimit',
), // .authproc
'simplesaml.nameidattribute' => 'eduPersonPrincipalName',
'attributeencodings' => array(
'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw',
),
'sign.logout' => true
-
További tudnivalók a Resource Registry-ről, ill. a Föderációs attribútum specifikációról.
-
Ha minden rendben ment, akkor a Resource Registry-ben regisztrált IdP-hez tartozó adminisztrációs jogok átkerülnek az IdP technikai gazdájához, s ezzel a folyamat kész is.
SP
Amennyiben IdP-t is beállítottunk, és be is tudunk lépni a Resource Registry-be, úgy nincs más dolgunk, mint az RR-ben új SP-t hozzáadni a föderációhoz, amely a megfelelő átfutási idő után a föderáció minden tagjánál látható is lesz.
Ellenkező esetben (nincs IdP, és nem is tervezünk beállítani), akkor az IdP hozzáadásánál részletezett pontokon kell végig menni a metaadat betöltéséig, s a továbbiakat az említett e-mail címen megbeszélni.
Attribútum scopeok használata
A HREF föderáció IdP-i ún. scopeolt attribútumokat is használnak. Ez a scopeolás azt jelenti, hogy minden egyes IdP csak a saját scopejában ad ki attribútumokat, és a Shibboleth SP-k ezt ellenőrzik is. A scope és az attribútum valódi értéke egy '@' karakterrel kerül elválasztásra (ilyen attribútumok jelenleg: eduPersonScopedAffiliation illetve eduPersonPrincipalName).
A SimpleSAMLphp alapértelmezett telepítése nem szűri a hibásan scopeolt értékeket. Kiegészítő modulként szűrésre használható az NIIF által fejlesztett attributescope modul, ami reményeink szerint rövid távon a hivatalos SimpleSAMLphp kiadás része lehet.
A telepítésről és konfigurációról bővebben itt lehet olvasni: https://github.com/NIIF/simplesamlphp-module-attributescope
- Az
attributescope
modul használata esetén a következőképp kell módosítani aconfig/config.php
fájlt:
authproc.sp = array(
...
// 49 => array('class' => 'core:AttributeMap', 'oid2name'),
50 => array( 'class' => 'attributescope:FilterAttributes'
),
...
),
Figyeljünk arra, hogy mire a modulhoz ér a vezérlés, az attribútumok nevei friendlyName alakúak legyenek (ne pedig oid-ok). A példában erre utal a 49-es sor.
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](https://help.edu.hu/books/aai/page/lazy-session) 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ó
!!! warning "Figyelem"
A szócikk további része lehetséges, hogy elavult, az [angol nyelvű dokumentáció](https://help.edu.hu/books/aai/page/drupal-shibboleth-module) 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 <drupal telepítési könyvtára>/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.: <drupal telepítési könyvtára>/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 <Drupal CMS elérhetősége>/?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.
Publikációk
- AAI előadás a 2007-es Networkshopon
- AAI és Shibboleth (HBONE Workshop)
Federation_Policy
About eduID
Hungarian Research and Educational Federation (HREF) is a SAML2-based Identity Federation of Hungarian higher education and research institutions, public collections and other content providers. For the end-users, the federation aims to be transparent, therefore the login procedure is communicated as eduID login.
Contacts
The Federation is operated by NIIF Institute as a Federation Operator. Questions, concerns or any kind of requests about the Federation should be directed to any of the following addresses:
- aai@niif.hu
- Kristof Bajnok, NIIF Institute
- 18-22 Victor H. str
- H-1132 Budapest
- Hungary
News and information about the federation is published at http://eduid.hu (Hungarian only)
Policy and principles of interoperation
Basic principles
- The aim of the Federation is to allow the use of services of its Members and Partners, where authorisation is based on the user information originating from the users' Home Institutions.
- Home Institutions must only authenticate users having a known affiliation to them.
- IdPs and SPs must not give false or misleading information about themselves.
- User information provided by IdPs should be as accurate as possible. SPs must take into account that parts of the received information may be at the discretion of the user.
- User credentials (i.e. passwords) stored by IdPs must be protected and verified only through secure procedures.
- SPs must request only the user attributes which are absolutely necessary for their operation.
- SPs must not ask users for their federation passwords.
- SPs must handle personal data according to the local privacy laws.
- IdPs and SPs must cooperate in the investigation of possible abuse/fraud.
- IT systems running IdPs and SPs must be operated with due diligence.
Data protection
- Prior joining the federation, every entity needs to publish the Data Protection Policy under which it operates. This policy must be kept up-to-date.
- Whenever the Data Protection Policy changes, the Federation Operator must be notified.
- Transfer of personal data is only allowed when either
- authorised by law, or
- the user expressed his or her consent on the data transfer.
Rules of membership
The Federation is operated by the Federation Operator, that also operates the national research network. Further participants are Members and Partners that must have a signed contract with the Operator.
- The following institutions may be Members of the federation:
- Institutions of the higher education;
- Institutions of the Hungarian Research Academy and other research institutions;
- Institutions of secondary education;
- Public collections.
- Any organisation might join as a Partner.
- All Members and Partners of the Federation might provide services.
- A Partner might participate in the meeting of the Members' Board as an observer, without having rights to vote.
- Only Members are entitled to
- supply user identity information to the federation
- send representatives into the Members' Board with a right to vote.
Governance
The governance body of the federation is the Members' Board (MB). Every Federation Member may send one representative person to the Members' Board, who has one vote.
The working language of the MB is Hungarian. The Board publishes its decisions and guidelines at http://eduid.hu/dokumentumok in Hungarian, although whenever the topic is of interest of any international Partner, it shall be translated to English and the administrative contacts shall be notified.
- accept new Federation documents or modify existing ones,
- accept application of new Members and Partners
Partners may also send representatives for MB meetings, without voting rights.
Legal
The Federation itself is not a legal entity, Members and Partners establish a legal connection to the Federation Operator. Any legal claims between Members and/or Partners shall be directed to the organisation operating the Identity Provider or the Service Provider.
Shibboleth_Service_Provider__SP__és_Docker
Az alábbi lapon összefoglaljuk a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő Shibboleth SP-t állítsunk üzembe, Docker konténerben. Fontos, hogy rengeteg olyan igény lehet, amely további speciális beállítások meglétét teszik szükségessé, ezeket ezen a lapon nem részletezzük, ilyen irányú tájékozódáshoz legbiztosabb források:
Apache 2.4
Az alábbi példákban az SP és az alkalmazás konténer SSL termination proxy mögött helyezkedik el. Természetesen a VirtualHost átalakítható úgy, hogy SSL-t is ki tudjon szolgálni, ha erre van igény.
Proxy
Ebben az esetben, a Shibboleth SP-vel védeni kívánt alkalmazást proxy-zuk egy másik futó konténerből.
<VirtualHost *:80>
ServerName https://domain:443
ServerAdmin admin@domain.com
UseCanonicalName On
ErrorLog /dev/stderr
CustomLog /dev/stdout combined
ProxyVia On
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /Shibboleth.sso !
ProxyPass / http://cel_kontener:8080/ retry=0 timeout=30
ProxyPassReverse / http://cel_kontener:8080/
<Location "/socket.io">
RewriteEngine On
RewriteCond %{QUERY_STRING} transport=websocket [NC]
RewriteRule /(.*) ws://cel_kontener:8080/socket.io/$1 [P,L]
ProxyPass http://cel_kontener:8080/socket.io retry=0 timeout=30
ProxyPassReverse http://cel_kontener:8080/socket.io
</Location>
<Proxy "*">
AuthType shibboleth
ShibRequestSetting requireSession 1
Require valid-user
</Proxy>
</VirtualHost>
Lazy session
Az előző példához hasonlóan, a Shibboleth SP-vel védeni kívánt alkalmazást proxy-zuk egy másik futó konténerből, de csak a https://domain.com/secure útvonalat védjük.
<VirtualHost *:80>
ServerName https://domain:443
ServerAdmin admin@domain.com
UseCanonicalName On
ErrorLog /dev/stderr
CustomLog /dev/stdout combined
ProxyVia On
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /Shibboleth.sso !
ProxyPass / http://cel_kontener:8080/ retry=0 timeout=30
ProxyPassReverse / http://cel_kontener:8080/
<Location "/secure">
AuthType Shibboleth
ShibRequestSetting requireSession true
ShibUseHeaders On
Require shibboleth
ProxyPass http://cel_kontener:8080/secure retry=0 timeout=30
ProxyPassReverse http://cel_kontener:8080/secure
</Location>
<Proxy "*">
AuthType shibboleth
ShibRequestSetting requireSession false
Require shibboleth
</Proxy>
</VirtualHost>
Shibboleth
Load balance
Terheléselosztó mögött a shibboleth2.xml-ben, a <Session>
beállításnál érdemes a consistentAddress="false"
értéket beállítani, ha tudjuk, hogy változó (LAN!) címekről érkeznek a felhasználók.
EduIDTest
hosts file használata
A hosts file meglehetősen egyszerűen használható eszköz arra, hogy élesben működő szolgáltatás átalakítása során tudjunk. Mivel az eduID-ban elterjedten használt SAML profilokban az üzenetváltás a legtöbb esetben a böngészőn keresztül zajlik, ezért elegendő a böngészőt arra rávenni, hogy a tesztelni kívánt SP-t vagy IdP-t ne a világ által látott helyen, hanem a tesztelni kívánt ponton keresse. Ez a módszer mind SP, mind IdP tesztelésre használható.
Néhány tipp:
- A tesztelni kívánt IdP vagy SP föderációs konfigjában megadott tanúsítványok egyezzenek meg az éles rendszerben használt tanúsítvánnyal. Ennek hiányában az aláírás nem lesz valid, illetve az esetlegesen titkosítottan küldött adatokat nem lehet kibontani.
- Ha végül az új gép a régi nevén fog hallgatni, akkor nincs szükség a Resource Registry-ben módosítani az adatokon.
- Bármely SP-vel / IdP-vel tesztelhetjük az IdP-nket / SP-nket, hacsak nem rontunk el valamit (vö. első két pont) a távoli fél nem fogja észrevenni, hogy nem az "éles" partnerrel beszél.
- Tesztelésre privát IP cím is megfelelő, feltéve, hogy a saját gépünk eléri azt a tartományt.
- [SP]: HEXXA kapcsolat is tesztelhető a módszerrel, feltéve, hogy a tesztelt SP képes kapcsolatot nyitni a hexaa.eduid.hu 8443-as portjára. A HEXAA kizárólag a használt SSL tanúsítvány alapján azonosítja be a kérdezőt, így ugyanazt a tanúsítványt és entityID-t használva ugyanazt a választ kapjuk a tesztelt és az éles SP-n is.
- [IdP]: Az IdP-nk helyes működését például itt tudjuk ellenőrizni: https://attributes.eduid.hu
SP tesztelés
A szolgáltatásunk SAML integrációjának tesztelésére remekül használható eszköz a https://samlidp.io, amellyel pár kattintással készíthetünk magunknak teszt célokra IdP-t, amelynek megadható - akár a föderációban még nem regisztrált - SP metaadata is, így különböző felhasználói profilokkal próbálkozhatunk.
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.
FederationStats
Federation usage statistics
!!! warning "A szócikk vagy fejezet még megírásra vár"
I am a stub, please fix me!
Federation visualization project - discountinued.
- source (ruby on rails) https://repo.niif.hu/gitweb/gitweb.cgi?p=federation-stats.git;a=summary
- live demo
Running the sample project
- Install Ruby
- Install Rails (
gem install rails
) - Setup a
development.sqlite3
database with therake db:setup
command - Fire up
script/server
, it will run the project on localhost:3000
Statistic types
Currently we have the following types of statistics:
- Unique users per day (
USER_COUNT
) - AuthnResponse per day (
AUTH
) - AuthnResponse per service per day (
SSO_TO_SERVICE
)
Log statistics format
The following simple format is used to convey statistics from IdPs to the central module - the white spaces (new lines) are important:
ENTITYID #ENTITYID#
APIKEY #API_KEY#
DATE yyyy-mm-dd
STAT #STAT_ID#
xxxx
STAT #STAT_ID#
yyyy
STAT #STAT_ID#
ww | #PEER_ENTITY_1#
zz | #PEER_ENTITY_2#
The following sample might help understanding the format:
ENTITYID https://idp.niif.hu/idp/shibboleth APIKEY 0123....... DATE 2009-03-18 STAT AUTH 68 logins STAT USER_COUNT 16 unique userids STAT SSO_TO_SERVICE 1 | urn:geant:niif.hu:niifi:sp:register.ca.niif.hu 12 | https://repo.niif.hu/shibboleth 1 | https://sandbox.aai.niif.hu/shibboleth 5 | https://sysmonitor.hbone.hu/shibboleth 10 | https://www.ki.iif.hu/shibboleth 1 | https://noc6.vh.hbone.hu/shibboleth 21 | https://webadmin.iif.hu/shibboleth 3 | https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth 7 | https://ugyeletes.vh.hbone.hu/shibboleth 2 | https://noc.grid.niif.hu/shibboleth 1 | https://wiki.voip.niif.hu/shibboleth 2 | https://netmonitor.hbone.hu/shibboleth 2 | https://idp.sch.bme.hu:443/opensso/sp/test
Running the log statistics collector
This following script can be used the collect statistics from the idp audit logs of Shibboleth 2 IdP generated on the day before running. It is based on Peter Schober's audit_r7.py, and good for run from daily cronjob:
#!/bin/bash
#Config section
PARSER_COMMAND="/opt/shibboleth-idp/bin/audit_r7.py"
SOURCEDIR="/opt/shibboleth-idp/logs"
TARGETDIR="/tmp"
ENTITYID="idp-entity-id"
APIKEY="aaa..."
LOCATION2PUT="https://fedstats.example.org/import_stats"
DATE=`date -d "yesterday" +"%Y-%m-%d"`
SOURCEFILE="$SOURCEDIR/idp-audit-$DATE.log"
#Should not edit below this
if [-f $SOURCEFILE ]()
then
LOGINS=`$PARSER_COMMAND -l $SOURCEFILE`
UNIQUE_LOGINS=`$PARSER_COMMAND -u $SOURCEFILE`
SERVICES=`$PARSER_COMMAND -p $SOURCEFILE | sed '/^[0-9]/p' -n`
TARGETFILE="stat-$DATE.log"
echo "ENTITYID $ENTITYID
APIKEY $APIKEY
DATE $DATE
STAT AUTH
$LOGINS
STAT USER_COUNT
$UNIQUE_LOGINS
STAT SSO_TO_SERVICE
$SERVICES
" > $TARGETDIR/$TARGETFILE
wget -q --no-check-certificate --post-file=$TARGETDIR/$TARGETFILE $LOCATION2PUT -O /dev/null
rm $TARGETDIR/$TARGETFILE
fi
The script below can be used the collect statistics from all the idp audit logs placed in a folder.
#!/bin/bash
#Config section
PARSER_COMMAND="/opt/shibboleth-idp/bin/audit_r7.py"
SOURCEDIR="/opt/shibboleth-idp/logs"
TARGETDIR="/tmp"
ENTITYID="idp-entity-id"
APIKEY="aaa..."
LOCATION2PUT="https://fedstats.example.org/import_stats"
FILES="idp-audit-*.log"
#Should not edit below this
cd $SOURCEDIR
for f in $FILES
do
if [-f $f ]()
then
echo "Processing $f file..."
DATE=${f:10:10}
LOGINS=`$PARSER_COMMAND -l $f`
UNIQUE_LOGINS=`$PARSER_COMMAND -u $f`
SERVICES=`$PARSER_COMMAND -p $f | sed '/^[0-9]/p' -n`
TARGETFILE="stat-$DATE.log"
echo "ENTITYID $ENTITYID
APIKEY $APIKEY
DATE $DATE
STAT AUTH
$LOGINS
STAT USER_COUNT
$UNIQUE_LOGINS
STAT SSO_TO_SERVICE
$SERVICES
" > $TARGETDIR/$TARGETFILE
wget -q --no-check-certificate --post-file=$TARGETDIR/$TARGETFILE $LOCATION2PUT -O /dev/null
rm $TARGETDIR/$TARGETFILE
fi
done
Feeding the database with the statistics
The federation statistics rails project contains the script/stat_parser/file.rb
command which can process the statistics format and load the data to the database. Note that this script currently contains an absolute path for the script/runner
script, so you must fix this before use.
Using HTTP-Post to feed the database
When deployed, the rails project provides a /import_stats
URL to which one could POST the generated statistics file.
Creating IdPs
Use the rails console to create new idps:
$ RAILS_ENV=production script/console
>> Entity.create :name => 'foo', :entity_type => 'idp'
=> #<Entity id: 1, name: "foo", entity_type: "idp", created_at: "2010-11-29 14:55:40", updated_at: "2010-11-29 14:55:40", api_key: "da9l233a45698fa5c4a252e301e3da2sf5ece24e">
HREFGlossary
Föderáció
Olyan bizalmi szövetség, melynek résztvevői elfogadják egymás felhasználóit azonosítottnak.
HREF Föderáció
(Hungarian Research and Education Federation, Magyar Kutatási és Felsőoktatási Föderáció), magyar felsőoktatási, kutatási intézmények és közgyűjtemények föderációja.
Föderációs Operátor
A Föderációs Operátor a Tagokkal és Partnerekkel megkötött csatlakozási szerződés alapján a HREF föderáció központi szolgáltatásainak működtetője. Elsődleges szerepe az, hogy a tagok közötti bizalmi viszonyt kialakítsa és fenntartsa.
Gyakorlati feladatai közé tartozik a központi szolgáltatások működtetése (Discovery Service, Resource Registry), a Metadata állomány karbantartása és rendszeres aláírása, valamint a tagokkal ill. partnerekkel való szerződéses viszony kialakítása. A Föderációs Operátor vállalt feladatait és ezek szolgáltatási szint paramétereit az SLA megállapodás tartalmazza.
Felhasználó
Egy Tag alkalmazottja, oktatási tevékenységet végző munkatársa ill. hallgatója, akik igénybevehetik a Tartalomszolgáltatók szolgáltatásait.
Tag
A HREF Föderációhoz a Föderációs Operátorral megkötött csatlakozási szerződés alapján csatlakozó intézmény. Ilyen módon csak magyar felsőoktatási, kutatási, ill. oktatási és közgyűjteményi tevékenységet folytató jogi személyek csatlakozhatnak.
A Tag azonosított felhasználói igénybe vehenek más tagok ill. Partnerek által biztosított szolgáltatásokat.
Partner
A HREF Föderációhoz a Föderációs Operátorral megkötött csatlakozási szerződés alapján csatlakozó partner intézmény.
Partner intézmény szolgáltatásokat biztosíthat Tagok által azonosított felhasználók számára.
Tagok Tanácsa
A Föderáció működését szabályozó dokumentumokat a Föderációs Operátor a Tagok Tanácsa jóváhagyásával módosíthatja.
IdP
Identity Provider. Szövegkörnyezettől függően jelentheti az Azonosító Szervezetet, ill. az IdP AAI Kaput.
Azonosító Szervezet
A felhasználók azonosítását elvégző intézmény ("saját intézmény"). Az azonosító szervezet - az adatvédelmi szabályok betartása mellett - a felhasználóról Attribútumokat adhat át a Tartalomszolgáltatónak
Attribútum
A felhasználóhoz kapcsolódó személyes adat, illetve a felhasználó intézményhez való viszonyát leíró adat. A felhasználó attribútumait az Azonosító Szervezet tartja karban. Az attribútumok egy jól meghatározott halmazát az azonosítási folyamat részeként az IdP AAI Kapu átadja a Tartalomszolgáltatónak.
IdP AAI Kapu
Az a szoftver, amely elvégzi a felhasználók azonosítását és lehetőséget biztosít az azonosítással kapcsolatos információk, valamint felhasználói adatok (Attribútumok) kiadására.
SP
Service Provider. Szövegkörnyezettől függően jelentheti a Tartalomszolgáltatót, ill. az SP AAI Kaput.
Tartalomszolgáltató
A Tartalomszolgáltató az Azonosító Szervezet azonosítása alapján, az arra jogosult felhasználók számára webes szolgáltatásokat nyújtó szervezet. A HREF Föderációban Tartalomszolgáltatóként részt vehet mind a Tag, mind a Partner.
SP AAI Kapu
Az a szoftver, amely értelmezi az Azonosító Szervezettől kapott adatokat, ellenőrzi a kapott üzenet az érvényességét és sértetlenségét, majd jogosultságellenőrzést végez.
Entitás
Az SP AAI Kapu és az IdP AAI Kapu összefoglaló neve.
Saját SP
Tag által üzemeltett webes szolgáltatás, amely kizárólag intézményen belül elérhető. Saját SP-k regisztrálhatók a Resource Registry segítségével, azonban a föderációs metadatában nem jelennek meg.
Resource Registry
A Resource Registry az HREF Föderáció működtetéséhez szükséges olyan nyilvántartás, amely az Azonosító Szervezetekre és a Tartalomszolgáltatókra vonatkozó információkat kezeli. A Resource Registry segítségével előállítható és szerkeszthető a föderációs Metadata, valamint az Azonosító Szervezetek által a Tartalomszolgáltatók részére átadandó információkra vonatkozó szabályok.
Discovery Service
A Föderációs Operátor által üzemeltetett Keresőszolgáltatás (Discovery Service) egy olyan webes felület, ahol a felhasználók kiválaszthatják az őket azonosítani tudó Azonosító Szervezetet.
Keresőszolgáltatást Tartalomszolgáltató és Azonosító Szervezet is üzemeltethet.
Metaadatok
(Metadata) Az HREF Föderációban résztvevő intézményeket leíró adatállomány. Az állomány tartalmaz:
- technikai információkat
- kontaktok elérhetőségi adatokat
- leíró adatokat Az állományban található adatokat, valamint az állomány kezelésével kapcsolatos előírásokat a Metadata Specifikáció részletezi.
Virtuális Azonosító Szervezet
(VHO, Virtual Home Organization) A Föderációs Operátor által üzemeltetett szolgáltatás, mely azonosítási szolgáltatást nyújt a Föderációban Tagként nem szereplő intézmények felhasználói számára, illetve lehetőséget biztosít a Tagok vendég felhasználói adminisztrálására is.
Shibboleth_IdP_telepítés__Debian_
!!! bug "Elavult információ"
**Figyelem**: a Shibboleth szoftver ezen változata már nem támogatott. Az új verziókhoz a leírások itt találhatók:
* [Shibboleth2_IdP](https://help.edu.hu/books/aai/page/shibboleth2-idp)
* [Shibboleth2_SP](https://help.edu.hu/books/aai/page/shibboleth2-sp)
Előkészületek
Tanúsítvány
Kell készíteni egy megfelelő SSL szerver tanúsítványt. Ha más nem szól ellene, érdemes ugyanazt a tanúsítványt használni a felhasználók felé, mint az SP-k felé.
Tűzfal
Be kell engedni a 443-as és a 8443-as portokat. Ha nagyon szigorúan vesszük, akkor a 8443-as portot elegendő csak a szóbajöhető SP-kről beengedni, de ezzel általában nem vagyunk tisztában, ezért célszerű a "nagyvilágból" beengedni. Biztonsági szempontból nem sok különbség van a 443-as és a 8443-as porton elérhető alkalmazások között.
Tomcat
JDK telepítés
Sajnos Etch alatt a sun-java5-jdk
csomag függ egy csomó X-es csomagtól, melyeket nem biztos, hogy szeretnénk telepíteni egy szerveren, érdemes lehet
- feltenni a
sun-java5-jre
csomagot ÉS - kézzel telepíteni egy JDK-t, mondjuk a http://java.sun.com oldalról letöltve
Ez igazából egy nagy hack, ugyanis ahhoz, hogy a tomcat-et csomagból telepíteni tudjuk, kell a java2-runtime
csomag, amelyet biztosít a JRE is, viszont a Tomcat-nek JDK kell, hogy JSP-t tudjon futtatni.
* <small>**Megj.:** Minden JSP-t első futtatáskor a konténer (Tomcat) lefordít Java kóddá, aztán byte-kóddá, ezért tart jó sokáig az - újraindítás utáni - első request. Ezután az eredményt elcache-eli, így csak akkor kell újrafordítania, ha a JSP megváltozik.</small>
A JDK telepítés elég egyszerű, letöltjük a java.sun.com oldalról a nekünk tetsző verziót, aztán kicsomagoljuk, mondjuk a /usr/lib
alá, aztán csinálunk egy szimbolikus linket, hogy a /usr/jdk
mindig a "jó" JDK-ra mutasson.
Tomcat telepítés
Ha minden rendben meg, akkor elegendő egy
apt-get install tomcat5.5
Ez felpakolja a tomcat különböző függőségeit is.
Ahhoz, hogy a Tomcat rendben elinduljon, szükséges neki megmondani, hogy hol találja a JDK-t. Ezért tegyük a /etc/default/tomcat5.5
fájlba a következőt:
JAVA_HOME=/usr/jdk
Ne felejtsük el, hogy a Tomcat szerver "tomcat55" user nevében fog futni! Mivel a Shibboleth servletnek szüksége van arra, hogy hozzáférjen a filerendszerhez, a Java Security Manager-t ki kell kapcsolni a /etc/default/tomcat5.5
fájlban:
TOMCAT5_SECURITY=no
Tomcat konfiguráció
A 8009-es porton figyelő Connector elem konfigurációjához hozzá kell adni, hogy a tomcatAuthentication
értéke "false" legyen, ezen kívül a hozzáférést korlátozhatjuk a localhost-ra is (hiszen a Connector-t csak a helyben futó Apache mod_jk konnektora érheti el).
<Connector port="8009" address="127.0.0.1" tomcatAuthentication="false"
enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
Apache
IdP-t telepíthetünk "standalone" Tomcat környezetre is, ekkor nincs szükségünk Apache-ra. A leírást ide kérjük :)
Az IdP telepítéséhez szükségünk lesz az alap apache szerverre (Etch-ben 2.2-es verziójú) és néhány modulra:
: alibapache-mod-ssl
mod_ssl
azapache2
csomag része.libapache2-mod-jk
A konfiguráció lépései:
mod_ssl
modul betöltése; figyelés a 8443-as porton ismod_jk
modul betöltése, konfigurálása- VirtualHost konfigurálása
- autentikáció konfigurálása
mod_ssl
/etc/apache2/ports.conf
Listen 443
Listen 8443
Engedélyezzük az SSL modult.
a2enmod ssl
mod_jk
A mod_jk
telepítés után alapértelmezetten engedélyezve van, ha mégsem lenne, az a2enmod jk
paranccsal engedélyezhetjük.
A /etc/libapache2-mod-jk/workers.properties
file-ban állítsuk be a workers.tomcat_home
és a workers.java_home
paramétereket a Tomcat ill. a JDK telepítésénél használt értékekre. (tomcat_home=/usr/share/tomcat5.5 az alapértelmezett telepítésnél.)
Már csak az van hátra, hogy bizonyos URI-kra érkező kéréseket a modul átküldje a Tomcat-nek. Ehhez az alábbi konfigurációs direktívákat kell megadnunk valahol a szerver konfigurációban (pl. /etc/apache2/apache2.conf
)
<IfModule mod_jk.c>
JkWorkersFile /etc/libapache2-mod-jk/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
JkMount /shibboleth-idp/* ajp13_worker
</IfModule>
A fenti példában a shibboleth-idp az IdP servlet telepítése során (később) megadott URI. Ez azt jelenti, hogy a /shibboleth-idp
URI alá jövő összes kérést a Tomcat fogja megkapni.
- RedHat ES4 disztribúció alatt az ajp13_worker helyett ajp13-t kellett használni.
VirtualHost
Nem feltétlenül szükséges külön VirtualHost-ban futtatni az IdP-t, de sok szempontból "tisztább" konfigurációt eredményez. Egy működő konfig:
<VirtualHost 193.224.163.21:443 [2001:738:0:600:216:3eff:fe00:18]:443>
ServerName papigw.aai.niif.hu
ServerAdmin root@niif.hu
DocumentRoot /var/www/papigw.aai.niif.hu/htdocs
CustomLog /var/log/apache2/papigw.aai.niif.hu.ssl_access.log combined
ErrorLog /var/log/apache2/papigw.aai.niif.hu.ssl_error.log
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/papigw.aai.niif.hu.crt
SSLCertificateKeyFile /etc/apache2/ssl/papigw.aai.niif.hu.key
<Location /shibboleth-idp/SSO>
AuthType Basic
AuthBasicProvider ldap
AuthName "Login to PAPIGW Identity Provider"
AuthLDAPURL ldaps://directory.iif.hu:636/ou=users,o=niifi,o=niif,c=hu?uid?one
AuthLDAPBindDN uid=papigw.aai.niif.hu,ou=https,ou=applications,o=niifi,o=niif,c=hu
AuthLDAPBindPassword ******
AuthzLDAPAuthoritative off
require valid-user
</Location>
</VirtualHost>
<VirtualHost 193.224.163.21:8443 [2001:738:0:600:216:3eff:fe00:18]:8443>
ServerName papigw.aai.niif.hu
ServerAdmin root@niif.hu
DocumentRoot /var/www/papigw.aai.niif.hu/htdocs
CustomLog /var/log/apache2/papigw.aai.niif.hu.ssl_access.log combined
ErrorLog /var/log/apache2/papigw.aai.niif.hu.ssl_error.log
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/papigw.aai.niif.hu.crt
SSLCertificateKeyFile /etc/apache2/ssl/papigw.aai.niif.hu.key
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSLVerifyClient optional_no_ca
SSLVerifyDepth 10
SSLOptions +StdEnvVars +ExportCertData
</VirtualHost>
- Megj.: IPv6-on is figyelünk :)
Autentikáció
SSO URI
Ez az az URI, amelyre az SP átirányítja a felhasználót, általában a szabványos https porton érhető el. A példában LDAP-ból azonosítjuk a felhasználót, majd az azonosított felhasználónevet a REMOTE_USER változóban adjuk át a Shibboleth IdP servletnek.
A <Location ...>
blokkban bármilyen azonosítást beállíthatunk (MySql, plain file, stb).
- Megj.: Az LDAP SSL használatához a leírás itt található
AA URI
Ezen az URI-n az SP-k kapcsolódnak hozzánk, hogy a felhasználóról adatokat kérjenek. Az SP-ket mindig tanúsítvánnyal azonosítjuk. "Természetesen" a request-et utána továbbítani kell a Tomcatben futó IdP servletnek. (Ezt a mod_jk fejezetben mutatott példában a JkMount /shibboleth-idp/*
megadásával értük el.)
IdP servlet telepítése
Az IdP innen tölthető le: http://shibboleth.internet2.edu/latest.html
A tar.gz állományt csomagoljuk ki, majd lépjünk be a létrejövő könyvtárba.
Endorsed jar állományok
Sajnos - legalábbis a cikk írásakor - a "kincstári" Sun-os Tomcat (Java?) JAXP parser egy ismert memóriaszivárgást tartalmaz, ezért a disztribúcióban az endorsed/
könyvtárban található .jar file-okat kézzel be kell másolni a Tomcat endorsed/
könyvtárába.
- A Debian alatti tomcat5.5 csomag használatakor a
/usr/share/tomcat5.5/common/endorsed
könyvtárba kell tenni a jar file-okat.
Installer
export JAVA_HOME=/usr/jdk
./ant
A telepítés során az alábbi paramétereket kell megadnunk:
- Shibboleth IdP alkalmazás neve: az URI, amelyre érkező kéréseket a Tomcat az IdP servletnek ad át. Default:
shibboleth-idp
- Filesystem- vagy manager-alapú telepítést akarunk? (Javasolt: Filesystem)
- Az IdP alkalmazás könyvtára. Default:
/usr/local/shibboleth-idp
- Tomcat home. Default:
/usr/local/tomcat
, Debian alatt a/var/lib/tomcat5.5
könyvtárat érdemes használni.
Könyvtárak
A telepítő minden file-t (binárisok, konfiguráció, logok, stb) egyetlen könyvtár alatti struktúrába tenne, de valószínűleg jobban járunk, ha az alkalmazásunk konfigurációja a /etc
, a logok pedig a /var/log
alatt találhatók.
Például:
export IDP_HOME=/usr/local/shibboleth-idp
mv $IDP_HOME/etc /etc/`basename $IDP_HOME`
ln -s /etc/`basename $IDP_HOME` $IDP_HOME/etc
mv $IDP_HOME/logs /var/log/`basename $IDP_HOME`
ln -s /var/log/`basename $IDP_HOME` $IDP_HOME/logs
Mivel a Debianon a Tomcat "tomcat55" user nevében fut, a szükséges állományokhoz hozzá kell tudnia férni
chown tomcat55 /var/log/`basename $IDP_HOME`
chmod 755 $IDP_HOME/bin/*
Ezek után már csak újra kell indítani a Tomcat-et, és az IdP-nek működnie kell. Ellenőrizni pl. úgy tudjuk, hogy meghívjuk a https://hostnev/shibboleth-idp/Status URI-t, amelynek az "AVAILABLE" stringet kell visszaadni.
Forrás
- Shibboleth Identity Provider Installation
- Shibboleth IdP installation with Debian and Tomcat
- Shibboleth IdP telepítése Debian 4.0 / Ubuntu 7.04 alatt (német nyelvű)
- Más környezetekre vonatkozó telepítési leírások
- SUSE 10
- OpenSUSE 10.2 (német)
- Tomcat-only telepítési leírások
- "Hivatalos" Tomcat-only leírás
- Debian + Tomcat
SimpleSAMLphp_NIIF_ldap_séma_mapping
A simpleSAMLphp különböző attribútum mappinget használ az attribúmnevek átfordításaihoz. A href ldap sémához még nincs, ezt a két file tartalmazza az oid - name oda-vissza mapping-et. Az attributemap könyvtárban van a helyük. A config.php authproc szabályai között kell felvenni őket, amikor szükség van rá.
config/config.php
...
'authproc.sp' => array(
...
11 => array(
'class' => 'core:AttributeMap', 'oid-href'
),
...
),
...
attributemap/href-oid.php
<?php
/**
* Hungarian Research and Education Federation AttributeSchema representation
* source: [https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif](https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif)
* @author: Szabó Gyula, aai.sztaki.hu <gyufi@sztaki.hu>
*
*/
$attributemap = array(
'niifPersonCityOfBirth' => 'urn:oid:1.3.6.1.4.1.11914.0.1.155',
'niifPersonDateOfBirth' => 'urn:oid:1.3.6.1.4.1.11914.0.1.152',
'niifPersonActivityStatus' => 'urn:oid:1.3.6.1.4.1.11914.0.1.153',
'niifPersonJoinDate' => 'urn:oid:1.3.6.1.4.1.11914.0.1.169',
'niifPersonOrgID' => 'urn:oid:1.3.6.1.4.1.11914.0.1.154',
'niifCertificateSubjectDN' => 'urn:oid:1.3.6.1.4.1.11914.0.1.151',
'niifEduPersonFacultyDN' => 'urn:oid:1.3.6.1.4.1.11914.0.1.161',
'niifPersonPosition' => 'urn:oid:1.3.6.1.4.1.11914.0.1.167',
'niifStatus' => 'urn:oid:1.3.6.1.4.1.11914.0.1.1',
'niifPersonIdentityNumber' => 'urn:oid:1.3.6.1.4.1.11914.0.1.158',
'niifTitle' => 'urn:oid:1.3.6.1.4.1.11914.0.1.2',
'niifCertificateSHA1Fingerprint' => 'urn:oid:1.3.6.1.4.1.11914.0.1.173',
'niifEduPersonAttendedCourse' => 'urn:oid:1.3.6.1.4.1.11914.0.1.164',
'niifEduPersonArchiveCourse' => 'urn:oid:1.3.6.1.4.1.11914.0.1.171',
'niifEduPersonHeldCourse' => 'urn:oid:1.3.6.1.4.1.11914.0.1.172',
'niifPrefix' => 'urn:oid:1.3.6.1.4.1.11914.0.1.0',
'niifPersonDegree' => 'urn:oid:1.3.6.1.4.1.11914.0.1.166',
'niifEduPersonFaculty' => 'urn:oid:1.3.6.1.4.1.11914.0.1.160',
'niifEduPersonMajor' => 'urn:oid:1.3.6.1.4.1.11914.0.1.162',
'niifPersonQuitDate' => 'urn:oid:1.3.6.1.4.1.11914.0.1.170',
'niifPersonMothersName' => 'urn:oid:1.3.6.1.4.1.11914.0.1.157',
'niifEduPersonAcademicYear' => 'urn:oid:1.3.6.1.4.1.11914.0.1.163',
'niifPersonCountyOfBirth' => 'urn:oid:1.3.6.1.4.1.11914.0.1.156',
'niifUniqueId' => 'urn:oid:1.3.6.1.4.1.11914.0.1.3',
'niifPersonPrefix' => 'urn:oid:1.3.6.1.4.1.11914.0.1.165',
'niifActiveMemberOf' => 'urn:oid:1.3.6.1.4.1.11914.0.1.168',
'niifPersonResidentalAddress' => 'urn:oid:1.3.6.1.4.1.11914.0.1.159',
'niifIDPrefix' => 'urn:oid:1.3.6.1.4.1.11914.0.1.100',
);
?>
/attributemap/oid-href.php
<?php
/**
* Hungarian Research and Education Federation AttributeSchema representation
* source: [https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif](https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif)
* @author: Szabó Gyula, aai.sztaki.hu <gyufi@sztaki.hu>
*
*/
$attributemap = array(
'urn:oid:1.3.6.1.4.1.11914.0.1.155' => 'niifPersonCityOfBirth',
'urn:oid:1.3.6.1.4.1.11914.0.1.152' => 'niifPersonDateOfBirth',
'urn:oid:1.3.6.1.4.1.11914.0.1.153' => 'niifPersonActivityStatus',
'urn:oid:1.3.6.1.4.1.11914.0.1.169' => 'niifPersonJoinDate' ,
'urn:oid:1.3.6.1.4.1.11914.0.1.154' => 'niifPersonOrgID',
'urn:oid:1.3.6.1.4.1.11914.0.1.151' => 'niifCertificateSubjectDN',
'urn:oid:1.3.6.1.4.1.11914.0.1.161' => 'niifEduPersonFacultyDN',
'urn:oid:1.3.6.1.4.1.11914.0.1.167' => 'niifPersonPosition' ,
'urn:oid:1.3.6.1.4.1.11914.0.1.1' => 'niifStatus',
'urn:oid:1.3.6.1.4.1.11914.0.1.158' => 'niifPersonIdentityNumber',
'urn:oid:1.3.6.1.4.1.11914.0.1.2' => 'niifTitle',
'urn:oid:1.3.6.1.4.1.11914.0.1.173' => 'niifCertificateSHA1Fingerprint',
'urn:oid:1.3.6.1.4.1.11914.0.1.164' => 'niifEduPersonAttendedCourse',
'urn:oid:1.3.6.1.4.1.11914.0.1.171' => 'niifEduPersonArchiveCourse',
'urn:oid:1.3.6.1.4.1.11914.0.1.172' => 'niifEduPersonHeldCourse',
'urn:oid:1.3.6.1.4.1.11914.0.1.0' => 'niifPrefix',
'urn:oid:1.3.6.1.4.1.11914.0.1.166' => 'niifPersonDegree' ,
'urn:oid:1.3.6.1.4.1.11914.0.1.160' => 'niifEduPersonFaculty',
'urn:oid:1.3.6.1.4.1.11914.0.1.162' => 'niifEduPersonMajor',
'urn:oid:1.3.6.1.4.1.11914.0.1.170' => 'niifPersonQuitDate' ,
'urn:oid:1.3.6.1.4.1.11914.0.1.157' => 'niifPersonMothersName',
'urn:oid:1.3.6.1.4.1.11914.0.1.163' => 'niifEduPersonAcademicYear',
'urn:oid:1.3.6.1.4.1.11914.0.1.156' => 'niifPersonCountyOfBirth',
'urn:oid:1.3.6.1.4.1.11914.0.1.3' => 'niifUniqueId',
'urn:oid:1.3.6.1.4.1.11914.0.1.165' => 'niifPersonPrefix' ,
'urn:oid:1.3.6.1.4.1.11914.0.1.168' => 'niifActiveMemberOf' ,
'urn:oid:1.3.6.1.4.1.11914.0.1.159' => 'niifPersonResidentalAddress',
'urn:oid:1.3.6.1.4.1.11914.0.1.100' => 'niifIDPrefix',
);
?>
Shibboleth3_IdP
Telepítési leírások
- Shibboleth 3 IdP telepítése (Debian 8 + Jetty 9.2)
- Shibboleth 3 IdP éles szolgáltatás építése (unix service)
Konfigurációs leírások
- Shibboleth 3 IdP metaadat beállítása
- Shibboleth 3 IdP hitelesítés beállítása
- Shibboleth 3 IdP attribútum feloldás beállítása
- Shibboleth 3 IdP attribútum szűrés beállítása
Interoperabilitás_mátrix
Interoperabilitás mátrix
Tesztelt szoftverek
- Shibboleth 2.0 IdP
- metadata: papigw-shibboleth2-idp.xml
- telepítési útvonal: /usr/local/shibboleth-idp-2.0.0
- protokollok: SAML1.1, Shibboleth1.3, SAML2.0
- Shibboleth 2.0 SP
- metadata: papigw-shibboleth2-sp.xml
- telepítés Debian csomagból, konfiguráció /etc/shibboleth/ alatt
- protokollok: SAML1.1, Shibboleth1.3, SAML2.0
- OpenSSO/FAM 8.0 CVS build - IdP
- metadata: maszat-opensso-idp.xml
- host: maszat.sch.bme.hu
- protokollok: SAML2.0
- simpleSAMLphp (?) - SP
- entityID: https://papigw.aai.niif.hu/simplesaml
- protokollok: Shibboleth1.3, SAML2.0
Tesztelt protokollok és bindingok
- SAML2.0 AuthnRequest/AuthnResponse protokoll (Web browser SSO profil)
- HTTP-GET / HTTP-POST binding
- HTTP-GET / HTTP-Artifact binding
- SAML2.0 AttributeQuery protokoll
- SAML2.0 Single Logout
SAML2.0 Interoperabilitás mátrix
Jelmagyarázat:
- Single Sign on - AuthnRequest/Response (Attribute push-sal együtt)
- HTTP-POST - SAML2.0 HTTP-Post binding
- HTTP-Artifact - SAML2.0 HTTP-Artifact binding
- Attribute query - SAML2.0 Attribute Query protocol
- Signing / encryption - az Assertion aláírása, aláírt és titkosított Assertion feldolgozása
- Metadata management - mennyire egyszerű megoldani hogy az IdP és az SP ismerje egymást
A zöld-del jelölt funkciók tökéletesen működnek, a narancssárgák nem triviálisan, de működésre bírhatók (ilyenkor mindig van megjegyzés is hozzájuk), a pirossal jelölt funkciók nem működtek. Az áthúzott funkciókat nem implementálja az adott szoftverpáros.
Sure, here's the HTML conversion of the provided MediaWiki table:
Shibboleth2 SP | OpenSSO SP | simpleSAMLphp SP | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Shibboleth2 IdP |
|
|
|
|||||||||||||||||||||
OpenSSO IdP |
|
|
|
|||||||||||||||||||||
simpleSAMLphp IdP |
|
|
|
HREF
Magyarországi felsőoktatási és kutatói föderáció (Hungarian Research & Education Federation)
A föderáció jelenleg technikai pilot státuszban van, azaz elsősorban a technikai együttműködésre, ill. a hosszú távú szabályozás előkészítésére koncentrálunk.
Tagjai
- Debreceni Egyetem
- Dunaújvárosi Főiskola
- ELTE
- Georgikon Keszthely
- MTA KFKI Csillebérc
- MTA Sztaki
- NIIF Intézet
- PPKE
- ZMNE
Szolgáltatások
URN
Támogatott szabványok
A föderáció a SAML2 szabvány protokolljait használja. Minden résztvevő támogatja a SAML2 SSO Profile-t HTTP POST bindingon keresztül, néhányan Artifact bindingon keresztül is. A legtöbb résztvevő támogatja a SAML2 Single Logout profile-t.
WebmailShibboleth
Shibboleth, Webmail, IMAP Proof-of-concept
In English
Requirements
- The webmail software must not see or use users' LDAP password, the IdP must not release even the hashed form of the password.
- IMAP must authenticate with username and password.
- If one has access to the webmail server, she must not have access to the IMAP on behalf of all users (she can however access to active users session).
Solution concepts
- The IdP and the IMAP server share an authentication database.
- With every webmail SP request the IdP generates a new password for that particular user and writes it to the database.
- The webmail SP receives this password with the attribute set and uses the username (e-mail address) and password to access the IMAP server.
- The IMAP server tries to authenticate against the database.
- In order to secure access, this password entry should contain an expiration time, which invalidates the password after the IdP session ends, so IMAP accepts only those users who has recently initiated active session at the IdP side.
Shibboleth IdP plugin
- We have developed an IdP plugin -attribute resolver- which can generate this short-lifetime password (called service token) for the user and write it to the database.
- Shibboleth IdP attribute resolver configuration is independent from the actual SP, so the plugin must check whether the current request came from an SP for which it needs to generate the token.
- The service token is sent in plain-text, so the Shibboleth attribute statement must be encrypted either by using artifact resolution over SSL/TLS or by using XML encryption with HTTP-Post.
IMAP configuration
- As we don't want to force the use of webmail, IMAP needs to use LDAP authentication as well.
- Most IMAP servers can be configured to use PAM, which can be configured to use arbitrary SQL tables for authentication and it also supports authentication chaining.
Webmail softwares
- For our proof-of-concept we have tried squirrelmail and roundcube with its HTTP-authentication plugin. If the SP is releasing the username and service token as PHP_AUTH_USER and PHP_AUTH_PW, this authentication module works out-of-the-box.
Magyarul
Koncepció
A webmail és a levelezőszerver (IMAP/POP3) együttes működését szeretnénk Shibbolizálni. A fő probléma abból áll, hogy a webmail az IMAP szerver felé felhasználónévvel és jelszóval autentikál. Az címtárban tárolt jelszót azonban nem adhatjuk ki az alkalmazásoknak, ráadásul legtöbb esetben ez egy hashelt jelszó.
A következő kritériumoknak kell teljesülniük:
- a webmail nem fér hozzá a felhasználó SSO jelszavához (még hashelt formátumban sem)
- az IMAP szerver jelszavas autentikációt használ, minden felhasználónak egyedi jelszava van
- a webmail feltörése esetén nem férhetnek hozzá az összes felhasználó levelezéséhez
A fenti kritériumokat az 'egyszer használatos', rövid lejáratú jelszó használata ('service token') kielégíti. Ebben az esetben az IdP minden egyes webmail bejelentkezéshez generál egy véletlen jelszót, és ezt elmenti egy adatbázisban, (beállítva a jelszóhoz egy rövid lejárati időt) valamint elküldi a webmail SP-nek. A webmail ezen rövid lejáratú jelszó használatával autentikál az IMAP szerver felé.
A leírt gondolatmenet megvalósításához három komponens együttműködése szükséges:
- az IdP jelszót kell generáljon egy adatbázisba
- a webmailnek el kell érnie ezt a jelszót
- az IMAP szervernek a jelszóadatbázist kell használnia az autentikációra
Adatbázis struktúra
MySQL használata esetén a következő adatbázisstruktúra használható:
CREATE TABLE `service_tokens` (
`uid` varchar(255) NOT NULL,
`password` varchar(255) NOT NULL,
`expiration` datetime NOT NULL,
PRIMARY KEY (`uid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
IdP plugin
Az IdP plugin aktuális verziója a következő URL-ről tölthető le: http://software.niif.hu/maven2/hu/niif/shibboleth-servicetoken/1.0. A shibboleth-servicetoken-1.0.jar
-t illetve a megfelelő adatbázis drivert (MySQL esetén mysql-connector.jar
) be kell másolni az idp.war WEB-INF/lib
könyvtárába.
Az attribute-resolver.xml
-ben a következő változtatásokat kell megtenni:
<!--xml semak megfelelo beallitasa -->
<AttributeResolver
....
xmlns:niifconnector="urn:geant:niif.hu:dataconnector"
xsi:schemaLocation="
....
urn:geant:niif.hu:dataconnector classpath:/schema/servicetokendataconnector.xsd">
<!-- onetimepassword definicio -->
<resolver:AttributeDefinition id="serviceToken" xsi:type="Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="serviceToken">
<resolver:Dependency ref="serviceTokenConnector" />
<resolver:AttributeEncoder xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:geant:niif.hu:servicetoken" friendlyName="serviceToken" />
</resolver:AttributeDefinition>
<!-- uid definicio -->
<resolver:AttributeDefinition id="uid" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="uid">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:uid" />
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" />
</resolver:AttributeDefinition>
<!-- service token generalasa -->
<resolver:DataConnector xsi:type="niifconnector:ServiceToken"
id="serviceTokenConnector"
sourceAttributeID="uid"
generatedAttributeID="serviceToken"
tableName="service_tokens"
principalColumn="uid"
passwordColumn="password"
expirationColumn="expiration"
passwordLifetime="XXXXXX"
spEntityID="https://webmail.example.org/shibboleth" >
<resolver:Dependency ref="myLDAP" />
<dc:ApplicationManagedConnection
jdbcDriver="com.mysql.jdbc.Driver"
jdbcURL="jdbc:mysql://localhost:3306/shib_idp"
jdbcUserName="*****"
jdbcPassword="*****" />
</resolver:DataConnector>
Fontos, hogy a DataConnector
(másodpercekben értelmezett) passwordLifetime
attribútumát jól állítsuk be, azaz hosszabb legyen, mint a webmail oldali SP session, de javasolt 24 óránál rövidebbre venni.
Az attribute-filter.xml
-ben pedig ki kell engedni az uid
és serviceToken
attribútumokat a webmail sp-nek:
<AttributeFilterPolicy id="sendServiceTokenToWebmail">
<PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
value="https://webmail.example.org/shibboleth" />
<AttributeRule attributeID="uid">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
<AttributeRule attributeID="serviceToken">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
</AttributeFilterPolicy>
IMAP konfiguráció (Cyrus imapd)
Imapd saját autentikáció
A Cyrus imapd-ben be kell állítani az SQL autentikációt. Ehhez a libsasl2-modules-sql debian csomagra is szükségünk lesz. A konfigurációt az imapd.conf-ban tehetjük meg:
sasl_mech_list: PLAIN
sasl_pwcheck_method: auxprop
sasl_auxprop_plugin: sql
sasl_sql_engine: mysql
sasl_sql_hostnames: localhost
sasl_sql_user: *****
sasl_sql_passwd: *****
sasl_sql_database: shib_idp
sasl_sql_select: SELECT password AS userPassword FROM service_tokens WHERE uid = '%u' AND expiration > now()
Amennyiben az IMAP szervert nem TLS/SSL felett használjuk, ezek a beállítások nem biztonságosak!
Használat PAM-mal
PAM használata esetén távolítsuk el a libsasl2-modules-sql csomagot, mert felesleges logüzeneteket gyárt. Ezen kívül szükség van a saslauthd-re is, amit debian alatt a sasl2-bin csomagban találhatunk.
Az imapd.conf-ot a következőképp kell beállítani:
sasl_mech_list: PLAIN
sasl_pwcheck_method: saslauthd
A saslauthd-t az /etc/default/saslauthd fájlban kell engedélyeznünk:
START=yes
MECHANISMS="pam"
Az /etc/pam.d/imap fájlban kell az imap pam beállításokat megtenni. Adatbázis használatához a libpam-mysql csomag is szükséges. Ha az adatbázisos felhasználókhoz nincs lokális account, akkor a PAM 'account' metódusát permit-re kell állítani.
auth sufficient pam_ldap.so
auth sufficient pam_mysql.so use_first_pass user=****** passwd=****** \
host=/var/run/mysqld/mysqld.sock db=shib_idp table=service_tokens usercolumn=uid passwdcolumn=password \
crypt=plain [where=expiration>now()]
auth required pam_deny.so
@include common-account
SP konfiguráció
A webmailt futtató webszerver Shibboleth konfigurációjában el kell fogadni a felhasználónevet és a jelszót az IdP-től. Az attribute-map.xml -hez a következő bejegyezéseket kell hozzáadni:
<Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="PHP_AUTH_USER"/>
<Attribute name="urn:geant:niif.hu:servicetoken" id="PHP_AUTH_PW"/>
Figyeljünk arra, hogy az attribute-policy.xml -ben ezeket az attribútumokat beengedjük! (Az alapértelmezett telepítés egy catch-all engedélyező szabályt tartalmaz, tehát az attribútum rendben meg fog jelenni.)
Webmail szoftverek konfigurációja
Squirrelmail
A Squirrelmailhez a Squirrelmail HTTP Authentication Plugin letöltésével és telepítésével elvégezhető az IdP által kiadott és az SP által láthatóvá tett felhasználónév és jelszó alapú bejelentkezés.
Roundcube
A HTTP Authentication Plugin telepítése után a plugin-ból el kell távolítani a következő sort:
public $task = 'login';
Shibboleth_IdP_konfigurációja
!!! bug "Elavult információ"
**Figyelem**: a Shibboleth szoftver ezen változata már nem támogatott. Az új verziókhoz a leírások itt találhatók:
* [Shibboleth2_IdP](https://help.edu.hu/books/aai/page/shibboleth2-idp)
* [Shibboleth2_SP](https://help.edu.hu/books/aai/page/shibboleth2-sp)
Az IdP alkalmazást az idp.xml
állományon keresztül konfigurálhatjuk. Ebben a leírásban feltételezzük, hogy az IdP alkalmazás konfigurációs állományai a /etc/shibboleth-idp
könyvtárban vannak.
Működő példa konfiguráció
<?xml version="1.0" encoding="ISO-8859-1"?>
<IdPConfig
xmlns="urn:mace:shibboleth:idp:config:1.0"
xmlns:cred="urn:mace:shibboleth:credentials:1.0"
xmlns:name="urn:mace:shibboleth:namemapper:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:idp:config:1.0 ../schemas/shibboleth-idpconfig-1.0.xsd"
AAUrl="https://idp.niif.hu:8443/shibboleth-idp/AA"
resolverConfig="file:/etc/shibboleth-idp/resolver.ldap.xml"
defaultRelyingParty="urn:niif.hu:aai:HREF"
defaultAuthMethod="urn:oasis:names:tc:SAML:1.0:am:password"
providerId="https://idp.niif.hu/shibboleth">
<RelyingParty name="urn:niif.hu:aai:HREF" signingCredential="href_cred">
<NameID nameMapping="shm"/>
</RelyingParty>
<RelyingParty name="urn:geant:niif.hu:niifi:sp:register.ca.niif.hu"
signingCredential="href_cred"
forceAttributePush="true">
<NameID nameMapping="shm"/>
</RelyingParty>
<ReleasePolicyEngine>
<ArpRepository implementation="edu.internet2.middleware.shibboleth.aa.arp.provider.FileSystemArpRepository">
<Path>file:/etc/shibboleth-idp/arps/</Path>
</ArpRepository>
</ReleasePolicyEngine>
<Logging>
<ErrorLog level="DEBUG" location="file:/var/log/shibboleth-idp/shib-error.log" />
<TransactionLog level="INFO" location="file:/var/log/shibboleth-idp/shib-access.log" />
</Logging>
<NameMapping
xmlns="urn:mace:shibboleth:namemapper:1.0"
id="shm"
format="urn:mace:shibboleth:1.0:nameIdentifier"
type="SharedMemoryShibHandle"
handleTTL="28800"/>
<ArtifactMapper implementation="edu.internet2.middleware.shibboleth.artifact.provider.MemoryArtifactMapper" />
<Credentials xmlns="urn:mace:shibboleth:credentials:1.0">
<FileResolver Id="href_cred">
<Key>
<Path>file:/etc/httpd/conf/ssl.key/idp.niif.hu.key</Path>
</Key>
<Certificate>
<Path>file:/etc/httpd/conf/ssl.crt/idp.niif.hu.crt</Path>
</Certificate>
</FileResolver>
</Credentials>
<ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.ShibbolethV1SSOHandler">
<Location>https?://[^:/]+(:(443|80))?/shibboleth-idp/SSO</Location> <!-- regex works when using default protocol ports -->
</ProtocolHandler>
<ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.SAMLv1_AttributeQueryHandler">
<Location>.+:8443/shibboleth-idp/AA</Location>
</ProtocolHandler>
<ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.SAMLv1_1ArtifactQueryHandler">
<Location>.+:8443/shibboleth-idp/Artifact</Location>
</ProtocolHandler>
<ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.Shibboleth_StatusHandler">
<Location>https://[^:/]+(:443)?/shibboleth-idp/Status</Location>
</ProtocolHandler>
<MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata"
uri="file:/etc/shibboleth-idp/href-metadata.xml"/>
</IdPConfig>
XML elemek magyarázata
IdPConfig
Az IdPConfig elem attribútumai közül az xmlns: és xsi: attribútumokat nem szabad megváltoztatni, de van néhány, amit kötelező:
- defaultRelyingParty: ez adja meg, hogy melyik RelyingParty-t kell használni, ha a request alapján nem állapítható meg. Ha nincs ehhez tartozó RelyingParty elem, akkor az IdP nem indul el.
- providerID: ez adja meg az IdP egyedi azonosítóját a föderációban. Általában URN vagy URL formában adjuk meg.
- resolverConfig: az attribútum feloldás konfigurációs állományát adja meg.
- AAUrl: az Attribute Authority elérhetősége. (Erre csak a Shibboleth 1.1-el való kompatibilitás megőrzése érdekében van szükség. Nem biztos, hogy kötelező megadni...)
Általában nem szükséges megadni:
- authHeaderName: itt kell megadni, ha az SSO Handler más változóban kapja meg a felhasználó azonosítóját (principal), mint a REMOTE_USER szerver változó
- defaultAuthMethod: megadható, hogy az elkészített SAML Assertion milyen autentikációs metódust tartalmazzon. A lehetséges értékek a SAML 1.1 specifikáció 7.1-es szakaszában találhatók. Ha nincs megadva, akkor az értéke
urn:oasis:names:tc:SAML:1.0:am:unspecified
. AdefaultAuthMethod
értéke RelyingParty szintjén felülbírálható - maxSigningThreads: az üzenet aláírására és egyéb műveletekre indított thread-ek maximális száma. Az IdP teljesítménye hangolható ezzel.
- passThruErrors: boolean változó, amely azt szabályozza, hogy a hibákat az IdP továbbadja-e az SP felé
Az IdP konfigurációban a többi XML Element az IdPConfig gyereke.
RelyingParty
Egy IdP tetszőleges mennyiségű RelyingParty-t kezelhet.
A legfelső szintű alapértelmezett beállításokon kívül minden egyes RelyingParty-ra beállíthatjuk az alábbi értékeket:
- name (kötelező): a RelyingParty neve. Ha nem egyezik meg az SP által küldött providerId-vel, akkor az IdP a metadata segítségével próbálja megállapítani, hogy az SP-re melyik RelyingParty definíció vonatkozik.
- providerId: az a providerId, amelyet az IdP használ a RelyingParty-k felé.
- signingCredential: az Assertion-ök és az SSL sessionben használt SSL kulcsokra vonatkozó FileResolver elem ID-jét adhatjuk meg itt.
- AAUrl: az Attribute Authority elérhetősége.
- defaultAuthMethod: megadható, hogy a RelyingParty számára elkészített SAML Assertion milyen autentikációs metódust tartalmazzon. A lehetséges értékek a SAML 1.1 specifikáció 7.1-es szakaszában találhatók. Ha nincs megadva, akkor az értéke az IdPConfig element-nél megadott érték, ill.
urn:oasis:names:tc:SAML:1.0:am:unspecified
. - passThruErrors: boolean változó, amely azt szabályozza, hogy a hibákat az IdP továbbadja-e az SP felé. Alapértelmezett érték: false
- signAssertions: boolean változó, amely azt szabályozza, hogy az IdP aláírja-e a kiállított Assertion-öket. Leginkább akkor van rá szükség, ha az Assertion-t más alkalmazásnál is fel akarjuk használni. Alapértelmezett érték: false
- forceAttributePush: boolean változó, ennek segítségével ki lehet kényszeríteni az Attribute Push használatát. Alapértelmezett érték: false
A RelyingParty element NameID gyermeke segítségével állítható be a használt NameID kezelés.
ReleasePolicyEngine
Itt adhatjuk meg az attribútum kiadás implementációját (ezt általában nem kell változtatni) és az ARP állományok elérhetőségét.
Logging
A Logging element szabályozza a naplózási szintet, ill. a naplófile-ok helyét. Részletesebb beállításokra a Log4J-t is használhatjuk. (Lásd még: Értelmes naplóüzenetek (IdP))
NameMapping
Ebben az elemben adható meg a NameMapper implementációja, illetve az assertionökben használt azonosító (Subject Identifier) formátuma.
- Az alapértelmezett értékek az esetek többségében megfelelők, csak akkor módosítsd, ha tudod, mit csinálsz!
Attribútumok:
- id: egyedi név, erre lehet hivatkozni a NameID elementben.
- format (URI): ez határozza meg a Subject Identifier formátumát. Tetszőleges URN használható, amiben az IdP és az SP megegyezik. Néhány gyakrabban használt formátum:
urn:mace:shibboleth:1.0:nameIdentifier
: alapértelmezett Shibboleth azonosító (tranziens, átlátszó)urn:oasis:names:tc:SAML1.1:nameid-format:X509SubjectName
: X.509 tanúsítvány DN. A GridShib használja ezt a formátumot.urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
: email-cím, használata nem javasolthttp://schemas.xmlsoap.org/claims/UPN
: MS UPN, az ADFS integrációhoz használható
- class: a NameMapper implementációjának a javaclass útvonala. (HAShib használatához módosítani kell.) A további attribútumok csak az alapértelmezett implementáció esetén értelmezhetők.
- handleTTL: azt határozza meg, hogy az IdP mennyi ideig őrizze a Session Cache-ében a kiosztott azonosítókat. (Csak
urn:mace:shibboleth:1.0:nameIdentifier
formátum esetén értelmezhető.) Ezt követően erre az azonosítóra történő hivatkozás már nem lesz megengedett, a felhasználónak esetleg újra kell azonosítania magát. - type: azt adja meg, hogy az SSO Handler és az Attribute Authority között milyen formában utazzanak az azonosítók. Lehetséges értékek:
CryptoHandleGenerator
: szimmetrikus kódolással titkosított azonosítók használataPrincipal
: az SSO Handler-től megkapott azonosító átadása az Attribute Authority-nekSharedMemoryShibHandle
: (alapértelmezett) megosztott, memóriában tárolt session cache. Ha az SSO Handler és az Attribute Authority egy konténerben futnak, ezt érdemes használni.
ArtifactMapper
Itt adható meg az ArtifactMapper implementációja. HAShib használata esetén át kell állítani.
Credentials
Ebben az elemben adhatók meg a használt titkos kulcsok és tanúsítványok. Több is megadható, az id attribútum értékével hivatkozhatunk rájuk, pl a RelayingParty konfigurációban.
ProtocolHandler
Itt adhatók meg az egyes handler servletek elérhetőségei. Általában nem szükséges felülírni!
Forrás
** Shibboleth Wiki**
Single_Logout_in_Shibboleth_IdP
Important notes on third party cookies
In some browsers, the IFrame-driven front-channel logout doesn't work due to the browser blocking third party cookies.
Additional links:
- Shibboleth-dev thread on the issue
- How to disable third party cookies in firefox
- Additional explanation in Mozilla Bugzilla
- Same origin policy for cookies
- Further information on third party cookie handling
"Although any third-party cookie restrictions are not a sufficient method to prevent cross-domain user tracking, they prove to be rather efficient in disrupting or impacting the security of some legitimate web site features, most notably certain web gadgets and authentication mechanisms."
Why service providers might need the session cookie
Most of the services do not need the session cookie itself, they only need the NameIdentifier, which is carried by the logout request, so back-channel logout requests are enough for them. But there might be service providers which do not implement back-channel bindings (eg. SimpleSAMLphp), or need front-channel application notification.
Why not fully back-channel?
SAML profiles specification (section 4.4.3.1) clearly states that front-channel should be preferred when sending the logoutrequest to the session authority (IdP). If the user interface is generated by the IdP, it could inform the user about the whole logout process, and each SP response. If the SP would use back-channel logoutrequest, the IdP's response would only contain minimal information (ie. success or failure), and this is not desirable. Also, the IdP would need to execute back-channel requests in parallel and synchronize them with the originating request, so this would make the processing code much more complex.
Technical solution
Our proposal is to prefer back-channel endpoints at the service provider side, unless your application needs to be notified via front-channel. For example,
- if your application behind your SP needs the session cookie with the notification, use only front-channel bindings in the SP metadata,
- otherwise use only back-channel binding in the SP metadata.
By these mutually exclusive endpoint sets, the SP can clearly advise the IdP which binding it should use when contanting this SP. Thus on the IdP side, both implementations need to be available.
Non-technical solution
Another option would be to add a new requirement for your end users. You can claim that banning third-party cookies is unsupported (because it breaks SLO), just like disabling all cookies (which breaks SSO). Convincing your users (and the Shibboleth developers to accept this solution) might be dubious, though.
Features
- Implements SAML2 Single Logout profile
- If initiated by an SP, user must confirm the single logout process: one can choose to logout only from the initiating SP and the IdP.
- Highly customizable front-channel logout interface which leverages javascript and asynchronous operations in order to provide a clean, simple UI.
- UI is usable with javascript disabled.
- Supports localized SP name lookup via Organization elements in SAML metadata .
- Fallback to back-channel logout if front-channel is not supported by the SP.
- Supports Shibboleth SSO sessions (if the SP initiates sessions using Shibboleth1.3 protocol, but supports SAML2 logout).
- Supports full back-channel operation.
- Supports IdP-initiated Single Logout.
UI customization
The UI is located in two JSP files:
sloQuestion.jsp
the user chooses whether she wants to logout from all service providers or just from the provider where she came from.sloController.jsp
is the logout UI where every session participant and their corresponding logout status is shown. At the end of the logout process, the user is notified if the single logout was completed.
How it works
SLOServlet
The heart of the logout process is the SLOServlet
. This servlet is responsible for these actions:
- rendering the logout question and controller page
- initiating front-channel or back-channel logout to one SP (
SLOServlet?action&entityID=...
) - returning the logout status as a JSON string (
SLOServlet?status
)
With javascript
The controller renders a page where an iframe is placed for every active session participant. This iframe calls the SLOServlet?action&entityID=...
URL where the logout request is issued for the given session participant. If the request is front-channel, the iframe will make a front-channel SAML message exchange with the peer (using HTTP-Redirect or POST bindings).
The status of the single logout process is queried via asynchronous requests. The status response from SLOServlet
is a JSON array. This JSON array contains one object with the entityID
and logoutStatus
properties for each session participant.
The logout status can be one of the followings:
LOGGED_IN
: logout is not initiated for this participant yet.LOGOUT_ATTEMPTED
: logout was initiated.LOGOUT_FAILED
: logout failed.LOGOUT_UNSUPPORTED
: SAML2 logout is not supported by the participant (the metadata does not contain the necessary endpoints).LOGOUT_TIMED_OUT
: timed out waiting for a response.LOGOUT_SUCCEEDED
: logout was successful.
Status queries are issued using exponential backoff timing, until the timeout is reached. Please see the sloController.jsp
for the exact timing used.
Without javascript
Controller renders an HTML page with <noscript>
tags. There is one link for each session participant opening up in new window/tab, which can initiate the logout process for that particular SP. Depending on the current logout status, several other controls are enabled on the page:
IdP-initiated Logout (available since v2.1.3-slo2)
The user can initiate their logout process from the IdP (the URL is /idp/Logout
). IdP-initiated logout has a clear advantage over SP-initiated logout, because the URL and the UI is fully independent from the current SP software used, thereby providing a unique logout URL for all users of the given IdP.
Non-trivial settings
Security
SAML Single Logout Profile requires the logout requests and responses to be signed or otherwise authenticated. Without this, a user session could be DOS-ed knowing the NameID.
You have two choices
- instruct the SP to sign messages
- configure the IdP not to require authentication of logout messages (and bear with possible DOS-attacks)
Signing messages
Signing can be turned on by setting the signing
property to front
(for front-channel only) or true
in the ApplicationDefaults
or ApplicationOverride
element in shibboleth2.xml.
!!! note
Signing messages is normally unnecessary for back-channel, as the transport is usually authenticated with the certificates in the metadata. However, for back-channel logout it is the IdP who initiates the HTTP connection to the SP, and it is the **webserver**, who answers the request. Because of the different needs, the webserver almost always uses a different certificate (a server certificate signed by a well-known CA) than the SP (possibly self-signed, client certificate). Therefore the SP must sign back-channel messages as well to authenticate itself to the IdP. Unfortunately, you can only enable signing all (otherwise transport protected) messages, and this may affect performance.
Not requiring peer authentication
Message issuer authentication can be turned off by changing the security policy of processing Single Logout messages. You can do this by commenting out the following line from the block SAML2SLOSecurityPolicy
at relying-party.xml
:
<security:Rule xsi:type="security:MandatoryMessageAuthentication" />
Session lifetime
IdP session lifetime must be longer than any SP session lifetime. Otherwise, if an SP session outlives the IdP session and the user reauthenticates for a new session for other SPs, logout would not terminate session at the first SP.
The IdP can limit the maximum lifetime of the SP session by using the (optional) SessionNotOnOrAfter
property in the SAML2 authentication statement. SAML1.1 does not have this feature, so you cannot limit the session lifetime for SPs using Shibboleth SSO protocol.
This can be set in the
relying-party.xml
by specifying the number of milliseconds in themaximumSPSessionLifetime
attribute of theSAML2SSOProfile
configuration.
Required changes in the IdP
Name identifier caching in IdP session
In the LogoutRequest the IdP must reference the current user's name identifier. This name identifier is issued as part of the SSO process. In order to efficiently retrieve this information, the IdP should cache the name identifier in the IdP session information object.
Associated ticket: SIDP-336
Session indexing
On receiving a LogoutRequest from a session participant, the IdP must be able to retrieve the IdP session associated with the principal. Session participants use the issued name identifier to identify the principal. The IdP session object can be indexed (and then retrieved of course) by any arbitrary unique key, so we use the name identifier value to index the session.
Associated ticket: SIDP-338
IdP Session invalidation
Currently there is a bug in the IdP implementation which causes the IdP sessions to outlive the session removal.
Associated ticket: SIDP-333
How to use
How to build
- install the maven2 build tool
- source code is available from our git repository
- you can use the convenient snapshot links below to start playing
- if you are brave enough, feel free to clone the whole repository and track our development branches (frontchannel-slo for the idp project and slo-configuration branch for the shibboleth-common project)
- compile the shib-java-common project first with the
mvn -DskipTests install
command (the first build might take quite a long time if you haven't used maven before) - compile the java-idp project with the same maven command
- install the
java-idp/target/shibboleth-identityprovider-{version}-bin.zip
binary package the same way as you'd install a vanilla Shibboleth IdP bundle
Released versions
- download the latest binary snapshot version from our software distribution site
v2.2.0-slo10
- fix configuration templates
- source code snapshots
v2.2.0-slo9
- allow EncryptedID to be used in the initiating request (patch contributed by Michael Simon from Karlsruher Institut für Technologie)
- expose method for programatical back-channel logout
- source code snapshots
v2.1.5-slo7
- use AttributeConsumingService/ServiceName to feed the logout interface
- source code snapshots
v2.1.5-slo6
- skip session-indexing under error conditions
- source code snapshots
v2.1.5-slo5
- fixed NullPointerException with non-existent or filtered NameIdentifiers
- fixed a flaw in session-indexing logic, use the whole NameIdentifier as the index, not just the value
- source code snapshots
v2.1.5-slo4
- upstream version bump
v2.1.4-slo4
- updated Shibboleth-core
- fixed NullPointerException introduced by an erroneous merge in v2.1.4-slo3
v2.1.3-slo3
- support Terracotta clustering
- source code snapshots
v2.1.3-slo2
- support IdP initiated logout
- source code snapshots
v2.1.3-slo1
- support SP initiated front- and back-channel logout
Hints
- Don't forget to include Single Logout endpoints in the IdP metadata
- Shibboleth SP prior to 2.1 did not include NameID properly in the LogoutRequest, therefore you cannot initiate SLO with Shibboleth SPs older than 2.1
- Shibboleth SP prior to 2.2.1 answered with Partial logout for back-channel requests due to a bug
- Shibboleth SP (currently released versions) do not distinguish between Success and Partial logout when showing the UI (see this report for details). This is not needed unless you are using back-channel logout.
- If you plan to upgrade a clustered IdP to this version, don't forget to check the new tc-config.xml and rebuild the terracotta boot jar
Missing features
- Administrative logout
- Logout the user in the underlying JAAS provider
Shib2IdpTomcat6
Ezt a lapot össze kellene vonni ezzel, és az elavult infókat frissíteni
JVM beállítások
A Tomcat6 jelenleg nem működik együtt tökéletesen 6-os JVM-mel (egész pontosan a commons-dbcp csomag a JDBC API pici megváltozása miatt), ezért egyelőre ajánlott 5-ös JVM-mel futtatni - FIXME.
A Shibboleth2 IdP nem hajlandó elindulni a JVM-mel szállított Sun-féle Xerces implementációval, ezért az IdP csomaggal szállított Xerces és Xalan implementációkat be kell másolni a $JAVA_HOME/lib/endorsed könyvtárba, vagy a következő kapcsolóval kell indítani a Tomcat-et:
java -Djava.endorsed.dirs=/path/to/xerces-libs
Shibboleth IdP telepítése
A kitömörített bináris disztribúció könyvtárában adjuk ki a
sh ant.sh
parancsot, ami megkérdezi a telepítési könyvtárat (${SHIB_HOME}) és a hostnevet, majd elkészíti azt, legenerálja a teszt-céllal használható kulcsokat és tanúsítványokat (ezeket a credentials könyvtárba teszi idp.key, idp.crt néven).
Ezután a tomcat-et futtató felhasználónak (nálam: tomcat) írási jogot kell adni a log könyvtárra, majd telepíthetjük az idp webalkalmazást a tomcat webapps root alá (nálam: a /var/lib/tomcat-6/webapps/ROOT)
chown tomcat:tomcat ${SHIB_HOME}/logs
cp ${SHIB_HOME}/war/idp.war /var/lib/tomcat-6/webapps/ROOT
Új SAML SP felvétele
Egy új SP felvételéhez csak az SP metaadatára van szükségünk SAMLv2 szabványos XML formában. A metaadatot vagy fizikailag el kell helyezni a ${SHIB_HOME}/metadata könyvtárban, vagy egy URL-en elérhetővé kell tenni a Shibboleth IdP számára.
Metaadat-források megadása a ${SHIB_HOME}/conf/relying-party.xml -ben
<!-- több provider megadása láncolással -->
<MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata">
<!-- Fájlrendszerből olvasott metaadat -->
<!-- Fill in metadataFile attribute with deployment specific information -->
<MetadataProvider id="sp1" xsi:type="FilesystemMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
metadataFile="${SHIB_HOME}/metadata/sp1-meta.xml" maintainExpiredMetadata="true">
<!--Metaadat aláírás ellenőrzése -->
<!--MetadataFilter xsi:type="SignatureValidation" trustEngineRef="shibboleth.MetadataTrustEngine" /-->
</MetadataProvider>
</MetadataProvider>
SAMLv2 Profilok beállítása
A ${SHIB_HOME}/conf/relying-party.xml -ben kell a következő módosításokat eszközölni:
Először a SAMLv2 SSO Profil alapbeállításai
<!-- a saját IDP entityID-je, amivel minden SP-hez egyszerre beállíthatjuk mint provider -->
<DefaultRelyingParty
provider="https://idp.example.com/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential">
<!--
5 perces assertion érvényesség (óraszinkronizálás IdP - SP között fontos!)
A válaszok kötelező digitális aláírása
Attribútum push
-->
<ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
includeAttributeStatement="true"
assertionLifetime="300000"
assertionProxyCount="0"
signResponses="always"
signAssertions="never"
encryptAssertions="conditional"
encryptNameIds="conditional" />
</DefaultRelyingParty>
SP esetén az alapértelmezett beállítások felülírása:
<RelyingParty
id="https://sp1.example.com/shibboleth"
provider="https://idp.example.com/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential">
<ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never"/>
</RelyingParty>
Attribútum kiadása (címtárból)
Egy attribútum kiadásához két dolgot kell beállítani: a resolver-t és a filter-t. Előbbi felelős az attribútum megszerzéséért és a session kontextusba helyezésért, utóbbi az SP felé történő kiadást szabályozza.
Új attribútum beolvasása címtárból (${SHIB_HOME}/conf/attribute-resolver.xml) és SAMLv1 illetve SAMLv2 AttributeStatement -be kódolása:
<resolver:AttributeDefinition id="email" xsi:type="Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="mail">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="SAML1String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:mail" />
<resolver:AttributeEncoder xsi:type="SAML2String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />
</resolver:AttributeDefinition>
A resolver:Dependency adja meg azt a forrást, amiből az attribútum feloldásra kerül. Ez esetünkben a myLDAP:
<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://ldap.example.com" baseDN="ou=people,dc=example,dc=com"
principal="userid=shibboleth,ou=systems,dc=example,dc=com"
principalCredential="password">
<FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</FilterTemplate>
</resolver:DataConnector>
NameIdentifier leképzés
Szintén az attribute-resolver.xml -ben kell beállítani az Assertion Subject NameID -t, ami az IdP-SP közötti azonosítóért felel. Példaképp egy SAMLv2 Tranziens azonosítót a következőképp állíthatunk be:
<resolver:AttributeDefinition id="transientId" xsi:type="TransientId" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
<resolver:AttributeEncoder xsi:type="SAML2StringNameID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
</resolver:AttributeDefinition>
<resolver:PrincipalConnector xsi:type="Transient"
xmlns="urn:mace:shibboleth:2.0:resolver:pc"
id="saml2Transient"
nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />