„HREF műszaki előírások” változatai közötti eltérés

Innen: KIFÜ Wiki
(egyéb)
a (3. Üzemeltetési kérdések: typo)
 
(27 közbenső módosítás, amit 3 másik szerkesztő végzett, nincs mutatva)
1. sor: 1. sor:
= Föderációs policy csatlakozó intézmények (IdP-k) számára =
+
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.
  
{{ATTENTION|A specifikáció kidolgozása folyamatban van, lényeges változások is belekerülhetnek figyelmeztetés nélkül. Amíg ez a figyelmeztetés itt szerepel, addig munkaverziónak tekintendő!}}
+
A dokumentumban a '''KÖTELEZŐ''', '''TILOS''', '''AJÁNLOTT''', '''NEM AJÁNLOTT''' kifejezések értelmezése az alábbiak szerinti:
  
{{TODO|Kérlek, kommentjeiddel segítsd a tervezetet!}}
+
* '''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;
  
== Jelen dokumentum célja ==
+
* '''TILOS''' jelentése KÖTELEZŐ NEM, azaz a pontban leírtak szerint az intézmény nem járhat el;
A dokumentum célja, hogy a föderációhoz csatlakozó intézmények számára elvárásokat és ajánlásokat fogalmazzon meg, melyek a csatlakozáshoz szükséges általános üzemeltetési és identitás-menedzsment területeket fednek le. Ezen elvárások és ajánlások a föderációba vetett bizalom kiépítéséhez és megtartásához elengedhetetlenül szükségesek.
 
  
== Felépítés ==
+
* 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.
  
= Identitás-menedzsment =
 
Jelen fejezet összefoglalja az intézményen belüli felhasználókezelésre vonatkozó előírásokat és tanácsokat. A felhasználókezelés magában foglalja a
 
  
* felhasználói accountok létrehozását,
+
== 1. Identitás-menedzsment ==
* ezen accountok folyamatos ellenőrzését és naprakészen tartását,
 
* a felhasználó távozása után a felhasználói adatok törlését,
 
* az adatok védelmét illetéktelen behatolással szemben.
 
  
Az intézmények kötelesek az alkalmazott felhasználókezelési elveiket dokumentálni, és a működést ezen dokumentáció alapján rendszeresen ellenőrizni, szükség esetén a dokumentációt frissíteni.
+
:1.1. Az intézmény köteles adatkezelési elveit dokumentálni, azt a felhasználókkal megismertetni.
  
== Adatforrások ==
+
: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.
A felhasználói adatok több helyről származhatnak:
 
  
* személyes felvétel,
+
:1.3. Kötelező a felhasználónevek egyediségét biztosítani.
* egyéb autoritatív adatbázis (tanulmányi, munkaügyi rendszer).
 
  
Amennyiben egy intézmény külső, független adatbázist használ az IdP adatbázisának feltöltésére, köteles a következő kritériumokat betartani:
+
:1.4. Egy természetes személyhez nem ajánlott több felhasználói azonosítót rendelni.
  
* az adatforrásként szolgáló rendszer naprakész adatokat tartalmaz
+
:1.5. Nem ajánlott szerep felhasználók (dékán, igazgató) használata.
* az IdP adatbázisban szereplő felhasználók rendszeresen szinkronizálásra kerülnek az autoritatív adatbázissal
 
* a hiteles adatforrásból kikerülő felhasználókat törölni kell az IdP adatbázisából is.
 
  
 +
:1.6. Attribútumok használata:
  
== Hitelesítési policy ==
+
::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;
* Az IdP adatbázisában (LDAP, relációs adatbázis) szereplő minden egyes bejegyzésnek egy valós, intézmény által azonosított felhasználóhoz kell tartoznia.
 
* Minden egyes adatbázisbeli bejegyzés különböző egyénhez kell tartozzon.
 
* A felhasználói account hitelesítésekor ajánlott az account tulajdonosát személyesen azonosítani, személyi igazolvány, vagy egyéb hivatalos okmány segítségével.
 
* Ajánlott a természetes azonosítókat (név, anyja neve, születési hely és idő), illetve a postai elérhetőséget a hivatalos okmányokon szereplő adatokkal egyeztetni.
 
* Amennyiben a felhasználók nem közvetlenül kerülnek rögzítésre az IdP adatbázisába, hanem külső adatforrásból, ezen azonosítási feladatok a külső adatforrás karbantartóját (pl. tanulmányi rendszer) terhelik.
 
  
 +
::1.6.2. Az IdP-nek kötelező megvalósítania az alábbi attribútumokat:
 +
::* eduPersonTargetedID
 +
::* eduPersonPrincipalName
 +
::* eduPersonScopedAffialiation
  
== Accountok kiosztása és karbantarása ==
+
::1.6.3. Az IdP-nek ajánlott megvalósítania az alábbi attribútumokat:
* Ajánlott a felhasználói accountokhoz tartozó jelszavakat személyes, vagy egyéb, nem elektronikus módon kiosztani (pl. postai úton).
+
::* displayName
* Lehetőség van arra, hogy a felhasználó saját maga állítsa be jelszavát, ha technikailag a felhasználó biztonságos azonosítása lehetséges (pl. külső rendszerben).
+
::* mail
* Az intézmény köteles a felhasználói adatbázisát rendszeresen karbantartani, abban a lejárt és nem használt accountokat letiltani.
+
::* sn
* Az intézmény köteles a felhasználói adatokban bekövetkezett változásokat 4 héten belül(?) átvezetni az IdP adatbázisába. Amennyiben egy felhasználó viszonya megszűnt az intézménnyel, 3 hónapon belül(?) a felhasználói accountot le kell tiltani.
+
::* givenName
* Az intézmény köteles a felhasználókról annyi adatot és annyi ideig megtartani, ameddig a felhasználó által esetleg okozott visszaélések bizonyíthatósága jogilag fennáll (?).
 
  
 +
::1.6.4. Az IdP-nek kötelező biztosítania, hogy az eduPersonTargetedID és az eduPersonPrincipalName attribútumok ne legyenek újra kioszthatók.
  
== Jelszavak ==
+
:1.7. Teszt felhasználók az alábbi megkötések mentén használhatóak:
* Az intézmények kötelesek dokumentálni a jelszavakkal kapcsolatban alkalmazott megkötéseiket.
 
* A jelszavak minimális hossza legalább 6 karakter.
 
* Ajánlott a legalább 8 karakteres, több karakterosztályt tartalmazó jelszavak kikényszerítése.
 
* Ajánlott a szótárban szereplő szavak jelszavakban történő felhasználásának tiltása.
 
* Ajánlott a jelszavak cseréjének kikényszerítése legalább évente (illetve az utolsó 3 évben felhasznált jelszavak újrabeállításának tiltása).
 
* Ajánlott a jelszavak brute-force támadásának kiszűrése, egyéb preventív módszerek alkalmazása (például 3 elrontott jelszó után automatikus 5 perces tiltás).
 
* Ha az IdP adatbázisa külső rendszerrel szinkronizált, lehetséges a jelszómódosítást a külső rendszerben használt jelszóhoz kötni, amennyiben a külső rendszerben kikényszerített jelszó-policy a fent leírtaknak megfelel.
 
* A jelszavak csak titkosított csatornán kerülhetnek átadásra bármely két, hálózatilag szeparált rendszerelem között (pl. böngésző - IdP, IdP - LDAP, ...)
 
  
= Szolgáltatás-menedzsment =
+
::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),
Ez a szakasz az előzőekben leírt identitás-menedzsment elvekhez kapcsolódóan az egyes szoftver-komponensek üzemeltetését foglalja össze. A szakasz többnyire csak ajánlásokat fogalmaz meg.
 
  
== Rendelkezésre állás ==
+
::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,
* Tervezett leállások csak az előre meghirdetett karbantartási időszakokban történjenek.
 
* Szükséges dokumentálni a szolgáltatási szintet, mely a következő pontokat foglalja magában:
 
** egy éven belüli előre tervezett karbantartási célú leállások maximális száma
 
** egy éven belüli maximális állási idő
 
** a leállási időszakok kommunikálásának módja
 
** nem tervezett leállások kommunikálásának módja
 
* A karbantartási időszakokat ajánlott rendszeres frissítések alkalmazására használni, ezen karbantartások lehetőleg előre kiszámíthatóan, kevés kiesést okozó időben történjenek.
 
* Az IdP szolgáltatás lehető legnagyobb rendelkezésre állása klaszterezett architektúrában valósítható meg.
 
* Amennyiben a klaszterezett működés nem megvalósítható, ajánlott egy tartalék-rendszer kiépítése, amely probléma esetén minimális kézi beavatkozással képes átvenni a működést.
 
* Klaszterezett esetben fontos, hogy sem a terheléselosztó, sem az autentikációs és egyéb adatforrások nem képeznek egyszeres hibapontot a rendszerben. A hálózati eszközök és áramforrások redundáns kiépítése is ajánlott.
 
  
 +
::1.7.3. ajánlott ezen felhasználókat a megfelelő homeOrganizationType értékkel megkülönböztetni.
  
== Support ==
+
: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.
* Az intézményeknek kötelességük az IdP-vel kapcsolatosan végfelhasználói támogatást nyújtani. Ezen támogatás elérhetőségéről a felhasználókat tájékoztatni kell, amit a [[Resource_Registry]]-n keresztül felvitt helpdesk URL segíthet.
 
* Az IdP-t üzemeltető szervezeti egység elérhetőségét fel kell tüntetni a [[Resource_Registry]]-ben. Ajánlott a csoporthoz közösen tartozó telefonszámot és e-mail címet használni.
 
* Az IdP operátori problémákat ajánlott issue tracking rendszerben követni, amihez optimális esetben hibaelhárítást segítő tudásbázis is tartozhat.
 
* A gyakran előforduló hibákat és kérdéseket ajánlott a fent említett helpdesk URL-en publikálni.
 
  
 +
:1.9. A felhasználói jelszavakat ajánlott nem elektronikus formában kiosztani (pl. személyesen, vagy postai úton).
  
== Incidens-kezelés ==
+
: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.
* Az intézményeknek kötelességük dokumentálni az IdP szolgáltatással kapcsolatos katasztrófa-elhárítási teendőket, és ezen dokumentációkat rendszeresen (legalább évente) ellenőrizni, naprakészen tartani.
 
* Amennyiben az IdP szolgáltatás által használt kriptográfiai kulcsok kompromittálódtak, az adminisztrátornak kötelessége a kulcsot visszavonni a föderációból (a [[Resource_Registry]]-n keresztül), illetve értesítenie a NIIF AAI csapatot.
 
  
 +
::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ó.
  
== Jelentések készítése ==
+
== 2. Szolgáltatás-menedzsment ==
* Az IdP szolgáltatás működésével kapcsolatban ajánlott meghatározni különböző metrikákat, melyek a szolgáltatás rendelkezésre állását és felhasználásának módját, hatékonyságát mérik.
+
: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.
* A föderáció összesített statisztikájának elkészítéséhez ajánlott a következő adatok begyűjtése, napi felbontással:
 
** egyedi felhasználók száma
 
** egyes szolgáltatások felé adott SSO autentikációk száma
 
** összes SSO session száma
 
* A működés belső finomításához ennél több, és részletesebb adatra is szükség lehet (csúcsterhelés meghatározása, terhelési időszakok számítása, kiadott attribútumok gyakorisága, ...)
 
  
= Üzemeltetési kérdések =
+
: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.
== Naplózás, monitorozás ==
 
* Az operációs rendszer illetve a webszerver naplóállományait rendszeresen monitorozni kell, a gyanús üzeneteket kivizsgálni szükséges.
 
* Folyamatosan monitorozni kell a hálózat elérhetőségét, lehetőleg ugyanazon a hálózati útvonalon, amelyen keresztül a felhasználók használják a szolgáltatást.
 
* Folyamatosan monitorozni kell a szükséges processzeket (NTP, webszerver, címtár-szerver, stb.)
 
  
=== IdP processz ===
+
: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.
* Az IdP alkalmazásszerver és az IdP processz logjait a hiba (ERROR) és figyelmeztetés (WARN) üzenetek szintjén folyamatosan monitorozni kell.
 
* A szolgáltatás kiesése esetén ajánlott a rendszergazdák automatikus értesítése (e-mail, sms)
 
* Ajánlott az IdP naplózási konfigurációját úgy módosítani, hogy a hibaüzenetek (ERROR) email-ben elküldésre kerüljenek.
 
* Az IdP processz alapvető működését folyamatosan monitorozni kell (/idp/Status).
 
* Ajánlott egy dedikált teszt-account segítségével a belépést figyelni. Ajánlott a teszt-account jelszavát gyakran (legalább havonta) megváltoztatni.
 
  
=== Naplóállományok ===
+
== 3. Üzemeltetési kérdések ==
* Azon naplóállományokat, melyek egy incidens esetén bizonyítékul szolgálhatnak (audit logok), szükséges legalább annyi ideig megőrizni, míg a bizonyítás kapcsán jogilag szükséges.
 
* A naplóállományokat ajánlott legalább 6 hónapig megőrizni.
 
* A személyes adatokhoz való hozzáférésről (pl. LDAP-access) naplóállományokat kell készíteni, ezeket az IdP naplókkal összhangban meg kell őrizni.
 
* Biztosítani kell, hogy a naplóállományokhoz csak az arra felhatalmazott személyek férhessenek hozzá.
 
* Amennyiben a naplóállományok elhagyják az IdP-t, kötelező a benne szereplő személyes adatokat (minden felhasználói attribútum, IP cím, stb...) törölni, "anonimizálni".
 
* Ajánlott a webszerver és az IdP logokat napi szinten cserélni (rotálni), a régi logfájlokat pedig tömörített formátumban tárolni.
 
* Ajánlott a régi, "rotált" naplóállományok integritásvédelmének biztosítása.
 
  
 +
: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.
  
== Mentés ==
+
:3.1.1. Az intézmény ezeket a naplókat köteles a hatályos adatvédelmi szabályokkal összhangban kezelni.
* A mentési és visszaállítási procedúrát az intézményeknek dokumentálniuk kell.
 
* A kellő rendelkezésre állás biztosításáért ajánlott hetente teljes mentést készíteni az IdP-ről.
 
* Érdemes napi inkrementális mentést készíteni az IdP rendszerről.
 
* A mentéseket biztonságos, "off-site" rendszeren kell tárolni.
 
* A visszaállítási procedúrát legalább évente ajánlott ellenőrizni.
 
  
 +
:3.2. Az AAI infrastruktúra komponensei esetén kötelező legalább 2048 bites kulcsok használata.
  
== Biztonság ==
+
::3.2.1. Biztosítani kell a privát kulcsok védelmét.
* A felhasználókezelést végző szerverekre való belépést erősen korlátozni kell. Ajánlott a többfaktoros, emelt szintű autentikáció, illetve a belépés bizonyos hálózati szegmensekre való korlátozása.
 
* Ajánlott behatolást észlelő rendszer (IDS) futtatása.
 
* A szerverekhez hozzáféréssel rendelkező felhasználók jogosultságait gyakran felül kell vizsgálni.
 
* Szükséges a szerverek tűzfallal történő védelme (az IdP processz számára csak a 443 illetve 8443-as portokat kell nyitva tartani).
 
* Ajánlott a felhasználók felé megbízható tanúsítványkiadó által aláírt tanúsítvány használata.
 
* Biztosítani kell, hogy a működéshez szükséges privát kulcsokat csak az IdP processz olvashassa.
 
* Legalább 3 évente érdemes új kulcspárt generálni.
 
* Amennyiben egy kulcs kompromittálódik, azt azonnal vissza kell vonni az AAI rendszerből!
 
  
=== Frissítések ===
+
::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.
* Az operációs rendszer illetve IdP szoftver kritikus biztonsági frissítéseit legkésőbb 2 héttel azok megjelenése után alkalmazni kell.
 
* Ajánlott az operációs rendszer illetve IdP frissítését legritkábban havonta alkalmazni.
 
  
 +
::3.2.3. Ajánlott hosszú lejáratú, self-signed tanúsítványok használata.
  
== Dokumentálási rend ==
+
:3.3. Vonatkozó SAML szabványok
* Ajánlott az IdP által felhasznált attribútumokat egyesével megvizsgálni, azokhoz hiteles adatforrásokat illetve adatfelelősöket kötni.
 
* Az IdP szoftver- és hardverkörnyezetét (beleértve a hálózati beállításokat is) intézményen belül dokumentálni kell.
 
* Az IdP szoftver menedzselését - indítás, leállítás, monitorozást - intézményen belül dokumentálni kell.
 
* Érdemes naplót vezetni az IdP-t érintő konfiguráció-módosításokról.
 
  
== IdP Konfiguráció ==
+
::3.3.1. Kötelező az ''Interoperable SAML 2.0 Web Browser SSO Deployment Profile'' ([http://saml2int.org]) dokumentumban kötelezőnek megjelölt elemek támogatása
* Az IdP entityID-jának URL formátumúnak kell lennie, és ezen URL-nek az IdP metadatáját kell visszaadnia. Shibboleth esetén ez az URL így néz ki: https://idp.example.org/idp/shibboleth.
 
* Ajánlott az IdP konfiguráció verziókövetése.
 
* Ajánlott egy tesztrendszer üzemeltetése, amely mindenben megegyezik az éles szolgáltatással, ezért az éles szolgáltatás konfiguráció-változtatásai tesztelhetőek benne.
 
  
=== Metaadatok kezelése ===
+
::3.3.2. Ajánlott a SAML2 Single Logout profil támogatása HTTP-Redirect illetve SOAP binding felett.
* A föderációs metaadatot a központi helyről kell letölteni (https://rr.aai.niif.hu/metadata/href-metadata.xml).
 
** A metaadatot legalább óránként ajánlott újra letölteni.
 
** A metaadatot kötelező legfeljebb napi gyakorisággal frissíteni.
 
* A metaadat aláírását minden letöltés után ellenőrizni kell.
 
* Az aláíró tanúsítványt ajánlott összevetni a NIIF AAI visszavonási listával.
 
  
=== Attribútumok ===
+
:3.4. Az IdP köteles minden végpontját HTTPS (SSL/TLS) protokollok segítségével védeni.
* Az adatforrásokhoz való kapcsolatot titkosított hálózati protokoll felett kell végezni (kivétel ezalól a lokális hoszt).
 
* Az IdP nem hozhat létre, változtathat, törölhet olyan attribútumokat, amelyekért nem ő a felelős. Ezt a védelmet az adatforrás szintjén kell megvalósítani.
 
* A kiadott attribútumoknál az adatvédelmi elveket kell szem előtt tartani
 
** csak olyan attribútum adható ki, ami minimálisan szükséges az adott szolgáltatás működéséhez
 
** csak olyan attribútum adható ki, amelynek kiadásába a felhasználó beleegyezett (uApprove)
 
* Az attribútum-kiadást ajánlott a [[Resource_Registry]]-n keresztül generált filterrel szabályozni.
 
** a lokális attribútum-kiadási szabályokat ajánlott külön filter állományban tárolni.
 
* Az IdP-nek kötelező támogatnia célzott, átlátszatlan azonosítót
 
** ez az azonosító lehet az ún. eduPersonTargetedId, vagy SAML2 persistent NameID
 
** a NameID használata esetén kötelező ezt az értéket perzisztensen kezelni (tehát adatbázisban tárolni).
 
  
= Egyéb =
+
: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.
* Hardver követelmények
 
** Rack / szerverszoba / klíma, etc
 
** UPS
 
* Szoftver követelmények
 
** LTS OS
 
** NTP
 
* Hálózati követelmények
 
* redundáns, legalább 100mbit
 
  
= Források =
+
: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.
[http://www.switch.ch/aai/support/bcp/idp-1.0.html SWITCH - Best current practices for operating a SWITCHaai Identity Provider]
 

A lap jelenlegi, 2017. május 29., 12:56-kori változata

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 ([1]) 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.