# HREF/eduID föderáció

# HREF

Magyarországi felsőoktatási és kutatói [föderáció](https://help.edu.hu/books/alapok-es-fogalmak/page/foderacio) (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](https://help.edu.hu/books/hrefeduid-foderacio/page/niifi-idp)
* [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

| Tulajdonság | Érték  |
|---|---|
| Intézmény (IdP) neve | **Dunaújvárosi Főiskola `(idp2.duf.hu)`** |
| IdP szoftver | *nincs megadva* |
| Technikai kapcsolattartó | Kovács Csaba, cs.kovacs@mail.duf.hu; Botka István, boti@makacs.duf.hu |
| Azonosítható felhasználók száma  | 280  |
| Hallgatók száma | 5200 |
| Alkalmazottak száma | 130 |
| Külsősök száma | 0 |
| Nem felhasználóhoz köthető bejegyzések száma | 5 |
| Hallgatók felvételének folyamata | Neptun rendszerben regisztrált hallgató adatai folyamatosan szinkronizálásra kerülnek a címtárral. |
| Alkalmazottak felvételének folyamata | Minden oktató és nem oktató dolgozó a Netware eDirectoryba kerül felvételre a Humánerőforrás Igazgatóságon (HR szervezet). A címtárral való szinkronizásás a dolgozó számára ismertetett jelszómódosítási eljárás alkalmával történik meg. Ettől kezdve tudják használni a föderatív és belső szolgáltatásokat (Shibboleth, Eduroam, SSO). |
| Külsősök felvételének folyamata | - |
| Hallgatók törlésének folyamata | Végzett, vagy eltávozott hallgató aktív statusa törlésre kerül. A tanulmányi előadó eltávolítja az `edupersonAffiliation: student` attribútumot |
| Alkalmazottak törlésének folyamata | A munkatárs kilépésekor a HR szervezeti előadó eltávolítja az `edupersonAffiliation: employee` attribútumot, az esetleg használt `edupersonEntitlement` értékeket. Inaktív felhasználói bejegyzését a címtárból egyelőre nem törlünk. (Kialakítandó az archiválási és törlési szabályozás.) |
| Külsősök törlésének folyamata | - |
| Felhasználó intézményhez való kapcsolatát leíró attribútum/érték | <li> Oktató/dolgozó: `edupersonAffiliation: employee`<li> Hallgató: `edupersonAffiliation: students`<li> Egyéb alkalmazott: `edupersonAffiliation: member`<li> Külsős munkatársak: nincs `edupersonAffiliation` attribútum vagy `edupersonAffiliation: affiliate` |
| Egyes attribútumok származás helye ill. módosításra jogosultak | A felhasználók attribútumait - a jelszavukat leszámítva - kizárólag a névtár adminisztrációjára jogosult az Informatikai Szolgáltató Központ alkalmazásában álló rendszergazda módosíthatja. A `userCertificate;binary` attribútumot a tanúsítvány publikálásakor az NIIF CA hozza létre. |
| Jelszavak formai követelményei | A felhasználók jelszómegadási szabálya: legalább 8 karakter hosszú, lehetőleg nem értelmes szóként ismert jelszavakat kell használniuk. A jelszóváltoztató felület ellenőrzi, hogy az új jelszó megfelel-e ezeknek a követelményeknek.</br></br>A teszt felhasználóknak generált (kis- és nagybetűket, számokat, opcionálisan egyéb karaktereket) tartalmazó jelszavakat állítunk elő. |
| Naplóállományok rendelkezésre állási ideje | Jelenleg nincs log rotálás |
| Autentikációs backend | LDAP |
| Autentikációs mód | Apache |
| Vállalt rendelkezésre állás | Az Identity Provider funkciót egy virtuális szerverkörnyezetben (Vmware) futó szerver biztosítja. A rendelkezésre állásnak nincs meghatározott értéke (belső szolgáltatás). |

# MTA Sztaki IdP

| Tulajdonság | Érték |
|---|---|
| Intézmény (IdP) neve | **MTA SZTAKI** |
| IdP szoftver | nincs megadva |
| Technikai kapcsolattartó | Szabó Gyula, sys-admin@sztaki.hu |
| Azonosítható felhasználók száma | 400  |
| Hallgatók száma  | 0 |
| Alkalmazottak száma   | 400 |
| Külsősök száma | 0 |
| Nem felhasználóhoz köthető bejegyzések száma | 20  |
| Hallgatók felvételének folyamata  | Nem alkalmazható |
| Alkalmazottak felvételének folyamata | Új munkatárs intézetbe történő beléptetésekor a Személyügyi Osztály felelős munkatársa veszi fel a névtárba az elsődleges adatokat, megadva a belépő munkatárs nevét, szervezeti egységét, beosztását, a besorolás típusát (főállású/részmunkaidős, tudományos/nem tudományos munkatárs)) és az intézetbe való belépés idejét is. A belépő munkatársak mail címét, azonosítóját (uid) és elsődleges jelszavát a közvetlen munkahelyi vezető írásos témaszám igénylése alapján az alkalmazás adminisztrátor regisztrálja a névtárban. A munkatárs ezután azonosítható az IdP számára. |
| Külsősök felvételének folyamata | A SZTAKI külön IdP-ben tartja nyilván a különböző projektekben résztvevő partnereket (*SZTAKI Partners' IdP*), ez az IdP nem része a [HREF](https://help.edu.hu/books/hrefeduid-foderacio/page/href) föderációnak. |
| Hallgatók törlésének folyamata | Nem alkalmazható |
| Alkalmazottak törlésének folyamata | A munkatárs kilépésekor a Személyügyi Osztály felelős munkatársa regisztrálja a névtárban a kilépés tényét és időpontját. Ennek eredményeként a kilépett munkatárs már nem tud bejelentkezni a rendszerekbe, így a SZTAKI IdP sem azonosítja. Ezt követően a kilépők adatait áthelyezzük egy archívumba, ahová a kereséseket nem engedjük be. |
| Külsősök törlésének folyamata | HREF föderáció szempontjából érdektelen információ |
| Felhasználó intézményhez való kapcsolatát leíró attribútum/érték | IdP-nk csak munkatársakat azonosít, így minden assertion **eduPersonAffiliaton** attribútuma **employee** értékkel van kiállítva. |
| Egyes attribútumok származás helye ill. módosításra jogosultak | Új munkatárs intézetbe történő beléptetésekor a Személyügyi Osztály felelős munkatársa veszi fel a névtárba az elsődleges adatokat, megadva a belépő munkatárs nevét, szervezeti egységét, beosztását és az intézetbe való belépés idejét is.</br></br>A belépő munkatársak mail címét, azonosítóját (uid) és elsődleges jelszavát a közvetlen munkahelyi vezető írásos témaszám igénylése alapján az alkalmazás adminisztrátor regisztrálja a névtárban.</br></br>A mail szolgáltatáshoz kapcsolódó egyéni beállítások önálló szabályozására kifejlesztettünk egy web-es felületet, az IFAR-t (Integrált Felhasználói Adminisztrációs Rendszer). Ennek segítségével a munkatársak önállóan tudják  változtatni jelszavaikat, kezelhetik leveleik átirányítását, ill. akár megadhatják a szabadság idején küldendő automatikus válasz szövegét is. Az önadminisztrációs felület ad lehetőséget az azonosított felhasználónak a szobaszáma, telefomszáma ill a mobil telefonszáma regisztrálására is. |
| Jelszavak formai követelményei | A felhasználóknak legalább 6 karakter hosszú jelszavakat kell használniuk. A jelszóváltoztató felület ellenőrzi, hogy az új jelszó megfelel-e ennek a követelménynek.</br></br>A teszt felhasználók jelszavai minimálisan 8 karaktert (kis- és nagybetűket, számokat, opcionálisan egyéb karaktereket) kell, hogy tartalmazzanak. |
| Naplóállományok rendelkezésre állási ideje | Havonta |
| Autentikációs backend | LDAP |
| Autentikációs mód | Apache |
| Vállalt rendelkezésre állás  | Az Identity Provider funkciót egy nagy rendelkezésre állású klaszter biztosítja. A rendelkezésre állásnak nincs formálisan vállalt értéke, a havi rendelkezésre állási statisztikák szerint a megelőző 6 hónapban a SZTAKI IdP rendelkezésre állása 99,99% volt. |

# NIIFI IdP

| Tulajdonság | Érték |
|---|---|
| Intézmény (IdP) neve | **NIIF Intézet** |
| IdP szoftver | Shibboleth IdP 2.1 |
| Technikai kapcsolattartó | Bajnok Kristóf, aai _KuKaC_ niif _PoNT_ hu |
| Azonosítható felhasználók száma | 70  |
| Hallgatók száma  | 0 |
| Alkalmazottak száma   | 63 |
| Külsősök száma | 3 |
| Nem felhasználóhoz köthető bejegyzések száma | 4  |
| Hallgatók felvételének folyamata  | Nem alkalmazható |
| Alkalmazottak felvételének folyamata | Új munkatárs érkezése esetén - az érkező felettesének kérésére - a névtár felelős veszi fel az adatokat az NIIFI névtárába. |
| Külsősök felvételének folyamata | Az NIIF-fel speciális (szoros) viszonyban levők szintén azonosíthatók ennél az IdP-nél, de ez kivétel, csak igazgató(helyettesi) utasításra hozható létre. |
| Hallgatók törlésének folyamata | Nem alkalmazható |
| Alkalmazottak törlésének folyamata | A munkatárs kilépésekor a névtár felelős eltávolítja az `edupersonAffiliation: employee` attribútumot, az esetleg használt `edupersonEntitlement` értékeket és a kilépő munkatárs felettesével egyeztetett időpontban törli a felhasználó bejegyzését |
| Külsősök törlésének folyamata | Nem meghatározott, mivel a felvétel is különleges eljárás szerint történik |
| Felhasználó intézményhez való kapcsolatát leíró attribútum/érték | <li>**Alkalmazott**: `edupersonAffiliation: employee`<li> **Külsős munkatársak**: nincs `edupersonAffiliation` attribútum vagy `edupersonAffiliation: affiliate` |
| Egyes attribútumok származás helye ill. módosításra jogosultak | A felhasználók attribútumait - a jelszavukat leszámítva - kizárólag a névtár adminisztrációjára jogosult műszaki kollégák módosíthatják. A `userCertificate;binary` attribútumot a tanúsítvány publikálásakor az NIIF CA hozza létre. |
| Jelszavak formai követelményei | A felhasználók jelszavait időnként audittal ellenőrizzük, legalább 6 karakter hosszú, szólistában nem található jelszavakat kell használniuk. A jelszóváltoztató felület ellenőrzi, hogy az új jelszó megfelel-e ezeknek a követelményeknek.</br></br>A teszt felhasználók jelszavai minimálisan 8 karaktert (kis- és nagybetűket, számokat, opcionálisan egyéb karaktereket) kell, hogy tartalmazzanak. |
| Naplóállományok rendelkezésre állási ideje | min. 6 hónap |
| Autentikációs backend | LDAP |
| Autentikációs mód | Username/password |
| Vállalt rendelkezésre állás  | Az Identity Provider funkciót egy nagy rendelkezésre állású klaszter biztosítja. A rendelkezésre állásnak nincs formálisan vállalt értéke (belső szolgáltatás). |

# HREFContract

A HREF Föderáció nem jogi személy, így a szerződést formálisan a [Föderációs Operátor](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) és a [Tag](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) illetve a [Partner](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) 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](http://www.eduid.hu/hu/dokumentumok/) oldalról.

A szerződés az alábbi dokumentumokra hivatkozik:

* [Szószedet](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary): a szerződésben és a vonatkozó dokumentumokban használt fogalmak meghatározása. [Glossary](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary)
* [Alapelvek](https://help.edu.hu/books/hrefeduid-foderacio/page/href-alapelvek-es-alapveto-szabalyok): a HREF Föderáció működésének alapvető szabályai [Federation Policy](https://help.edu.hu/books/hrefeduid-foderacio/page/href-alapelvek-es-alapveto-szabalyok)
* Műszaki előírások:
	* IdP műszaki követelmények; [IdP Operation Requirements](https://help.edu.hu/books/aai-4BA/page/idp-operational-requirements)
	* SP műszaki követelmények; [SP Operation Requirements](https://help.edu.hu/books/aai-4BA/page/sp-operational-requirements)
* [Szolgáltatási szint megállapodás](https://help.edu.hu/books/hrefeduid-foderacio/page/href-szolgaltatasi-szint-megallapodas): a Föderációs Operátor szolgáltatásai és ezek vállalt paraméterei. [Service Level Agreement](https://help.edu.hu/books/hrefeduid-foderacio/page/href-szolgaltatasi-szint-megallapodas)
* [Attribútum specifikáció](https://help.edu.hu/books/hrefeduid-foderacio/page/href-attributum-specifikacio): a felhasználói attribútumok cseréjét meghatározó leírás. [Attribute Specification](https://help.edu.hu/books/hrefeduid-foderacio/page/href-attributum-specifikacio)
* [Metadata specifikáció](https://help.edu.hu/books/hrefeduid-foderacio/page/href-metadata-specifikacio): a metaadatok használatának és értelmezésének szabályai. [Metadata Specification](https://help.edu.hu/books/hrefeduid-foderacio/page/href-metadata-specifikacio)
* [Föderációs szolgáltatások](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefservices): a föderáció Tagjai és Partnerei által a Föderációban üzemeltetett szolgáltatások. [Definition of Federated Services](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefservices)

----

<!--
A Föderáció működésével kapcsolatos egyéb dokumentumok, amelyek nem képezik a szerződés mellékleteit:
* [Tanácsának Működése]]([Tagok)* [Üzemeltetéssel kapcsolatos ajánlások]()
-->

# 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](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](https://help.edu.hu/books/hrefeduid-foderacio/page/href-alapelvek-es-alapveto-szabalyok)-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](https://docs.google.com/document/d/1XkFqQx9npWVgftAU1b0cRoqiTNrhj9oqEWpMWaIJO6o/edit?hl=en_US), [Műszaki előírások SP-k számára](https://docs.google.com/document/d/1QZWwFqHm4VNyIn6GdKnOzyA0Xdg2uYgwlAkJA1ffpM8/edit?hl=en_US))
	* 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](https://listserv.niif.hu/mailman/listinfo/href-tech) levelezőlistára, az entitás adminisztratív kapcsolattartója pedig a [href-admin](https://listserv.niif.hu/mailman/listinfo/href-admin) levelezőlistára.

# HREF alapelvek és alapvető szabályok

## Föderációs alapelvek

1. A [föderáció](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) 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.
1. Az IdP csak abban az esetben azonosít egy felhasználót, ha az illető valamilyen - ismert - viszonyban van az intézménnyel.
1. Az IdP és az SP nem ad meg magáról hamis, félrevezető információt.
1. 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.
1. 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.
1. Az SP csak a működéséhez minimálisan szükséges adatmennyiséget ([attribútumokat](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary)) igényli a felhasználóról.
1. Az SP nem kérheti a felhasználót, hogy adja meg az IdP-nél érvényes jelszavát.
1. Az SP-nél történő adatkezelés a törvényi előírások szerint működik.
1. Felhasználói visszaélések vizsgálatában az IdP és az SP együttműködik egymással.
1. Az IdP és az SP az informatikai rendszereit az elvárható gondossággal üzemelteti.

## Szabályok

### Adatvédelmi szabályok

1. A [Tag](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) és a [Partner](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) biztosítja, hogy a [HREF Föderáció](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) 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.
1. 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.
1. 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](https://docs.google.com/document/d/1XkFqQx9npWVgftAU1b0cRoqiTNrhj9oqEWpMWaIJO6o/edit?hl=en_US), [SP üzemeltetési szabályok](https://docs.google.com/document/d/1QZWwFqHm4VNyIn6GdKnOzyA0Xdg2uYgwlAkJA1ffpM8/edit?hl=en_US)
1. A Föderációs Operátor jogosult ellenőrizni a vonatkozó szabályok betartását.
1. A Tag és a Partner gondoskodik arról, hogy a metaadatok kezelése a [metadata specifikációnak](https://help.edu.hu/books/hrefeduid-foderacio/page/href-metadata-specifikacio) megfelelően történjen, így:
	* a Tag a [Resource Registry](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) 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.
1. A felhasználói [attribútumok](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) átadása során az IdP és a SP az [attribútum specifikáció](https://help.edu.hu/books/hrefeduid-foderacio/page/href-attributum-specifikacio) 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.
1. Csak olyan felhasználó azonosítható, akinek az intézményhez való [viszonya](https://help.edu.hu/books/hrefeduid-foderacio/page/href-attributum-specifikacio) egyértelműen megállapítható.
1. 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](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) 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.
1. 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.
1. Az Azonosító Szervezet biztosítja, hogy az IdP AAI Kapu az [attribútum specifikációban](https://help.edu.hu/books/hrefeduid-foderacio/page/href-attributum-specifikacio) 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](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) és a [Partnerek](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary).

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.
1. A föderáció **Partnere** tetszőleges szervezet lehet
1. A föderáció Tagjai és Partnerei jogosultak a föderációban szolgáltatásokat üzemeltetni
1. A Partner a Tagok Tanácsa ülésein megfigyelőként részt vehet, azonban szavazati joggal nem rendelkezik.
1. Csak Tagok jogosultak:
	* felhasználói adatokat szolgáltatni;
	* a [Tagok Tanácsába](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) 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/](http://middleware.internet2.edu/eduperson/))
- *SCHAC* ([http://www.terena.org/activities/tf-emc2/schacreleases.html](http://www.terena.org/activities/tf-emc2/schacreleases.html))
- *niifPerson*, *niifEduPerson* ([NIIFSchema](https://help.edu.hu/books/kiegeszito-tudnivalok/page/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](https://help.edu.hu/books/elavult-archiv/page/resource-registry)-ben, és ezen keresztül a [metadata](https://help.edu.hu/books/alapok-es-fogalmak/page/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

<table id="bkmrk-edupersonscopedaffil"><thead><tr><th>eduPersonScopedAffiliation</th></tr></thead><tbody><tr><td>schacHomeOrganizationType</td></tr><tr><td>eduPersonPrincipalName</td></tr></tbody></table>

#### Ajánlott attribútumok

<table id="bkmrk-mail-edupersonentitl"><thead><tr><th>mail</th></tr></thead><tbody><tr><td>eduPersonEntitlement</td></tr></tbody></table>

### Á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](https://help.edu.hu/books/aai-4BA/page/scope) vagy <a>entityID</a>).
- **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...

<p class="callout info">**Info**  
  
Egy SP a [Resource Registry](https://help.edu.hu/books/elavult-archiv/page/resource-registry)-ben jelezheti, hogy milyen NameID formátumokat támogat. Ha kizárólag perzisztens NameID formátumot támogat, akkor vagy kap az IdP-től ilyet, vagy hiba lép fel a válasz feldolgozása során.</p>

#### eduPersonTargetedID

<table id="bkmrk-%C2%A0-edupersontargetedi"><thead><tr><th> </th><th>eduPersonTargetedID</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonTargetedID  
**OID:** 1.3.6.1.4.1.5923.1.1.1.10</td></tr><tr><td>**Rövid leírás**</td><td>**Nem átlátszó**, **célzott** azonosító, amely **nem osztható ki újra**</td></tr><tr><td>**Implementáció**</td><td>kötelező</td></tr><tr><td>**Részletes leírás**</td><td>Lásd: [https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID) , ill. a fenti megjegyzést az implementációs szinttel kapcsolatban.  
  
Az SP a kapott értéket fel kell, hogy dolgozza, nem adhatja XML formátumban tovább az alkalmazásnak. A benne szereplő ún. qualifier-ek közül az IdP azonosítóját (`NameQualifier`) és természetesen magát az azonosítót *kötelező* szerepeltetni az alkalmazás számára átadott azonosítóban. Javasolt az egyes mezőket '!' karakterrel elválasztani egymástól.  
  
Az IdP-nek biztosítania kell, hogy egy felhasználó számára kiosztott azonosító valóban perzisztens legyen, tehát gondoskodnia kell az attribútum-értékek biztos tárolásáról - például egy megfelelő mentési tervvel üzemeltetett relációs adatbázisban.  
  
Az eduPersonTargetedID **nem osztható ki újra**.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>Az attribútum értékének a SAML2 szabványban definiált NameID formátumúnak kell lennie; az azonosító (nem számítva az XML attribútumokat) legfeljebb 256 karakterből állhat.</td></tr><tr><td>**Példa**</td><td>Az IdP ilyen formában adja ki az azonosítót: ```
<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"<br></br>   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"<br></br>   NameQualifier="<a href="https://idp.example.org/idp/shibboleth">https://idp.example.org/idp/shibboleth</a>"<br></br>   SPNameQualifier="<a href="https://sp.example.org/shibboleth">https://sp.example.org/shibboleth</a>"><br></br>84e411ea-7daa-4a57-bbf6-b5cc52981b73<br></br></saml2:NameID>
```

  
Az alkalmazás ilyen formában kapja meg az azonosítót:  
[https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73](https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73)</td></tr></tbody></table>

#### eduPersonPrincipalName

<table id="bkmrk-%C2%A0-edupersonprincipal"><thead><tr><th> </th><th>eduPersonPrincipalName</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonPrincipalName  
**OID:** 1.3.6.1.4.1.5923.1.1.1.6</td></tr><tr><td>**Rövid leírás**</td><td>**Állandó**, **nem célzott**, **nem újra kiosztható** egyedi azonosító</td></tr><tr><td>**Implementáció**</td><td>kötelező</td></tr><tr><td>**Részletes leírás**</td><td>Formátum: &lt;egyedi\_lokális\_azonosító&gt;@  
Ahol - **&lt;egyedi\_lokális\_azonosító&gt;**: tetszőleges állandó azonosító, amely az intézményen belül egyértelműen azonosítja a felhasználót. Kézenfekvő megoldás a felhasználói azonosító (**uid**) használata, azonban bármilyen más azonosító használható
- : helyi biztonsági tartomány. A végződése kötelezően egy DNS domain, amely az IdP-t üzemeltető intézmény tulajdonában áll.  
      
    **Megjegyzés**: az **eduPersonPrincipalName** érzékeny személyes adat, hiszen sok esetben megegyezik a felhasználó e-mail címével. Intézményen belüli használata javasolt, intézményen kívül célszerű nem átlátszó, célzott azonosítót használni.  
      
    Az eduPersonPrincipalName a föderációban **nem osztható ki újra**.  
      
    Bizonyos alkalmazások nem támogatják a különleges karaktereket az azonosítókban, ezért a föderációban az eduPersonPrincipalName kizárólag alfanumerikus karaktereket, pont ('.'), kötőjel ('-') és alulvonás ('\_') karaktereket tartalmazhat.

</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>gipsz.jakab@example.org</td></tr></tbody></table>

#### niifPersonOrgID

<table id="bkmrk-%C2%A0-niifpersonorgid-el"><thead><tr><th> </th><th>niifPersonOrgID</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonPrincipalName  
**OID:** 1.3.6.1.4.1.11914.0.1.154</td></tr><tr><td>**Rövid leírás**</td><td>Állandó egyedi azonosító intézményen belüli, ill. e-learning használatra</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>Bizonyos esetekben adatvédelmi szempontok miatt szükség lehet arra, hogy a felhasználó intézményen belüli azonosítója (pl. Neptun kódja) és az egyéb alkalmazásokban használt `uid` különböző legyen.  
  
Ezen attribútum intézmények közötti átadása csak abban az esetben javasolt, ha e-learning rendszerek miatt meg kell osztani a tanulmányi azonosítót.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr></tbody></table>

#### schacPersonalUniqueCode

<table id="bkmrk-%C2%A0-schacpersonaluniqu"><thead><tr><th> </th><th>schacPersonalUniqueCode</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.25178.1.2.14</td></tr><tr><td>**Rövid leírás**</td><td>Állandó egyedi azonosító interföderációs környezetben való használatra</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>-</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>`urn:schac:personalUniqueCode:hu:bme.hu:Neptun:gmx3f0`</td></tr></tbody></table>

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

#### sn

<table id="bkmrk-%C2%A0-sn-elnevez%C3%A9s-uri%3A-"><thead><tr><th> </th><th>sn</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:sn  
**OID:** 2.5.4.4</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó vezetékneve</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználó vezetékneve. Amennyiben több vezetékneve van a felhasználónak, akkor ezeket egyetlen értékben kell tárolni.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>- Gipsz
- Gipszné Kiss

</td></tr></tbody></table>

#### givenName

<table id="bkmrk-%C2%A0-givenname-elnevez%C3%A9"><thead><tr><th> </th><th>givenName</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:givenName  
**OID:** 2.5.4.42</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó keresztneve</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>Amennyiben több keresztneve van a felhasználónak, ezeket egyetlen értékben kell tárolni.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>- Jakab
- Mária Lujza

</td></tr></tbody></table>

#### displayName

<table id="bkmrk-%C2%A0-displayname-elneve"><thead><tr><th> </th><th>displayName</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:displayname  
**OID:** 2.16.840.1.113730.3.1.241</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó megjelenítendő neve</td></tr><tr><td>**Implementáció**</td><td>ajánlott</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználó neve abban a formában, ahogy a felhasználó, vagy a felhasználó intézménye meg kívánja jeleníteni.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>Gipsz Jakab Aladár</td></tr></tbody></table>

#### mail

<table id="bkmrk-%C2%A0-mail-elnevez%C3%A9s-uri"><thead><tr><th> </th><th>mail</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:mail  
**OID:** 0.9.2342.19200300.100.1.3</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó email címe</td></tr><tr><td>**Implementáció**</td><td>ajánlott</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználó értesítési e-mail címe. Az így átadott email címről az intézmény biztosítja, hogy - azt az intézmény biztosítja a felhasználó részére (pl neptunkod@intemzeny.hu)
- vagy az intézmény a cím rögzítésekor ellenőrizte, hogy az a felhasználó tulajdonában van (pl egy megerősítő levél kiküldésével).  
      
    Az attribútumban ellenőrizetlen, felhasználó által megadott email címet átadni tilos.

</td></tr><tr><td>**Lehetséges értékek**</td><td>Létező e-mail cím</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Lásd: [RFC 2822](http://www.faqs.org/rfcs/rfc2822.html)`</td></tr><tr><td>**Példa**</td><td>gipsz.jakab@example.org</td></tr></tbody></table>

#### preferredLanguage

<table id="bkmrk-%C2%A0-preferredlanguage-"><thead><tr><th> </th><th>preferredLanguage</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:preferredLanguage  
**OID:** 2.16.840.1.113730.3.1.39</td></tr><tr><td>**Rövid leírás**</td><td>Előnyben részesített nyelv</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználó által elsődlegesen használni kívánt, általa előnyben részesített nyelv</td></tr><tr><td>**Lehetséges értékek**</td><td>RFC 2068 Language Tags szekcióban meghatározott formátumú nyelvkódok</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>hu</td></tr></tbody></table>

#### schacDateOfBirth

<table id="bkmrk-%C2%A0-schacdateofbirth-e"><thead><tr><th> </th><th>schacDateOfBirth</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.25178.1.2.3</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó születési dátuma</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>-</td></tr><tr><td>**Lehetséges értékek**</td><td>YYYYMMDD (RFC 3339 'full-date') formátumú dátum</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>19700101</td></tr></tbody></table>

#### schacYearOfBirth

<table id="bkmrk-%C2%A0-schacyearofbirth-e"><thead><tr><th> </th><th>schacYearOfBirth</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.25178.1.0.2.3</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó születési éve (amennyiben csak az évre van szükség, egyébként ajánlott a [schacDateOfBirth](#bkmrk-schacdateofbirth) használata)</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>-</td></tr><tr><td>**Lehetséges értékek**</td><td>YYYY formátumú év</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>1970</td></tr></tbody></table>

#### schacPersonalTitle

<table id="bkmrk-%C2%A0-schacpersonaltitle"><thead><tr><th> </th><th>schacPersonalTitle</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.25178.1.2.8</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó személyes megszólítása.</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználó nevéhez kapcsolódó megszólítás, mely a teljes név elé fűzhető. A címtárban tárolható a [niifPersonPrefix](https://help.edu.hu/books/kiegeszito-tudnivalok/page/niifschema) attribútumban is.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>- Dr.
- Prof.

</td></tr></tbody></table>

#### niifPersonMothersName

<table id="bkmrk-%C2%A0-niifpersonmothersn"><thead><tr><th> </th><th>niifPersonMothersName</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.11914.0.1.157</td></tr><tr><td>**Rövid leírás**</td><td>Felhasználó anyja neve</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználó anyjának születési neve a felhasználó hivatalos irataiban.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>Kőkori Vilma</td></tr></tbody></table>

#### niifPersonResidentalAddress

<table id="bkmrk-%C2%A0-niifpersonresident"><thead><tr><th> </th><th>niifPersonResidentalAddress</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.11914.0.1.159</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó állandó lakcíme</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>-</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>1111 Budapest, Villányi út 155.</td></tr></tbody></table>

#### homePostalAddress

<table id="bkmrk-%C2%A0-homepostaladdress-"><thead><tr><th> </th><th>homePostalAddress</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 0.9.2342.19200300.100.1.39</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó ideiglenes lakcíme</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>-</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>1111 Budapest, Villányi út 155.</td></tr></tbody></table>

#### telephoneNumber

<table id="bkmrk-%C2%A0-telephonenumber-el"><thead><tr><th> </th><th>telephoneNumber</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 2.5.4.20</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó vezetékes telefonszáma</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>-</td></tr><tr><td>**Lehetséges értékek**</td><td>A telefonszámot az [ITU-T E.123 szabvány](https://www.comnap.aq/interoperability/ITU-T-REC-E.123-2001-02.pdf) szerint kell tárolni. A melléket a `/` jellel elválasztva jelölhető.</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>- +36 1 123 1234
- +36 1 123 1234 / 102

</td></tr></tbody></table>

#### mobile

<table id="bkmrk-%C2%A0-mobile-elnevez%C3%A9s-u"><thead><tr><th> </th><th>mobile</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 0.9.2342.19200300.100.1.41</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó mobilszáma</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>-</td></tr><tr><td>**Lehetséges értékek**</td><td>A telefonszámot az [ITU-T E.123 szabvány](https://www.comnap.aq/interoperability/ITU-T-REC-E.123-2001-02.pdf) szerint kell tárolni.</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>+36 30 123 1234</td></tr></tbody></table>

#### eduPersonNickName

<table id="bkmrk-%C2%A0-edupersonnickname-"><thead><tr><th> </th><th>eduPersonNickName</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.5923.1.1.1.2</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó beceneve</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>Az a becenév, amelyet a felhasználó általában használ (pl. online fórumokon). Nem egyedi, a hossza és a tartalma sem kötött, nem állandó, ezért az alkalmazásnak mindenképpen ellenőriznie kell, mielőtt - esetleg - lokális felhasználónévként figyelembe veszi.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>felhasználó</td></tr><tr><td>**Példa**</td><td>- gipszj
- the.man.who.was.bored.to.death.by.some.american.smartguys

</td></tr></tbody></table>

#### cn

<table id="bkmrk-%C2%A0-cn-elnevez%C3%A9s-uri%3A-"><thead><tr><th> </th><th>cn</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 2.5.4.3</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó teljes neve</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználó vezetéknevének és keresztnevének valamilyen módon történő, szóközzel elválasztott összefűzése. Használata intézményenként és országonként eltérő. Jellemző, hogy több értékben különböző módokon előállított értékeket is tartalmaz.  
  
**Helyette a [displayName](#bkmrk-displayname) használata javasolt.**</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>- Gipsz Jakab
- Kovács Áron;Kovacs Aron;Aron Kovacs

</td></tr></tbody></table>

#### jpegPhoto

<table id="bkmrk-%C2%A0-jpegphoto-elnevez%C3%A9"><thead><tr><th> </th><th>jpegPhoto</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 0.9.2342.19200300.100.1.60</td></tr><tr><td>**Rövid leírás**</td><td>Kis méretű fotó a felhasználóról JPEG formátumban</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>-</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr></tbody></table>

#### labeledUri

<table id="bkmrk-%C2%A0-labeleduri-elnevez"><thead><tr><th> </th><th>labeledUri</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.250.1.57</td></tr><tr><td>**Rövid leírás**</td><td>Felhasználóhoz tartozó URI-k</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználó által megadott, vagy rá valamilyen formában jellemző URI-k (gyakran URL-ek) gyűjteménye, mint pl. a személyes honlapjának címe. Minden azonosítóhoz opcionálisan kapcsolható szöveges leírás.</td></tr><tr><td>**Lehetséges értékek**</td><td>Az URL-t urlencode-olva kell tárolni (RFC 2079).</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>- [http://example.com/%7Euser/foo](http://example.com/~user/foo) Foo page
- [ftp://ftp.example.com](ftp://ftp.example.com)

</td></tr></tbody></table>

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

#### eduPersonScopedAffiliation

<table id="bkmrk-%C2%A0-edupersonscopedaff"><thead><tr><th> </th><th>eduPersonScopedAffiliation</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonScopedAffiliation  
**OID:** 1.3.6.1.4.1.5923.1.1.1.9</td></tr><tr><td>**Rövid leírás**</td><td>Felhasználó és intézmény közti viszony leírása</td></tr><tr><td>**Implementáció**</td><td>kötelező</td></tr><tr><td>**Részletes leírás**</td><td>**&lt;viszony&gt;@&lt;\\scope&gt;**- **&lt;viszony&gt;**: a felhasználó és az intézmény közti viszony leírására az alábbi értékek választhatók
- *student*: intézmény hallgatója
- *faculty*: oktatási tevékenységet végez az intézményben
- *staff*: nem oktatási tevékenységet végző alkalmazott (pl. a rendszergazda és a kertész is)
- *employee*: alkalmazott (használata intézmények között nem javasolt)
- *member*: azok a felhasználók, amelyek azáltal, hogy azonosította őket az IdP, rendelkeznek intézményhez kötődő általános jogosultságokkal. Jellemzően ide sorolhatók a *student*, *faculty*, *staff* viszonnyal rendelkezők.
- *affiliate*: az intézmény azonosítja őket, de nem rendelkeznek általános jogosultságokkal
- *alum*: öregdiák
- *library-walk-in*: könyvtári tag

**Megjegyzés:** lehetséges, hogy a föderációban használható értékek körét a későbbiekben szűkíteni fogjuk - **&lt;scope&gt;**: helyi biztonsági tartomány. A végződése kötelezően egy DNS domain, amely az IdP-t üzemeltető intézmény tulajdonában áll.

  
Lásd még: [http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201310.html#eduPersonAffiliation](http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201310.html#eduPersonAffiliation)  
  
[Egy lehetséges vizuális ábrázolás](#bkmrk-edupersonscopedaffiliation), azonban a halmazok pontos meghatározása az intézmény feladata.</td></tr><tr><td>**Lehetséges értékek**</td><td>A következő értékek egyike: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, valamint a [Scope](https://help.edu.hu/books/aai-4BA/page/scope)</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>- Hallgatók: *student@example.org;member@example.org*
- Oktatók: *faculty@example.org;employee@example.org;member@example.org*
- Nem alkalmazott oktató-hallgatók: *student@example.org;faculty@example.org;member@example.org*

</td></tr></tbody></table>

#### eduPersonEntitlement

<table id="bkmrk-%C2%A0-edupersonentitleme"><thead><tr><th> </th><th>eduPersonEntitlement</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonEntitlement  
**OID:** 1.3.6.1.4.1.5923.1.1.1.7</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó által jogosan használt erőforrás(ok)</td></tr><tr><td>**Implementáció**</td><td>ajánlott</td></tr><tr><td>**Részletes leírás**</td><td>Azon erőforrások listája, melyet a felhasználó használhat. Sok erőforrást minden felhasználó elérhet, néhányat csak korlátozott kör - ez utóbbi esetben válik fontossá ez az attribútum  
  
> **Info**  
> Az eduPersonEntitlement attribútumnak csak azon értékeit szabad kiadni az SP-nek, amelyek rá vonatkoznak. Ennek meghatározása kézi adminisztráció esetén igen nehéz lehet, ezért erre célszerű valamilyen adminisztrációs felületet használni. (Sajnos jelenleg nem létezik ilyen alkalmazás.)

</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>urn:geant:niif.hu:niif:entitlement:vhoadmin</td></tr></tbody></table>

#### schacHomeOrganizationType

<table id="bkmrk-%C2%A0-schachomeorganizat"><thead><tr><th> </th><th>schacHomeOrganizationType</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:schacHomeOrganizationType  
**OID:** 1.3.6.1.4.1.25178.1.2.10</td></tr><tr><td>**Rövid leírás**</td><td>Az intézmény jellege</td></tr><tr><td>**Implementáció**</td><td>kötelező</td></tr><tr><td>**Részletes leírás**</td><td>- **university**: Az Oktatási Minisztérium által elismert felsőoktatási intézmények (egyetemek és főiskolák)
- **nren**: Nemzeti kutatási és felsőoktatási kutatói hálózat szolgáltatója
- **library**: Könyvtárak
- **vho**: Virtuális azonosító szervezet egyének föderációs azonosítása céljára
- **school**: Általános és középiskolák
- **business**: Ipari vagy kereskedelmi intézmények
- **other**: Egyéb
- **test**: Teszt felhasználóról van szó

</td></tr><tr><td>**Lehetséges értékek**</td><td>urn:schac:homeOrganizationType:hu:{university,nren,library,vho,school,business,other,test}</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`URN`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr></tbody></table>

#### ou

<table id="bkmrk-%C2%A0-ou-elnevez%C3%A9s-uri%3A-"><thead><tr><th> </th><th>ou</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:ou  
**OID:** 2.5.4.11</td></tr><tr><td>**Rövid leírás**</td><td>Az intézményen belüli egység teljes neve (organizationalUnit)</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>Azon egység (tanszék, intézet, könyvtár, stb) neve, amelyhez a felhasználó tartozik.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>Automatizálási és alkalmazott informatikai tanszék</td></tr></tbody></table>

#### eduPersonOrgUnitDN

<table id="bkmrk-%C2%A0-edupersonorgunitdn"><thead><tr><th> </th><th>eduPersonOrgUnitDN</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonOrgUnitDN  
**OID:** 1.3.6.1.4.1.5923.1.1.1.4</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználóhoz tartozó szervezeti egység azonosítója</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználóhoz tartozó szervezeti egység (pl. tanszék, intézet, könyvtár, ...) intézményen belüli egyedi, esetleg hierarchikusan képzett azonosítója.  
Amennyiben az adott felhasználó több egységhez is besorolható, ez az attribútum több értéket is tartalmazhat.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`DN`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr></tbody></table>

#### eduPersonPrimaryOrgUnitDN

<table id="bkmrk-%C2%A0-edupersonprimaryor"><thead><tr><th> </th><th>eduPersonPrimaryOrgUnitDN</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonPrimaryOrgUnitDN  
**OID:** 1.3.6.1.4.1.5923.1.1.1.8</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználóhoz hozzárendelhető elsődleges szervezeti egység azonosítója.</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>Az [eduPersonOrgUnitDN](#bkmrk-edupersonorgunitdn)-ben tárolt egység-azonosítók közül azon elem, amelyhez a felhasználó elsődlegesen köthető.</td></tr><tr><td>**Lehetséges értékek**</td><td>Egy olyan azonosító, mely szerepel az [eduPersonOrgUnitDN](#bkmrk-edupersonorgunitdn) értékei között.</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`DN`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr></tbody></table>

### Oktatásban használt attribútumok

#### niifEduPersonAttendedCourse

<table id="bkmrk-%C2%A0-niifpersonattended"><thead><tr><th> </th><th>niifPersonAttendedCourse</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:geant:niif.hu:dir:attribute-def:niifEduPersonAttendedCourse  
**OID:** 1.3.6.1.4.1.11914.0.1.164</td></tr><tr><td>**Rövid leírás**</td><td>Felhasználó által hallgatott tárgy kódja</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>Azon tantárgyak kódja, amelyet a felhasználó az adott félévben hallgat.  
  
Oktatási intézmény esetén JAVASOLT az attribútumot implementálni és az intézményen belüli SP-k számára kiadni. Adatvédelmi szempontból JAVASOLT az értékeket úgy szűrni, hogy az SP csak a számára releváns tárgyak kódját kapja meg.</td></tr><tr><td>**Lehetséges értékek**</td><td>A tanulmányi rendszerben meghatározott tantárgykódok</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>- VIMM1234
- VIMA4321

</td></tr></tbody></table>

#### niifEduPersonArchiveCourse

<table id="bkmrk-%C2%A0-niifedupersonarchi"><thead><tr><th> </th><th>niifEduPersonArchiveCourse</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.11914.0.1.171</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó által valaha hallgatott kurzusok</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>Azon tantárgyak kódja, amelyet a felhasználó valaha hallgatott az adott intézményben.</td></tr><tr><td>**Lehetséges értékek**</td><td>A tanulmányi rendszerben meghatározott tantárgykódok</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr></tbody></table>

#### niifEduPersonHeldCourse

<table id="bkmrk-%C2%A0-niifedupersonheldc"><thead><tr><th> </th><th>niifEduPersonHeldCourse</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.11914.0.1.172</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó által aktuálisan oktatott tárgyak</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>Azon tantárgyak kódja, amelyet a felhasználó az adott félévben (esetleg előző félévben) oktatott.</td></tr><tr><td>**Lehetséges értékek**</td><td>A tanulmányi rendszerben meghatározott tantárgykódok</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr></tbody></table>

#### niifEduPersonMajor

<table id="bkmrk-%C2%A0-niifedupersonmajor"><thead><tr><th> </th><th>niifEduPersonMajor</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.11914.0.1.162</td></tr><tr><td>**Rövid leírás**</td><td>A hallgató főszakja</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A hallgató főszakja - a [mab.hu](http://web.mab.hu/joomla/index.php?option=com_content&view=article&id=87&Itemid=623&lang=hu) oldalán található lista alapján</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>- műszaki informatikus mérnök
- elméleti fizikus

</td></tr></tbody></table>

#### niifEduPersonFaculty

<table id="bkmrk-%C2%A0-niifedupersonfacul"><thead><tr><th> </th><th>niifEduPersonFaculty</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.11914.0.1.160</td></tr><tr><td>**Rövid leírás**</td><td>Kar neve</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>Teljes neve annak a karnak, amelyhez a hallgató tartozik</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>Villamosmérnöki és Informatikai Kar</td></tr></tbody></table>

#### niifEduPersonFacultyDN

<table id="bkmrk-%C2%A0-niifedupersonfacul-1"><thead><tr><th> </th><th>niifEduPersonFacultyDN</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.11914.0.1.161</td></tr><tr><td>**Rövid leírás**</td><td>A hallgató karának DN-je</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>-</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`DN`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr></tbody></table>

#### niifEduPersonStudentCategory

<table id="bkmrk-%C2%A0-niifedupersonstude"><thead><tr><th> </th><th>niifEduPersonStudentCategory</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva  
**OID:** 1.3.6.1.4.1.11914.0.1.174</td></tr><tr><td>**Rövid leírás**</td><td>Tanuló/hallgató képzési szintjének meghatározása</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A hallgató képzési szintjének pontosabb meghatározása (az [eduPersonScopedAffiliation](#bkmrk-edupersonscopedaffiliation) kiegészítése) - **bachelor**: bachelor képzésben részt vevő hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): student,member)
- **master**: master képzésben részt vevő hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): student,member)
- \* **doctor**: doktori képzésben részt vevő hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): student,member)
- **exchange-student**: vendéghallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): student,member)
- **qualifying-studies**: előkészítős hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): member)
- **open-university**: nyílt egyetemi képzésben részt vevő hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): affiliate)

  
Ha egy hallgató nem sorolható be egyik kategóriába sem (pl. nem bolognai rendszer szerint tanul), akkor az attribútum ne kapjon értéket!</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr></tbody></table>

# 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](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) felé.
1. Mind jogilag, mind technikailag előkészül a csatlakozáshoz: [Föderáció alapelvek](https://help.edu.hu/books/aai-4BA/page/href-alapelvek-es-alapveto-szabalyok),  [Műszaki előírások IdP-k számára](https://docs.google.com/document/d/1XkFqQx9npWVgftAU1b0cRoqiTNrhj9oqEWpMWaIJO6o/edit?hl=en_US), [Műszaki előírások SP-k számára](https://docs.google.com/document/d/1QZWwFqHm4VNyIn6GdKnOzyA0Xdg2uYgwlAkJA1ffpM8/edit?hl=en_US).
1. Egyeztetés után elküldi az [aláírt szerződést, ill. nyilatkozatot](http://www.eduid.hu/dokumentumok/), és ezzel párhuzamosan elérhetővé teszi a csatlakozás előtti ellenőrzéskor [átnézendő dokumentumokat](https://help.edu.hu/books/aai-4BA/page/hrefchecklist). 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.
1. A Föderációs Operátor elkészíti a Tag számára a szükséges HEXAA jogosultságokat
1. 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](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary)
1. Tagok Tanácsa dönt a csatlakozni kívánó tag/partner kérelméről
1. 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](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary) 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](https://help.edu.hu/books/elavult-archiv/page/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.
1. 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](https://help.edu.hu/books/elavult-archiv/page/resource-registry)-ben rögzíti az SP minden szükséges adatát.
1. 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](https://help.edu.hu/books/elavult-archiv/page/resource-registry)-ben rögzíti az SP minden szükséges adatát.
1. 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.
1. 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ó](https://help.edu.hu/books/hrefeduid-foderacio/page/href-metadata-specifikacio) 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](https://help.edu.hu/books/elavult-archiv/page/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](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](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary))**: 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](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary))**: 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](https://help.edu.hu/books/hrefeduid-foderacio/page/hrefglossary))**: 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

| Elnevezés | Metaadat aláíró tanúsítvány | Kivezetés tervezett időpontja |
|---|---|---|
| HREF-2011 | [href-metadata-signer-2011.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2011.crt) | 2022.01.01. |
| HREF-2015 | [mdx-test-signer-2015.crt](https://metadata.eduid.hu/certs/mdx-test-signer-2020.crt) | 2022.01.01. |
| HREF-2020 | [href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt) | 2025.06.14. |

### SHA1 fingerprints

| Elnevezés | SHA1 fingerprint  |
|---|---|
| HREF-2011 | `FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66`  |
| HREF-2015 | `91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43`  |
| HREF-2020 | `C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61`  |

### Domain név változások

| Domain | Technikai domain | Kulcs | Állapot  |
|---|---|---|---|
| metadata.eduid.hu | `metadata.eduid.hu/2011/href.xml` | HREF-2011 | Prod  |
| metadata.eduid.hu | `metadata.eduid.hu/2020/href.xml` | HREF-2020 | Prod  |
| mdx.eduid.hu | `mdx-2015.eduid.hu` | HREF-2015 | Prod  |
| mdx.eduid.hu | `mdx-2020.eduid.hu` | HREF-2020 | Prod  |

## Shibboleth Service Provider beállítások

[https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider](https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider)

### XML

[https://wiki.shibboleth.net/confluence/display/SP3/XMLMetadataProvider](https://wiki.shibboleth.net/confluence/display/SP3/XMLMetadataProvider)

```xml
<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](https://wiki.shibboleth.net/confluence/display/SP3/MDQMetadataProvider)

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

```xml
<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](https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider)

```xml
<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](https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider)

```xml
<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](https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider)

```xml
<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](https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider)

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

```php
//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://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_3)

[https://github.com/simplesamlphp/simplesamlphp-module-metarefresh/blob/master/docs/simplesamlphp-automated_metadata.md](https://github.com/simplesamlphp/simplesamlphp-module-metarefresh/blob/master/docs/simplesamlphp-automated_metadata.md)

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

```php
// 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

| Code name | Metadata signing certificate | Date of expiration  |
|---|---|---|
| HREF-2011 | [href-metadata-signer-2011.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2011.crt) | 2022.01.01. |
| HREF-2015 | [mdx-test-signer-2015.crt](https://metadata.eduid.hu/certs/mdx-test-signer-2020.crt) |  2022.01.01. |
| HREF-2020 | [href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt) |  2025.06.14.  |

### SHA1 fingerprints

| Code name | SHA1 fingerprint  |
|---|---|
| HREF-2011 | `FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66`  |
| HREF-2015 | `91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43`  |
| HREF-2020 | `C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61`  |

### Domain names

| Domain | URL | Key | Status  |
|---|---|---|---|
| metadata.eduid.hu | `metadata.eduid.hu/2011/href.xml` | HREF-2011 | Prod |
| metadata.eduid.hu | `metadata.eduid.hu/2020/href.xml` | HREF-2020 | Prod |
| mdx.eduid.hu | `mdx-2015.eduid.hu` | HREF-2015 | Prod |
| mdx.eduid.hu | `mdx-2020.eduid.hu` | HREF-2020 | Prod |

## Shibboleth Service Provider Configurations

[https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider](https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider)

### XML

[https://wiki.shibboleth.net/confluence/display/SP3/XMLMetadataProvider](https://wiki.shibboleth.net/confluence/display/SP3/XMLMetadataProvider)

```xml
<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](https://wiki.shibboleth.net/confluence/display/SP3/MDQMetadataProvider)

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

```xml
<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](https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider)


```xml
<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](https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider)


```xml
<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](https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider)


```xml
<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](https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider)


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


```php
//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://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_3)

[https://github.com/simplesamlphp/simplesamlphp-module-metarefresh/blob/master/docs/simplesamlphp-automated_metadata.md](https://github.com/simplesamlphp/simplesamlphp-module-metarefresh/blob/master/docs/simplesamlphp-automated_metadata.md)


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


```php
// 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

| Elnevezés | Metaadat aláíró tanúsítvány | Kivezetés tervezett időpontja|
|---|---|---|
| HREF-2011 | [https://metadata.eduid.hu/certs/href-metadata-signer-2011.crt href-metadata-signer-2011.crt] | 2022.01.01.  |
| HREF-2015 | [https://metadata.eduid.hu/certs/mdx-test-signer-2020.crt mdx-test-signer-2015.crt] | 2022.01.01.  |
| HREF-2020  | [https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt href-metadata-signer-2020.crt]  | 2025.06.14.  |
| HREF-2025  | [https://metadata.eduid.hu/certs/href-metadata-signer-2025.crt href-metadata-signer-2025.crt]  | 2030.06.14.  |

### SHA1 fingerprints

| Elnevezés | SHA1 fingerprint  |
|---|---|
| HREF-2011  | `FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66`  |
| HREF-2015  | `91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43`  |
| HREF-2020  | `C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61`  |
| HREF-2025  | `45:B2:33:96:7C:4F:7E:42:86:8D:CC:CF:CC:0E:3E:1C:2E:24:C2:DE`  |

### Domain név változások

| Domain | Technikai domain | Kulcs | Állapot  |
|---|---|---|---|
| metadata.eduid.hu | `metadata.eduid.hu/2011/href.xml` | HREF-2011  | Prod  |
| | `metadata.eduid.hu/2020/href.xml` | HREF-2020  | Prod  |
| | `metadata.eduid.hu/2025/href.xml` | HREF-2025  | Prod  |
| mdx.eduid.hu | `mdx-2015.eduid.hu` | HREF-2015  | Prod  |
| | `mdx-2020.eduid.hu` | HREF-2020  | Prod  |
| | `mdx-2025.eduid.hu` | HREF-2025  | Prod  |

### Discovery Service változások

| URL  |
|---|
| <https://mdx-2020.eduid.hu/role/idp.ds>  |
| <https://mdx-2025.eduid.hu/discovery/ds>  |

## Shibboleth Service Provider beállítások

<https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider>

### XML

<https://wiki.shibboleth.net/confluence/display/SP3/XMLMetadataProvider>

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

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

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

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

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

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

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

```php
//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>

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

```php
// 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](https://help.edu.hu/books/alapok-es-fogalmak/page/foderacio) 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](https://idp.niif.hu/shibboleth) formában
- **URN**: valamilyen URN hierarchiában, pl. `urn:geant:niif.hu:href:idp:niifi`

<p class="callout info">**Info**  
  
Azt tanácsolják, hogy, amennyiben a providerId URL, akkor az az entitáshoz tartozó metaadatokat szolgálja ki, ezzel lehetővé téve dinamikus metaadatok használatát.   
  
A [HREF](https://help.edu.hu/books/hrefeduid-foderacio/page/href) jelenleg nem használ dinamikus metaadatokat.</p>

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](https://help.edu.hu/books/elavult-archiv/page/attributum-kiadas).

# 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

| Code name | Metadata signing certificate | Date of expiration |
|---|---|---|
| HREF-2011 | [href-metadata-signer-2011.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2011.crt) | 2022.01.01. |
| HREF-2015 | [mdx-test-signer-2015.crt](https://metadata.eduid.hu/certs/mdx-test-signer-2020.crt) | 2022.01.01. |
| HREF-2020 | [href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt) | 2025.06.14. |
| HREF-2025 | [href-metadata-signer-2025.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2025.crt) | 2030.06.14. |

### SHA1 fingerprints

| Code name | SHA1 fingerprint  |
|---|---|
| HREF-2011  | `FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66`  |
| HREF-2015  | `91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43`  |
| HREF-2020  | `C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61`  |
| HREF-2025  | `45:B2:33:96:7C:4F:7E:42:86:8D:CC:CF:CC:0E:3E:1C:2E:24:C2:DE`  |

### Domain names

| Domain | URL | Key | Status |
|---|---|---|---|
| metadata.eduid.hu | `metadata.eduid.hu/2011/href.xml` | HREF-2011  | Prod  |
| | `metadata.eduid.hu/2020/href.xml` | HREF-2020  | Prod  |
| | `metadata.eduid.hu/2025/href.xml` | HREF-2025  | Prod  |
| mdx.eduid.hu | `mdx-2015.eduid.hu` | HREF-2015  | Prod  |
| | `mdx-2020.eduid.hu` | HREF-2020  | Prod  |
| | `mdx-2025.eduid.hu` | HREF-2025  | Prod  |

### Discovery Service change

| URL  |
|---|
| <https://mdx-2020.eduid.hu/role/idp.ds>  |
| <https://mdx-2025.eduid.hu/discovery/ds>  |

## Shibboleth Service Provider beállítások

<https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider>

### XML

<https://wiki.shibboleth.net/confluence/display/SP3/XMLMetadataProvider>

```xml
<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>

```xml
<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

```xml
<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>

```xml
<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>

```xml
<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>

```xml
<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>

```xml
<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

```php
//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>

```php
// 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',
       ],
    ],
];
```

```php
// 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](http://www.pro-m.hu/) (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*</br>
	35 Váci út</br>
	H-1134 Budapest</br>
	Hungary

News and information about the federation is published at [http://eduid.hu](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.
1. Home Institutions must only authenticate users having a known affiliation to them.
1. IdPs and SPs must not give false or misleading information about themselves.
1. 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.
1. User credentials (i.e. passwords) stored by IdPs must be protected and verified only through secure procedures.
1. SPs must request only the user attributes which are absolutely necessary for their operation.
1. SPs must not ask users for their federation passwords.
1. SPs must handle personal data according to the local privacy laws.
1. IdPs and SPs must cooperate in the investigation of possible abuse/fraud.
1. 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.
1. Any organisation might join as a **Partner**.
1. All Members and Partners of the Federation might provide services.
1. A Partner might participate in the meeting of the Members' Board as an observer, without having rights to vote.
1. 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](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

| Szolgáltatások | Hallgatóknak | Oktatóknak | Adminisztratív  személyzet részére  |
|---|---|---|---|
| Internetelérés nem csak az anyaintézményben | + | + | +  |
| Online könyvtári szolgáltatások | + | + | +  |
| Online elérhető szakmai folyóiratok | + | + | +  |
| Tudás adatbázisok (tananyagok) | + | + |   |
| Statisztikai adatbázisok | + | + |   |
| Speciális keresési szolgáltatások  | + | + | +  |
| Hírszolgáltatások | + | + | +  |
| Elektronikus oktatási (e-learning) szolgáltatások | + | + | +  |
| Tanulmányi rendszerek | + | + |   |
| Elektronikus vizsgáztatási rendszerek | + | + |   |
| Számlázási, könyvelési szolgáltatások |  |  | +  |
| Erasmusos diákok VHO-s azonosítása | + |  |   |
| Külföldi oktatóknak biztosított szolgáltatások VHO-s azonosítása |  | + | +  |
| Közösségépítő szolgáltatások ([Sample Use Case](http://www.capacitybuilder.co.uk/login.asp?refer=)) | + | + |   |
| Hallgatói önkormányzatok saját  szolgáltatásai | + |  |   |
| Utazás iroda által nyújtott szolgáltatások | + | + | +  |
| Online rendelhető termékekre diák vagy oktatói kedvezmények (pl. jegyrendelés (mozijegy, koncert stb.) | + | + |   |
| Kollégiumokkal kapcsolatos szolgáltatások (adatbázis, jelentkezés stb.) | + |  | +  |
| HR szolgáltatások |  | + | +  |
| Projektszemléletű jogosultságok kezelése | + | + | +  |
| Telekommunikációs és informatikai szolgáltatások (pl. tárhely, domain név) | + | + |   |
| Marketing szolgáltatások, online felmérések | + | + | +  |
| Egyéb |  |  |   |

# Sirtfi

## Security Incident Response Trust Framework for Federated Identity (SIRTFI)

A [SIRTFI](https://refeds.org/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](https://help.edu.hu/books/aai-4BA/page/href-attributum-specifikacio) 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](https://help.edu.hu/books/elavult-archiv/page/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](#bkmrk-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](http://wiki.oasis-open.org/security/SAML2MetadataUI).

A kiegészítő séma névtere: `urn:oasis:names:tc:SAML:2.0:metadata:ui`. Az alábbi táblázatban ezen névtérben definiált legfontosabb elemeket foglaljuk össze:

| element név | szemantika | értékekre vonatkozó megkötések  |
|---|---|---|
| GeolocationHint | szélesség és hosszúság érték, a + előjel az északi szélességet illetve keleti hosszúságot jelöli | 47.47359,19.052891  |
| InformationURL | az entitásról további információkat (pl. helpdesk) szolgáltató oldal. |   |
| PrivacyStatementURL | Az SP adatvédelmi nyilatkozátnak elérhetősége (URL) | Engedélyezett formátumok: HTML, PDF  |
| Logo | Az IdP/SP logójának elérhetősége | Formátummal kapcsolatban lásd [Logo](#bkmrk-logo)  |
| IPHint | (Csak az IdP-knél) az intézmény hálózati tartománya(i). IdP felderítés esetén előválasztás lehetséges ennek alapján. | CIDR, több érték is megadható  |
| DomainHint | (Csak az IdP-knél) az intézmény által felügyelt domain név. IdP felderítés esetén előválasztás lehetséges ennek alapján. | Több érték is megadható  |


#### Logo

* formátum: URL egy transzparens hátterű PNG, vagy transzparens hátterű GIF képre
* méretezés
	* javasolt oldalarány 1:1 vagy 16:9
	* maximális méret 200x200px
	* ajánlott egy 16x16px-es verziót is megadni
* attribútumok
	* `xml:lang`: lokalizációs információ
	* `href`: opcionális link
	* `height`: opcionális magasság érték pixelben
	* `width`: opcionális szélesség érték pixelben

### Egy IdP példa

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

```xml
 <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](https://rr.eduid.hu) oldalról ütemezetten, minden óra 15. és 45. percében letöltésre kerül.
1. A letöltött metaadat XML séma ellenőrzése ellenőrzése.
1. 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](https://metadata.eduid.hu) oldalról érhető el.

| SHA-1 | `FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66`  |
|---|---|
| Serial Number | 1  |
| Version | 3  |
| C | HU  |
| O | NIIF Institute  |
| OU | eduID Federation Operator  |
| CN | Metadata Signer  |
| emailAddress | aai@niif.hu  |
| Érvényesség kezdete | 2011.10.05.  |
| Érvényesség vége | 2031.09.30.  |

#### HREF-2020

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

| SHA-1 | `C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61`  |
|---|---|
| Serial Number | 80:21:EF:F0:BA:16:04:BD  |
| Version | 1  |
| C | HU  |
| ST | Budapest  |
| L | Budapest  |
| O | Governmental Agency for IT Development  |
| OU | eduID Federation Operator  |
| CN | Metadata Signer  |
| emailAddress | info@eduid.hu  |
| Érvényesség kezdete | 2020.06.13.  |
| Érvényesség vége | 2025.06.14.  |

### Aláíró kulcs cseréje

* A kulccsere koordinálása a `href-tech` levelezőlistán keresztül történik.
* Kulcs visszavonásakor (kompromittálódás gyanúja esetén) a régi aláíró kulcs azonnal eltávolításra kerül, kontrollált kulcscsere esetén az aláírás párhuzamosan történik a régi és az új kulccsal.

## Metaadat elérése

A HREF föderációban többféle metaadat-forrás áll rendelkezésre, melyeket a [http://metadata.eduid.hu](http://metadata.eduid.hu) -ról lehet elérni. Fontos megemlíteni, hogy a metadata letöltésénél nem indokolt az SSL használata, ezért - amennyiben lehetséges -, érdemes a metadata URL-eket nem titkosított HTTP protokoll segítségével letölteni.

A metadata elérés URL-je a következő: `http://metadata.eduid.hu/${alairo_kulcs_kibocsatas_eve}/${metadata_forras}.xml`.

A metadata források jelenleg a következők lehetnek:

| `href.xml` | Az éles föderációban részt vevő, és a föderáció kritériumait teljesítő entitások.  |
|---|---|
| `href-test.xml` | A HREF föderáció tesztrendszerei. Bármely, a föderációban részt vevő intézmény tehet be teszt-entitást ebbe a halmazba, ezért ezen metaadat-forrás csak tesztelési célra használható.  |
| `href-pending.xml` | A HREF föderáció "előszobája". Az újonnan csatlakozó intézmények IdP-je először itt lesz elérhető.  |
| `href-edugain.xml` | A HREF föderációból az [eduGAIN](http://edugain.org) konföderációba kiajánlott entitások. Ide csak olyan entitások kerülhetnek be, melyek megfelelnek a föderációs kritériumoknak, és képesek az [eduGAIN](http://edugain.org) konföderációval való együttműködésre. Ezen entitások be kell hogy olvassák az eduGAIN metaadatot is.  |
| `edugain.xml` | Az [eduGAIN](http://edugain.org) konföderáció metaadata, a HREF aláíró kulccsal aláírva.  |
| `intézmény-specifikus` | Az intézmény-specifikus metaadat fájlok (pl.: bme.xml, ceu.xml, stb.), melyeket a föderáció kérésre biztosítja, tetszőleges entitások halmazba gyűjtésével.  |

### MDX-alapú elérés

Az MDX, azaz MetaDataeXchange protokolt erőforrás optimalizálás céljából találták ki, hogy ne kelljen egyes IdP-knek és SP-knek indokolatlanul nagy XML fájlokat feldolgozniuk és tárolniuk, mikor a felhasználóiknak jó eséllyel a fájlokban tárolt entitások töredékére van csak szükségük. Ezért az egyes entitásokat be lehet úgy állítani, hogy csak akkor töltsék le az adott entitás metaadatát, mikor arra szükség van (az első letöltés után természetesen helyben tároldóik a metaadat a `cacheDuration`-ben megadott ideig).

A HREF föderációban teszt jelleggel működik és elérhető MDX-kiszolgáló: [http://mdx.eduid.hu](http://mdx.eduid.hu). A megfelelő beállításokhoz [itt](https://help.edu.hu/books/hrefeduid-foderacio/page/mdx) é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](http://metadata.eduid.hu/current/mdx-test-signer-2015.crt)

#### HREF-2015

| SHA-1 | `91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43`  |
|---|---|
| Serial Number | AA:90:7C:D9:0C:D5:64:8D  |
| Version | 3  |
| C | HU  |
| ST | -  |
| L | Budapest  |
| O | NIIFI  |
| OU | AAI  |
| CN | eduID MDX metadata signer  |
| emailAddress | aai@niif.hu  |
| Érvényesség kezdete | 2015.10.13.  |
| Érvényesség vége | 2034.12.12.  |

# FederationStats

# Federation usage statistics

<p class="callout warning">
<strong>A szócikk vagy fejezet még megírásra vár</strong>
</p>

Federation visualization project - discountinued.

* source (ruby on rails) [https://repo.niif.hu/gitweb/gitweb.cgi?p=federation-stats.git;a=summary](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:

<pre>
ENTITYID <a href="https://idp.niif.hu/idp/shibboleth">https://idp.niif.hu/idp/shibboleth</a>
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       | <a href="https://repo.niif.hu/shibboleth">https://repo.niif.hu/shibboleth</a>
1        | <a href="https://sandbox.aai.niif.hu/shibboleth">https://sandbox.aai.niif.hu/shibboleth</a>
5        | <a href="https://sysmonitor.hbone.hu/shibboleth">https://sysmonitor.hbone.hu/shibboleth</a>
10       | <a href="https://www.ki.iif.hu/shibboleth">https://www.ki.iif.hu/shibboleth</a>
1        | <a href="https://noc6.vh.hbone.hu/shibboleth">https://noc6.vh.hbone.hu/shibboleth</a>
21       | <a href="https://webadmin.iif.hu/shibboleth">https://webadmin.iif.hu/shibboleth</a>
3        | <a href="https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth">https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth</a>
7        | <a href="https://ugyeletes.vh.hbone.hu/shibboleth">https://ugyeletes.vh.hbone.hu/shibboleth</a>
2        | <a href="https://noc.grid.niif.hu/shibboleth">https://noc.grid.niif.hu/shibboleth</a>
1        | <a href="https://wiki.voip.niif.hu/shibboleth">https://wiki.voip.niif.hu/shibboleth</a>
2        | <a href="https://netmonitor.hbone.hu/shibboleth">https://netmonitor.hbone.hu/shibboleth</a>
2        | <a href="https://idp.sch.bme.hu:443/opensso/sp/test">https://idp.sch.bme.hu:443/opensso/sp/test</a>
</pre>

## 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:

```bash
#!/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.

```bash
#!/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](https://help.edu.hu/books/alapok-es-fogalmak/page/foderacio).

## Föderációs Operátor

A Föderációs Operátor a [Tagokkal](#bkmrk-tag) és [Partnerekkel](#bkmrk-partner) 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](#bkmrk-discovery-service), [Resource Registry](#bkmrk-resource-registry)), a [Metadata](#bkmrk-metaadatok) á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](https://help.edu.hu/books/aai-4BA/page/href-szolgaltatasi-szint-megallapodas) tartalmazza.

## Felhasználó

Egy [Tag](#bkmrk-tag) alkalmazottja, oktatási tevékenységet végző munkatársa ill. hallgatója, akik igénybevehetik a [Tartalomszolgáltatók](#bkmrk-tartalomszolgáltató) szolgáltatásait.

## Tag

A [HREF Föderációhoz](#bkmrk-href-föderáció) a [Föderációs Operátorral](#bkmrk-föderációs-operátor) 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](#bkmrk-felhasználó) igénybe vehenek más tagok ill. [Partnerek](#bkmrk-partner) által biztosított szolgáltatásokat.

## Partner

A [HREF Föderációhoz](#bkmrk-href-föderáció) a [Föderációs Operátorral](#bkmrk-föderációs-operátor) 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](#bkmrk-tag) által azonosított felhasználók számára.

## Tagok Tanácsa

A [Föderáció](#bkmrk-href-föderáció) működését szabályozó dokumentumokat a [Föderációs Operátor](#bkmrk-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](#bkmrk-azonosító-szervezet), ill. az [IdP AAI Kaput](#bkmrk-idp-aai-kapu).

## 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](#bkmrk-attribútum) adhat át a [Tartalomszolgáltatónak](#bkmrk-tartalomszolgáltató)

## 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](#bkmrk-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](#bkmrk-idp-aai-kapu) átadja a [Tartalomszolgáltatónak](#bkmrk-tartalomszolgáltató).

## 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](#bkmrk-attribútum)) kiadására.

## SP

Service Provider. Szövegkörnyezettől függően jelentheti a [Tartalomszolgáltatót](#bkmrk-tartalomszolgáltató), ill. az [SP AAI Kaput](#bkmrk-sp-aai-kapu).

## Tartalomszolgáltató

A Tartalomszolgáltató az [Azonosító Szervezet](#bkmrk-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](#bkmrk-href-föderáció) 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](#bkmrk-azonosító-szervezet) 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](#bkmrk-sp-aai-kapu) és az [IdP AAI Kapu](#bkmrk-idp-aai-kapu) összefoglaló neve.

## Saját SP

[Tag](#bkmrk-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](#bkmrk-resource-registry) segítségével, azonban a föderációs [metadatában](#bkmrk-metaadatok) nem jelennek meg.

## Resource Registry

A Resource Registry az [HREF Föderáció](#bkmrk-href-föderáció) működtetéséhez szükséges olyan nyilvántartás, amely az [Azonosító Szervezetekre](#bkmrk-azonosító-szervezet) és a [Tartalomszolgáltatókra](#bkmrk-tartalomszolgáltató) vonatkozó információkat kezeli. A Resource Registry segítségével előállítható és szerkeszthető a föderációs [Metadata](#bkmrk-metaadatok), 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](#bkmrk-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](#bkmrk-azonosító-szervezet).

Keresőszolgáltatást [Tartalomszolgáltató](#bkmrk-tartalomszolgáltató) és [Azonosító Szervezet](#bkmrk-azonosító-szervezet) is üzemeltethet.

## Metaadatok

(Metadata) Az [HREF Föderációban](#bkmrk-href-föderáció) 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ó](https://help.edu.hu/books/aai-4BA/page/href-metadata-specifikacio) részletezi.

## Virtuális Azonosító Szervezet

(VHO, Virtual Home Organization) A [Föderációs Operátor](#bkmrk-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

![The Big Attribute Picture](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-08/jra5attributes_bigpicture.png)

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](https://help.edu.hu/books/hrefeduid-foderacio/page/attribute-conversion-for-edugain) 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](http://en.wikipedia.org/wiki/Regular_expression) and [Unified Expression Language](http://en.wikipedia.org/wiki/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.

```xml
<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.

```xml
<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.

```xml
<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.

```xml
<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.

<p class="callout info">**Info**  
  
You cannot reference regular expressions from another rule.</p>

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

```xml
<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.

```xml
<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.

```xml
<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):

```xml
<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.

<table id="bkmrk-physical-input-attri"><thead><tr><th>Physical input attribute name</th><th>Logical attribute name</th><th>Physical output attribute name</th></tr></thead><tbody><tr><td>urn:mace:dir:attribute-def:mail</td><td>**mail** {: rowspan="2"}</td><td>urn:mace:dir:attribute-def:mail {: rowspan="2"}</td></tr><tr><td>urn:oid:0.9.2342.19200300.100.1.3</td><td>&amp;#8288 {: style="padding:0"}</td><td>&amp;#8288 {: style="padding:0"}</td></tr></tbody></table>

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

```xml
 <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.

<p class="callout info">**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.</p>

### 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
<?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).

```java
  // 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`.

<p class="callout danger">**Figyelem**  
  
If you do not pass `local` or `remote` then rules containing `LocalProviderMatch` or `RemoteProviderMatch` will **NOT** be executed.</p>

```java
  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
<?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
<?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
<?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

<p class="callout warning">**A szócikk vagy fejezet még megírásra vár**  
  
Please post your BE configuration here.</p>

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

| Namespace | Purpose | Date Registered | Registry link/email  |
|---|---|---|---|
|  urn:geant:niif.hu:niif| Namespace supporting KIFÜ systems | 10 March 2010 | urn@niif.hu  |
| - | - | - | -  |

# 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](http://www.geant2.net/server/show/nav.1876).

## 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](https://forja.rediris.es/projects/urnreg/).

### 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](https://forja.rediris.es/projects/siledap/) (kipróbálva: 0.2)

#### Slapd inicializálás

[A Quickstart Guide](http://www.openldap.org/doc/admin23/quickstart.html) 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](http://www.niif.hu) 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.
1. Home Institutions must only authenticate users having a known affiliation to them.
1. IdPs and SPs must not give false or misleading information about themselves.
1. 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.
1. User credentials (i.e. passwords) stored by IdPs must be protected and verified only through secure procedures.
1. SPs must request only the user attributes which are absolutely necessary for their operation.
1. SPs must not ask users for their federation passwords.
1. SPs must handle personal data according to the local privacy laws.
1. IdPs and SPs must cooperate in the investigation of possible abuse/fraud.
1. 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.
1. Any organisation might join as a **Partner**.
1. All Members and Partners of the Federation might provide services.
1. A Partner might participate in the meeting of the Members' Board as an observer, without having rights to vote.
1. 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](http://www.eduid.hu/wp-content/uploads/2012/08/href-contract-partner.doc)**.


## Technical information


### Operational requirements

* [SP Operational Requirements](https://help.edu.hu/books/aai-4BA/page/sp-operational-requirements)
* [IdP Operational Requirements](https://help.edu.hu/books/aai-4BA/page/idp-operational-requirements)


### Attributes

[Attribute Specification](https://help.edu.hu/books/hrefeduid-foderacio/page/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](https://help.edu.hu/books/hrefeduid-foderacio/page/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](#bkmrk-contacts)) 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](https://help.edu.hu/books/hrefeduid-foderacio/page/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:

<pre>
ENTITYID <a href="https://idp.niif.hu/idp/shibboleth">https://idp.niif.hu/idp/shibboleth</a>
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       | <a href="https://repo.niif.hu/shibboleth">https://repo.niif.hu/shibboleth</a>
1        | <a href="https://sandbox.aai.niif.hu/shibboleth">https://sandbox.aai.niif.hu/shibboleth</a>
5        | <a href="https://sysmonitor.hbone.hu/shibboleth">https://sysmonitor.hbone.hu/shibboleth</a>
10       | <a href="https://www.ki.iif.hu/shibboleth">https://www.ki.iif.hu/shibboleth</a>
1        | <a href="https://noc6.vh.hbone.hu/shibboleth">https://noc6.vh.hbone.hu/shibboleth</a>
21       | <a href="https://webadmin.iif.hu/shibboleth">https://webadmin.iif.hu/shibboleth</a>
3        | <a href="https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth">https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth</a>
7        | <a href="https://ugyeletes.vh.hbone.hu/shibboleth">https://ugyeletes.vh.hbone.hu/shibboleth</a>
2        | <a href="https://noc.grid.niif.hu/shibboleth">https://noc.grid.niif.hu/shibboleth</a>
1        | <a href="https://wiki.voip.niif.hu/shibboleth">https://wiki.voip.niif.hu/shibboleth</a>
2        | <a href="https://netmonitor.hbone.hu/shibboleth">https://netmonitor.hbone.hu/shibboleth</a>
2        | <a href="https://idp.sch.bme.hu:443/opensso/sp/test">https://idp.sch.bme.hu:443/opensso/sp/test</a>
</pre>

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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-08-Aug/Audit_shib.py) és [simpleSAMLphp-hez](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-08-Aug/Audit_ssp.py) készítettük el.
1. A beküldendő fájlt elkészítő [szkript](https://help.edu.hu/books/hrefeduid-foderacio/page/federationstats) 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.
1. Az utóbbi szkript elején meg kell adni a beállításokat.

```bash
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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-08-Aug/Audit_shib_cstamas.py)
* Példa konfig: [Audit_shib_cstamas.cfg](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-08-Aug/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.

```bash
 #!/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](https://listserv.niif.hu/mailman/listinfo/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](http://edugain.org) 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](http://edugain.org) 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](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](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](https://help.edu.hu/books/hrefeduid-foderacio/page/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](https://help.edu.hu/books/simplesamlphp/page/simplesamlmixedmetadata).

## 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](https://help.edu.hu/books/kiegeszito-tudnivalok/page/ssp-entitycategories).
* *Shibboleth*: natívan ismeri mindkét attribútumkiadási mechanizmust:
	* [https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeInMetadata](https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeInMetadata)
	* [https://wiki.shibboleth.net/confluence/display/IDP30/EntityAttributeExactMatchConfiguration](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](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](https://help.edu.hu/books/hrefeduid-foderacio/page/mdx)!

### 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](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](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](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](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](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](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](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](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](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:

```php
'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](https://help.edu.hu/books/simplesamlphp/page/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](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

```xml
<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](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt)
* A `conf/metadata-providers.xml` fájlt kell szerkeszteni az alábbi módon:

```xml
<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ó](https://help.edu.hu/books/alapok-es-fogalmak/page/foderacio)
* [Károkozási táblázat](https://help.edu.hu/books/aai-4BA/page/karokozasi-tablazat)
* [Döntési táblázat](https://help.edu.hu/books/aai-4BA/page/dontesi-tablazat)
* [Metadata specifikáció](https://help.edu.hu/books/hrefeduid-foderacio/page/href-metadata-specifikacio)
* [Attribútum specifikáció](https://help.edu.hu/books/hrefeduid-foderacio/page/href-attributum-specifikacio)
* [Föderációs operátor szolgáltatásai](https://help.edu.hu/books/hrefeduid-foderacio/page/href-szolgaltatasi-szint-megallapodas)
* [Naplózás a föderációban](https://help.edu.hu/books/aai-4BA/page/fedentitieslogging)
* [HREFPolicyStub](https://help.edu.hu/books/hrefeduid-foderacio/page/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](https://help.edu.hu/books/kiegeszito-tudnivalok/page/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](https://help.edu.hu/books/elavult-archiv/page/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

|eduPersonTargetedID  |
|---|
|eduPersonScopedAffiliation  |
|schacHomeOrganizationType  |


#### Recommended attributes

|mail  |
|---|
|eduPersonEntitlement  |

#### Optional attributes

| Attributes describing </br>user properties | Attributes describing </br>institutional relationship | Attributes for </br>educational use  |
|---|---|---|
| sn | ou | niifEduPersonAttendedCourse  |
| givenName | eduPersonOrgUnitDN | niifEduPersonArchiveCourse  |
| preferredLanguage | eduPersonPrimaryOrgUnitDN | niifEduPersonHeldCourse  |
| schacDateOfBirth | | niifEduPersonMajor  |
| schacYearOfBirth | | niifEduPersonFaculty  |
| schacPersonalTitle | | niifEduPersonFacultyDN  |
| niifPersonMothersName  | | niifEduPersonStudentCategory  |
| niifPersonResidentalAddress  | | |
| homePostalAddress  | | |
| telephoneNumber  | | |
| mobile  | | |
| eduPersonNickName  | | |
| cn  | | |
| jpegPhoto  | | |
| labeledUri  | | |


### Persistent user identifiers

For most services, it is necessary to store application-specific data, such as user edits for a wiki page. This data is stored in a database, which is local to the SP, while the key between the user and the database entry is the **persistent user identifier**.

Persistent identifiers can be:

* **computed**: the identifier is generated run-time from one or more attributes of the user (usually by some cryptographic hashing algorithm).
* **stored**: the identifier is stored in the user's digital identity at the IdP, thus it is persistent even when other user information is changed. Uniqueness of the identifier must be preserved.

Identifiers can hold the following properties:

* **persistence**: IdPs must ensure that the identifier does not change during the life-cycle of the user at the institution.
* **non-reassignable**: IdPs must ensure that an identifier of a user will not be reassigned to another user.
* **opacity**: opaque identifiers do not refer to any personal data
* **targeted**: targeted identifiers are different for each SP, thus the SPs are unable to build common user profile without the cooperation of the IdP. Such identifiers are preferred from privacy reasons.

Persistent identifiers can be transferred in SAML attributes or in NameID of a SAML Assertion. Certain SP implementations (such as Shibboleth 2.x) can hide the details of the transfer, and can provide a persistent identifier in REMOTE_USER header.


### List of attributes

In this specification, only mandatory and recommended attributes are specified. The [Hungarian version of the Attribute Specification](https://help.edu.hu/books/hrefeduid-foderacio/page/href-attributum-specifikacio) contains descriptions of the optional attributes as well. If you have any questions regarding the optional attributes, please contact the Federation Operator.


#### eduPersonTargetedID


|     | eduPersonTargetedID |
|---|---|
| **Elnevezés** | **URI:** urn:mace:dir:attribute-def:eduPersonTargetedID</br> **OID:** 1.3.6.1.4.1.5923.1.1.1.10 |
| **Rövid leírás** | **Opaque**, **targeted**, **non-reassignable** identifier |
| **Implementáció** | kötelező |
| **Részletes leírás** | See: <https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID> </br></br> An SP must process the received value, it must not forward unparsed XML value to the application. As a minimum, the unique identifier and the IdP `NameQualifier` must be included in the parsed value, which is forwarded to the application. It is recommended to separate fields (such as qualifier values) with an exclamation mark ('!'). |
| **Lehetséges értékek** | nincs korlátozás |
| **Értékek száma** | `single` |
| **Szintaktika** | `Must be a SAML2 persistent NameID; the unique identifier part must not be longer than 256 ASCII characters.` |
| **Adatgazda** | intézmény |
| **Példa** | An IdP sends the attribute on the wire such as:</br></br><pre><saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"<br>   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"<br>   NameQualifier="<https://idp.example.org/idp/shibboleth>"<br>   SPNameQualifier="<https://sp.example.org/shibboleth>"><br>84e411ea-7daa-4a57-bbf6-b5cc52981b73<br></saml2:NameID></pre></br> The application at the SP receives the attribute as the following:</br><https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73> |



#### eduPersonPrincipalName


|     | eduPersonPrincipalName |
| --- | --- |
| **Elnevezés** | **URI:** urn:mace:dir:attribute-def:eduPersonPrincipalName</br> **OID:** 1.3.6.1.4.1.5923.1.1.1.6 |
| **Rövid leírás** | **Persistent**, **non-targeted**, **non-reassignable** personal identifier |
| **Implementáció** | kötelező |
| **Részletes leírás** | Format: `<local_id>`@`<scope>` </br></br> where: </br> <li> **`<local_id>`**: arbitrary persistent key which unambiguously maps to a person within an institution.<li> **`<scope>`**: local security domain. It must have a format as a DNS domain, and ends with a resolvable domain name, which is possessed by the identity provider institution. (Note: the scope as a whole may not be resolved from DNS.)</br></br>**Note**: **eduPersonPrincipalName** is sensitive personal data, it is often equal to the mail address of the person. It is recommended to use it only within the institution's domain. For federation use, opaque, targeted identifiers are more privacy preserving.</br></br>eduPersonPrincipalName **must not be reassigned**</br></br>As some applications do not support special characters in identifiers, eduPersonPrincipalName MUST only contain the following characters: alpanumeric characters, dot ('.'), hyphen ('-') and underscore ('_'). |
| **Lehetséges értékek** | nincs korlátozás |
| **Értékek száma** | `single` |
| **Szintaktika** | `Directory String` |
| **Adatgazda** | intézmény |
| **Példa** | gipsz.jakab@example.org |



#### displayName


|     | displayName |
| --- | --- |
| **Elnevezés** | **URI:** urn:mace:dir:attribute-def:displayname</br> **OID:** 2.16.840.1.113730.3.1.241 |
| **Rövid leírás** | Display name of the person |
| **Implementáció** | ajánlott |
| **Részletes leírás** | Full name of the person in a form the user (or his or her institution) probably wants to be shown.</br></br>For international use, please note that Hungarian names are usually in the form of ***Surname Givenname***, and names often contain accented or other non-ascii characters. But also note that this document does not specify the exact name order. |
| **Lehetséges értékek** | nincs korlátozás |
| **Értékek száma** | `single` |
| **Szintaktika** | `Directory String` |
| **Példa** | Gipsz Jakab Aladár |



#### mail


|     | mail |
| --- | --- |
| **Elnevezés** | **URI:** urn:mace:dir:attribute-def:mail</br> **OID:** 0.9.2342.19200300.100.1.3 |
| **Rövid leírás** | Mail address of the person |
| **Implementáció** | ajánlott |
| **Részletes leírás** | Notification email address of the person. The institution asserts that</br><li> either the address is provided by the institution to the person<li> or the address was provided by the person and the availability and the possession of the mailbox was verified (i.e. by sending a verification email before recording).</br></br>Transferring unverified values in this attribute is not allowed. |
| **Lehetséges értékek** | Valid email address |
| **Értékek száma** | `multi` |
| **Szintaktika** | `See also: [RFC 2822](http://www.faqs.org/rfcs/rfc2822.html)` |
| **Adatgazda** | intézmény |
| **Példa** | gipsz.jakab@example.org |



#### eduPersonScopedAffiliation

|     | eduPersonScopedAffiliation |
| --- | --- |
| **OID** | 1.3.6.1.4.1.5923.1.1.1.9 |
| **Description** | Describes the relationship between the person and the institution |
| **Semantics** | **`<affiliation>`@`<scope>`**<li> **`<affiliation>`**: the following values are permitted<ul><li>*student*: the person is a student at the institution<li>*faculty*: the person is a member of the teaching or researching staff<li>*staff*: the person is a member of the non-teaching staff (ie. IT personnel, etc)<li>*employee*: the person is employed in the institution (not recommended for use between institutions)<li>*member*: users who get basic set of privileges. In general, users having *student*, *faculty* or *staff* affiliations, should also be given this value.<li>*affiliate*: the user is recognised by the institution, but no basic privileges should be given.<li>*alum*: alumni<li>*library-walk-in*: affiliated to the library only</ul><li> **`<scope>`**: local security domain. It must have a format as a DNS domain, and ends with a resolvable domain name, which is possessed by the identity provider institution.</br></br>(Note: the scope as a whole may not be resolved from DNS.)\n\nSee also: <http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation> |
| **Values** | One of the following: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, followed by the **scope** |
| **# of values** | `multi` |
| **Availability** | `-` |
| **Syntax** | `Directory String` |
| **Examples** | <li> Learners: *student@example.org;member@example.org* <li> Teachers: *faculty@example.org;member@example.org* |
| **Notes** | - |
| **Use in federation** | - |


#### eduPersonEntitlement


|     | eduPersonEntitlement |
| --- | --- |
| **Elnevezés** | **URI:** urn:mace:dir:attribute-def:eduPersonEntitlement</br> **OID:** 1.3.6.1.4.1.5923.1.1.1.7 |
| **Rövid leírás** | URI (either URN or URL) that indicates a set of rights to specific resources. |
| **Implementáció** | ajánlott |
| **Részletes leírás** | List of resources what the user is entitled to use at the SP. The trust between the two parties must be established out of band.</br></br>**An IdP should give only the values which are relevant for the SP** |
| **Lehetséges értékek** | nincs korlátozás |
| **Értékek száma** | `multi` |
| **Szintaktika** | `Directory String` |
| **Adatgazda** | intézmény |
| **Példa** | urn:geant:niif.hu:niif:entitlement:vhoadmin |



#### schacHomeOrganizationType

|     | schacHomeOrganizationType |
| --- | --- |
| **OID** | 1.3.6.1.4.1.25178.1.2.10 |
| **Description** | Type of the Home Organisation |
| **Semantics** | <li>**university**: universities and colleges<li> **nren**: National research and educational network<li> **library**: Libraries<li> **vho**:  Virtual home organisation<li> **school**: Primary and secondary education<li> **business**: Industrial or commercial companies<li> **other**: Other<li> **test**: The principal is a test account |
| **Values** | urn:schac:homeOrganizationType:hu:{university,nren,library,vho,school,business,other,test} |
| **# of values** | `multi` |
| **Availability** | `-` |
| **Syntax** | `Directory String` |
| **Examples** | - |
| **Notes** | - |
| **Use in federation** | - |