HREF/eduID föderáció

• HREF
• Tagok
• Dunaújvárosi Főiskola IdP
• MTA Sztaki IdP
• NIIFI IdP
• HREFContract
• HREF műszaki előírások
• HREFChecklist
• HREF alapelvek és alapvető szabályok
• HREF attribútum specifikáció
• HREFJoin
• HREF szolgáltatási szint megállapodás
• HREFServices
• HREF Key Rollover 2020
• HREF Key Rollover 2020 English
• HREF Key Rollover 2025
• ProviderId
• HREF Key Rollover 2025 English
• Federation Policy
• HREFUseCaseStub
• Sirtfi
• HREFPolicyStub
• HREFMetadataRegistrationPracticeStatement
• HREF metadata specifikáció
• FederationStats
• HREFGlossary
• Attribute Conversion for eduGAIN
• URN
• URN SCHAC
• URN Registry
• AboutEduID.hu
• EduidFedStats
• FedReqDef
• Metadata Specification
• JoiningEduGAIN
• MDX
• FedDev
• Attribute Specification

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.

Tagok

Dunaújvárosi Főiskola IdP

MTA Sztaki IdP

NIIFI IdP

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

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
    • mail
    • 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.

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.

HREF alapelvek és alapvető szabályok

Föderációs alapelvek

1. 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.
2. Az IdP csak abban az esetben azonosít egy felhasználót, ha az illető valamilyen - ismert - viszonyban van az intézménnyel.
3. Az IdP és az SP nem ad meg magáról hamis, félrevezető információt.
4. 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.
5. 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.
6. 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.
7. Az SP nem kérheti a felhasználót, hogy adja meg az IdP-nél érvényes jelszavát.
8. Az SP-nél történő adatkezelés a törvényi előírások szerint működik.
9. Felhasználói visszaélések vizsgálatában az IdP és az SP együttműködik egymással.
10. Az IdP és az SP az informatikai rendszereit az elvárható gondossággal üzemelteti.

Szabályok

Adatvédelmi szabályok

1. 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.
2. 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.
3. Mind a Tag, mind a Partner a mindenkor hatályos adatkezelési szabályzatukat elérhetővé teszik.

Üzemeltetési szabályok

1. 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
2. A Föderációs Operátor jogosult ellenőrizni a vonatkozó szabályok betartását.
3. 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.
4. 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

1. Az Azonosító Szervezet biztosítja, hogy a felhasználó regisztrációs folyamatai dokumentáltak legyenek.
2. Csak olyan felhasználó azonosítható, akinek az intézményhez való viszonya egyértelműen megállapítható.
3. 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.
4. 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.
5. 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.

1. 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.
2. A föderáció Partnere tetszőleges szervezet lehet
3. A föderáció Tagjai és Partnerei jogosultak a föderációban szolgáltatásokat üzemeltetni
4. A Partner a Tagok Tanácsa ülésein megfigyelőként részt vehet, azonban szavazati joggal nem rendelkezik.
5. Csak Tagok jogosultak:
   • felhasználói adatokat szolgáltatni;
   • a Tagok Tanácsába szavazati joggal rendelkező képviselőt küldeni.

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
• 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

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

Ajánlott attribútumok

Á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ó?

1. Ha nem, akkor egyértelmű a választás: tranziens formátumot kell használni.
2. 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ó.
3. 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.
4. 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-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

<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>

eduPersonPrincipalName

niifPersonOrgID

schacPersonalUniqueCode

Felhasználói tulajdonságokat leíró attribútumok

sn

givenName

displayName

mail

preferredLanguage

schacDateOfBirth

schacYearOfBirth

schacPersonalTitle

niifPersonMothersName

niifPersonResidentalAddress

homePostalAddress

telephoneNumber

mobile

eduPersonNickName

cn

jpegPhoto

labeledUri

Felhasználó és az intézmény viszonyát leíró attribútumok

eduPersonScopedAffiliation

eduPersonEntitlement

schacHomeOrganizationType

ou

eduPersonOrgUnitDN

eduPersonPrimaryOrgUnitDN

Oktatásban használt attribútumok

niifEduPersonAttendedCourse

niifEduPersonArchiveCourse

niifEduPersonHeldCourse

niifEduPersonMajor

niifEduPersonFaculty

niifEduPersonFacultyDN

niifEduPersonStudentCategory

HREFJoin

Az eduID föderációhoz való csatlakozás folyamata

1. A csatlakozni kívánó tag/partner jelzi csatlakozási szándékát a Föderációs Operátor felé.
2. 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.
3. 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.
4. A Föderációs Operátor elkészíti a Tag számára a szükséges HEXAA jogosultságokat
5. 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
6. Tagok Tanácsa dönt a csatlakozni kívánó tag/partner kérelméről
7. 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

1. 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.
2. 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

1. 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.
2. 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

1. A Föderációs Operátor a Resource Registry-ben rögzíti az SP minden szükséges adatát.
2. 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.
3. 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.

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

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.

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

SHA1 fingerprints

Domain név változások

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

https://github.com/simplesamlphp/simplesamlphp-module-metarefresh/blob/master/docs/simplesamlphp-automated_metadata.md

// 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?

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

SHA1 fingerprints

Domain names

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

https://github.com/simplesamlphp/simplesamlphp-module-metarefresh/blob/master/docs/simplesamlphp-automated_metadata.md

// 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'],
],

HREF Key Rollover 2025

Bevezetés

A HREF új metaadat aláírókulcsra áll át a SAML 2.0 metaadataiban (HREF-2025). A HREF szövetségi tagoknak és partnernek az új aláírókulcshoz tartozó konfigurációkat 2025. juniús 14.-ig frissíteniük kell az összes eduID.hu-t támogató rendszerükben. Ezt követően a régi - több, mint 4 éves aláírókulcs (HREF-2020) - 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

SHA1 fingerprints

Domain név változások

Discovery Service változások

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-2020" url="https://mdx-2020.eduid.hu" backingFilePath="href-2020.xml">
        <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
    </MetadataProvider>
    <MetadataProvider type="XML" id="href-2025" url="https://mdx-2025.eduid.hu" backingFilePath="href-2025.xml">
        <MetadataFilter type="Signature" certificate="href-metadata-signer-2025.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-2020" ignoreTransport="true" baseUrl="https://mdx-2020.eduid.hu/">
    <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
    <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
<MetadataProvider type="MDQ" id="href-2025" ignoreTransport="true" baseUrl="https://mdx-2025.eduid.hu/">
    <MetadataFilter type="Signature" certificate="href-metadata-signer-2025.crt"/>
    <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>

példa

apache + shibboleth 3.X - sed segítségével

sudo sed 's/mdx-2020.eduid.hu/mdx-2025.eduid.hu/g' /etc/shibboleth/shibboleth2.xml -i
sudo sed 's/href-2020/href-2025/g' /etc/shibboleth/shibboleth2.xml -i
sudo sed 's/href-metadata-signer-2020.crt/href-metadata-signer-2025.crt/g' /etc/shibboleth/shibboleth2.xml -i
sudo sed 's#https://mdx-202..eduid.hu/role/idp.ds#https://mdx-2025.eduid.hu/discovery/ds#g'  /etc/shibboleth/shibboleth2.xml -i
sudo systemctl restart shibd.service apache2.service

Shibboleth 2.X

<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>
<MetadataProvider type="Dynamic" id="href-2025" ignoreTransport="true">
    <Subst>https://mdx-2025.eduid.hu/entities/$entityID</Subst>
    <MetadataFilter type="Signature" certificate="href-metadata-signer-2025.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-2025.xml"
                  metadataURL="https://metadata.eduid.hu/2025/href.xml">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2025.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-2025.xml"
                  metadataURL="https://metadata.eduid.hu/2025/href.xml">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2025.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-2025.crt"/>

    <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>

    <MetadataQueryProtocol>https://mdx-2025.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-2025.crt"/>

    <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>

    <MetadataQueryProtocol>https://mdx-2025.eduid.hu/</MetadataQueryProtocol>

</MetadataProvider>

SimpleSAMLphp

MDX

//config/config.php
'metadata.sources' => [
     ['type' => 'flatfile'], // ez a *-hosted metadata konfiguráció betöltése miatt szükséges
     [
         'type' => 'mdq',
         'server' => 'https://mdx-2025.eduid.hu',
         /* --- */
         'validateFingerprint' => '45:B2:33:96:7C:4F:7E:42:86:8D:CC:CF:CC:0E:3E:1C:2E:24:C2:DE'
     ],
],

metarefresh

https://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_3

https://github.com/simplesamlphp/simplesamlphp-module-metarefresh/blob/master/docs/simplesamlphp-automated_metadata.md

// config/config-metarefresh.php
$config = [
   'sets' => [
       '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',
       ],
       'href-2025' => [
           'cron'      => ['hourly'],
           'sources'   => [
               [
                   'src' => 'https://metadata.eduid.hu/2025/href.xml',
                   'validateFingerprint' => '45:B2:33:96:7C:4F:7E:42:86:8D:CC:CF:CC:0E:3E:1C:2E:24:C2:DE',
               ],
           ],
           'expireAfter'       => 777600, // 9 nap.
           'outputDir'     => 'metadata/metarefresh-href-2025/',
           'outputFormat' => 'flatfile',
       ],
    ],
];

// config/config.php
'metadata.sources' => [
    ['type' => 'flatfile'],
    ['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2020'],
    ['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2025'],
],

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?

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 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 2025 English

Introduction

The Hungarian Research and Educational Federation is migrating to a new metadata signing certificate (HREF-2025).

All HREF members and partners must update their IdP and SP configurations with the new signing certificate by June 14, 2025, in order to ensure uninterrupted access to federated services supporting eduID.hu. After this date, the old signing certificate (HREF-2020), which has been in use for more than 4 years, will be decommissioned, and 10 days after its last use, the old metadata will become invalid.

The tables below contain all necessary data for the transition. Where possible, configuration examples offer solutions that allow simultaneous use of both the old and new metadata.

Key Rollover

Code names

SHA1 fingerprints

Domain names

Discovery Service change

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-2020" url="https://mdx-2020.eduid.hu" backingFilePath="href-2020.xml">
        <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
    </MetadataProvider>
    <MetadataProvider type="XML" id="href-2025" url="https://mdx-2025.eduid.hu" backingFilePath="href-2025.xml">
        <MetadataFilter type="Signature" certificate="href-metadata-signer-2025.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-2020" ignoreTransport="true" baseUrl="https://mdx-2020.eduid.hu/">
    <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
    <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>
<MetadataProvider type="MDQ" id="href-2025" ignoreTransport="true" baseUrl="https://mdx-2025.eduid.hu/">
    <MetadataFilter type="Signature" certificate="href-metadata-signer-2025.crt"/>
    <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
</MetadataProvider>

példa

apache + shibboleth 3.X - sed segítségével

sudo sed 's/mdx-2020.eduid.hu/mdx-2025.eduid.hu/g' /etc/shibboleth/shibboleth2.xml -i
sudo sed 's/href-2020/href-2025/g' /etc/shibboleth/shibboleth2.xml -i
sudo sed 's/href-metadata-signer-2020.crt/href-metadata-signer-2025.crt/g' /etc/shibboleth/shibboleth2.xml -i
sudo sed 's#https://mdx-202..eduid.hu/role/idp.ds#https://mdx-2025.eduid.hu/discovery/ds#g'  /etc/shibboleth/shibboleth2.xml -i
sudo systemctl restart shibd.service apache2.service

Shibboleth 2.X

<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>
<MetadataProvider type="Dynamic" id="href-2025" ignoreTransport="true">
    <Subst>https://mdx-2025.eduid.hu/entities/$entityID</Subst>
    <MetadataFilter type="Signature" certificate="href-metadata-signer-2025.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-2025.xml"
                  metadataURL="https://metadata.eduid.hu/2025/href.xml">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2025.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-2025.xml"
                  metadataURL="https://metadata.eduid.hu/2025/href.xml">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2025.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-2025.crt"/>

    <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>

    <MetadataQueryProtocol>https://mdx-2025.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-2025.crt"/>

    <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>

    <MetadataQueryProtocol>https://mdx-2025.eduid.hu/</MetadataQueryProtocol>

</MetadataProvider>

SimpleSAMLphp

MDX

//config/config.php
'metadata.sources' => [
     ['type' => 'flatfile'], // ez a *-hosted metadata konfiguráció betöltése miatt szükséges
     [
         'type' => 'mdq',
         'server' => 'https://mdx-2025.eduid.hu',
         /* --- */
         'validateFingerprint' => '45:B2:33:96:7C:4F:7E:42:86:8D:CC:CF:CC:0E:3E:1C:2E:24:C2:DE'
     ],
],

metarefresh

https://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_3

https://github.com/simplesamlphp/simplesamlphp-module-metarefresh/blob/master/docs/simplesamlphp-automated_metadata.md

// config/config-metarefresh.php
$config = [
   'sets' => [
       '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',
       ],
       'href-2025' => [
           'cron'      => ['hourly'],
           'sources'   => [
               [
                   'src' => 'https://metadata.eduid.hu/2025/href.xml',
                   'validateFingerprint' => '45:B2:33:96:7C:4F:7E:42:86:8D:CC:CF:CC:0E:3E:1C:2E:24:C2:DE',
               ],
           ],
           'expireAfter'       => 777600, // 9 nap.
           'outputDir'     => 'metadata/metarefresh-href-2025/',
           'outputFormat' => 'flatfile',
       ],
    ],
];

// config/config.php
'metadata.sources' => [
    ['type' => 'flatfile'],
    ['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2020'],
    ['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2025'],
],

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?

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 Pro-M (successor of KIFÜ which is successor of 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:

• eduid@pro-m.hu
• Péter Molnár and János Mohácsi, Pro-M 35 Váci út H-1134 Budapest Hungary

News and information about the federation is published at http://eduid.hu (Hungarian only)

Policy and principles of interoperation

Basic principles

1. 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.
2. Home Institutions must only authenticate users having a known affiliation to them.
3. IdPs and SPs must not give false or misleading information about themselves.
4. 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.
5. User credentials (i.e. passwords) stored by IdPs must be protected and verified only through secure procedures.
6. SPs must request only the user attributes which are absolutely necessary for their operation.
7. SPs must not ask users for their federation passwords.
8. SPs must handle personal data according to the local privacy laws.
9. IdPs and SPs must cooperate in the investigation of possible abuse/fraud.
10. 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.

1. 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.
2. Any organisation might join as a Partner.
3. All Members and Partners of the Federation might provide services.
4. A Partner might participate in the meeting of the Members' Board as an observer, without having rights to vote.
5. 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.

MB is authorised to

• 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.

HREFUseCaseStub

NIIF AAI felhasználási lehetőségek

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.

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.

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.

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 illetve ContactPerson 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útumokat
      • RequestedAttributes - itt az attribútum informális neve is szerepeljen
      • ServiceName, 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:

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 link
  • height: opcionális magasság érték pixelben
  • width: 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:

1. Az aláíratlan metaadat a https://rr.eduid.hu oldalról ütemezetten, minden óra 15. és 45. percében letöltésre kerül.
2. A letöltött metaadat XML séma ellenőrzése ellenőrzése.
3. 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.

HREF-2020

• A HREF-2020 tanúsítvány a https://metadata.eduid.hu oldalról érhető el.

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:

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

FederationStats

Federation usage statistics

A szócikk vagy fejezet még megírásra vár

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 the rake 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.

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.

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:

1. Default action is to deny ALL attributes.
2. You can allow/deny whole attributes or specific values of the attributes.
3. 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.

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} &lt;${mail}&gt;</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 &amp;lt;adam.lantos@niif.hu&amp;gt;</AttributeValue>
       <AttributeValue>Adam Lantos &amp;lt;hege@niif.hu&amp;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

A szócikk vagy fejezet még megírásra vár

Please post your BE configuration here.

Hungarnet

Home

Remote

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Ü

URN SCHAC

URN schac sémák

URN Registry

Géant névtér

A Dante regisztrált egy önálló namespace-t a Géant számára urn:geant néven. Ezt a namespace-et közvetlenül a Dante felügyeli.

A regisztrált névterek listája itt tekinthető meg.

URN Registry Application

A RedIris kifejlesztett egy URN névtér kezelő alkalmazást, amelyben definiálni lehet az egyes URN-ek jelentését.

Az URNReg alkalmazás itt érhető el.

Függőségek

• Apache (kipróbálva: 2.2.3)
• PHP (kipróbálva: 5.2.0)
• LDAP szerver (kipróbálva: slapd 2.3.30)
• SiLeDAP (kipróbálva: 0.2)

Slapd inicializálás

A Quickstart Guide alapján SEM kell megtenni, mert a Debian telepítő elintézi helyettünk.

Schema

Be kell másolni a kicsomagolt program alatt a schemata/urnReg.schema a /etc/ldap/schema/ könyvtárba, és a /etc/ldap/slapd.conf -ban include-olni kell.

• BUG1: A schema állományból töröljük az sn1 és sn2 attribútumokra való hivatkozásokat!

SiLeDAP

Fogalmam sincs, mit csinál ez a függőség. A leírás szerint így kell telepíteni:

mkdir siLeDAP
cd siLeDAP
tar xzvf /tmp/siledap-api-0.2.tar.gz

• BUG2: a tar.gz tele van ._Ldap kezdetű állományokkal. Ezeket törölni kell.

Be kell állítani az LDAP kapcsolat paramétereit az LdapConf.php állományban. A file tartalmaz egy HTTP_BASE változót, arra nem lesz szükség, kommenteljük ki.

simpleSAMLphp

Konfiguráció

config.php

browser/js/URNregConfig.js

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

1. 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.
2. Home Institutions must only authenticate users having a known affiliation to them.
3. IdPs and SPs must not give false or misleading information about themselves.
4. 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.
5. User credentials (i.e. passwords) stored by IdPs must be protected and verified only through secure procedures.
6. SPs must request only the user attributes which are absolutely necessary for their operation.
7. SPs must not ask users for their federation passwords.
8. SPs must handle personal data according to the local privacy laws.
9. IdPs and SPs must cooperate in the investigation of possible abuse/fraud.
10. 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.

1. 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.
2. Any organisation might join as a Partner.
3. All Members and Partners of the Federation might provide services.
4. A Partner might participate in the meeting of the Members' Board as an observer, without having rights to vote.
5. 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.

MB is authorised to

• 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

• SP Operational Requirements
• IdP 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.

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

1. Kivonatoló python szkript letöltése. Jelenleg Shibboleth-hez és simpleSAMLphp-hez készítettük el.
2. 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.
3. 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

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

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 until Sep 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:
  • https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeInMetadata
  • https://wiki.shibboleth.net/confluence/display/IDP30/EntityAttributeExactMatchConfiguration

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.

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>

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

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.
• 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.

Attributes

Summary

Mandatory attributes

Recommended attributes

Optional attributes

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

<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>

eduPersonPrincipalName

displayName

mail

eduPersonScopedAffiliation

eduPersonEntitlement

schacHomeOrganizationType