AAI

Auto-generated book for AAI

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
  • Alkalmazott: edupersonAffiliation: employee
  • 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.A teszt felhasználók jelszavai minimálisan 8 karaktert (kis- és nagybetűket, számokat, opcionálisan egyéb karaktereket) kell, hogy tartalmazzanak.
    Naplóállományok rendelkezésre állási ideje min. 6 hónap
    Autentikációs backend LDAP
    Autentikációs mód Username/password
    Vállalt rendelkezésre állás Az Identity Provider funkciót egy nagy rendelkezésre állású klaszter biztosítja. A rendelkezésre állásnak nincs formálisan vállalt értéke (belső szolgáltatás).

    Döntési_táblázat

    Döntési módok

    Regisztrációs folyamat

    Döntési folyamat Kérelem forma Csatolt dokumentáció Döntés módja Döntés eredménye
    Új Tag felvétele Szerződés, szándéknyilatkozat Aktív többségi döntés Szerződés aláírása Felvétel T.T. -ba
    Tag (új) IdP RR Adatkezelési folyamatok dokumentálása Adatkezelési nyilatkozat Gyorsított eljárás Jóváhagyás az RR-ben
    Tag (új) SP RR Adatkezelési nyilatkozat Gyorsított eljárás Jóváhagyás az RR-ben
    Új Partner felvétele Szerződés, szándéknyilatkozat Aktív többségi döntés Szerződés aláírása Jóváhagyás az RR-ben
    Partner új SP RR Adatkezelési nyilatkozat Gyorsított eljárás Jóváhagyás az RR-ben

    Döntési jogok

    Döntési jog Intézményi döntés, Tagok tájékoztatása Föderációs operátor döntése, Tagok tájékoztatása Föderációs operátor mint szolgáltató döntése Gyorsított eljárás Tagok Tanácsának döntése
    Műszaki dokumentumok megváltoztatása
  • Attribútum specifikáció
  • Metadata specifikáció
  • Műszaki követelmények és ajánlások
  • X
    Policy dokumentumok bármilyen megváltoztatása
  • Szószedet
  • Alapelvek
  • X
    Csatlakozás nemzetközi szervezetekhez és együttműködésekhez
    X
    Azonosítási szolgáltatás (Identity Management) kiszervezése
    X
    Metadata módosítása
    X (jóváhagyás)
    Szolgáltatási díj bevezetése / megváltoztatása
    X (Tagok új szerződést kötnek)
    Egyedi díjkedvezmények megállapításának joga
    X
    Bevételek felhasználása
    X
    Szerződés rendes felmondása
    X
    X
    Súlyos szerződésszegés miatti rendkívüli felmondás
    X
    X
    Föderáció megszüntetése
    X
    Tagok Tanácsak saját eljárási szabályainak elfogadása, módosítása
    X

    Shibboleth2_DiscoveryService

    Shibboleth2 Discovery Service

    A Discovery Service ugyanazt a szerepet játssza a Shibboleth2 infrastruktúrában mint a WAYF szolgáltatás a Shibboleth1.x esetén. A WAYF szolgáltatás azonban Shibboleth-specifikus, míg a Discovery Service pontos működését a SAML2.0 szabvány írja le.

    Részletes konfigurációs segédlet a Shibboleth2 Wikin

    Az IdP Discovery menete

    A Discovery Service (DS) feladata tehát, hogy az SP számára kiválasszon egy IdP-t, amit a felhasználó használ. Ezt alapvetően kétféleképpen éri el: cookie-k illetve egy webes IdP kiválasztó felület segítségével.

    Amennyiben a DS cookie-ban tárolja a felhasználó által kiválasztott IdP-t, ezt egy _saml_idp nevű cookieban kell tennie, aminek a formátuma kötött: egy darab space-szel elválasztott, base64 kódolt IdP entityID lista (tehát több IdP-t is képes tárolni, és a használati sorrendet is megőrzi - bár utóbbit nem teszi kötelezővé a szabvány).

    A Shibboleth2 DS képes arra, hogy a cookie-k használatán kívül a felhasználónak egy webes formot mutasson, amiben a federációk és az egyes federációkban szereplő IdP-k listáját jeleníti meg. Ezt a listát a felhasználó egy szöveges kereső segítségével szűrheti is.

    A Discover Service metaadatok konfigurálása

    A DS konfigurálása a wayfconfig.xml fájl segítségével történik. Itt kell megadni a használt template-et és a metaadatokat is. A metaadatokat ugyanazon formátumban kell konfigurálni mint az IdP esetén (tehát lehetőség van egy URL-ről automatikusan letöltött metaadat-állomány használatára is).

    A DS-nek ismernie kell a kérő SP metaadatát is, alapbeállításként pedig csak azokat az IdP-ket listázza, amelyek egy metaadat-fájlban vannak az aktuális SP-vel.

    Discovery Service pluginek

    A DS kiterjeszthető olyan pluginekkel, amelyek segítik a felhasználót az IdP választásban. Ilyen plugin például a _saml_idp cookie kezelő, ami SAML2 szabvány-kompatibilissé teszi a DS-t.

    AAIInterop-OpenSSOShib2

    !!! bug "Elavult információ"

    **Figyelem**: ez a szakasz vagy szócikk elavult információkat tartalmazhat!
    

    OpenSSO IdP - Shibboleth2 SP Interoperabilitás

    SAML2.0 Single Sign on

    HTTP-Post

    <SessionInitiator type="Chaining" Location="/Login" id="maszat-opensso-post"
        relayState="cookie" entityID="https://idp.sch.bme.hu/niif-teszt">
        <SessionInitiator type#"SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
    </SessionInitiator>
    

    HTTP-Artifact

    Attribute push

    Attribute pull

    NameIDFormat

    SAML2.0 Single Log out

    Metaadat problémák

    Shibboleth2_SP

    Telepítési leírások

    Konfigurációs leírások

    Shib3IdpMetadata

    Shibboleth 3 IdP metaadat beállítása

    Vonatkozó állományok:

    Nem föderációs SP metaadat

    Nem föderációs SP metaadatának felvitele a metadata-providers.xml állományba az alábbiak szerint történik. A példában szereplő %{idp.home}/metadata/sp-sp.intezmenyneve-metadata.xml állományt el kell helyezni az állományrendszerben és meg kell győződni annak valódiságáról (nincs aláírva).

    <MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" ... >
    
    <!-- ... további tartalom ... -->
    
        <!-- Helyi, nem föderációs SP -->
        <MetadataProvider id="SajatSPLocalMetadata"
           xsi:type="FilesystemMetadataProvider"
           metadataFile="%{idp.home}/metadata/sp-sp.intezmenyneve-metadata.xml"/>
    
    <!-- ... további tartalom ... -->
    
    </MetadataProvider>
    

    EduID föderációs metaadat

    EduID föderációs metaadat felvitele a metadata-providers.xml állományba az alábbiak szerint történik. Töltsük le föderáció metaadat aláíró tanúsítványát.

    cd /opt/shibboleth-idp/credentials
    wget https://metadata.eduid.hu/href-metadata-signer-2011.crt
    

    A tanúsítvány SHA-1 és SHA-256 lenyomata a következőképpen ellenőrizhető le.

    $ openssl x509 -in href-metadata-signer-2011.crt -noout -fingerprint
    SHA1 Fingerprint=FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66
    $ openssl x509 -in href-metadata-signer-2011.crt -noout -fingerprint -sha256
    SHA256 Fingerprint=B3:2C:16:EB:3B:77:39:42:46:E3:CD:D7:86:D6:0D:11:A9:FB:6E:1C:11:E2:FD:23:71:67:E4:33:B4:ED:9F:FA
    

    Szerkesszük a beállítóállományt.

    <MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" ... >
    
    <!-- ... további tartalom ... -->
    
        <!-- eduID.hu föderációs metaadat -->
        <MetadataProvider id="HTTPMetadata"
                      xsi:type="FileBackedHTTPMetadataProvider"
                      backingFile="%{idp.home}/metadata/localCopyFromEduID.xml"
                      metadataURL="https://metadata.eduid.hu/current/href.xml">
            <MetadataFilter xsi:type="SignatureValidation"
                requireSignedMetadata="true"
                            certificateFile="${idp.home}/credentials/href-metadata-signer-2011.crt" />
    
    <!-- ... további tartalom ... -->
    
    </MetadataProvider>
    

    Az eduID föderáció metaadat weblapja a https://metadata.eduid.hu/ helyen érhető el.

    Tovább a föderációba

    Amennyiben a telepítendő IdP-t szeretnénk a HREF-be integrálni, úgy ennél a pontnál küldjünk egy levelet az aai@niif.hu címre, amely nyomán, ha minden rendben van, az IdP regisztrálásra kerül a Resource Registry-ben.

    Dokumentáció

    RelyingParty

    A Shibboleth terminológiában a RelyingParty kifejezés jelenti a "másik fele(ke)t". Egy RelyingParty vonatkozhat egyetlen SP-re vagy IdP-re, illetve egy teljes föderációra is.

    Mind az SP-nél, mind az IdP-nél meg lehet adni, hogy különböző RelyingParty-ra vonatkozóan más azonosító kulcsokat és más providerId-t használjon.

    Annak eldöntése, hogy a másik félre melyik RelyingParty konfiguráció vonatkozik így dől el:

    1. Ha a másik fél providerId-je megegyezik a RelyingParty nevével, akkor az vonatkozik rá
    2. Keresés indul a rendelkezésre álló föderációs metadata állományokban. Amennyiben valamelyikben megtalálható a másik fél providerId-je, akkor a föderáció URI-jának megfelelő RelyingParty vonatkozik rá, amennyiben az létezik
    3. Ha nem található megfelelő RelyingParty konfiguráció, akkor az alapértelmezett RelyingParty konfiguráció vonatkozik a másik félre.

    Lásd még:

    Shibboleth_Service_Provider__SP_

    Az alábbi lapon megkíséreljük összefoglalni a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő Shibboleth SP-t állítsunk üzembe. Fontos, hogy rengeteg olyan igény lehet, amely további speciális beállítások meglétét teszik szükségessé, ezeket ezen a lapon nem részletezzük, ilyen irányú tájékozódáshoz legbiztosabb forrás a http://wiki.shibboleth.net lap.

    Telepítés

    Előkészületek

    A Shibboleth SP egy webszerver modul, így szükséges előfeltétel, hogy a gépünkön legyen egy webszerver telepítve, jelenleg Apache és IIS a biztosan támogatott webszerverek. Emellett szükséges, hogy a 443-as port a tűzfalon mindkét irányban engedélyezett legyen, ill. a hosztnév, amelyen a webszerver üzemel, be legyen jegyezve a DNS-be.

    Letöltés és telepítés

    A legfrissebb változat letölthető https://wiki.shibboleth.net/confluence/display/SP3 címről. Célszerű valamilyen előre csomagolt változattal dolgozni, melyet az adott rendszer csomagkezelőjén keresztül egy mozdulattal feltelepíthetünk minden függőségével együtt.

    Debian 9 “Stretch” / Ubuntu 16.04 LTS (Xenial)

    sudo apt install apache2 libapache2-mod-shib2
    

    Debian 8 “Stretch” / Ubuntu 14.04 LTS (Trusty)

    sudo apt-get install apache2 libapache2-mod-shib2
    

    Debian 6 “Squeeze” / Debian 7 “Wheezy” / Ubuntu 12.04 LTS (Precise)

    Debian 6, Debian 7 és Ubuntu 12.04 rendszerek támogatása lejárt, így a Shibboleth csomag telepítését sem ajánljuk ezekre a rendszerekre!

    A Debian Shibboleth csapat által készített új verziók időről időre bekerülnek backports.org tárolóiba is, ezért stable Debiant futtató rendszereken javasolt ezt használni.

    A backports.org tárolójának beállításához adjuk hozzá a /etc/apt/sources.list fájlhoz a következő sort:

    deb http://backports.debian.org/debian-backports squeeze-backports main
    

    A csomagokat így telepíthetjük:

    sudo aptitude update
    sudo aptitude install -t squeeze-backports libapache2-mod-shib2
    

    Ez a Shibboleth webszerver modul függőségeit is telepíti. A Shibboleth használatba vételéhez engedélyezni kell a modult és újra kell indítani az Apache webszervert.

    Red Hat / CentOS (RPM) alapú disztribúciók

    Shibboleth SP-ből RHEL/CENTOS rendszerekre egyből rendelkezésünkre áll bináris csomag, a fejlesztők ezen platformokon dolgoznak első körben. A telepítés előtt a teendőnk mindössze annyi, hogy a YUM forrásokhoz hozzá kell adni a Shibboleth SP repóját. Ehhez látogassunk el a http://download.opensuse.org/repositories/security://shibboleth/ oldalra, majd a pontos verzió kiválasztása után a security:shibboleth.repo fájl tartalmát másoljuk be a /etc/yum/ /etc/yum.repos.d/CentOS-Base.repo fájl aljára, majd

    yum install shibboleth
    

    Hibaelhárítás: Can't connect to listener process

    Ha a fenti hibába futunk bele, az azt jelenti, hogy a SE linux nem engedi kommunikálni a shibd és a httpd folyamatokat, ezért ezt külön engedélyezni kell. Ehhez készítsünk egy fájlt shibd.te néven, melynek tartalma az alábbi legyen:

    module shibd 1.0;
    require {
           type var_run_t;
           type httpd_t;
           type initrc_t;
           class sock_file write;
           class unix_stream_socket connectto;
    }
    ####### # httpd_t ######=
    allow httpd_t initrc_t:unix_stream_socket connectto;
    allow httpd_t var_run_t:sock_file write;
    

    Ezek után futtassuk le az alábbi parancsokat, melyek a fenti fájlt megfelelően lefordítják, és be is illesztik a létrehozott szabályunkat.

    # checkmodule -M -m -o shibd.mod shibd.te
    checkmodule:  loading policy configuration from shibd.te
    checkmodule:  policy configuration loaded
    checkmodule:  writing binary representation (version 6) to shibd.mod
    # semodule_package -o shibd.pp -m shibd.mod
    # semodule -i ./shibd.pp
    

    Alapbeállítások

    A telepített Shibboleth SP konfigurációs állományait Linux alatt a /etc/shibboleth könyvtárban találjuk. Itt a shibboleth2.xml és az attribute-map.xml fájlokkal lesz dolgunk.

    shibboleth2.xml

    A telepítéskor alapértelmezetten érkező fájl nagyrészt megfelelő számunkra, az induláshoz csak az alább részletezett módosításokat kell megejtenünk. A változtatandó kódrészletek mind szerepelnek már az eredeti xml-ben is, így a feladat többnyire csak változtatásról, átírásról, bizonyos részek kommentjelek közül történő kiszabadításáról szól.

    A péda szerint a hosztnév alatti tartalom nem kíván meg shibbolethes azonosítást, kivéve a /secure location. Ha valahol shibbolethes azonosítást kívánunk használni, azt ezen kívül az adott hoszt webszerver konfigjában is jeleznünk kell. Apache-nál az alábbi módon.

    <Location /secure>
     AuthType shibboleth
     require valid-user
     ShibUseHeaders On
     ShibRequireSession On
    </Location>
    

    További részletek az authorizációval kapcsolatban: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPhtaccess

    SP adatainak közzététele

    A fenti beállítások után egy működő Shibboleth SP-t kapunk eredményül, ugyanakkor ténylegesen csak akkor fog tudni együttműködni a föderációban résztvevő IdP-kkel, ha az SP metaadatait közzétesszük, így azt az IdPk megismerhetik. Ehhez az eduID föderációban a frissen beállított SP adatait a Resource Registry nevű webes adminisztrációs oldalon kell felvinni egy varázsló segítségével, majd a jóváhagyás után várni pár órát, amíg a változások érvénybe lépnek. Ha nincs az intézményi entitások menedzseléséhez jogod ('Access denied'), akkor konzultálj az intézményed eduID kapcsolattartójával, hogy az SP-det szeretnéd a föderációba regisztrálni. Segítséget nyújt az alábbi lista: https://rr.eduid.hu/list

    HEXAA integráció

    Ha az eduID-ban használatos külső attribútum forrást is szeretnénk az SP-nkhez illeszteni, akkor a shibboleth2.xml fileban a következő példán keresztül lehet megtenni.

    <AttributeResolver type="Chaining">
       <AttributeResolver type="Query"/>
       <AttributeResolver type="SimpleAggregation" attributeId="eppn" format="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">
           <Entity>https://hexaa.eduid.hu/hexaa</Entity>
           <Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="eduPersonEntitlement"/>
       </AttributeResolver>
     </AttributeResolver>
    

    Kapcsolódó lapok

    ProviderId

    A föderációban résztvevő entitásokat (Identity Provider, Service Provider) providerId azonosítja a föderáción belül. Ennek a formája tetszőleges lehet, az egyetlen követelmény, hogy egyértelműen azonosítsa az entitást.

    A gyakorlatban kétféle providerId formátumot használnak:

    !!! info

    Azt tanácsolják, hogy, amennyiben a providerId URL, akkor az az entitáshoz tartozó metaadatokat szolgálja ki, ezzel lehetővé téve dinamikus metaadatok használatát.
    
    A [HREF](https://help.edu.hu/books/aai/page/href) jelenleg nem használ dinamikus metaadatokat.
    

    A Shibboleth SP és IdP lehetővé teszi, hogy egy pédány több providerId-vel rendelkezzen, például akkor, ha több föderációban is részt vesz. SP-k esetében lehetőség van arra, hogy bizonyos alkalmazások külön providerId alatt látszódjanak, még akkor is, ha egyetlen környezetben (webszerveren) futnak. Ennek az a jelentősége, hogy így az IdP más és más szabályok szerint tudja kiadni az attribútumokat.

    HREF_Key_Rollover_2020

    Bevezetés

    A HREF új metaadat aláírókulcsra áll át a SAML 2.0 metaadataiban (HREF-2020). A HREF szövetségi tagoknak és partnernek az új aláírókulcshoz tartozó konfigurációkat 2022. január 1.-ig frissíteniük kell az összes eduID.hu-t támogató rendszerükben. Ezt követően a régi - több, mint 6 éves aláírókulcs (HREF-2011) - leállításra kerül, és az utolsó aláírástól számított 10. napon a régi metaadat érvénytelen lesz.

    Az alábbi táblázatok az átálláshoz szükséges összes adatot tartalmazzák. A konfigurációs példák, olyan megoldásokat kínálnak (ahol ez lehetséges), amelyekkel egyszerre lehet használni a régi és az új metaadatot.

    Key Rollover

    Elnevezések

    Elnevezés Metaadat aláíró tanúsítvány Kivezetés tervezett időpontja
    HREF-2011 href-metadata-signer-2011.crt 2022.01.01.
    HREF-2015 mdx-test-signer-2015.crt 2022.01.01.
    HREF-2020 href-metadata-signer-2020.crt 2025.06.14.

    SHA1 fingerprints

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

    Domain név változások

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

    Shibboleth Service Provider beállítások

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

    XML

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

    <MetadataProvider type="Chaining">
        <MetadataProvider type="XML" id="href-2011" url="https://metadata.eduid.hu/2011/href.xml" backingFilePath="href-2011.xml">
            <MetadataFilter type="Signature" certificate="href-metadata-signer-2011.crt"/>
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
        </MetadataProvider>
        <MetadataProvider type="XML" id="href-2020" url="https://metadata.eduid.hu/2020/href.xml" backingFilePath="href-2020.xml">
            <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
        </MetadataProvider>
    </MetadataProvider>
    

    MDX

    Shibboleth 3.X

    https://wiki.shibboleth.net/confluence/display/SP3/MDQMetadataProvider

    <MetadataProvider type="MDQ" id="href-2015" ignoreTransport="true" baseUrl="https://mdx-2015.eduid.hu/">
        <MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
    </MetadataProvider>
    <MetadataProvider type="MDQ" id="href-2020" ignoreTransport="true" baseUrl="https://mdx-2020.eduid.hu/">
        <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
    </MetadataProvider>
    

    Shibboleth 2.X

    <MetadataProvider type="Dynamic" id="href-2015" ignoreTransport="true">
        <Subst>https://mdx-2015.eduid.hu/entities/$entityID</Subst>
        <MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
    </MetadataProvider>
    <MetadataProvider type="Dynamic" id="href-2020" ignoreTransport="true">
        <Subst>https://mdx-2020.eduid.hu/entities/$entityID</Subst>
        <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
    </MetadataProvider>
    

    Shibboleth Identity Provider beállítások

    XML

    Shibboleth 4.X

    https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider

    <MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
                      backingFile="%{idp.home}/metadata/href-2020.xml"
                      metadataURL="https://metadata.eduid.hu/2020/href.xml">
    
        <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
            certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>
    
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
    
        <MetadataFilter xsi:type="EntityRoleWhiteList">
            <RetainedRole>md:SPSSODescriptor</RetainedRole>
        </MetadataFilter>
    
    </MetadataProvider>
    

    Shibboleth 3.X

    https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider

    <MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
                      backingFile="%{idp.home}/metadata/href-2020.xml"
                      metadataURL="https://metadata.eduid.hu/2020/href.xml">
    
        <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
            certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>
    
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
    
        <MetadataFilter xsi:type="EntityRoleWhiteList">
            <RetainedRole>md:SPSSODescriptor</RetainedRole>
        </MetadataFilter>
    
    </MetadataProvider>
    

    MDX

    Shibboleth 4.X

    https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider

    <MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
                      connectionRequestTimeout="PT2S"
                      connectionTimeout="PT2S"
                      socketTimeout="PT4S">
    
        <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
            certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>
    
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
    
        <MetadataQueryProtocol>https://mdx-2020.eduid.hu/</MetadataQueryProtocol>
    
    </MetadataProvider>
    

    Shibboleth 3.X

    https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider

    <MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
                      connectionRequestTimeout="PT2S"
                      connectionTimeout="PT2S"
                      socketTimeout="PT4S">
    
        <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
            certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>
    
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
    
        <MetadataQueryProtocol>https://mdx-2020.eduid.hu/</MetadataQueryProtocol>
    
    </MetadataProvider>
    

    SimpleSAMLphp

    MDX

    //config/config.php
    'metadata.sources' => [[=> 'flatfile']('type'), // ez a *-hosted metadata konfiguráció betöltése miatt szükséges
        [
            'type' => 'mdq',
            'server' => 'https://mdx-2020.eduid.hu',
            /* --- */
            'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61'
        ],
    ],
    

    metarefresh

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

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

    // config/config-metarefresh.php
    $config = [
      'sets' => [
          'href-2011' => [
              'cron'      => ['hourly'],
              'sources'   => [
                  [
                      'src' => 'https://metadata.eduid.hu/2011/href.xml',
                      'validateFingerprint' => 'FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66',
                  ],
              ],
              'expireAfter'       => 777600, // 9 nap
              'outputDir'     => 'metadata/metarefresh-href-2011/',
              'outputFormat' => 'flatfile',
          ],
          'href-2020' => [
              'cron'      => ['hourly'],
              'sources'   => [
                  [
                      'src' => 'https://metadata.eduid.hu/2020/href.xml',
                      'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61',
                  ],
              ],
              'expireAfter'       => 777600, // 9 nap.
              'outputDir'     => 'metadata/metarefresh-href-2020/',
              'outputFormat' => 'flatfile',
          ],
       ],
    ];
    
    // config/config.php
    'metadata.sources' => [
        ['type' => 'flatfile'],
        ['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2011'],
        ['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2020'],
    ],
    

    FAQ /GYIK

    Bővítés alatt!

    Shib2IdpAuth

    Autentikáció nativan, Shib2Idp-ből

    LDAP-alapon

    Szerkesszük a ${SHIB_HOME}/conf/login.config -ot:

    ShibUserPassAuth {
      edu.vt.middleware.ldap.jaas.LdapLoginModule required
         host="ldap.example.com"
         base="ou=people,dc=example,dc=com"
         ssl="false"
         serviceUser="userid=example-system,ou=systems,dc=example,dc=com"
         serviceCredential="password"
         userField="uid";
    }
    

    A serviceUser és a serviceCredential kihagyható, ekkor anonymous bind történik (azonban ilyen esetben a helytelen név / jelszó megadása LDAP Exception-t okoz és nem a jól értelmezhető hibás név / jelszó üzenetet adja a felhasználónak)

    Ezután be kell állítani, hogy ezt a bekonfigurált autentikációt használja a Shibboleth (${SHIB_HOME}/conf/handlers.xml)

    <LoginHandler xsi:type="UsernamePassword"
                     authenticationDuration="240"
                     jaasConfigurationLocation="file://${SHIB_HOME}/conf/login.config">
     <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthenticationMethod>
    </LoginHandler>
    <!-- SSO-hoz kell hogy az előző session-t át tudja venni -->
    <LoginHandler xsi:type="PreviousSession">
           <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</AuthenticationMethod>
    </LoginHandler>
    

    Az authenticationDuration paraméter elhagyása esetén az IdP 30 perc érvényességgel állítja ki a munkamenetet (<AuthnStatement SessionNotOnOrAfter="...">), tehát akár aktív tevékenység esetén is 30 perc múlva lejár a felhasználó session-je. Ezt érdemes tehát átállítani magasabb értékre.

    A FORM-ot az idp.war -ban tudjuk testreszabni (login.jsp). A szállított login.jsp által beállított FORM tag és INPUT tag-ek tartalmát ne módosítsuk!

    Ha a bejelentkezés nem sikerül jó felhasználónév/jelszó párral sem, a logging.xml szerkesztésével tudjuk megjeleníteni a debug üzeneteket (a edu.vt.middleware.ldap loggert kell átkonfigurálni).

    Kerberos alapon

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

    Ha ki tudod egészíteni, megköszönjük!
    

    SQL (JDBC) alapon

    A Shibboleth 2 IdP képes az autentikálást szabványos JAAS (Java Authentication and Authorization Service) modulokkal elvégezni, ezért lehetőség van relációs adatbázist használó autentikációs modul használatára is. Számos JAAS modul létezik adatbázisos autentikációra is, azonban ezek vagy túl bonyolultak, vagy nem kellően rugalmasak. Az alábbiakban az NIIF által fejlesztett (a Tagish/JDBC kódbázisán alapuló) modul beállítását mutatjuk be:

    A JAAS modul konfigurációja a login.config fájlban:

    hu.niif.middleware.jaas.JDBCLoginModule required
      dbDriver="com.mysql.jdbc.Driver"
      dbURL="jdbc:mysql://databaseHost:3306/databaseName"
      dbUser="dbuser"
      dbPassword="randomsecret"
      usersPreparedStatement="SELECT password FROM users where username=?"
      passwordHashMethod="MD5";
    

    LDAP-ból ellenőrzött X.509 tanúsítvánnyal

    Ezen autentikációs mód a konténer (pl. Apache) által a klienstől elkért klienstanúsítványt veti össze a felhasználó LDAP bejegyzésében tárolt tanúsítványokkal (userCertificate). A modul használatának előfeltételei:

    A modul dokumentációja a ezen az oldalon érhető el.

    Autentikáció konténer által

    MySQL Autentikáció Apache-on keresztül

    Az alábbiakban leírt Apache beállítások elsőre nyakatekertnek tűnhetnek, de az Apache 2.2-es sorozatában előforduló - ez idáig érdemben nem javított - bug miatt ez a megoldás működik csak.

    Telepíteni kell a MySQL autentikációs Apache modult:

    apt-get install libapache2-mod-auth-mysql
    

    Engedélyezni kell a modul használatát

    a2enmod auth_mysql
    

    Az Apache adott hosthoz tartozó configjában meg kell adni:

    Auth_MySQL_Info <host> <DB_user> <DB_password>
    

    Ugyanitt meg kell adni az adott Location-re vonatkozó beállításokat - itt látja majd a webszerver, hogy ha az adott url-re érkezett kérés, akkor MySQL-ből kell autentikálnia az itt megadott paraméterek szerint

    <Location /whereTo/Authn/RemoteUser>
     AuthType Basic
     AuthName "You can login here"
     AuthUserFile /dev/null
     AuthBasicAuthoritative Off
    
     AuthMySQL on
     AuthMySQL_Authoritative off
     AuthMySQL_DB VHOtools
     AuthMySQL_Password_Table vho_Users
     AuthMySQL_Password_Field password
     AuthMySQL_Encryption_Types PHP_MD5
     require valid-user
    </Location>
    

    MySQL Autentikáció TomCat-en keresztül

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

    Ha ki tudod egészíteni, megköszönjük!
    

    LDAP Autentikáció Apache-on keresztül

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

    Ha ki tudod egészíteni, megköszönjük!
    

    Single Sign-on

    IdP Session

    Az IdP-ben a session-nek nincs rögzített lifetime-ja, hanem aktivitásfüggő timeout értéket lehet beállítani. A jelenlegi IdP-ben az IdP session timeout független a fent megadott authenticationDuration értéktől, ezt az internal.xml állományban állíthatjuk be:

       <bean id="shibboleth.SessionManager"
             class="edu.internet2.middleware.shibboleth.idp.session.impl.SessionManagerImpl"
             depends-on="shibboleth.LogbackLogging">
           <constructor-arg ref="shibboleth.StorageService" />
           <constructor-arg value="<b>28800000</b>" type="long" />
       </bean>
    

    A példában a StorageService konstruktorának értéke ezredmásodpercben értendő.

    Single Logout

    URN_SCHAC

    URN schac sémák

    AAI

    Meghatározások

    Föderációs alapinfrastruktúrák (IdP-k, SP-k)

    Tapasztalatok alapján IdP esetén egyszerűsége miatt talán jobb választás a simpleSAMLphp, SP esetén Shibboleth ill. simpleSAMLphp egyaránt megfelelő választás mind beállítási, mind üzemeltetési szempontból.

    HREF/eduID föderációhoz kapcsolódó tudnivalók

    További föderációs megoldások

    Kiegészítő tudnivalók

    FastCGI

    Amennyiben úgy szeretnék Shibboleth SP-t beüzemelni, hogy biztonsági, vagy bármilyen egyéb megfontolásokból az FastCGI-ként fusson, úgy az alábbiakban leírtak szerint kell(ene) a rendszernek működnie.

    FastCGI-ről

    CGI (Common Gateway Interface) alkalmazás esetén a program futása a következőképpen néz ki: jön a kérés a kiszolgáló felé, mire az továbbítja a kérést a CGI programnak. Jelen esetben ez a PHP értelmező lesz, ami futtatja a programot, és az eredményt visszaadja a kiszolgálónak, majd ezután eltűnik a memóriából. Egy következő kéréskor ugyanez a folyamat ismétlődik, amiből egyből láthatjuk, hogy ez a módszer nem túl hatékony, a PHP értelmezőt állandóan be kell tölteni, majd ki kell pakolni a memóriából.

    A FastCGI ezt a be/ki töltögetést küszöböli ki: a PHP értelmező bent marad a memóriában addig, amíg szükség van rá. Sőt, egyszerre több értelmezőt is a memóriában tart, így egyszerre több kérést is ki tud szolgálni a szerver.

    A CGI program külön szálként fut a kiszolgálón, elkülönítve tőle, és a többi hasonló száltól. Ha az egyik kedves felhasználó programja megöli a CGI értelmezőjét, akkor sincs semmi gond, az meghal, de a többi attól még vígan dolgozik, és szolgálja ki a lapokat.

    Forrás: Weblabor

    Lighttpd, mint webszerver

    !!! warning FIGYELEM!

    Az alább leírt módszer csak elviekben működik, a gyakorlatban - a szükséges patchelés ellenére sem - sikerült működésre bírni. A hiba oka [egy **lighttpd bug**](http://redmine.lighttpd.net/issues/show/322), melyről a fejlesztők is tudnak, ám kijavítása nem szerepel a napirenden, mivel hivatalosan a patch megjavítja, ám a gyakorlat ezt cáfolja. Az érthetőség kedvéért hibajelenség pontos leírása a telepítési folyamat leírása után található.
    

    Lighttpd

    A figyelmeztetésben is emlegetett, és az alább részletezett patch-elés miatt nem a legfrissebb, hanem az 1.4.15-ös lighttpd-t használjuk.

    Beszerzés

    wget http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz
    tar -xf http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz
    

    A szükséges patch letöltése

    wget http://redmine.lighttpd.net/attachments/download/91/fastcgi-authorizer-fixes.diff
    

    Patchelés (a letöltött lighthttpd kitömörített könyvtárában vagyunk):

    patch -p0 < fastcgi-authorizer-fixes.diff
    

    Majd a patchelés kiegészítéseként be kell szúrnunk egy sort a src/mod_fastcgi.c fájlba.

                                con->http_status == 0)) {
                                   /*
                                    * If we are here in AUTHORIZER mode then a request for autorizer
                                    * was proceeded already, and status 200 has been returned. We need
                                    * now to handle autorized request.
                                    */
    +++                            con->http_status = 0;
                                   if ( ! buffer_is_empty(host->docroot) ) {
                                           /*
                                            * Serve local file if they specified
                                            * a docroot
                                            */
    

    Fordítás és telepítés (configure paraméterei természetesen tovább finomíthatók)

    ./configure --libdir=/usr/lib/lighttpd --with-openssl --with-openssl-libs=/usr/lib
    make
    make install
    

    Telepítés utáni beállítás:

    vim /etc/lighttpd/lighttpd.conf
    

    server.modules szekcióba be kell írni

    "mod_fastcgi",
    

    majd ugyanebben a fájlban meg kell adni az alapvető beállításokat mind a 80-as, mind a 443-as portra vonatkozólag

    server.name     = "sp2.example.org"
    server.document-root       = "/var/www/"
    
    $SERVER["socket"] == "10.0.0.8:443" { // a host ip-címe
      ssl.engine = "enable"
      ssl.pemfile = "/etc/lighttpd/certs/lighttpd.pem" // ahol a domain-re vonatkozó tanusítványunk található
    }
    

    Shibboleth

    Beszerzés

    dget http://ftp.de.debian.org/debian/pool/main/s/shibboleth-sp2/shibboleth-sp2_2.0.dfsg1-4.dsc
    dpkg-source -x *.dsc
    

    Fordítás előtti hangolás

    vim debian/rules
    

    Be kell szúrni a ./configure paramétereit meghatározó sorba:

    --with-fastcgi=/usr/sbin/lighttpd (a lighttpd elérési útja)
    

    Shibboleth + Lighttpd

    Még két beállítást kell eszközölnünk, hogy a webszerver tudja, hogy shibbolethes hívások esetén mi a teendő. Először is a FastCGI beállításokat betöltetjük a lighttpd-vel (ez shibboleth-től függetlenül is kellhet, pl. php futtatása esetén). Egy egyszerű szimbolikus linket készítünk a mods-available könyvtár vonatkozó fájljáról a mods-enabled -be. A második, hogy ezt a fájlt kiegészítjük két, shibboleth specifikus sorral.

    "/Shibboleth.sso" => ((
          "socket" => "/tmp/fcgi-resp.sock",
          "bin-path" => "/usr/lib/shibboleth/shibresponder",
          "check-local" => "disable",
          "mode" => "responder"
    )),
    "/"   => ((
          "socket" => "/tmp/fcgi-auth.sock",
          "bin-path" => "/usr/lib/shibboleth/shibauthorizer",
          "check-local" => "disable",
          "mode" => "authorizer"
     )),
    

    Ezek után - s az itt nem részletezett Shibboleth SP beállítás után - a rendszernek további beállítások nélkül működnie kellene. Ám kizárólag statikus tartalmat tud rendeltetésszerűen kiszolgálni, dinamikusat nem.

    A HIBAJELENSÉG

    Amennyiben használni akarunk "authorizer" modult (a shibbolethnél ez ugye kell, a másik modul, a "responder" típusú mellett), akkor ehhez a fastcgi beállításoknál meg kell adni egy gyökér pontot, amelyhez viszonyítva az összes vele egy szinten lévő, ill. alatta lévő hivatkozás esetén lefut az authorizer, és megmondja, hogy jogosult, tehát mehet tovább, vagy sem. Ez a gyökérpont a shibbolethes beállításoknál a "/" kell, hogy legyen, tehát minden esetben átfut az authorizer-en egy-egy kérés. Ez nem is lenne rossz, de a bug miatt, amennyiben a fastcgi beállításoknál az authorizer megadása után bármilyen (pl. php) respondert beállítunk, akkor az az authorizer által lefedett környezetben (esetünkben a "/" miatt mindenhol) a webszerver 403 hibát dob.

    Lazy_Session

    Általában a Shibboleth SP Apache modul csak akkor enged hozzáférést az erőforráshoz (oldalhoz), ha sikerült autentikálnia és autorizálnia a felhasználót (azaz shibboleth session-t létrehozni).

    Elképzelhető azonban olyan alkalmazás is, amely azonosítatlan (anonymous) felhasználók számára is szolgáltat információkat. Ez a wiki is ezen az elven épül fel: bárki olvashatja, de csak bejelentkezett felhasználók szerkeszthetik.

    A lazy session csak a Shibboleth szempontjából "lusta"; a modul csak akkor hoz létre Shibboleth session-t, ha az alkalmazás erre kifejezetten utasítja. Ez azzal jár, hogy:

    Lazy session az alkalmazás szemszögéből

    Session érvényességének ellenőrzése

    Az alkalmazás a Shibboleth attribútumok vizsgálatával győződhet meg arról, hogy létezik-e Session. Célszerű olyan attribútumot választani, amely minden session létrehozáskor biztosan létrejön, ilyen például a _SERVER tömbből kinyerhető Shib-Application-ID (Shibboleth 1.3 esetén: HTTP_SHIB_APPLICATION_ID) header. Ha ez létezik, akkor biztosan van session.

    Session létrehozás

    Mivel a webszerveren futó alkalmazás és a Shibboleth webszerver modul közvetlenül nem tud kommunikálni, ezért szükséges, hogy a felhasználót valahogyan egy megfelelő URL-re (a SessionInitiator URL-jére). Ez az URL általában így áll össze:

    Példa URL:

    https://dev.aai.niif.hu/Shibboleth.sso/WAYF/NIIF-WAYF?target=https://dev.aai.niif.hu/drupal/shiblazy.php
    

    Request headerek megbízhatósága, lazy session biztonság

    A Shibboleth modul gondoskodik arról, hogy kiszűrje a HTTP_SHIB_ kezdetű header elemeket, mivel azokat csak ez a modul állíthatja be. Bárki más is állítaná be, az visszaélést jelentene (header spoofing). A header spoofing elleni védelem lazy session esetén is működik, függetlenül attól, hogy létrejött-e a Shibboleth session. Ez azt jelenti, hogy nem lehet létező "sessiont hazudni", mivel a HTTP_SHIB_IDENTITY_PROVIDER header védett.

    Természetesen a spoofing védelem csak akkor működik, ha

    A _SERVER tömb elemeit csak webszerver modulok tölthetik fel, ezért az ebből kivett értékek többé-kevésbé megbízhatóak header spoofing védelem nélkül is (megbízhatóságuk megegyezik a webszerver megbízhatóságával). Problémát okoz azonban, ha ezeket az elemeket összekeverjük a requestből kinyerhető értékekkel (pl. PHP-ban a register_globals használatával). Ez amúgy is kerülendő eljárás, lazy session-ök esetén pedig egyenesen öngyilkosság!

    Föderációs_modellek

    ShibAndEdugain

    Loading metadata

    Metadata downloaded from https://mds.edugain.org

    Strange things

    Problems loading metadata to Shibboleth SP

    For perl processing, MDS output is run through xml_pp, an XML pretty-printer.

    Here is the command I use to load MDS output to a Shibboleth 2.0 SP:

    wget -O- --ca-certificate=/home/bajnokk/edugain_bundle.crt https://mds.edugain.org |xml_pp \
    | perl -pe 's/(<(md:)?EntitiesDescriptor)/\1 xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/; s/.*RoleDescriptor.*//g; s/.*OnlineCA.*//g; \
               s/cacheDuration[>](^)*//g; ' >/tmp/mds-pp.xml
    

    Explanation follows:

    Unable to connect

    For some reason, Shibboleth 2.0 cannot connect to https://mds.edugain.org. It seems to be a libcurl issue, which is not easy to circumvent. (See this shib-users thread) Newer cURL's can handle the SSL handshake (the ones in Ubuntu Intrepid and Debian Lenny can not). So it's necessary to wget the metadata.

    It turned out that newer versions of Shibboleth can connect to mds.edugain.org, however the following errors prevent the metadata from being loaded directly.

    No default namespace

    There is no default namespace for the outer EntitiesDescriptor, the root element. No problem with that, but there is at least one EntityDescriptor, which is not correctly namespaced (and assumes that the default namespace is urn:oasis:names:tc:SAML:2.0:metadata)

    Solution:

    | perl -pe 's/(<(md:)?EntitiesDescriptor)/\1 xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/;'
    

    Invalid use of RoleDescriptor

    SAML Metadata Schema declares that RoleDescriptor is an abstract element, whatever it means. Shibboleth (2.0) cannot load an entity with such an element.

    Solution: | perl -pe 's/.RoleDescriptor.//g;' At the time of writing, it only affects Fresco-AAI. For some unknown reason, Fresco-AAI metadata is a one-liner (even after pretty printing), so it's possible to remove it such a way. If it wasn't the case, proper XSLT would be necessary.

    Invalid extension of the schema

    GIdP entity contains an egmd:OnlineCADescriptor element, which is not a standard extension of the SAML schema.

    Solution:

    | perl -pe 's/.*OnlineCA.*//g;'
    

    At the time of writing, it only affects GIdP. For some unknown reason, GIdP metadata is a one-liner (even after pretty printing), so it's possible to remove it such a way. If it wasn't the case, proper XSLT would be necessary.

    ShibIdPAttrib

    1. REDIRECT Attribútum feloldás

    Shib2PersistentId

    Perzisztens azonosító használata Shibboleth2 IdP esetén

    Ez az oldal a Shibboleth storedId plugin telepítését írja le MySQL adatbázis motorral.

    Adatbázis driver telepítése

    A MySQL JDBC driver a következő URL-ről érhető el: http://dev.mysql.com/downloads/#connector-j. Letöltés után a kitömörített drivercsomagból a .jar végű fájlt kell bemásolni a /usr/share/tomcat6/lib könyvtár alá.

    Táblaszerkezet

    CREATE TABLE `shibpid` (
      `localEntity` varchar(200) NOT NULL,
      `peerEntity` varchar(200) NOT NULL,
      `principalName` varchar(200) NOT NULL,
      `localId` varchar(200) NOT NULL,
      `persistentId` varchar(200) NOT NULL,
      `peerProvidedId` varchar(200) default NULL,
      `creationDate` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
      `deactivationDate` timestamp NULL default NULL,
      KEY `i_shibpid_pid` (`persistentId`),
      KEY `i_shibpid_pid_date` (`persistentId`,`deactivationDate`),
      KEY `i_shibpid_lid` (`localEntity`,`peerEntity`,`localId`),
      KEY `i_shibpid_lid_date` (`localEntity`,`peerEntity`,`localId`,`deactivationDate`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    

    Perzisztens attribútum feloldása

    Az attribute-resolver.xml konfigurációs fájlban vegyük fel a következő DataConnectort illetve PrincipalConnectort:

    <resolver:DataConnector xsi:type="StoredId"
      xmlns="urn:mace:shibboleth:2.0:resolver:dc"
      id="persistentIdConnector"
      sourceAttributeID="uid"
      generatedAttributeID="persistentId"
      salt="valami-random-sztring">
      <resolver:Dependency ref="myLDAP" />
      <ApplicationManagedConnection jdbcDriver="com.mysql.jdbc.Driver"
         jdbcURL="jdbc:mysql://localhost/installfest"
         jdbcUserName="root"
         jdbcPassword="" />
    </resolver:DataConnector>
    
    <resolver:PrincipalConnector xsi:type="StoredId"
      xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="saml2Persistent"
      nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
      storedIdDataConnectorRef="persistentIdConnector" />
    

    Amennyiben alkalmazásszerver oldali kapcsolatkezelést szeretnénk használni, a következő leírás hasznos lehet.

    Definiáljuk a persistentId attribútumot (a transientId ELŐTT! - különben a transientId -t választja ki az idp...):

    <resolver:AttributeDefinition id="persistentId" xsi:type="Simple"
      xmlns="urn:mace:shibboleth:2.0:resolver:ad">
        <resolver:Dependency ref="persistentIdConnector" />
        <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
          xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
          nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
    </resolver:AttributeDefinition>
    

    Perzisztens attribútum kódolása a SAML válaszba

    Az attribute_filter.xml -ben meg kell adni hogy a frissen létrehozott persistentId attribútumot kiadja az SP-nek:

    <AttributeFilterPolicy id="releaseNameIDToAnyone">
        <PolicyRequirementRule xsi:type="basic:ANY" />
    
        <AttributeRule attributeID="transientId">
            <PermitValueRule xsi:type="basic:ANY" />
        </AttributeRule>
        <AttributeRule attributeID="persistentId">
            <PermitValueRule xsi:type="basic:ANY" />
        </AttributeRule>
    </AttributeFilterPolicy>
    

    AAI_és_Shibboleth__2007.11.07_

    Elhangzott a 2007-es HBONE Workshopon

    Letöltés

    ArpFilterProposal

    ArpFilter before the profile servlet - support for other authentication modules

    ArpFilter and ArpViewer works great, but there is one big problem with ArpFilter: it only supports REMOTE_USER -based authentication. Shibboleth2 IdP comes with username and password module, which can be extended to use with any JAAS-compliant Login module. Unfortunately, current ArpFilter design can not work with this module.

    So I made some research to find out how to bring ArpFilter and Shibboleth IdP's internal authentication modules together. My motivation was to support the shipped UserPassword authentication and many of the features that Shibboleth IdP has (forceAuthn, isPassive).

    I found out that ArpFilter only depends on Shibboleth's LoginContext. This LoginContext is created by the profile handler code and interpreted by the authentication engine (and authentication modules) - then, after authentication succeeds, the profile handler processes the LoginContext and issues the response to the SP that requested it.

    So my idea is simple: why ArpFilter is put before the authentication servlets instead of the profile handler servlet?

    I got ArpFilter work before the profile servlet, but not quite sure whether my solution works in all use cases where it should do. I have tested it with SAML2 requests and UserPassword authentication and it seemed to work. Even the PreviousSession authentication handler did with no additional need of PreviousSessionServlet.

    Of course I made some modifications to the original ArpFilter code, but not too much. Basically, it just looks for LoginContext and makes sure the profile servlet gets the LoginContext, even if ArpFilter is called.

    The code logic is the following:

    I needed one more little modification to web.xml: remove filters from /Authn/ servlets and put the ArpFilter in front of the ProfileHandlerServlet (and include the 'forward' dispatcher here, because the profile handler servlet gets the second request from the authentication engine with servlet forward - when the authentication is succeeded).

    Shib3IdpInstall

    Az alábbiakban a Shibboleth 3 Identity Provider telepítése olvasható egyszerű beállítással.

    A telepítés Debian 8 (Jessie) operációs rendszerre történik Jetty 9.2 alkalmazáskonténerbe.

    Előkészületek

    Telepítés előtt praktikus előkészíteni az Shibboleth 3 Identity Provider (IdP) környezetét. Az IdP központi szerepet tölt be, így elérhetősége szerencsés esetben ritkán változik.

    !!! warning

    Az entityID a szolgáltatás neve, nem a kiszolgáló számítógépé. Érdemes a neveket úgy megválasztani, hogy egy későbbi gépcsere esetén is független legyen a gépnév a szolgáltatás nevétől.
    

    Jetty 9.2 telepítés és előkészítés

    Letöltés: http://download.eclipse.org/jetty/

    Telepítés menete.

    cd /opt
    tar -xf jetty-distribution-9.2.<legutóbbi stabil verzió>.tar.gz
    

    Jetty előkészítése Shibboleth 3 IdP számára.

    cd /opt
    mkdir jetty-shibboleth-idp
    cd jetty-shibboleth-idp
    mkdir etc modules lib logs resources webapps tmp
    cd /opt/jetty-distribution-9.<legutóbbi stabil verzió>
    cp etc/jetty-ssl.xml /opt/jetty-shibboleth-idp/etc/
    cp etc/jetty-https.xml /opt/jetty-shibboleth-idp/etc/
    cp etc/keystore /opt/jetty-shibboleth-idp/etc/
    cp etc/keystore.pkf /opt/jetty-shibboleth-idp/etc/
    cp modules/https.mod /opt/jetty-shibboleth-idp/modules/
    cp modules/ssl.mod /opt/jetty-shibboleth-idp/modules/
    

    Hozzuk létre a Jetty start.ini állományt az alábbi tartalommal az /opt/jetty-shibboleth-idp/start.ini helyen.

    # Required Jetty modules
    --module=server
    --module=deploy
    --module=annotations
    --module=resources
    --module=logging
    --module=requestlog
    --module=https
    --module=ssl
    --module=servlets
    --module=jsp
    --module=jstl
    --module=ext
    --module=plus
    
    # Allows setting Java system properties (-Dname=value)
    # and JVM flags (-X, -XX) in this file
    # NOTE: spawns child Java process
    --exec
    
    -Didp.home=/opt/shibboleth-idp
    
    -Djava.io.tmpdir=tmp
    
    # Maximum amount of memory that Jetty may use, at least 512M is recommended
    -Xmx512m
    
    # Maximum amount of memory allowed for the JVM permanent generation
    -XX:MaxPermSize=128m
    

    Webapp XML állomány létrehozása az IDP-hez az /opt/jetty-shibboleth/webapps/idp.xml helyen az alábbi tartalommal.

    <Configure class="org.eclipse.jetty.webapp.WebAppContext">
      <Set name="war"><SystemProperty name="idp.home"/>/war/idp.war</Set>
      <Set name="contextPath">/idp</Set>
      <Set name="extractWAR">false</Set>
      <Set name="copyWebDir">false</Set>
      <Set name="copyWebInf">true</Set>
    </Configure>
    

    Shibboleth 3 Identity Provider telepítés Jetty 9.2 konténerbe

    Letöltés: http://shibboleth.net/downloads/identity-provider/latest/

    cd /opt
    wget http://shibboleth.net/downloads/identity-provider/latest/shibboleth-identity-provider-VERSION.tar.gz
    tar -xf shibboleth-identity-provider-VERSION.tar.gz
    

    Telepítés

    root@idp:~# cd /opt/shibboleth-identity-provider-VERSION
    root@idp:/opt/shibboleth-identity-provider-3.1.1# bin/install.sh
    Source (Distribution) Directory: [/opt/shibboleth-identity-provider-3.1.1]
    
    Installation Directory: [/opt/shibboleth-idp]
    
    Hostname: [localhost.localdomain]
    **idp.intezmenyneve.hu**
    SAML EntityID: https://idp.intezmenyneve.hu/idp/shibboleth
    
    Attribute Scope: [localdomain]
    **intezmenyneve.hu**
    TLS Private Key Password: ********
    Re-enter password: ********
    Cookie Encryption Key Password: ********
    Re-enter password: ********
    Warning: /opt/shibboleth-idp/bin does not exist.
    Warning: /opt/shibboleth-idp/dist does not exist.
    Warning: /opt/shibboleth-idp/doc does not exist.
    Warning: /opt/shibboleth-idp/system does not exist.
    Warning: /opt/shibboleth-idp/webapp does not exist.
    Generating Signing Key, CN = idp.intezmenyneve.hu URI = https://idp.intezmenyneve.hu/idp/shibboleth ...
    ...done
    Creating Encryption Key, CN = idp.intezmenyneve.hu URI = https://idp.intezmenyneve.hu/idp/shibboleth ...
    ...done
    Creating TLS keystore, CN = idp.intezmenyneve.hu URI = https://idp.intezmenyneve.hu/idp/shibboleth ...
    ...done
    Creating cookie encryption key files...
    ...done
    Rebuilding /opt/shibboleth-idp/war/idp.war ...
    ...done
    
    BUILD SUCCESSFUL
    Total time: 1 minute 21 seconds
    root@idp:/opt/shibboleth-identity-provider-3.1.1#
    

    Az IdP indítása

    cd /opt/jetty-shibboleth-idp
    java -jar /opt/jetty-distribution-9.2.<legutóbbi stabil verzió>/start.jar
    

    Böngészőben a https://idp.intezmenyneve.hu:8443/idp URL-en rövid tájékoztatást kell kapnunk No services are available at this location. szöveggel.

    HREFChecklist

    Előzetes ellenőrzés

    Az alábbi listán haladunk végig egy-egy csatlakozási kérelem beérkeztekor, és ennek eredményének figyelembe vételével hozza meg a Tagok Tanácsa a döntést a felvételről.

    Shibenv

    Az alábbi test scriptek a Leuveni Egyetem Shibboleth oldaláról valók. (http://shib.kuleuven.be/download/sp/test_scripts/)

    SimpleSAMLphp

    Az alábbi lapon megkíséreljük összefoglalni a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő SimpleSAMLphp (SSP) alkalmazást állítsunk üzembe.

    Telepítés

    A leírás a forrásból történő telepítés lépéseit írja le. Az itt részletezetten kívül a SimpleSAMLphp telepíthető Debian (vagy más) operációs rendszer csomagjából, de ebben az esetben ne telepítsunk composerrel third-party (pl. általunk készített) modulokat!

    Előkészületek

    Ahhoz, hogy problémamentesen telepíthessük SSP alkalmazásunkat, az alábbi szoftverkomponenseknek kell működniük szerverünkön.

    Debian 9 / Ubuntu 16.04 LTS csomagok

    sudo apt install php php-dom mcrypt php-xml php-mbstring
    

    RHEL / CentOS 7 csomagok

    A php-mcrypt csomaghoz engedélyezni kell az "epel-release"-t.

    sudo yum install epel-release
    sudo yum update
    sudo yum install php php-dom php-mcrypt php-xml php-mbstring php-common mod_ssl
    

    Composer

    A composer PHP csomagkezelőt is telepíteni kell (akár forrásból, akár csomagból), hogy telepíteni lehessen a SimpleSAMLphp futásához szükséges PHP library-ket.

    Letöltés

    A GitHubról történő telepítés előnye, hogy a simplesamlphp könnyen frissíthető marad, csak a third party modulokat kell újratelepíteni. Az utolsó stabil verzió számát a https://simplesamlphp.org/download oldalról tudhatjuk meg.

    cd /var
    git clone [https://github.com/simplesamlphp/simplesamlphp.git](https://github.com/simplesamlphp/simplesamlphp.git)
    cd simplesamlphp
    git checkout tags/v1.16.2 -b v1.16.2
    composer install --no-dev
    

    Apache konfigurálás

    A webről csak a /var/simplesamlphp/www könyvtárat kell elérni. Tilos a teljes simplesamlphp könyvtárat a DocumentRoot alá tenni!

    Alias /simplesaml /var/simplesamlphp/www
    <Directory /var/simplesamlphp/www>
      Require all granted
    </Directory>
    

    Alapbeállítások

    Konfigurációs fájlok másolása

    Mielőtt aktiváljuk valamelyik főszolgáltatását (IdP,SP...) a telepített alkalmazásnak, néhány beállítást meg kell adnunk a config/config.php és config/authsources.php konfigurációs fájlokban.

    A config.php és authsources.php fájlok másolása utána ellenőrizzük, hogy a SimpleSAMLphp működik-e, a https://example.org/simplesaml oldalon.

    Konfigurációs fájlok szerkesztése

    Adminisztrációs adatok beállítása

    Amennyiben az SimpleSAMLphp kezdőlapja hiba nélkül megjelent, akkor nyissuk meg a config/config.php fájl szerkesztésre és végezzük el az alábbi beállításokat.

    Az alapadatok megadása után mentsük és zárjuk be a config.php-t.

    Naplózás beállítása

    Alapértelmezetten a SimpleSAMLphp a syslog-ba irányítja a naplózást.

    Ha fájlba akarunk naplózni, akkor a megfelelő könyvtárhoz biztosítsunk írás jogot a webszerver felhasználónak, és ne felejtsünk el gondoskodni a naplófájlok rotálásáról!

    A "SimpleSAML\Logger::DEBUG" a legrészletesebb naplózási beállítás, éles rendszernél nem ajánlott csak hiba keresés esetén.

    Tanúsítvány készítése

    Nem ajánlott a SimpleSAMLphp-hoz és webszerverhez ugyanazt a tanúsítvány használni!

    A fingerprint az alábbi módon kérdezhető le a legegyszerűbben

        openssl x509 -fingerprint -noout -in cert/saml-example-org.crt
    

    Telepítés kész

    Amennyiben elkészültünk a fenti lépésekkel, úgy a https://service.example.org/simplesaml/ címen elérjük a telepített SSP-nk webes adminfelületét, ahol megejthetjük a további beállítások nagy részét.

    Identity Provider (IdP) beállítás

    Alapbeállítások

    IdP engedélyezése: a config/config.php fájlban kell a saml20 idp-t "true"-re állítani.

    'enable.saml20-idp' => true,
    

    LDAP autentikáció

    Meg kell adni, hogy az IdP milyen módon azonosítsa a felhasználót, amennyiben alapértelmezés szerint nem engedélyezett modult szeretnénk használni, úgy a megfelelő modult a modules könyvtár alatt engedélyezni kell. Az alábbi példában az LDAP alapú azonosítást mutatjuk be, amely külön modult nem igényel, alapértelmezés szerint része a telepített alkalmazásnak.

    Javasolt az LDAP-ban egy olyan bejegyzést létrehozni az IdP számára, amely olvasni tudja a felhasználóknak a föderációban használt attribútumait. Az azonosítás alapértelmezett módon a felhasználó nevében történő újra bind-olással történik, így a jelszóhoz nem kell hozzáférést adni.

    Ahhoz, hogy megadhassuk az LDAP-hoz tartozó beállításokat, a config/authsources.php fájlt kell szerkesztenünk. Az alábbi kódrészletet elegendő beszúrni, és az egyes változóknak a helyi LDAP-nak megfelelő adatokat értékül adni.

    'example-ldap' => array(
        'ldap:LDAP',
    
        /* The hostname of the LDAP server. */
        'hostname' => 'ldap.example.org',
    
        /* Whether SSL/TLS should be used when contacting the LDAP server. */
        'enable_tls' => FALSE,
    
        /*
         * Which attributes should be retrieved from the LDAP server.
         * This can be an array of attribute names, or NULL, in which case
         * all attributes are fetched.
         */
        'attributes' => NULL,
    
        /*
         * The pattern which should be used to create the users DN given the username.
         * %username% in this pattern will be replaced with the users username.
         *
         * This option is not used if the search.enable option is set to TRUE.
        'dnpattern' => 'uid=%username%,ou=people,dc=example,dc=org',
         */
    
        /*
         * As an alternative to specifying a pattern for the users DN, it is possible to
         * search for the username in a set of attributes. This is enabled by this option.
         */
        'search.enable' => TRUE,
    
        /*
         * The DN which will be used as a base for the search.
         * This can be a single string, in which case only that DN is searched, or an
         * array of strings, in which case they will be searched in the order given.
         */
        'search.base' => 'ou=people,dc=example,dc=org',
    
        /*
         * The attribute(s) the username should match against.
         *
         * This is an array with one or more attribute names. Any of the attributes in
         * the array may match the value the username.
         */
        'search.attributes' => array('uid', 'mail'),
    
        /*
         * The username & password the simpleSAMLphp should bind to before searching. If
         * this is left as NULL, no bind will be performed before searching.
         */
        'search.username' => 'cn=simplesamlphp,dc=example,dc=org',
        'search.password' => 'servicepassword',
    
        'priv.read' => TRUE,
        // The DN & password the SimpleSAMLphp should bind to before
        // retrieving attributes. These options are required if
        // 'priv.read' is set to TRUE.
        'priv.username' => 'cn=simplesamlphp,dc=example,dc=org',
        'priv.password' => 'servicepassword;,
       ),
    

    Metaadat alapok

    A beállítandó IdP alapvető paraméterei a metadata/saml20-idp-hosted.php fájlban állíthatók. Az alábbi kódrészlet egy minimális, de már működő példát mutat.

    
     $metadata['__DYNAMIC:1__'] = array(
        /*
         * The hostname for this IdP. This makes it possible to run multiple
         * IdPs from the same configuration. '__DEFAULT__' means that this one
         * should be used by default.
         */
        'host' => '__DEFAULT__',
    
        /*
         * The private key and certificate to use when signing responses.
         * These are stored in the cert-directory.
         */
        'privatekey' => 'saml-example-org.key',
        'certificate' => 'saml-example-org.crt',
    
        /*
         * The authentication source which should be used to authenticate the
         * user. This must match one of the entries in config/authsources.php.
         */
        'auth' => 'example-ldap',
     );
    

    Megfelelő beállítások után a dinamikusan generált metadata a /saml2/idp/metadata.php útvonalon érhető el.

    Tesztelés

    Legegyszerűbben a telepített SSP felületén tudjuk ellenőrizni, hogy a beállított autentikációs forrás működik-e. A felületen az Authentication fül alatt található egy 'Test authentication sources' link, amelyre kattintva látható minden beállított autentikációs forrás is, így a két alapértelmezett, teszt célokat szolgáló alatt a most beállított example-ldap névre hallgatónak is meg kell jelenni. (A közvetlen url erre az oldalra: simplesaml/module.php/core/authenticate.php) Ez utóbbira kattintva a beállított LDAP-ból autentikálva be kell tudnunk jelentkeznünk; siker esetén az LDAP-ból kinyerhető attribútumokat láthatjuk.

    Service Provider (SP) beállítás

    Alapbeállítások

    A telepített alkalmazásunk által kezelt SP-ket a config/authsources.php fájlban tudjuk beállítani. Az entityID, idp, discoURL értékeket most hagyjuk NULL értéken és adjuk hozzá a privatekey / certificate részt.

    A SimpleSAMLphp a tanúsítvány fájlokat a korábban létrehozott cert mappában fogja keresni, a fájlokat elég relatív elérési úttal megadni.

    
     'default-sp' => array(
            'saml:SP',
    
            // The entity ID of this SP.
            // Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
            'entityID' => NULL,
    
            // The entity ID of the IdP this should SP should contact.
            // Can be NULL/unset, in which case the user will be shown a list of available IdPs.
            'idp' => NULL,
    
            // The URL to the discovery service.
            // Can be NULL/unset, in which case a builtin discovery service will be used.
            'discoURL' => NULL,
    
            'privatekey' => 'saml-example-org.key',
            'certificate' => 'saml-example-org.crt',
    
     ),
    

    A fenti beállítások alapján az SP entityID-ja megegyezik a metadata elérési útvonalával (szokásos megoldás SSP-nél), nem adunk meg alapértelmezett idp-t, ezáltal az SSP választási lehetőséget kínál fel számunkra, mikor az SP-re szeretnénk bejelentkezni, ill. most még Discovery Service URL-t sem adunk meg, hanem a beépítettet használjuk. Ez utóbbit majd a HREF-be történő integrációkor meg kell változtatni - lásd lejjebb.

    Az SP készen áll arra, hogy összekössük egy IdP-vel (ez jellemzően szintén egy SimpleSAMLphp alkalmazás). Ehhez szükséges, hogy SP oldalon beállítsuk az IdP metadata-t és IdP oldalon is beállítsuk az SP metadata-t.

    Metadata

    Metadata fájlok

    A különböző metadata template fájlok a metadata-templates mappában találhatóak. A nekünk szükséges template fájlt másoljuk át a metadata mappába.

    Metadata letöltés

    Ezen az oldalon megtaláljuk az SP vagy IdP-re vonatkozó metadata-t, XML és PHP formátumban: https://example.org/simplesaml/module.php/saml/sp/metadata.php/default-sp?output=xhtml

    SP metadata beállítás IdP oldalon

    A metadata simplesaml kezdőlapon, az alábbi helyen érhető el:

    A "SimpleSAMLphp fájl formátumban - akkor használható, ha a másik oldalon SimpleSAMLphp van" mezőből tegyük a vágólapra az alábbi PHP kódot:

    $metadata['https://example.org/simplesaml/module.php/saml/sp/metadata.php/default-sp'] = array (
      'SingleLogoutService' =>
      array (
        0 =>
        array (
          'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
          'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp',
        ),
      ),
      'AssertionConsumerService' =>
      array (
        0 =>
        array (
          'index' => 0,
          'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
          'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
        ),
        1 =>
        array (
          'index' => 1,
          'Binding' => 'urn:oasis:names:tc:SAML:1.0:profiles:browser-post',
          'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml1-acs.php/default-sp',
        ),
        2 =>
        array (
          'index' => 2,
          'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact',
          'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
        ),
        3 =>
        array (
          'index' => 3,
          'Binding' => 'urn:oasis:names:tc:SAML:1.0:profiles:artifact-01',
          'Location' => 'https://example.org/simplesaml/module.php/saml/sp/saml1-acs.php/default-sp/artifact',
        ),
      ),
      'contacts' =>
      array (
        0 =>
        array (
          'emailAddress' => 'admin@example.org',
          'contactType' => 'technical',
          'givenName' => 'Example Corp. IT Dept.',
        ),
      ),
      'certData' => 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==',
    );
    

    A vágólapra másolt kódot IdP oldalon, a metadata/saml20-sp-remote.php fájl végére illesszük be.

    IdP metadata beállítás SP oldalon

    A metadata simplesaml kezdőlapon, az alábbi helyen érhető el:

    A "SimpleSAMLphp fájl formátumban - akkor használható, ha a másik oldalon SimpleSAMLphp van" mezőből tegyük a vágólapra az alábbi PHP kódot:

    $metadata['https://idp.example.org/simplesaml/saml2/idp/metadata.php'] = array (
      'metadata-set' => 'saml20-idp-remote',
      'entityid' => 'https://idp.example.org/simplesaml/saml2/idp/metadata.php',
      'SingleSignOnService' =>
      array (
        0 =>
        array (
          'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
          'Location' => 'https://idp.example.org/simplesaml/saml2/idp/SSOService.php',
        ),
      ),
      'SingleLogoutService' =>
      array (
        0 =>
        array (
          'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
          'Location' => 'https://idp.example.org/simplesaml/saml2/idp/SingleLogoutService.php',
        ),
      ),
      'certData' => 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==',
      'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
    );
    

    A vágólapra másolt kódot SP oldalon, a metadata/saml20-idp-remote.php fájl végére illesszük be.

    Tesztelés

    A fent elvégzett alapbeállítások után már tudjuk tesztelni a, hogy a felépített IdP - SP kapcsolat működik-e.

    SP oldalon nyissuk meg a simplesaml kezdőlapot:

    A legördülő menüben az IdP-nk "nevére" kattintva, be kell tudnunk jelentkezni (az IdP-n keresztül). Ha működik, akkor az IdP visszairányít az SP-re, kiírja az azonosított felhasználó attribútumait.

    Az alapvető lépsekkel kész vagyunk, van egy működő SP-nk és egy működő IdP-nk.

    HREF-integráció

    Metadata beállítása (IdP és SP is)

    Javasolt dinamikus metaadatforrást (MDX) használni, opcionálisan kiegészítve statikus állományokkal. Részletes leírás itt: SimpleSAMLMixedMetadata

    IdP

    Amennyiben van SSP alapú IdP-nk, melyet szeretnénk a föderáció részévé tenni, úgy a teendők a következők.

    Attribútumok kezelése

    Beállított IdP-nk alapértelmezés szerint azokat az attribútumokat adja ki, melyeket a metaadat alapján az SP kért (Lásd a metadatában a RequestedAttribute elemeket), és egyúttal alapból meg tudta szerezni a felhasználói adatbázisból, esetünkben az LDAP-ból. Mivel néhány attribútum nem szerepel az LDAP-ban, hanem az IdP-ben kell előállítani, így pár helyen módosítanunk kell az alapértelmezett konfiguráción.

    A metadata/saml20-idp-hosted.php fájlba szerkesszük be az alábbi kódrészlet értelemszerűen módosított változatát. Az 'auth' => 'example-ldap', sor alatt kezdjük. Fontos, hogy egyúttal a config.php authproc.idp részét kikommentezzük, nehogy az ottani sorszámokkal megadott default feladatok bekavarjanak.

    'AttributeNameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
     'userid.attribute' => 'uid', // Itt adjuk meg, hogy mely, az LDAPból származó attribútum alapján fogja az IdP kiszámítani az eduPersonTargetedID-t
     'authproc' => array(
                    10 => array(
                            'class' => 'core:AttributeMap',
                            'uid' => 'eduPersonPrincipalName'
                    //Itt az 'uid' az az attribútum az LDAP-ban, amely a felhasználó azonosítóját tartalmazza, mert ebből képezzük az eduPersonPrincipalName-t.
                    ),
                    # 20 => array(
                    #         'class' => 'core:AttributeAdd',
                    #         'schacHomeOrganizationType' => array('urn:schac:homeOrganizationType:hu:university')
                    # //Kötelező statikus attribútum az [[HREFAttributeSpec#schacHomeOrganizationType|intézmény jellegének]] megfelelően
                    # ),
                    30 => array(
                            'class' => 'core:AttributeAlter',
                            'subject' => 'eduPersonPrincipalName',
                            'pattern' => '/^.*$/',
                            'replacement' => '${0}@intezmenydomain.hu',
                    // Itt adjuk hozzá az intézményi scope-ot az eduPersonPrincipalName már meglévő értékéhez
                    ),
                    40 => array(
                            'class' => 'core:AttributeAlter',
                            'subject' => 'eduPersonAffiliation',
                            'pattern' => '/^.*$/',
                            'replacement' => '${0}@intezmenydomain.hu',
                    // Itt adjuk hozzá az intézményi scope-ot az eduPersonAffiliation már meglévő értékéhez
                    ),
                    50 => array(
                            'class' => 'core:AttributeMap',
                            'eduPersonAffiliation' => 'eduPersonScopedAffiliation'
                    // Az LDAP-ból eduPersonAffiliation-ként érkező attribútumból föderációs elvárásoknak megfelelően eduPersonScopedAffiliationt készítünk
                    ),
                    60 => array(
                            'class' => 'core:AttributeAdd',
                            'eduPersonScopedAffiliation' => array('member@intezmenydomain.hu')
                    // Az eduPersonScopedAffiliation-ben tesztelés céljából kiadhatjuk member értéket,
                    // így ha LDAP-ból nem jön érték, akkor is láthatjuk, hogy működik az attribútum kiadás
                    ),
                    61 => array(
                            'class' => 'core:TargetedID',
                            'nameId' => TRUE,
                    ),
                   // Itt állítjuk be, hogy az IdP előállítson és kiadhasson állandóazonosítóként eduPersonTargetedID-t, ha kérik
                    70 => array('class' => 'core:AttributeMap',
                            'name2oid'
                    // Az LDAP-os attribútum nevekből itt kreálunk szabványos urn:oid formátumúakat
                    ),
                    80 => 'core:AttributeLimit',
                  ), // .authproc
           'simplesaml.nameidattribute' => 'eduPersonPrincipalName',
           'attributeencodings' => array(
                   'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw',
            ),
            'sign.logout' => true
    

    SP

    Amennyiben IdP-t is beállítottunk, és be is tudunk lépni a Resource Registry-be, úgy nincs más dolgunk, mint az RR-ben új SP-t hozzáadni a föderációhoz, amely a megfelelő átfutási idő után a föderáció minden tagjánál látható is lesz.

    Ellenkező esetben (nincs IdP, és nem is tervezünk beállítani), akkor az IdP hozzáadásánál részletezett pontokon kell végig menni a metaadat betöltéséig, s a továbbiakat az említett e-mail címen megbeszélni.

    Attribútum scopeok használata

    A HREF föderáció IdP-i ún. scopeolt attribútumokat is használnak. Ez a scopeolás azt jelenti, hogy minden egyes IdP csak a saját scopejában ad ki attribútumokat, és a Shibboleth SP-k ezt ellenőrzik is. A scope és az attribútum valódi értéke egy '@' karakterrel kerül elválasztásra (ilyen attribútumok jelenleg: eduPersonScopedAffiliation illetve eduPersonPrincipalName).

    A SimpleSAMLphp alapértelmezett telepítése nem szűri a hibásan scopeolt értékeket. Kiegészítő modulként szűrésre használható az NIIF által fejlesztett attributescope modul, ami reményeink szerint rövid távon a hivatalos SimpleSAMLphp kiadás része lehet.

    A telepítésről és konfigurációról bővebben itt lehet olvasni: https://github.com/NIIF/simplesamlphp-module-attributescope

    
     authproc.sp =  array(
                          ...
                         // 49 => array('class' => 'core:AttributeMap', 'oid2name'),
                         50 => array(             'class' => 'attributescope:FilterAttributes'
                         ),
                         ...
                    ),
    

    Figyeljünk arra, hogy mire a modulhoz ér a vezérlés, az attribútumok nevei friendlyName alakúak legyenek (ne pedig oid-ok). A példában erre utal a 49-es sor.

    HREFMetadataRegistrationPracticeStatement

    Metadata Registration Practice Statement

    Federation Name: eduID Federation Operator: NIIFI, Hungary Federation Web Page: http://www.eduid.hu

    Date of last change: 20110907

    Common Practices

    All IdP, SP and RRA [1] administrators connect via https and authenticate via eduID to the Resource Registry, where the original information gets administrated which is later used for generating the federation metadata.

    In addition, before the federation operator publishes metadata dedicated for interfederation, an institution has first to declare that its processes are ready for interfederation. Only then the federation operator will be able to declare that their respective entity is also technically ready to participate in interfederation.

    Practices on Identity Provider Registration

    An IdP registering to the federation needs to be manually approved by the Members' Board. Such approval requires:

    Subsequent changes to these elements and attributes do not require re-approval by the federation operator. Only, administrators appointed specifically by that institution can modify the IdP specific information.

    Practices on Service Provider Registration

    Each SP must be manually approved by an RRA Administrator in order to be registered with the federation. RRA Administrators must be from the institution on whose behalf the SP gets registered.

    It is the duty of the RRA Administrator to review and approve all the details provided by the SP administrator. In addition, an RRA Administrator can reject changes or further modify details of an SP before approving it.

    After approving the details about a new SP, the user who requested to register it becomes its first SP administrator. An SP administrator can transfer the administration right to further users. Only users with administrator rights for a specific SP are able to modify its elements and attributes. Such changes require re-approval by an RRA Administrator.

    Additional Rules for Federation Partner Service Providers

    A signed Federation Partner Agreement is required before a Federation Partner SP can register with the federation. Federation Partner SPs are always approved by a Federation Operator.

    Practices regarding metadata modifications

    In eduID, no metadata gets modified because the federation operator generates it on behalf of all entities.

    The source for generating metadata is the Resource Registry. The details of a registering entity are entered manually by providing the necessary information. Alternatively, a wizard will parse existing entity metadata to gather as many details as possible in order to facilitate the registration.

    The IdP/SP administrator also has to supply non-technical information like descriptions or support contacts. All technical and non-technical information is stored as decomposed items in a database. To generate federation metadata, information from that database gets composed into SAML metadata format.

    All entites in the Resource Registry could be in one or more metadata-sets. Beside the federation metadata there are metadata-sets with generated metadata files for each institution and for edugain.


    [1] RRA Administrator = Resource Registration Authority Administrator A role assigned to one or more persons to act on behalf of the institution which signed the federation service agreement. An RRA Administrator has to review and approve new and changed SPs belonging to or sponsored by the institution before such an SP gets loaded into federation metadata.

    Shib2SPSourceInstall

    Függőségek

    Fordítás

    A Shibboleth fordításához néhány "külső" csomagot is le kell fordítani.

    log4shib vs. log4cpp

    !!! danger "Figyelem"

    Lásd: [log4cpp kontra log4shib](https://help.edu.hu/books/aai/page/log4whatever)
    

    XML-Security C

    Ez a csomag igazából része általában a disztribúcióknak, de a Shibboleth 2-nek (és az OpenSAML-nak) >=1.4.0 verzió kell, ami jelenleg még nincs is kiadva (2008.04.24.). Hurrá :(

    Örüljünk, a download könyvtárban meg lehet találni az 1.4.0 verziójú .tar.gz-t.

    wget http://xml.apache.org/security/dist/c-library/xml-security-c-1.4.0.tar.gz
    tar xzf xml-security-c-1.4.0.tar.gz
    cd xml-security-c-1.4.0
    ./configure --prefix=/opt
    make
    sudo make install
    

    xmltooling

    Az xmltooling log4cpp-vel történő lefordításához szükség van erre a patch-re.

    patch -p0 <../xmltooling_log4cpp5.patch
    ./configure --prefix=/opt --with-xmlsec=/opt
    make
    sudo make install
    

    opensaml

    ./configure --prefix=/opt --with-xmlsec=/opt --with-xmltooling=/opt
    make
    sudo make install
    

    Shibboleth SP

    ./configure --prefix=/opt --with-xmltooling=/opt --with-saml=/opt
    make
    sudo make install
    

    ShibIdPX509LdapAuthentication

    Shibboleth 2.x IdP X.509/LDAP autentikációs modul

    Ezen az oldalon az NIIF által fejlesztett X.509 klienstanúsítvány alapú Shibboleth autentikációs modul leírása szerepel.

    In English

    Motivations

    PKIful versus PKIless

    Shibboleth X.509 authentication

    X.509 + LDAP certificate authentication (implementation details)

    Combining X.509 and username/password authentication

    Követelmények

    Az X.509/LDAP autentikációs modul a következő követelmények alapján került kifejlesztésre:

    Ezen követelmények kielégíthetők a címtárban tárolt klienstanúsítványokkal, ugyanis a címtárba csak egy felettes szerv képes beírni a tanúsítványt, ott minden bejelentkezéskor ellenőrzésre is kerül, ezért könnyen visszavonható.

    !!! info

    A felhasználó tanúsítvány alapú azonosításához (identification) szükséges, hogy a tanúsítvány tartalmazza a felhasználónevet, mégpedig az `UID` (subject) mezőben.
    

    Telepítés

    Az autentikációs modul letölthető a http://software.niif.hu oldalról. A Shibboleth2 IdP autentikációs motorjának konfigurációját részetesen a Shibboleth2 User Authentication wikioldal írja le.

    Apache beállítása

    Amennyiben az alapértelmezett szervlet elérési utat választjuk (/Authn/X509), a következő opciókat kell megadni az Apache webszerver konfigurációjában:

    <Location /idp/Authn/X509>
       SSLVerifyClient optional_no_ca  #nincs CA ellenorzes
       SSLOptions +ExportCertData      #tanusitvany exportalasa
    </Location>
    

    IdP webalkalmazás beállítása

    A letöltött modulban található shibboleth-x509auth-verzio.jar java osztálykönyvtárat be kell másolni a Shibboleth webalkalmazás WEB-INF/lib könyvtárába, valamint a WEB-INF/web.xml fájlban meg kell adni az autentikációs szervlet paramétereit:

    <servlet>
      <servlet-name>X509LdapAuthHandler</servlet-name>
      <servlet-class>hu.niif.middleware.shibboleth.auth.X509LdapLoginServlet</servlet-class>
      <init-param>
        <param-name>jaasConfigName</param-name>
        <param-value>X509LdapAuth</param-value>
      </init-param>
      <load-on-startup>4</load-on-startup>
    </servlet>
    
    <servlet-mapping>
      <servlet-name>X509LdapAuthHandler</servlet-name>
      <url-pattern>/Authn/X509</url-pattern>
    </servlet-mapping>
    

    !!! info

    Az IdP webalkalmazás az `${SHIB_HOME}/war/idp.war` fájlban található, ebben kell elvégezni a módosításokat, majd újratelepíteni az alkalmazást a webkonténerbe.
    

    IdP konfiguráció

    Az IdP konfigurációjában két dolgot kell módosítani: a JAAS autentikációs modul login.config konfigurációját, valamint a handler.xml-ben az autentikációs módokat.

    Az X.509/LDAP JAAS modul beállításához a ${SHIB_HOME}/conf/login.config fájl tartalmához a következő sorokat adjuk hozzá (az LDAP elérési paramétereket értelem szerint kitöltve; az értékek általában a ShibUserPassAuth JAAS konfigurációból átmásolhatóak):

    X509LdapAuth {
      hu.niif.middleware.jaas.X509LdapLoginModule required
         host=""
         port=""
         base=""
         ssl=""
         userField=""
         serviceUser=""
         serviceCredential="";
    };
    

    !!! info

    Figyelni kell arra, hogy az itt megadott `serviceUser` olvasási joggal rendelkezzen a `userCertificate` LDAP attribútumra.
    

    A JAAS modul beállítása után a ${SHIB_HOME}/conf/handler.xml fájlban meg kell adnunk az új autentikációs modulunkat, a következőképpen:

    <LoginHandler xsi:type="RemoteUser" protectedServletPath="/Authn/X509" >
       <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:X509</AuthenticationMethod>
    </LoginHandler>
    

    Ha továbbra is alapértelmezetten felhasználónév/jelszó autentikációt szeretnénk használni, akkor a Shibboleth IdP-ben be kell állítani az alapértelmezett hitelesítési módot, a ${SHIB_HOME}/conf/relying_party.xml fájlban:

    ...
    <DefaultRelyingParty provider="..."
      defaultSigningCredentialRef="..."
      defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
    ...
    

    Shibboleth SP beállítása

    Az egyes SP-k eldönthetik hogy ők kérik-e az X.509 autentikációt, ezt az authnContextClassRef SP opcióval lehet jelezni a Shibboleth SP felé.

    Ez a kérés azonban nem teljesen megbízható, ezért érdemes az IdP oldalon konfigurálni hogy egy adott SP kérése alapján az X.509 autentikációs módot használjuk (a ${SHIB_HOME}/conf/relying-party.xml fájlban):

    ...
    <RelyingParty id="x509-protected-sp-entityid"
      provider="our-idp-entityid"
      defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:X509" />
    ...
    

    Integráció a felhasználónév / jelszó bejelentkezéssel

    A fent leírt telepítési módszer nem biztosítja azt a lehetőséget, hogy egy felhasználó eldönthesse hogy ő jelszóval vagy klienstanúsítvánnyal autentikál. Amennyiben szeretnénk ezt a választási lehetőséget megadni abban az esetben, amikor az SP nem jelez általa preferált autentikációs módot, az alábbi plusz konfiguráció segítségével ezt megtehetjük.

    !!! info

    A klienstanúsítvány segítségével történő autentikáció **nem feltétlenül biztonságosabb** mint a jelszavas bejelentkezés, ezért jól fontoljuk meg, hogy minden felhasználónak felkínáljuk-e ezt a lehetőséget.
    

    Shibboleth IdP webalkalmazás módosítása

    Az X.509/LDAP autentikációs modul tartalmaz egy olyan szervletet, ami képes a felhasználónév/jelszó és az X.509 autentikáció együtt történő futtatására. Első lépésként ezt a szervletet kell beállítani a WEB-INF/web.xml webalkalmazás konfigurációban:

    <servlet>
      <servlet-name>UsernamePasswordX509LoginServlet</servlet-name>
      <servlet-class>hu.niif.middleware.shibboleth.auth.UsernamePasswordX509LoginServlet</servlet-class>
      <init-param>
        <param-name>loginPage</param-name>
        <param-value>login_.jsp</param-value>
      </init-param>
      <load-on-startup>4</load-on-startup>
    </servlet>
    
    <servlet-mapping>
      <servlet-name>UsernamePasswordX509LoginServlet</servlet-name>
      <url-pattern>/Authn/UserPasswordX509</url-pattern>
    </servlet-mapping>
    

    Ez a konfiguráció hivatkozik a login_.jsp fájlra, ez egy módosított Shibboleth bejelentkeztető form, amiben két plusz gomb kapott helyet. Ezekkel a gombokkal a felhasználó kérheti, hogy erre az egy autentikációra szeretne klienstanúsítványt használni, vagy a munkamenetben mindig. Utóbbi esetben a bejelentkezést lekezelő szervlet létrehoz egy cookie-t a felhasználó gépén, ami ezt a preferenciát megőrzi a böngésző bezárásáig.

    !!! info

    Amennyiben a felhasználó egyszer bejelölte a tanúsítványos autentikációt a teljes munkamenetre, azt nem tudja kikapcsolni, csak a böngésző újraindításával.
    

    Shibboleth IdP konfiguráció

    Az IdP konfigurációjában meg kell adni ezt a hibrid autentikációs módot, mégpedig a következőképpen (${SHIB_HOME}/conf/handler.xml):

    <LoginHandler xsi:type="UsernamePassword"
      authenticationDuration="240"
      jaasConfigurationLocation="file://PATH/TO/IDP/conf/login.config"
      authenticationServletURL="/Authn/UserPasswordX509">
      <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</AuthenticationMethod>
    </LoginHandler>
    

    Ez a konfigurációs részlet azt közli az IdP-vel, hogy az autentikációs modul nem specifikált autentikációs mód esetén működik. Ezt a módot alapértelmezetté tehetjük a ${SHIB_HOME}/conf/relying_party.xml fájlban:

    ...
    <DefaultRelyingParty provider="..."
      defaultSigningCredentialRef="..."
      defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified">
    ...
    

    Shib2IdpSUSE

    Shibboleth 2 IdP függőségeinek beállítása OpenSUSE alatt

    Debian telepítési útmutató: Shib2IdpInstall, ezen az oldalon az OpenSUSE alatt történő azon beállításokat részletezzük, amelyek eltérnek a Debianban megszokottól.

    Szükséges csomagok

    Apache beállítása

    chkconfig apache2 on
    chkconfig tomcat6 on
    #alapbol nincs engedelyezve a proxy_ajp modul
    a2enmod proxy proxy_ajp
    

    További információk: Shib2IdpInstall#apache-beállítás

    Tomcat6 beállítása

    A /etc/tomcat6/tomcat6.conf fájlban találhatóak meg a környezeti beállítások:

    JAVA_OPTS="-Xms256M -Xmx512M -XX:-DisableExplicitGC"
    JAVA_ENDORSED_DIRS="/usr/local/shibboleth-idp/endorsed"
    CLASSPATH="/usr/share/java/mysql-connector-java.jar"
    SECURITY_MANAGER="false"
    

    További információk: Shib2IdpInstall#Tomcat_6

    MediaWikiShibboleth

    Attribútum_feloldás

    A felhasználó azonosítása után az IdP még csak a REMOTE_USER változóban megkapott principal azonosítót tudja. A következő lépésben meg kell határozni a felhasználóhoz kapcsolódó attribútumokat. Ezeket az attribútumokat általában valamilyen adatbázisból (LDAP, SQL) kell lekérdezni, de lehetséges konstans, ill. származtatott attribútumokat is használni.

    Fontos megjegyezni, hogy az attribútumok csak akkor adódnak át az SP-knek, ha ez az Attribute Release Policy-ban engedélyezve van. Természetesen fel nem oldott attribútumokat nem lehet átadni.

    Az attribútum feloldást az IdP konfiguráció IdPConfig elemének resolverConfig attribútumában megadott XML állományban konfigurálhatjuk. Ez általában a resolver.xml vagy resolver.ldap.xml névre hallgat

    Működő példa konfiguráció

    <AttributeResolver xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                       xmlns="urn:mace:shibboleth:resolver:1.0"
                       xsi:schemaLocation="urn:mace:shibboleth:resolver:1.0 shibboleth-resolver-1.0.xsd">
    
            <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonEntitlement">
                    <DataConnectorDependency requires="directory"/>
            </SimpleAttributeDefinition>
    
            <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonAffiliation">
                    <DataConnectorDependency requires="directory"/>
            </SimpleAttributeDefinition>
    
            <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn">
                    <DataConnectorDependency requires="directory"/>
            </SimpleAttributeDefinition>
    
            <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:uid">
                    <DataConnectorDependency requires="directory"/>
            </SimpleAttributeDefinition>
    
            <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonPrincipalName" smartScope="niif.hu">
                    <AttributeDependency requires="urn:mace:dir:attribute-def:uid"/>
            </SimpleAttributeDefinition>
    
            <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" smartScope="niif.hu">
                    <AttributeDependency requires="urn:mace:dir:attribute-def:eduPersonAffiliation"/>
            </SimpleAttributeDefinition>
    
            <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonOrgDN" >
                    <DataConnectorDependency requires="staticOrgDN"/>
            </SimpleAttributeDefinition>
    
             <JNDIDirectoryDataConnector id="directory">
                    <Search filter="uid%PRINCIPAL%">
                            <Controls searchScope="ONELEVEL_SCOPE" returningObjects="false" />
                    </Search>
                    <Property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" />
                    <Property name="java.naming.provider.url"
                              value="ldap://directory.iif.hu:636/ou=users,o=niifi,on=iif,c=hu" />
                    <Property name="java.naming.security.protocol" value="ssl" />
                    <Property name="java.naming.security.principal"
                              value="uidniif-idp,ou=shib,ou=applications,o=niifi,o=niif,c=hu" />
                    <Property name="java.naming.security.credentials" value="XXXXXXXX" />
            </JNDIDirectoryDataConnector>
    
            <StaticDataConnector id="staticOrgDN">
                    <Attribute name="eduPersonOrgDN">
                            <Value>o=niifi,o=niif,c=hu</Value>
                    </Attribute>
            </StaticDataConnector>
    
    </AttributeResolver>
    

    Attribútum feloldás menete

    Az attribútum feloldás abból áll, hogy attribútum definícióhoz adat(bázis) konnektorokat rendelünk. Az adat konnektor feladata az attribútum értékének meghatározása, pl. külső adatforrásokból. Az attribútum definíció azt adja meg, hogy miként kell az értéket a Shibboleth által használt SAML assertionbe tenni.

    Adatok kinyerése (DataConnector)

    Minden adatforrás rendelkezik egy id mezővel, amelynek az összes adatforrásra nézve egyedinek kell lennie.

    JNDIDirectoryDataConnector

    Ennek segítségével állíthatjuk be a JNDI LDAP kapcsolat paramétereit. Ezen az interfészen keresztül tetszőleges LDAP v3 interfészt biztosító adatforrás lekérdezhető.

    Példa:

    <JNDIDirectoryDataConnector id="directory">
        <Search filter="uid=%PRINCIPAL%">
            <Controls searchScope="ONELEVEL_SCOPE" returningObjects="false" />
        </Search>
        <Property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" />
        <Property name="java.naming.provider.url"
                  value="ldap://directory.iif.hu:636/ou=users,o=niifi,o=niif,c=hu" />
        <Property name="java.naming.security.protocol" value="ssl" />
        <Property name="java.naming.security.principal"
                  value="uid=niif-idp,ou=shib,ou=applications,o=niifi,o=niif,c=hu" />
        <Property name="java.naming.security.credentials" value="XXXXXXXX" />
    </JNDIDirectoryDataConnector>
    

    Példa beállítások magyarázata (részletes beállítási lehetőségekkel kapcsolatban lásd a Shibboleth Wiki vonatkozó részét!)

    JDBCDataConnector

    E konnektor segítségével tetszőleges JDBC-n keresztül elérhető adatforrásból kinyerhetünk adatokat.

    <JDBCDataConnector id="studentSystem"
                       dbURL="jdbc:postgresql://test.example.edu/test?user=postgres&password=test"
                       dbDriver="org.postgresql.Driver"
        <Query>select entitlement from foo where name = ?</Query>
    </JDBCDataConnector>
    

    A "?" karakterrel hivatkozhatunk a REMOTE_USER változóban kapott principal azonosítóra.

    A JDBCDataConnector részletes paraméterezhetőségéről lásd a Shibboleth wiki vonatkozó részét!

    StaticDataConnector

    Ennek segítségével rendelhetünk statikus adatokat a felhasználókhoz. Legtöbbször akkor használjuk, ha az IdP-nél történt azonosítás tényéből attribútumokat akarunk származtatni.

    <StaticDataConnector id="staticOrgDN">
       <Attribute name="eduPersonOrgDN">
           <Value>o=niifi,o=niif,c=hu</Value>
       </Attribute>
    </StaticDataConnector>
    

    Egy StaticDataConnector egyszerre több attribútumot is tud szolgáltatni, ill. egy attribútumnak több értéke is lehet. Bővebben lásd a Shibboleth wiki vonatkozó részét!

    Attribútumok előkészítése (AttributeDefinition)

    Az attribútum definíciók arra valók, hogy az adatforrásból származó értéket az átvitelt biztosító SAML szabványnak, illetve az attribútumot fogadó SP-nek megfelelő formátumba konvertálják. Ezért minden attribútum definíciónál meg lehet adni függőséget, amelyből az attribútum értéke származik. A függőségnek két fajtája van:

    Mindkét függőség megadásakor a requires XML attribútummal hivatkozhatunk a DataConnector vagy az AttributeDefinition id-jére. Ebből következik az is, hogy minden attribútum definíciónak egyedi id mezője kell, hogy legyen.

    SimpleAttributeDefinition

    Ezzel a pluginnal egyszerű műveleteket végezhetünk az adatforrásokból származó értékeken (vagy akár átalakítás nélkül is továbbíthatjuk). Az alábbi attribútumokkal rendelkezik:

    A sourceName mezőt nem kötelező megadni, mert a forrás attribútum neve megadható az id paraméterben is. A forrás attribútum nevének meghatározása a következő sorrendben történik:

    1. Ha meg van adva a sourceName, akkor az adat konnektortól ezt az attribútumot kapja meg
    2. Ha van olyan - az adat konnektor által nyújtott - attribútum, amely az id mezővel teljesen megegyezik, akkor annak az értékét használja
    3. Egyébként az adat konnektortól az id mezőben megadott paraméter utolsó ":" vagy "/" jel utáni részének megfelelő attribútumot kérdezi le.

    Példa 1.: a * directory* nevű adat konnektortól lekérdezi a "cn" attribútumot, majd ennek értékét az urn:mace:dir:attribute-def:cn attribútumban küldi el a másik félnek.

    <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn">
         <DataConnectorDependency requires="directory"/>
    </SimpleAttributeDefinition>
    

    Példa 2.: a directory nevű adat konnektortól lekérdezi a displayName attribútumot, majd ennek értékét az urn:mace:dir:attribute-def:<b>cn</b> (!) attribútumban küldi el a másik félnek.

    <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn" sourceName="displayName">
         <DataConnectorDependency requires="directory"/>
    </SimpleAttributeDefinition>
    

    Példa 3.: a (már korábban feloldott) urn:mace:dir:attribute-def:uid attribútumot (amennyiben az nem scope-olt) kiegészíti az "niif.hu" scope-pal, és ezt adja át urn:mace:dir:attribute-def:eduPersonPrincipalName néven. Ha viszont az uid értéke pl. valaki@valahol, akkor az átadott érték a valaki lesz, a scope pedig valahol.

    <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonPrincipalName" smartScope="niif.hu">
         <AttributeDependency requires="urn:mace:dir:attribute-def:uid"/>
    </SimpleAttributeDefinition>
    

    Részletes leírást lásd a Shibboleth wiki vonatkozó részében!

    CompositeAttributeDefinition

    TODO, lásd: https://spaces.internet2.edu/display/SHIB/CompositeAttributeDefinition

    RegExpAttributeDefinition

    TODO, lásd: https://spaces.internet2.edu/display/SHIB/RegExpAttributeDefinition

    ScriptletAttributeDefinition

    TODO, lásd: https://spaces.internet2.edu/display/SHIB/ScriptletAttributeDefinition

    SAML2PersistentID

    TODO, lásd: https://spaces.internet2.edu/display/SHIB/SAML2PersistentIDAttributeDefinition

    Tesztelés

    A Shibboleth IdP-hez tartozik egy resolvertest névre hallgató program, amellyel ellenőrizhetjük az attribútumok feloldását. Használatához először be kell állítani a telepítésnek megfelelően az IDP_HOME és a JAVA_HOME változókat.

    Példa: /usr/local/shibboleth-idp/bin/resolvertest --resolverxml=file:///etc/shibboleth-idp/resolver.ldap.xml --user=bajnokk

    <Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:xsi="ttp://www.w3.org/2001/XMLSchema-instance"
               AttributeName="urn:mace:dir:attribute-def:eduPersonOrgDN"
               AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
        <AttributeValue>o=niifi,o=niif,c=hu</AttributeValue>
    </Attribute>
    
    <Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               AttributeName="urn:mace:dir:attribute-def:uid"
               AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
        <AttributeValue>bajnokk</AttributeValue>
    </Attribute>
    
    <Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc)"
               AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName"
               AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
        <AttributeValue Scope="niif.hu">bajnokk</AttributeValue>
    </Attribute>
    

    Forrás

    SimpleSAMLphp_proxy_vidyo_portálhoz

    Vidyo Portal Authentication Proxy

    A vidyo portál utolsó fejlesztései lehetővé tették a SAML alapú authentikációt, és authorizációt.

    Az implementáció nem teljesen fedi le a SAML feature-öket, az SP implementáció csak egy IdP-vel képes kapcsolatot létesíteni.

    A portált a simpleSAMLphp proxy-ként való telepítésével tehetjük egy föderáció tagjává.

    simpleSAMLphp telepítése

    A simplesamlphp telepítését elvégezzük a dokumentáció szerint.

    SSP IdP oldalának konfigurálása, illesztés a Vidyo portál felé

    Legelőször is engedélyezni kell az IdP funkciót

    config/config.php

    'enable.saml20-idp' => true,
    

    Gyártsuk le az IdP certificate-jét, és rakjuk a cert könyvtárba idp.pem, illetve idp.crt néven.

    cd cert
    openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out idp.crt -keyout idp.pem
    

    metadata/saml20-idp-hosted.php

    'auth' => 'default-sp',
    'privatekey' => 'idp.pem',
    'certificate' => 'idp.crt',
    ),
    

    A vidyo portál admin felületéről le kell tölteni a portál metaadatát, és el kell menteni a metadata könyvtárba.

    metadata/vidyo-sp.xml
    

    Erre hivatkozni kell a config/config.php-ben is:

    'metadata.sources' => array(
        ...
        array('type' # > 'xml', 'file' > 'metadata/vidyo-sp.xml'), // vidyo sp
        ... ),
    

    Vidyo admin portál

    A portálon be kell állítani,

    Az előző fejezetben említett portál metaadatát ezen az oldalon érjük el. View Service Provider (SP) metadata XML Össze kell illeszteni a SAML rétegből jövő attribútumokat a Vidyo portál által használt adatmodellel. Edit IdP Attribute Mapping...

    VidyoAdmin1.png

    A SAML IdP Attribute Name oszlopokba az SSP-től kapott attribútum neveket kell írni. Ha a proxy IdP oldalán a példa szerint állítottuk be az AttributeMap szűrőt, akkor itt az attribútumok friendly nevét kell beírnunk. Tipp: https://github.com/simplesamlphp/simplesamlphp/blob/master/attributemap/name2oid.php

    VidyoAdmin2.png

    Bizonyos attribútumoknál lehetőség van érték mapping-re is, tipikusan csoport, vagy típus jellegű attribútumoknál, ahol a kapott attirbútumok értéke alapján történik a megfeleltetés.

    VidyoAdmin3.png

    SSP SP oldalának konfigurálása, illesztés a föderációba

    A proxy egyik oldala a föderáció felé, mint SP viselkedik. Az authsource-ot 'default-sp'-nek nevezzük el, erre kell hivatkozni a későbbiekben az IdP konfigurációban.

    A config/config.php file-ba

    Hogy a vidyo portál, és egyé authentikációs szűrők futtatásakor az attribútum megfeleltetéseknél ne okozzanak gondot az oid formátumú attribútum nevek, mielőtt kiadjuk őket, az AttributeMap szűrő segítségével alakítsuk át az attribútum neveket.

    config/config.php

    'authproc.sp' => array(
       ...
       200 # > array('class' > 'core:AttributeMap', 'oid2name'),
       ...
    ),
    

    Ha még nem tettük meg, rakjunk ide is certificate-et.

    cd cert
    openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out sp.crt -keyout sp.pem
    

    és könyveljük be a config/authsrouces.php -ba

    'default-sp' => array(
        'saml:SP',
     ...
        'privatekey'  => 'sp.pem',
        'certificate' => 'sp.crt',
     ...
    

    metadata

    Az SP-t regisztráljuk be a kívánt föderációba a föderáció által megadott szabályok alapján.

    metarefresh

    Hogy a metadadatok mindig napra készek legyenek, gondoskodjunk a metarefresh és cron modul beállításáról.

    A konfigurációs file-okat a config könyvtárba kell elhelyezni a sablonokat a modulok config-templates alkönyvtáraiban találjuk meg.

    A modulok bekapcsolásáról a rendszer konfigurációban rendelkezhetünk a legegyszerűbben.

    config/config.php

    'module.enable' => array(
            'cron' => TRUE,
            'metarefresh' => TRUE,
    ),
    

    OpenSSO_IdP_-_SimpleSAMLphp_SAML2_SP

    Cél

    OpenSSO hosztolt IdP és SimpleSAMLphp SP összekapcsolása a SAML2 protokoll segítségével.

    SimpleSAMLphp telepítése

    [[http://rnd.feide.no/content/installing-simplesamlphp]]

    Konfigurációs paraméterek (config/config.php)

    A következő paramétereket érdemes beállítani kezdésképp:

    secretsalt: egy titkos 32 bájtos véletlenszám, amit a titkosításhoz használni fog a simplesamlphp
    technicalcontact_name,email: az üzemeltető technikai kapcsolattartója
    logging_handler: file / syslog
    debug: bekapcsolva minden saml kérés és válasz megjelenik a webes felületen (kényelmes!)
    enable.saml20-sp, enable.saml20-idp, enable.shib13-sp, enable.shib13-idp
    default-saml20-idp: Discovery Service megkerülése és fix IdP választása
    

    IdP metaadat beállítása

    metadata/saml20-idp-remote.php:

    'https://idp.sch.bme.hu/niif-teszt' =>  array(
      'name'                                  =>      'NIIF Test at idp.sch.bme.hu',
      'description'                   => 'Log in via idp.sch.bme.hu',
      'SingleSignOnService'   =>      'http://maszat.sch.bme.hu:58080/opensso/SSORedirect/metaAlias/niif-teszt/idp',
      'SingleLogoutService'   =>      'http://maszat.sch.bme.hu:58080/opensso/IDPSloRedirect/metaAlias/niif-teszt/idp',
      'base64attributes'              =>      false,
      'request.signing' => false,
      'certificate' => "maszat-idp.crt",
      'certFingerprint' => "DE:F1:8D:BE:D5:47:CD:F3:D5:2B:62:7F:41:63:7C:44:30:45:FE:33",
      'saml2.relaxvalidation' => array('noattributestatement')
    )
    

    A cert könyvtárba mentsük le a maszat-idp.crt-t (például a maszat idp metaadatból kimásolva).

    A fenti konfiguráció HTTP/Redirect bindingot használ a SAML Requestre, a választ pedig HTTP/Post-on keresztül kapja. Fontos, hogy a base64attributes ki legyen kapcsolva, ugyanis az OpenSSO IdP nem kódolja base64-be az attribútumokat a SAML Response-ban.

    SP metaadat beállítása

    metadata/saml20-sp-hosted.php:

    'https://maszat.sch.bme.hu/simplesamlphp/sp/niif-teszt' => array(
      'host'  => 'maszat.sch.bme.hu',
    /*'privatekey' => 'server.pem',
      'certificate' => 'server.crt',
      'request.signing' => true,*/
      'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
    )
    

    Ezután a /simplesamlphp/saml2/sp/metadata.php?output=xml URL-en keresztül tudjuk elérni az SP metaadatot. Fontos, hogy ebben a generált metaadatban nem tükröződik pl. a signing certificate és a NameIDFormat beállítás, ezért ezeket kézzel kell beleszerkeszteni.

    Miután kijavítgattuk a metaadat fájlt, az OpenSSO adminfelület Federation -> Import Entity parancsával tudjuk importálni a megfelelő Realm-be. Importálás után a Circle of Trust konfigurációhoz is hozzá kell adni a SimpleSAMLphp SP-t.

    Problémák

    Nincsenek :)

    Shib2IdpInstall

    Előkészületek

    entityID

    Fontos, hogy az entityID egyedi és állandó legyen. Javasolt forma: https://idp.intezmenyneve.hu/idp/shibboleth.

    Tűzfal

    Be kell engedni a 443-as és a 8443-as portokat. Ha nagyon szigorúan vesszük, akkor a 8443-as portot elegendő csak a szóbajöhető SP-kről beengedni, de ezzel általában nem vagyunk tisztában, ezért célszerű a "nagyvilágból" beengedni. Biztonsági szempontból nem sok különbség van a 443-as és a 8443-as porton elérhető alkalmazások között.

    JDK

    Debian Lenny alatt a sun-java6-jdk csomagot kell feltelepíteni. Telepítés előtt érdemes az aptitude-ban kikapcsolni az opcionális függőségek telepítését.

    aptitude install sun-java6-jdk
    

    Állítsuk be, a JAVA_HOME környezeti változót!

    export JAVA_HOME=/usr/lib/jvm/java-6-sun
    

    !!! danger "Figyelem"

    Az `openjdk-6-jdk` csomag használata esetén ne felejtsük feltenni a `ca-certificates-java` csomagot, anélkül ugyanis hibát fogunk kapni az IdP indításakor!
    

    Shibboleth security provider

    !!! info

    A Shibboleth Security Provider csak akkor szükséges, ha a Java alkalmazásszerver (Tomcat) önállóan fog kéréseket feldolgozni és nem kerül elé proxy (Apache)
    

    Be kell másolni a lib/shib-jce-1.0.jar állományt a $JAVA_HOME/jre/lib/ext könyvtárba. Ha az ext/ könyvtár nem létezik, akkor hozzuk létre.

    cp lib/shib-jce-1.0.jar $JAVA_HOME/jre/lib/ext
    

    Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a $JAVA_HOME/jre/lib/security/java.security fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort:

    security.provider.7=edu.internet2.middleware.shibboleth.DelegateToApplicationProvider

    Bouncy Castle JCE

    !!! question "Bizonytalan információ!"

    Az alábbi leírás az 5-ös JVM-hez készült, 6-os JVM esetén erre nem biztos hogy szükség van.
    

    A JVM-mel jövő Java Cryptography Engine (JCE) nem támogatja az összes kriptográfiai algoritmust, amelyre az Identity Providernek szüksége lehet (pl. XML Digital Signature, XML Encryption). A Bouncy Castle JCE ezek mellett még olyan algoritmusokat is tartalmaz (általában hatékonyabb és szabványosabb formában), amelyek benne vannak a Java JCE-ben.

    Ehhez először le kell tölteni a Bouncy Castle JCE-t. A JCE állományok a Provider oszlopban, a "Signed Jar Files" részben találhatók. (A nevük bcprov-jdk-VERZIO.jar.) Letöltés után a .jar fájlokat a $JAVA_HOME/jre/lib/ext könyvtárba kell tenni.

    wget http://www.bouncycastle.org/download/bcprov-jdk15-141.jar
    cp bcprov-jdk15-141.jar $JAVA_HOME/jre/lib/ext
    

    Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a $JAVA_HOME/jre/lib/security/java.security fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort:

    security.provider.8=org.bouncycastle.jce.provider.BouncyCastleProvider

    Tomcat 6

    A 2.1.3 és újabb IdP megköveteli a Tomcat6 használatát (Tomcat5.5 -tel bizonyos böngészők esetén nem működik rendesen). A Debian Lenny nem tartalmazza a Tomcat6-ot, ezért a testing ágból kell feltelepíteni.

    A Tomcat6-ra való frissítésről további - vázlatos - információkkal ez az oldal szolgál.

    Telepítés

    Ha minden rendben meg, és a squeeze source beállításra került, akkor elegendő egy

    aptitude install tomcat6
    

    parancs kiadása. Ez felpakolja a tomcat különböző függőségeit is - az ajánlott függőségek (tomcat6-admin, -docs, stb.) feltelepítése nem szükséges.

    Ne felejtsük el, hogy a Tomcat szerver "tomcat6" user nevében fog futni! Mivel a Shibboleth servletnek szüksége van arra, hogy hozzáférjen a filerendszerhez, a Java Security Manager-t ki kell kapcsolni a /etc/default/tomcat6 fájlban:

    TOMCAT6_SECURITY=no
    

    Ahhoz, hogy a Tomcat számára üzembiztosan elegendő memóriát biztosítsunk, ugyanebbe a fájlba ( /etc/default/tomcat6 ) adjuk meg:

    JAVA_OPTS="-Xms256M -Xmx512M -XX:-DisableExplicitGC "
    

    Beállítás

    A /etc/tomcat6/server.xml fájlt kell szerkesztenünk

    Ha a Tomcat Apache mögött fut

    A 8009-es porton figyelő Connector elem konfigurációjához hozzá kell adni, hogy a tomcatAuthentication értéke "false" legyen, ezen kívül a hozzáférést korlátozhatjuk a localhost-ra is (hiszen a Connector-t csak a helyben futó Apache mod_proxy_ajp konnektora érheti el).

    <Connector port="8009" address="127.0.0.1" tomcatAuthentication="false"
                   enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
    

    Ha a Tomcat önállóan, Apache nélkül fut

    Ha a Tomcat Apache nélkül fut, akkor be kell állítani, hogy az SP-vel való kommunikációra fenntartott 8443-as porton egyből a Tomcat figyeljen.

    <Connector port="8443"
               maxHttpHeaderSize="8192"
               maxSpareThreads="75"
               scheme="https"
               secure="true"
               clientAuth="want"
               SSLEnabled="true"
               sslProtocol="TLS"
               keystoreFile="IDP_HOME/credentials/idp.jks"
               keystorePass="PASSWORD"
               truststoreFile="IDP_HOME/credentials/idp.jks"
               truststorePass="PASSWORD"
               truststoreAlgorithm="DelegateToApplication"/>
    

    Ahol az IDP_HOME az IdP alapkönyvtára, a PASSWORD pedig az IdP telepítésekor megadandó jelszó lesz.

    !!! info

    Amennyiben a Tomcat önállóan fut, szükség van a Shibboleth Security Provider telepítésére!
    

    További információ angolul

    Apache beállítás

    Tanúsítványok beszerzése és bemásolása /etc/ssl vonatkozó alkönyvtárai alá.

    Meg kell adni, hogy az Apache figylejen a 443-as és 8443-as portokon. Az alábbiak kerüljenek a /etc/apache2/ports.conf fájlba

    Listen 443
    Listen 8443
    

    SSO URL (443-as port)

    Be kell állítani a virtuális hosztot, amelyhez az IdP-t rendeltük. Először a 443-as portot konfiguráljuk.

     <VirtualHost _default_:443>
       ServerName aai.example.org:443
       SSLEngine On
       SSLCertificateFile /etc/ssl/certs/aai.example.org.crt
       SSLCertificateKeyFile /etc/ssl/private/aai.example.org.key
       SSLCertificateChainFile /etc/ssl/certs/aai.example.org.crt
       ProxyRequests Off
       <Proxy ajp://localhost:8009>
         Allow from all
       </Proxy>
       ProxyPass /idp ajp://localhost:8009/idp retry=5
     </VirtualHost>
    

    Ezen a porton valamilyen széles körben ismert tanúsítványt kell használni, mivel a felhasználók böngészőjének ismerniük kell(ene) a kibocsátót.

    AA ill. Artifact (8443-as port)

    Ezen keresztül az SP és az IdP közvetlenül kommunikálnak egymással. Ide arra a tanúsítványra van szükség, amely a föderációs metadatában szerepel - az aláírója nem érdekes.

    A csatorna felépítésekor az IdP és az SP is autentikálja magát. Az SP autentikációját az Apache végzi, ami nem végez kibocsátó-ellenőrzést (optional_no_ca). Ez utóbbit az IdP alkalmazás végzi el, ezért nagyon fontos, hogy a kliens tanúsítványát az Apache továbbadja az alkalmazásnak (ExportCertData).

    !!! danger "Figyelem"

    Az Apache a tanúsítvány-ellenőrzésnél ellenőrzi a tanúsítvány típusát. Ezért az SP tanúsítványának vagy kliens tanúsítványnak kell lennie, vagy nem lehet benne típus információ.
    
     <VirtualHost _default_:8443>
       ServerName aai.example.org:8443
       SSLEngine On
       SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:!SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
       SSLCertificateFile /etc/ssl/certs/aai-aa.example.org.crt
       SSLCertificateKeyFile /etc/ssl/private/aai-aa.example.org.key
       SSLVerifyDepth 10
       SSLVerifyClient optional_no_ca
       SSLOptions -StdEnvVars +ExportCertData
       ProxyRequests Off
       <Proxy ajp://localhost:8009>
         Allow from all
       </Proxy>
       ProxyPass /idp ajp://localhost:8009/idp retry=5
     </VirtualHost>
    

    A virtuális hoszt engedélyezése után be kell tölteni az ssl és proxy_ajp modulokat, majd újra kell indítani az apache-ot.

    Shibboleth 2.x IdP servlet telepítés

    Letöltés

    A hivatalos IdP kiadás innen innen tölthető le

    Alternatívaként az NIIF által patchelt, ezáltal SLO képes IdP kiadást ajánljuk, ami a NIIF AAI oldalról érhető el. A Single Logout-képes IdP-ről további információ itt.

    Kicsomagolás

    A shibboleth-idp-2.x.x-bin.zip fájl tartalma kicsomagolás után a /usr/local/shibboleth-idp könyvtár alákerül

    cd /usr/local
    jar -xf shibboleth-idp-2.x.x-bin.zip
    

    Endorsed jar állományok

    Sajnos - legalábbis a cikk írásakor - a "kincstári" Sun-os Tomcat (Java?) JAXP parser egy ismert memóriaszivárgást tartalmaz, ezért a disztribúcióban az endorsed/ könyvtárban található .jar file-okat kézzel be kell másolni a Tomcat endorsed/ könyvtárába.

    Installer

    export JAVA_HOME=/usr/jdk
    cd /usr/local/shibboleth-idp
    chmod 755 install.sh
    ./install.sh
    

    A telepítés során az alábbi kérdésekre kell választ adnunk:

    Is this a new installation? Answering yes will overwrite your current configurat ion. [yes|no] yes

    Új telepítés, vagy sem.

    Where should the Shibboleth Identity Provider software be installed? / opt/shibboleth-idp-2.0.0 /usr/local/shobboleth-idp

    Itt található a letöltött és kicsomagolt shibboleth programcsomag

    What is the hostname of the Shibboleth Identity Provider server? idp.example.org idp.example.org

    Shibboleth IdP alkalmazás URI alapú azonosítója.

    A keystore is about to be generated for you. Please enter a password that will be used to protect it. changeme

    Feljegyzendő jelszó :)

    Befejezés

    Környezeti változó beállítása

    IDP_HOME=/usr/local/shibboleth-idp
    export IDP_HOME
    

    Szimbolikus linkek megadása - az egyértelműség és konvenció kedvéért...

    mv $IDP_HOME/conf /etc/`basename $IDP_HOME`
    ln -s /etc/`basename $IDP_HOME` $IDP_HOME/conf
    mv $IDP_HOME/logs /var/log/`basename $IDP_HOME`
    ln -s /var/log/`basename $IDP_HOME` $IDP_HOME/logs
    mkdir /var/lib/`basename $IDP_HOME`
    mv $IDP_HOME/metadata /var/lib/`basename $IDP_HOME`/metadata
    ln -s /var/lib/`basename $IDP_HOME`/metadata $IDP_HOME/metadata
    

    Jogosultságok beállítása - hogy a tomcat6 felhasználó hozzáférhessen az alábbi könyvtárakhoz

    chown -R tomcat6 /var/log/`basename $IDP_HOME` /var/lib/`basename $IDP_HOME`
    

    További, már telepített IdP-től függő tomcat beállítás

    cd /var/lib/tomcat6/
    mkdir -p conf/Catalina/localhost
    

    Az így létrehozott könyvtárban készítsünk egy idp.xml nevű (a név legyen azonos a idp webalkalmazás nevével) fájlt az alábbi tartalommal:

    <Context
            docBase="/usr/local/shibboleth-idp/war/idp.war"
            privileged="true"
            antiResourceLocking="false"
            antiJARLocking="false"
            unpackWAR="false" />
    

    Naplófájlok rotálása

    Az alapértelmezett logging.xml nem törli a régi állományokat, ezért ezek egy idő után megtöltik a diszket.

    Erre a korrekt megoldás az (lenne), ha a Logback alrendszert utasítjuk, hogy az N (a példában 90) napnál régebbi fájlokat rotálja ki. Ehhez a logging.xml-ben adjuk meg a maxHistory paramétert az összes rollingPolicy-nál, valahogy így:

     <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
       <FileNamePattern>/usr/local/shibboleth-idp/logs/idp-access-%d{yyyy-MM-dd}.log</FileNamePattern>
       <maxHistory>4</maxHistory>
     </rollingPolicy>
    

    Sajnos azonban jelenleg a logback csak egy állományt töröl, a régi file-okat megtartja (pl. akkor is, ha több, mint egy napig nem futott az IdP. Amíg ez nincs megoldva, addig kerülő megoldás lehet cron-ból törölni a régi file-okat

    sudo crontab -u tomcat6 -e
    
    MAILTO=mail@example.com
    #m h  dom mon dow   command
    52 18 *   *   *     find /var/log/shibboleth-idp/ -mtime +90 -delete
    

    Teszt

    Ahhoz, hogy kiderítsük, működik-e (ill. fut-e :) ) az IdP webalkalmazásunk, ahhoz böngészőben hívjuk meg az alábbi urlt: https://idp.example.org/idp/profile/Status, amennyiben az oldalon egy ok-t látunk, akkor az alkalmazásunk fut, és elkezdhetjük beállítani az attribútumok feloldását és kiadását.

    Ha nem működik a webalkalmazás, akkor az alábbi naplófájlokban kezdjünk el keresgélni:

    A naplózás mélységét a /etc/shibboleth/logging.xml fájlban állíthatjuk be. Hibakereséshez érdemes a <ErrorLog> értékét DEBUG-ra állítani.

    Shibboleth 2.0 IdP beállítás

    Metadata beállítása

    Metadata aláírás ellenőrzés beállítása

    Az IdP-be beállított metaadat(ok) valódiságának ellenőrzéséhez szükséges egy ún. TrustEngine beállítása. Ezt a relying-party.xml -ben kell megtenni a Security Configurations részben:

    	<security:TrustEngine
    	   id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
    	 <security:Credential id="HREFSigner" xsi:type="security:X509Filesystem">
    	  <security:Certificate>/path/to/idp/credentials/href-metadata-signer-2011.crt</security:Certificate>
    	 </security:Credential>
    	</security:TrustEngine>
    

    A konfigurációban hivatkozott href-metadata-signer-2011.crt elérhető innen: https://metadata.eduid.hu/href-metadata-signer-2011.crt, SHA-1 lenyomata a következő: FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66

    HREF föderációs metadata beállítása az IdP-ben

    A HREF metadata állomány elérhetősége:

    A Shibboleth IdP relying-party.xml konfigurációban a következőképpen lehet beállítani a HREF metaadatot (fontos hogy az előző pontban leírt TrustEngine is be legyen állítva):

    	<MetadataProvider id="HREF-Metadata"
    	     xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
    	     metadataURL="http://metadata.eduid.hu/current/href.xml"
    	     backingFile="/path/to/idp/metadata/href.xml"
    	     maxRefreshDelay="PT1H">
    	  <MetadataFilter xsi:type="SignatureValidation" trustEngineRef="shibboleth.MetadataTrustEngine" />
    	</MetadataProvider>
    

    Tovább a föderációba

    Amennyiben a telepítendő IdP-t szeretnénk a HREF-be integrálni, úgy ennél a pontnál küldjünk egy levelet az aai@niif.hu címre, amely nyomán, ha minden rendben van, az IdP regisztrálásra kerül a Resource Registry-ben, s a válasz e-mail tartalmaz majd két hivatkozást, melyekről letölthetők az attribute-filter.xml és attribute-resolver.xml fájlok. Ezek már testreszabva tartalmazzák az IdP igényeit, az első fájlt elég csak bemásolni, a másodikban pedig - értelemszerűen - az egyes, a helyi erőforrásokra vonatkozó felhasználóineveket és jelszavakat kell kicserélni a megfelelőre.

    További információk a Resource Registry-be történő felvételről

    Attribútum filter automatikus frissítése A Resource Registry automatikusan generálja minden egyes föderációban szereplő IdP számára a saját, testre szabott attribútum filterét, így célszerű úgy beállítani az IdP-t, hogy ezt a fájlt automatikusan töltse le. Ehhez hozzunk létre egy confcache nevű könyvtárat, adjunk rá írásjogot a tomcat6 felhasználónak, majd szerkesszük a conf/service.xmlfájlt. Az XML felső harmadában kerül megadásra az AttributeFilterEngine, melyet az alábbiak alapján kell átírni.

    	<Service id="shibboleth.AttributeFilterEngine"
    	       xsi:type="attribute-afp:ShibbolethAttributeFilteringEngine"
    	       configurationResourcePollingFrequency="3600000"
    	       configurationResourcePollingRetryAttempts="128">
    	      <ConfigurationResource url="https://rr.aai.niif.hu/gen_attribute-filter.php/href/IDP_NEVE_AZ_RRBEN/attribute-filter.xml"
    	                             file="/path/to/shibboleth-idp/confcache/attribute-filter.xml" xsi:type="resource:FileBackedHttpResource" />
    	</Service>
    

    Több attribútum filter használata Hasznos lehet, ha a föderációs szűrőkön kívül további irányokba kívánunk IdP-nkből attribútumokat kiadni. Elterjedt, hogy pl. különböző google szolgáltatásokhoz lehet az intézményen keresztül autentikálni, amely beállítási részleteket értelemszerűen a Resource Registry nem tartalmazza, így a letöltött friss, és a régi, helyi adatokat is tartalmazó fájlok egyesítése bosszantó plusz munka lehet. Ezt elkerülendd dolgozhatunk több attribútum filterfájlból. Ehhez ismét a conf/service.xml fájlt kell szerkeszteni. Alább a fenti kódrészlet kiegészítése.

    	<Service id="shibboleth.AttributeFilterEngine"
    	       xsi:type="attribute-afp:ShibbolethAttributeFilteringEngine"
    	       configurationResourcePollingFrequency="3600000"
    	       configurationResourcePollingRetryAttempts="128">
    	      <ConfigurationResource url="https://rr.aai.niif.hu/gen_attribute-filter.php/href/IDP_NEVE_AZ_RRBEN/attribute-filter.xml"
    	                             file="/path/to/shibboleth-idp/confcache/attribute-filter.xml" xsi:type="resource:FileBackedHttpResource" />
    	      <ConfigurationResource file="/path/to/shibboleth-idp/conf/attribute-filter-local.xml" xsi:type="resource:FilesystemResource" />
    	</Service>
    

    Ezek a lépések természetesen kihagyhatók, ha nincs szándékunkban a föderáció tagjaivá válni, ekkor érdemes az alább részletezett attribútumokhoz kapcsolódó tudnivalókkal folytatni.

    Statisztika küldés

    Autentikáció beállítása

    Attribútum feloldás beállítása

    Attribútum kiadás beállítása

    HREFServices

    Föderációs Szolgáltatások

    Tagi Szolgáltatások

    A Tag az alábbi szolgáltatásokat regisztrálhatja a Föderációba:

    Partner Szolgáltatások

    A Partner az alábbi szolgáltatásokat regisztrálhatja a Föderációba:

    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

    Attributes are travelling on the wire in eduGAIN-defined format, ie. SAML. Naming attributes and defining their contents might be a standardization task of eduGAIN operators; however it should be possible for federations to agree on custom set of attributes beyond "eduGAIN commons".

    Attribute Conversion only adds attributes (or values) to the attribute set; use Attribute Filtering for filtering out unnecessary attributes. It also means that if no rules match an attribute, then it will go to the filter unmodified - so conversion works with a default by-pass policy.

    Attribute conversion rule concepts

    Most of the rules are based on standard regular expressions and Unified Expression Language.

    Each rule works on the actual attribute set which is not necessarily the initial set, as each rule can alter the set (ie. by changing values or names, adding new attributes to the set). This means that the order of the rules is important.

    Every rule consists of two parts: condition and action. The condition element is used to determine whether this particular rule is to be processed or not. Thus, the rule action is only processed when all the conditions are met (a rule without any conditions is processed by default).

    The condition engine now only supports regular expression -based matching rules. There are three types of matching rules

    The rule's action is to create new attributes (or to modify existing ones). Please refer to the detailed BasicRule, MergeRule, SplitRule documentation below.

    Attribute conversion rule types

    BasicRule

    The Basic rule is the simplest attribute conversion rule type. It can create one attribute and optionally use one attribute and regular expressions to transform attribute values.

    Basic Rule can create static attributes. You can achieve this by omitting the Condition node. The replaceValues parameter is true by default, so if you want to append values to (probably) existing attributes, you must declare it using replaceValues="false". Also note that you can use multiple AttributeValue nodes.

    <BasicRule>
      <Description>Create static attribute (or append to existing if attribute with this name already exists)</Description>
      <Attribute attributeName="eduPersonScopedAffiliation" replaceValues="false">
        <AttributeValue>staff@niif.hu</AttributeValue>
        <AttributeValue>member@href.hu</AttributeValue>
      </Attribute>
    </BasicRule>
    

    The next rule is using remote provider matching to determine whether the remote side has an identifier of 'urn:geant:edugain:be:' and any Hungarian domain appended to it.

    <BasicRule>
      <Description>Create static attribute for some remote providers</Description>
      <Condition>
        <RemoteProviderMatch>^urn:geant:edugain:be:[^:]+\.hu$</RemoteProviderMatch>
      </Condition>
      <Attribute attributeName="homeOrganization">
        <AttributeValue>niif.hu</AttributeValue>
      </Attribute>
    </BasicRule>
    

    This example shows how to rename an attribute without converting its values. Note that you must use AttributeMatch without regular expressions to achieve this.

    <BasicRule>
      <Description>Rename attribute uid to edupersonPrincipalName</Description>
      <Condition>
        <AttributeMatch attributeName="uid"/>
      </Condition>
      <Attribute attributeName="edupersonPrincipalName">
        <AttributeValue>${uid}</AttributeValue>
      </Attribute>
    </BasicRule>
    

    The next example demonstrates the use of regular expression matching groups.

    <BasicRule>
      <Decription>Transform 'o=org,c=country'-style OrgDN to DNS-based homeOrganization</Decription>
      <Condition>
        <AttributeMatch attributeName="edupersonOrgDN" id="regex">o=(.*),c=(.*)</AttributeMatch>
      </Condition>
      <Attribute attributeName="homeOrganization">
        <AttributeValue>${regex[1]}.${regex[2]}</AttributeValue>
      </Attribute>
    </BasicRule>
    

    This last example needs some more explanation. When you want to reference the regular expression matching groups (enclosed by parentheses), you must define the reference name with the 'id' parameter of AttributeMatch. Then, use ${id[0] to refer to the whole regular expression match (ie. the whole attribute value), and ${id[0]} to refer to the Nth. matching group of the regular expression. !!! info

    You cannot reference regular expressions from another rule.
    

    MergeRule

    The merge rule can merge two or more attributes into one. The attributes whose values you want to merge is declared using the InputAttribute node. You can also use the condition node, but only with RemoteProviderMatch and LocalProviderMatch (AttributeMatch is ignored).

    This example shows how to combine two attribute values:

    <MergeRule>
      <Description>Merges the uid and homeOrganization to edupersonPrincipalName</Description>
      <InputAttribute attributeName="homeOrganization" />
      <InputAttribute attributeName="uid" />
      <Attribute attributeName="edupersonPrincipalName" replaceValues="true">
        <AttributeValue>${uid}@${homeOrganization}</AttributeValue>
      </Attribute>
    </MergeRule>
    

    You can also use regular expressions, as with BasicRule.

    SplitRule

    The SplitRule is very similar to the MergeRule, the only difference is that the SplitRule contains one InputAttribute and more Attribute nodes.

    <SplitRule>
      <Description>Split the edupersonScopedAffiliation to edupersonAffiliation and homeOrganization</Description>
      <InputAttribute attributeName="edupersonScopedAffiliation" id="scopedAffiliation" >^([^@]+)@(.+)$</InputAttribute>
      <Attribute attributeName="edupersonAffiliation">
        <AttributeValue>${scopedAffiliation[1]}</AttributeValue>
      </Attribute>
      <Attribute attributeName="homeOrganization">
        <AttributeValue>${scopedAffiliation[2]}</AttributeValue>
      </Attribute>
    </SplitRule>
    

    CustomRule

    If you need to create new attributes from program (eg. appending generated identifiers), you can use the CustomRule type.

    <CustomRule className="org.test.MyCustomRuleImpl">
      <Configuration>
        <!-- any xml here -->
      </Configuration>
    </CustomRule>
    

    CustomRule class must implement the net.geant.edugain.attributes.rules.Rule interface, configuration can be read with the DOM API. Please refer to the Attribute Converter JavaDOC, and see the test package as it contains a sample implementation.

    Negating matches

    If your federation has optional attributes then sometimes it is desirable to process rules only if a particular attribute does not exist. Therefore it is possible to append a negate boolean attribute (setting it to true) to the <*Match> nodes (inside the <Condition> element) to revert the match. It means that the rule is only processed if there is no match for the given value.

    The following example creates preferredLanguage only if it is not set by the IdP (or by the peer's home bridging element):

    <BasicRule>
      <Decription>Create preferredLanguage only if source has not supplied it</Decription>
      <Condition>
        <AttributeMatch attributeName="preferredLanguage" negate="true"/>
      </Condition>
      <Attribute attributeName="preferredLanguage">
        <AttributeValue>hu, en-gb;q=0.8, en;q=0.7</AttributeValue>
      </Attribute>
    </BasicRule>
    

    Using attribute name mapper

    For interoperability, SAML AttributeStatement carries attribute names with URN-style attribute naming scheme. For example, the 'mail' logical attribute name can be named as 'urn:mace:dir:attribute-def:mail', or 'urn:oid:0.9.2342.19200300.100.1.3'. Shibboleth2 further encourages federations to use the latter form (ie. the LDAP oid).

    The eduGAIN Attribute Converter library comes with an attribute name mapping subsystem. With the help of the attribute name mapper, system administrators can write the attribute converter configuration independently of the currently used attribute name format in AttributeStatement.

    Attribute name mapper concepts

    As the attribute conversion sits between two federations (and probably two attribute naming schemes), there are two types of physical attributes: the 'input' and 'output' attributes. Note that these notation is different in Home and Remote BEs: Home BE releases attributes to the eduGAIN federation, Remote BE releases attributes to the local federation. So the eduGAIN format is the 'output' attribute format of the Home BE, and the 'input' format of the Remote BE.

    The following example shows the difference between logical and physical attribute names.

    Physical input attribute name Logical attribute name Physical output attribute name
    urn:mace:dir:attribute-def:mail mail {: rowspan="2"} urn:mace:dir:attribute-def:mail {: rowspan="2"}
    urn:oid:0.9.2342.19200300.100.1.3 &#8288 {: style="padding:0"} &#8288 {: style="padding:0"}

    Configuration of the attribute name mapper

    The configuration xml of the attribute name mapper consists of one or more AttributeDefinition nodes. Each AttributeDefinition node specifies one logical attribute name (called 'id') and one physical AttributeName - which is the physical 'output' attribute name format. You can also specify AttributeNamespace (for SAML1.0).

    The 'input' attribute names are configured using the 'Attribute' node. Note that the output name is also interpreted as input name, so it is not necessary to declare it twice.

     <AttributeDefinition
      Id="mail"
      AttributeName="urn:mace:dir:attribute-def:mail">
       <Attribute AttributeName="urn:oid:0.9.2342.19200300.100.1.3" />
     </AttributeDefinition>
    

    Using logical attribute names

    When attribute name is referenced in a conversion rule, attribute mapper tries to interpret it as logical attribute name. Note that the logical attribute names are case-insensitive.

    Using SAML1.1 Namespaces

    EduGAIN Bridging Elements use SAML1.1 as communication protocol. SAML1.1 forces the use of Attribute NameSpace. You can specify the exact namespace in the attribute name mapping configuration using the 'AttributeNameSpace' attribute (with both the AttributeDefinition and Attribute nodes). When you use AttributeNameSpace, the input matching considers two attributes with the same name but different namespace different. The output attributes will contain the namespace information.

    Attribute Filtering

    Concepts

    At Home BE, Filtering normally gets its incoming attribute set from Conversion; at Remote BE, it gets incoming attributes from the other bridging element.

    From a technical viewpoint, Attribute Filtering is just a Rule extension to Conversion, so you can use most of the features of Converter, especially regular expressions and matching conditions. One major difference is that only explicitly allowed attributes can pass through, so you have to list all the attributes that you want to support in eduGAIN.

    Filter uses name mappers in the same way as Converter. So you should define your attributes there before you start using 'friendly' attribute names here.

    Allowing and denying attributes

    Three main rules of the filtering:

    1. Default action is to deny ALL attributes.
    2. You can allow/deny whole attributes or specific values of the attributes.
    3. The first rule decides. If you allowed something, you can not deny it later and vice versa. So start with the special rules and leave the generic rules to the end.

    You can allow an attribute by using <AllowAttribute> element and deny it with <DenyAttribute>. Each element can optionally have child elements <AttributeValue>, which means that the action is only performed on certain values of the attribute.

    !!! info

    An attribute is removed from the set if its last value is removed. It means that it's not possible to pass through attributes without at least one value.
    

    Using conditions

    You can use the <Condition> node in a filter rule just like with converter. The syntax is the same. So if you omit the Condition element then the rule is evaluated unconditionally.

    There is one slight difference: in FilterRule, AttributeMatch is always evaluated on the original input attribute set. It means that you can reference attributes in conditions even if they were allowed or denied before. (This is what you would normally expect, though.)

    You can allow or deny multiple attributes within one <FilterRule>. Note that the rule only applies if all the conditions within its <Condition> element evaluate to true.

    Examples

    <?xml version="1.0" encoding="UTF-8"?>
    <AttributeFilter  xmlns='urn:geant:edugain:attribute-mangling:1.0'
       xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
       xsi:schemaLocation='urn:geant:edugain:attribute-mangling:1.0 AttributeMangling.xsd'>
    
       <FilterRule>
           <Description>Unconditional allowing and denying. The main rule is to deny ALL attributes.</Description>
           <AllowAttribute attributeName="mail" />
           <AllowAttribute attributeName="cn" />
           <AllowAttribute attributeName="eppn" />
           <DenyAttribute attributeName="userPassword" />
           <DenyAttribute attributeName="uid" />
           <DenyAttribute attributeName="homeOrganization" />
           <AllowAttribute attributeName="schacHomeOrganization" />
       </FilterRule>
    
       <FilterRule>
           <Description>Use conditions - allow only specific attribute values</Description>
           <Condition>
               <LocalProviderMatch>^urn:.*\.hu$</LocalProviderMatch>
           </Condition>
           <AllowAttribute attributeName="eduPersonEntitlement">
               <AttributeValue>^.*@.*\.hu$</AttributeValue>
           </AllowAttribute>
       </FilterRule>
    
       <FilterRule>
           <Description>Use conditions - reference any attribute</Description>
           <Condition>
               <AttributeMatch attributeName="homeOrganization">niif.hu</AttributeMatch>
           </Condition>
           <AllowAttribute attributeName="eduPersonEntitlement">
               <AttributeValue>^.*@niif\.hu$</AttributeValue>
           </AllowAttribute>
       </FilterRule>
    
    </AttributeFilter>
    

    Integration

    You can integrate Attribute Conversion and Filtering into your Bridging Element by using these java code snippets. (Of course, edugain.jar and converter.jar need to be placed on the classpath.)

    Initialization time

    This code needs to be invoked in BE initialization time (and not in runtime, as XML configuration parsing is a time-consuming process).

      // get a reference to the AttributeConverterFactory singleton object
      AttributeConverterFactory factory = AttributeConverterFactory.getInstance();
      // set the configuration file paths (which paths can be set in web.xml for example)
      factory.setAttributeConverterFilePath("path-to-converter.xml");
      factory.setAttributeFilterFilePath("path-to-filter.xml");
      factory.setAttributeNameMapperFilePath("path-to-namemapper.xml");
    
      // create converter and filter objects
      try {
        AttributeConverter converter = factory.createAttributeConverter();
        AttributeFilter filter = factory.createAttributeFilter();
      } catch (ConfigurationException ex) {
        // handle configuration errors (missing files, not valid xmls and more issues)
        log.error(ex);
      }
    

    Runtime

    This code is invoked in BE runtime. You should have a List of AttributeValues, which was either received from the IdP or from the H-BE. You will get the output attribute set after invoking process() method. Note that process() takes two more arguments: remote and local. These represent the local and remote peers that your BE bridges together. Use of these identifiers is optional, you can pass null.

    !!! danger "Figyelem"

    If you do not pass `local` or `remote` then rules containing `LocalProviderMatch` or `RemoteProviderMatch` will **NOT** be executed.
    
      String remote = "remote-federation-peer-identifier";
      String local = "local-federation-peer-identifier";
    
      // get Attributes from the assertion
      List<AttributeValues> input = ...;
    
      // Call converter and filter in order.
      // Home BE should call converter first, remote BE should call filter first.
      if (isHomeBE) {
        List<AttributeValues> output = converter.process(input, remote, local);
        output = filter.process(output, remote, local);
      } else {
        List<AttributeValues> output = filter.process(input, remote, local);
        output = converter.process(output, remote, local);
      }
    
      // process output here, create new assertion, etc.
    

    Testing

    XMLTest.sh

    Attribute conversion library comes with XML-based test framework. The test can be invoked by the net.geant.edugain.attributes.xmltest.AttributeConverterTest main class. There is the XMLTest.sh script attached to the project, which makes it easy to execute the testing framework.

    $ ./XMLTest.sh
    
    Attribute Converter Test usage
    
    java AttributeConverterTest
      [-debug]
      [AttributeConverter.xml](-converterconfig)
      [AttributeFilter.xml](-filteringconfig)
      [AttributeNameMapping.xml](-attributenameconfig)
      [output.xml](-output)
      input.xml
    

    Example test configuration

    The xmltest/ directory contains the following examples

    AttributeNameMapper.xml converter name mapper configuration

    <?xml version="1.0" encoding="UTF-8"?>
    <AttributeMapper
       xmlns='urn:geant:edugain:attribute-mapper:1.0'>
    
        <AttributeDefinition
        Id="mail"
        AttributeName="urn:mace:dir:attribute-def:mail">
            <Attribute AttributeName="urn:oid:0.9.2342.19200300.100.1.3" />
        </AttributeDefinition>
    
        <AttributeDefinition
        Id="edupersonAffiliation"
        AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation" />
    
        <AttributeDefinition
        Id="homeOrganization"
        AttributeName="urn:mace:dir:attribute-def:homeOrganization" />
    
        <AttributeDefinition
        Id="cn"
        AttributeName="urn:mace:dir:attribute-def:cn">
            <Attribute AttributeName="urn:oid:2.5.4.3"/>
        </AttributeDefinition>
    </AttributeMapper>
    

    AttributeConverter.xml converter configuration

    <?xml version="1.0" encoding="UTF-8"?>
    <AttributeConverter
       xmlns='urn:geant:edugain:attribute-mangling:1.0'>
        <BasicRule>
            <Description>Create static attribute</Description>
            <Attribute attributeName="eduPersonAffiliation" replaceValues="false">
                <AttributeValue>staff@niif.hu</AttributeValue>
            </Attribute>
        </BasicRule>
        <BasicRule>
            <Description>Create static attribute for some remote providers</Description>
            <Condition>
                <RemoteProviderMatch>^urn:geant:edugain:be:[^:]+\.hu$</RemoteProviderMatch>
            </Condition>
            <Attribute attributeName="homeOrganization">
                <AttributeValue>niif.hu</AttributeValue>
            </Attribute>
        </BasicRule>
        <MergeRule>
            <Description>Merges the common name to the email address(es)</Description>
            <InputAttribute attributeName="cn" />
            <InputAttribute attributeName="mail" />
            <Attribute attributeName="mail" replaceValues="true">
                <AttributeValue>${cn} &lt;${mail}&gt;</AttributeValue>
            </Attribute>
        </MergeRule>
    </AttributeConverter>
    

    AttributeTest.xml test input xml

    <?xml version="1.0" encoding="UTF-8"?>
    <AttributeTest
       xmlns='urn:geant:edugain:attribute-test:1.0'
       Remote="urn:geant:edugain:be:niif.hu" >
        <Attribute AttributeName="urn:oid:0.9.2342.19200300.100.1.3">
            <AttributeValue>adam.lantos@niif.hu</AttributeValue>
            <AttributeValue>hege@niif.hu</AttributeValue>
        </Attribute>
        <Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation">
            <AttributeValue>staff</AttributeValue>
        </Attribute>
        <Attribute AttributeName="urn:oid:2.5.4.3">
            <AttributeValue>Adam Lantos</AttributeValue>
        </Attribute>
    </AttributeTest>
    

    Output of the example

    $ ./XMLTest.sh \
      -converterconfig xmltest/AttributeConverter.xml \
      -attributenameconfig xmltest/AttributeNameMapper.xml \
      xmltest/AttributeTest.xml
    
    AttributeConverter.<init> (80) : Creating new rule: class net.geant.edugain.attributes.rules.BasicRule
    AttributeConverter.<init> (81) : Rule Description: Create static attribute
    AttributeConverter.<init> (80) : Creating new rule: class net.geant.edugain.attributes.rules.BasicRule
    AttributeConverter.<init> (81) : Rule Description: Create static attribute for some remote providers
    AttributeConverter.<init> (80) : Creating new rule: class net.geant.edugain.attributes.rules.MergeRule
    AttributeConverter.<init> (81) : Rule Description: Merges the common name to the email address(es)
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <AttributeTest xmlns="urn:geant:edugain:attribute-test:1.0">
       <Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation">
           <AttributeValue>staff</AttributeValue>
           <AttributeValue>staff@niif.hu</AttributeValue>
       </Attribute>
       <Attribute AttributeName="urn:mace:dir:attribute-def:mail">
           <AttributeValue>Adam Lantos &amp;lt;adam.lantos@niif.hu&amp;gt;</AttributeValue>
           <AttributeValue>Adam Lantos &amp;lt;hege@niif.hu&amp;gt;</AttributeValue>
       </Attribute>
       <Attribute AttributeName="urn:mace:dir:attribute-def:homeOrganization">
           <AttributeValue>niif.hu</AttributeValue>
       </Attribute>
       <Attribute AttributeName="urn:mace:dir:attribute-def:cn">
           <AttributeValue>Adam Lantos</AttributeValue>
       </Attribute>
    </AttributeTest>
    

    Real-life examples

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

    Please post your BE configuration here.
    

    Hungarnet

    Home
    Remote

    Xmltooling_Log4cpp_patch

    --- xmltooling/soap/impl/SOAPClient.cpp.orig    2008-03-14 23:50:29.000000000 +0100
    +++ xmltooling/soap/impl/SOAPClient.cpp 2008-04-25 13:14:29.000000000 +0200
    @@ -89,8 +89,11 @@
         XercesJanitor<DOMDocument> janitor(doc);
    
         Category& log = Category::getInstance(XMLTOOLING_LOGCAT".SOAPClient");
    -    if (log.isDebugEnabled())
    -        log.debugStream() << "received XML:\n" << *(doc->getDocumentElement()) << logging::eol;
    +    if (log.isDebugEnabled()) {
    +        string serializedXml;
    +        XMLHelper::serialize (doc->getDocumentElement(),serializedXml,false);
    +        log.debugStream() << "received XML:\n" << serializedXml << logging::eol;
    +    }
    
         auto_ptr<XMLObject> xmlObject(XMLObjectBuilder::buildOneFromElement(doc->getDocumentElement(), true));
         janitor.release();
    

    IdP_Operational_Requirements

    Purpose of this document

    This document defines identity management and system operation requirements and recommendations for Identity Providers joining the HREF Federation.

    Throughout this document the interpretation of terms MUST, MUST NOT, SHOULD, SHOULD NOT are defined as:

    Identity management

    1. The organisation operating the Identity Provider MUST document its privacy policy and make it available to its users.
    2. The organisation MUST define the sources, the maintenance procedures and approximate quality of the data about its users, and supply this documentation to the Federation.
    3. Uniqueness of the usernames MUST be guaranteed.
    4. One individual SHOULD NOT have more than one user accounts.
    5. Role accounts (such as 'director', 'secretary') SHOULD NOT be used.
    6. Use of attributes:
      1. Attribute implementations MUST follow the Attribute Specification.
      2. The Identity Provider MUST implement the following attributes:
        • eduPersonTargetedID
        • eduPersonScopedAffiliation
        • schacHomeOrganizationType
        • eduPersonPrincipalName
      3. The Identity Provider SHOULD implement the following attributes:
        • displayName
        • mail
        • eduPersonEntitlement
      4. The IdP MUST ensure that eduPersonTargetedID and eduPersonPrincipalName are not re-assignable.
    7. Limitation of test accounts:
      1. all test accounts MUST be identified and documented along with the individual who is responsible for the test account
      2. real transactions MUST NOT be initiated by test accounts
      3. test accounts SHOULD be distinguished with appropriate homeOrganizationType value.
    8. User credentials (i.e. passwords) MUST NOT be transmitted over public network in unencrypted form.
    9. If initial user passwords are distributed, it SHOULD be done through non-electronic form
    10. Changes in the users' affiliation to the institution MUST be populated to the IdP database within 7 days
      1. If the authoritative source of user information is an external database (i.e. student information system), then the above timeframe starts from the time of the change in the primary system.
      2. Students may use 'alum' affiliation after leaving the organisation. Values 'student' or 'member' MUST NOT be used afterwards.
      3. For faculty members and employees, affiliation values 'staff', 'employee', 'faculty' and 'member' MUST be revoked.

    Service management

    1. The organisation MUST develop a role responsible for liaison with the Federation Operator.
    2. The organisation operating the Identity Provider MUST provide end-user support for its affiliated users and have them informed about the availability of the support.
    3. The organisation MUST provide the following data to the Federation Operator as anonymous daily statistics about the Identity Provider usage:
      • number of unique users;
      • number of transactions initiated to each federation service;
      • total number of logins.

    Operational issues

    1. Any transaction including personal data MUST be logged and log files SHALL be kept for at least 30 days.
      1. The log files above MUST be treated in accordance with the applicable data protection laws.
    2. Cryptographic keys of the Identity Provider MUST be at least 2048 bits long.
      1. Private keys MUST be protected.
      2. In case of a key compromise, the Federation Operator MUST be notified within 24 hours.
      3. Use of self-signed certificates with a long expiration time is RECOMMENDED.
    3. Use of SAML:
      1. The Identity Provider MUST comply with the Interoperable SAML 2.0 Web Browser SSO Deployment Profile (http://saml2int.org)
      2. It is RECOMMENDED to support SAML2 Web Browser SSO Profile over HTTP Artifact Binding.
      3. It is RECOMMENDED to support SAML2 Single Logout Profile over HTTP Redirect and SOAP Bindings.
    4. All SAML endpoints of the Identity Provider SHALL be protected by HTTPS.
    5. All SAML endpoints of the Identity Provider MUST be under a DNS domain which is possessed by the operating organisation.
    6. All scopes used by the Identity Provider MUST be under a DNS domain which is possessed by the operating organisation.

    Openidp

    Az openIdP (open.eduid.hu) az eduID egy olyan azonosító szervezete, amelybe bárki regisztrálhat, majd a regisztrált azonosító birtokában különböző szolgáltatásokat vehet igénybe.

    Felhasználóknak

    Háttér

    Az openIdP célja, hogy azok a felhasználók, akiknek még nincs föderatív azonosítójuk, de szeretnének olyan szolgáltatást igénybe venni az eduID-n belülről, amely egyfelől lehetőséget nyújt föderatív azonosításra, másfelől "ismeri" az eduID openIdP-jét, ők egy gyors regisztráció után használhassák az adott szolgáltatást.

    Egy azonosítási föderáció a technológia mellett komolyan épít a bizalomra, melynek egyik sarokköve, hogy a szolgáltatók megbíznak az egyes azonosító szervezetek által a felhasználókról kiadott adatokban. Mivel az openIdP-be a felhasználók maguk regisztrálnak, nincs mögöttük egy intézmény, aki ellenőrizte volna az adatokat, és felelne azok hitelességéért, így nem elvárható, hogy az eduID minden szolgáltatása megbízzon, azaz ismerje az openIdP-t. Azoknál a szolgáltatásoknál, ahol erre lehetőség van, ott a szolgáltatás üzemeltetője ezt külön jelzi.

    Fontos! Az openIdP működése teljesen automatikus, funkcionalitásában minimalista, kizárólag a legszükségesebbeket tudja, azt viszont üzembiztosan, ezért az eduID kizárólag az üzemeltetést végzi, további felhasználói támogatás nem biztosít.

    Szolgáltatások üzemeltetőinek

    Ha szeretné, hogy szolgáltatását az openIdP felhasználói is igénybe vehessék, úgy a következők a teendők.

    1. A fent említett, adatok ellenőrizetlenségéből adódó kockázatok megértése
    2. Az openIdP metaadatának betöltése a szolgáltatás előtt dolgozó SP-be.

    Az openIdP az alábbi adatokat tárolja és adja ki egy-egy felhasználóról

    Elérés a központi Discovery Service-en keresztül Ha szolgáltatása ismeri az openIdP-t, úgy lehetőség van a központi Discovery Service-t oly módon meghívni, hogy az openIdP megjelenjen, mint választható azonosító szervezet. Ehhez az SP-hez tartozó Discovery Service beállításban módosítani kell az URL-t. Alapból ez az érték <https://discovery.eduid.hu/>, amelyet ki kell egészíteni ily módon: <https://discovery.eduid.hu/openidp/>

    Adatvédelem

    Az openIdP-ben a felhasználókról mindössze az e-mail cím, vezetéknév és keresztnév kerül tárolásra. Ezen adatok valódiságáért a felhasználó felel. Ezeket az adatokat az openIdP kizárólag az eduID-ban résztvevő szolgáltatásoknak adhatja ki.

    WAYF

    A WAYF szó a Where Are You From? mondat rövidítése. Olyan szolgáltatást jelent, amely kideríti, hogy a felhasználót melyik IdP képes azonosítani. A SAML2 szabvány ezt a szolgáltatást Discovery Service-nek nevezi.

    Legegyszerűbb esetben a WAYF kilistázza az elérhető IdP-ket, amelyek közül a felhasználó választhat. A választást bizonyos ideig (a böngésző bezárásáig, néhány napig, stb) megjegyeztethetjük, ekkor a WAYF szerver a választásunkat cookie-ban tárolja.

    A WAYF lehet az IdP-nek és az SP-nek is része, ill. különálló elem, a működést ez nem befolyásolja.

    ** Szoftverek:**

    HREF_Key_Rollover_2020_English

    Introduction

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

    All HREF member and partner have to update their IdP and SP configurations before 2022. January 1st., in order to provide the federational services without interruption. After 2022 January 1st., the old metadata signing certificate (HREF-2011) will be shut down.

    The tables below and configuration examples are containing all the necessary technical information.

    Key Rollover

    Code names

    Code name Metadata signing certificate Date of expiration
    HREF-2011 href-metadata-signer-2011.crt 2022.01.01.
    HREF-2015 mdx-test-signer-2015.crt 2022.01.01.
    HREF-2020 href-metadata-signer-2020.crt 2025.06.14.

    SHA1 fingerprints

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

    Domain names

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

    Shibboleth Service Provider Configurations

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

    XML

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

    <MetadataProvider type="Chaining">
        <MetadataProvider type="XML" id="href-2011" url="https://metadata.eduid.hu/2011/href.xml" backingFilePath="href-2011.xml">
            <MetadataFilter type="Signature" certificate="href-metadata-signer-2011.crt"/>
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
        </MetadataProvider>
        <MetadataProvider type="XML" id="href-2020" url="https://metadata.eduid.hu/2020/href.xml" backingFilePath="href-2020.xml">
            <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
        </MetadataProvider>
    </MetadataProvider>
    

    MDX

    Shibboleth 3.X

    https://wiki.shibboleth.net/confluence/display/SP3/MDQMetadataProvider

    <MetadataProvider type="MDQ" id="href-2015" ignoreTransport="true" baseUrl="https://mdx-2015.eduid.hu/">
        <MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
    </MetadataProvider>
    <MetadataProvider type="MDQ" id="href-2020" ignoreTransport="true" baseUrl="https://mdx-2020.eduid.hu/">
        <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
    </MetadataProvider>
    

    Shibboleth 2.X

    <MetadataProvider type="Dynamic" id="href-2015" ignoreTransport="true">
        <Subst>https://mdx-2015.eduid.hu/entities/$entityID</Subst>
        <MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
    </MetadataProvider>
    <MetadataProvider type="Dynamic" id="href-2020" ignoreTransport="true">
        <Subst>https://mdx-2020.eduid.hu/entities/$entityID</Subst>
        <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
    </MetadataProvider>
    

    Shibboleth Identity Provider Configurations

    XML

    Shibboleth 4.X

    https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider

    <MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
                      backingFile="%{idp.home}/metadata/href-2020.xml"
                      metadataURL="https://metadata.eduid.hu/2020/href.xml">
    
        <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
            certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>
    
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
    
        <MetadataFilter xsi:type="EntityRoleWhiteList">
            <RetainedRole>md:SPSSODescriptor</RetainedRole>
        </MetadataFilter>
    
    </MetadataProvider>
    

    Shibboleth 3.X

    https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider

    <MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
                      backingFile="%{idp.home}/metadata/href-2020.xml"
                      metadataURL="https://metadata.eduid.hu/2020/href.xml">
    
        <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
            certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>
    
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
    
        <MetadataFilter xsi:type="EntityRoleWhiteList">
            <RetainedRole>md:SPSSODescriptor</RetainedRole>
        </MetadataFilter>
    
    </MetadataProvider>
    

    MDX

    Shibboleth 4.X

    https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider

    <MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
                      connectionRequestTimeout="PT2S"
                      connectionTimeout="PT2S"
                      socketTimeout="PT4S">
    
        <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
            certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>
    
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
    
        <MetadataQueryProtocol>https://mdx-2020.eduid.hu/</MetadataQueryProtocol>
    
    </MetadataProvider>
    

    Shibboleth 3.X

    https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider

    <MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
                      connectionRequestTimeout="PT2S"
                      connectionTimeout="PT2S"
                      socketTimeout="PT4S">
    
        <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
            certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>
    
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P9D"/>
    
        <MetadataQueryProtocol>https://mdx-2020.eduid.hu/</MetadataQueryProtocol>
    
    </MetadataProvider>
    

    SimpleSAMLphp Configurations

    MDX

    //config/config.php
    'metadata.sources' => [[=> 'flatfile']('type'), // ez a *-hosted metadata konfiguráció betöltése miatt szükséges
         [
             'type' => 'mdq',
             'server' => 'https://mdx-2020.eduid.hu',
             /* --- */
             'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61'
         ],
    ],
    

    metarefresh

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

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

    // config/config-metarefresh.php
    $config = [
       'sets' => [
           'href-2011' => [
               'cron'      => ['hourly'],
               'sources'   => [
                   [
                       'src' => 'https://metadata.eduid.hu/2011/href.xml',
                       'validateFingerprint' => 'FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66',
                   ],
               ],
               'expireAfter'       => 777600, // 9 nap
               'outputDir'     => 'metadata/metarefresh-href-2011/',
               'outputFormat' => 'flatfile',
           ],
           'href-2020' => [
               'cron'      => ['hourly'],
               'sources'   => [
                   [
                       'src' => 'https://metadata.eduid.hu/2020/href.xml',
                       'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61',
                   ],
               ],
               'expireAfter'       => 777600, // 9 nap.
               'outputDir'     => 'metadata/metarefresh-href-2020/',
               'outputFormat' => 'flatfile',
           ],
        ],
    ];
    
    // config/config.php
    'metadata.sources' => [
        ['type' => 'flatfile'],
        ['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2011'],
        ['type' => 'flatfile', 'directory' => 'metadata/metarefresh-href-2020'],
    ],
    

    Shib2IdpConnectionPool

    Mi is az a connection pooling?

    A Java webalkalmazások általában többszálú, hosszú életciklusú környezetben futnak, az adatbázis kapcsolatok azonban természetükből fakadóan nem szálbiztosak (egy kapcsolaton egyszerre csak szál dolgozhat). Ezért szükség van arra, hogy a feldolgozó szálakhoz adatbázis kapcsolatokat rendeljünk. Megjegyzendő, hogy ez nem újdonság, ugyanis PHP esetén például minden egyes futáskor új kapcsolat nyílik.

    A kapcsolatkezelésre tehát alapvetően három módszer ismert:

    A fenti három megoldás közül az első kettő webes környezetben teljesítmény okokból erősen ellenjavallt, csak a harmadik módszer a járható út: az adatbázis kapcsolatokat tehát érdemes "készletezni" (connection pooling), és a kapcsolatot kérő szálakhoz futás közben, igény szerint hozzárendelni őket.

    Ezen paradigma hatékony működéséhez rendkívül fontos, hogy az alkalmazás csak annyi ideig használja a kapcsolatot, ameddig szükséges, majd azonnal jelezze a pool felé, hogy a kapcsolat szabad (ezt tulajdonképpen a kapcsolat API-szintű lezárásával jelzi, de ilyenkor a fizikai kapcsolat természetesen nem bomlik fel, az másik szál számára ismét kiajánlhatóvá válik).

    Az elterjedtebb connection pool implementációk rengeteg segítséget képesek nyújtani:

    A Java alkalmazásszervereknek egy szabványos módszert kell biztosítaniuk az adatbázis kapcsolatok elérésére. Az alkalmazások egy ún. JNDI erőforráson keresztül képesek elérni a kapcsolatok menedzseléséért felelős osztályt (ami általában egy ún. DataSource interfészt implementál). Fontos megemlíteni, hogy ilyenkor az adatbáziskapcsolat felépítését az alkalmazásszerver végzi, így az elérés paramétereit (url, felhasználónév, jelszó) ott kell adminisztrálni, és nem az alkalmazás saját konfigurációjában. Ez lehetőséget ad az adminisztrátor számára, hogy az egyes alkalmazásspecifikus beállítások megtanulása nélkül képes legyen egyik adatbázisról a másikra migrálni.

    "Hivatalos", Sun-féle leírás

    Connection pool használata Tomcat6 alatt

    A Tomcat jelenleg a dbcp nevű pool implementációt használja, ami elég régi és a teljesítménye sem a legjobb, de legalább működik.

    Az alábbi példakód egy MySQL kapcsolatot állít be (/etc/tomcat6/server.xml), ami kapcsolat-ellenőrzést is végez, mielőtt az alkalmazásnak válaszolna:

      <GlobalNamingResources>
    
        <!-- Create connection pool for idptest.
             Connections will be validated before handed over to the application,
             and every 10 minutes. -->
        <Resource name="jdbc/mymysql" auth="Container"
                  type="javax.sql.DataSource"
                  driverClassName="com.mysql.jdbc.Driver"
                  maxActive="10" maxIdle="2" maxWait="10000"
                  username="username" password="password"
                  url="jdbc:mysql://localhost:3306/database"
                  testWhileIdle="true" timeBetweenEvictionRunsMillis="6000000"
                  testOnBorrow="true" validationQuery="SELECT 1" />
      </GlobalNamingResources>
    

    A fenti globális JDNI erőforrást egyes alkalmazásokhoz kell rendelni a Context leíróban (pl /etc/tomcat6/Catalina/localhost/idp.xml):

      <Context docBase="...." ... >
         <ResourceLink name="jdbc/mymysql"
                       global="jdbc/mymysql"
                       type="javax.sql.DataSource" />
      </Context>
    

    A fenti konfiguráció elkészülte után az alkalmazás a java:comp/env/jdbc/mymysql JNDI néven éri el az adatbázis kapcsolatot, valahogy így (hibakezelés nélkül, természetesen):

     // initialize jndi datasource
     Context ctx = new InitialContext();
     DataSource dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/mymysql");
     // acquire a new connection
     Connection conn = dataSource.getConnection();
     try {
       // do something
     } finally {
       //don't forget to close the connection in the finally block!
       conn.close();
     }
    

    Egy fontos megjegyzés

    Az alkalmazásszerver és az alkalmazás általában két külön osztálybetöltőt (classloader) használ, ezért ebben az esetben nem az alkalmazás mellé kell csomagolni a megfelelő adatbázis drivert, hanem az alkalmazásszerver által látható helyre. Debian Lenny alatt ez például a következőképpen valósítható meg:

    sudo aptitude install libmysql-java
    sudo ln -s /usr/share/java/mysql.jar /usr/share/tomcat6/lib/
    

    IdP konfigurálása

    Tegyük fel, hogy alkalmazásszerverünk képes a connection poolingra, és a megfelelő DataSource objektumot a JNDI térben rendelkezésre bocsátja jdbc/idp néven.

    Attribútumok feloldása

    Az IdP leggyakrabban attribútum feloldáshoz (pl. perzisztens azonosítókhoz) használ relációs adatbázist, ezért példaként álljon itt egy DataConnector konfiguráció:

      <resolver:DataConnector xsi:type="StoredId" ...>
        <resolver:Dependency ref="myLDAP" />
        <ContainerManagedConnection resourceName="java:comp/env/jdbc/idp" />
      </resolver:DataConnector>
    

    Gyakorlatilag az ApplicationManagedConnection mondásokat kell ContainerManagedConnection-ra cserélni.

    JDBC login modul

    Bővebben lásd: Shib2IdpAuth#SQL (JDBC) alapon

    uApprove

    Az alábbi leírás a uApprove legalább 2.3-as verzióihoz íródtak, korábbiak használata nem javasolt.

    Ahhoz, hogy a tomcat által kezelt adatbáziskapcsolat használatára rávegyük a uApprove-ot, az alábbiakat kell tennünk.

    vim conf/uApprove.properties
    

    Az adatbázisbeállításoknál kommentezzük ki a default beállításokat és írjuk be a használni kívánt JNDI resource nevét:

    #---------------------------------------------------------------------#
    # Database configuration                                              #
    #---------------------------------------------------------------------#
    
    database.resourceName       = java:comp/env/jdbc/mymysql
    #database.driver             = com.mysql.jdbc.Driver
    #database.url                = jdbc:mysql://localhost:3306/uApprove
    #database.username           = uapprove
    #database.password           = password
    
    vim conf/uApprove.xml
    

    Tegyük inaktívvá az alapértelmezett uApprove.dataSource bean-t, és helyére tegyük az alábbi definíciót

    <bean id="uApprove.dataSource" class="org.springframework.jndi.JndiObjectFactoryBean" depends-on="shibboleth.LogbackLogging"
        p:jndiName="${database.resourceName}" p:lookupOnStartup="true"
        p:cache="true" p:proxyInterface="javax.sql.DataSource" />
    

    Utolsó lépésként másoljuk be a shibboleth-idp/lib és a shibboleth-idp/war/WEB-INF/lib könyvtárba az alábbi két jart is. (Alapértelmezés szerint az utóbbi útvonal becsomagolva található a shibboleth-idp/war/idp.war fájlban, ezesetben kicsomagolás --> fájlok bemásolása --> visszacsomagolás a követendő út):

    Shib3IdpAttrib

    Shibboleth 3 IdP attribútum feloldás beállítása

    Vonatkozó állományok:

    Az alábbiakban LDAP címtárat használunk forrás adatbázisként az attribútumok feloldásához. Az {idp.home}/conf/ldap.properties állományban beállított kapcsolódási paraméterek az attribútum feloldáshoz is használhatók.

    Az {idp.home}/conf/attribute-resolver-ldap.xml állomány jó kiindulási pont, cseréljük le erre az {idp.home}/conf/attribute-resolver.xml állományt.

    cd /opt/shibboleth-idp/conf # vagy ahová az IdP telepítésre került
    cp attribute-resolver.xml attribute-resolver-simple.xml # másolat készítése
    cp attribute-resolver-ldap.xml attribute-resolver.xml
    

    Szerkesszük az alábbiak szerint az {idp.home}/conf/attribute-resolver.xml állományt. A mail attribútumot már tartalmazza a beállító állomány. Az alábbi példában az sn és givenName attribútumokat vesszük fel.

        <!-- ========================================== -->
        <!--      Attribute Definitions                 -->
        <!-- ========================================== -->
    
        <!-- ... további tartalom ... -->
    
        <!--
        In the rest of the world, the email address is the standard identifier,
        despite the problems with that practice. Consider making the EPPN value
        the same as your official email addresses whenever possible.
        -->
    
        <resolver:AttributeDefinition id="mail" xsi:type="ad:Simple" sourceAttributeID="mail">
            <resolver:Dependency ref="myLDAP" />
            <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
            <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
        </resolver:AttributeDefinition>
    
        <resolver:AttributeDefinition id="sn" xsi:type="ad:Simple" sourceAttributeID="sn">
            <resolver:Dependency ref="myLDAP" />
            <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:sn" encodeType="false" />
            <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.4" friendlyName="sn" encodeType="false" />
        </resolver:AttributeDefinition>
    
        <resolver:AttributeDefinition id="givenName" xsi:type="ad:Simple" sourceAttributeID="givenName">
            <resolver:Dependency ref="myLDAP" />
            <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:givenName" encodeType="false" />
            <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.42" friendlyName="givenName" encodeType="false" />
        </resolver:AttributeDefinition>
    
        <!-- ========================================== -->
        <!--      Data Connectors                       -->
        <!-- ========================================== -->
    
        <!-- ... további tartalom ... -->
    

    Dokumentáció:

    OpenID

    Mi az OpenID?

    Az OpenID egy nyílt, decentralizált, ingyenes keretrendszer felhasználóközpontú digitális identitásmenedzsmenthez. Az OpenID elképzelés abból indul ki, hogy az interneten bárki azonosíthatja önmagát egy URI (avagy URL, web cím) segítségével, pontosan úgy, ahogy a weboldalak is teszik. Mivel az URIk a web felépítésének alapvető elemei, biztos alapjául szolgálhatnak a felhasználóközpontú identitásmenedzselésnek is.

    Az OpenID keretrendszer egyik fő eleme az autentikáció, vagyis hogy miképp bizonyítod, te birtokolsz egy adott URI-t. Manapság a weboldalak felhasználóneveket és jelszavakat kérnek a belépéshez, ami azt jelenti, hogy sokan ugyanazt a jelszót használják minden weboldalon. Az OpenID autentikáció esetében a felhasználóneved a saját URI-d, jelszavad (vagy további adatod) pedig biztonságosan el lesz tárolva az OpenID szolgáltatódnál (amelyet te magad is működtethetsz, vagy használhatsz egyéb identitás szolgáltatót).

    Egy OpenID-re nyitott weboldalra történő belépéshez (még ha sosem jártál rajta ezelőtt) csak add meg az OpenID URI-dat. A weboldal ezután át fog irányítani az OpenID szolgáltatódhoz, ahol meg kell adnod a szükséges adatokat. Amint megtörténik az autentikáció, OpenID szolgáltatód visszairányít a weboldalra a belépéshez szükséges adatokkal együtt. Ha erős autentikációra van szükség, az OpenID keretrendszer számos tranzakció típushoz is használható - az egyszerű Single-Sign-On eljárás vagy a megosztott adatok érzékenységének rugalmas kiterjesztésére.

    Az autentikáció mellett az OpenID keretrendszer eszközöket is biztosít a felhasználóknak ahhoz, hogy megosszák digitális identitásuk egyéb összetevőit. A folyamatosan bővülő OpenID Attribute Exchange specifikáció alapján a felhasználók képesek pontosan meghatározni az Identitás szolgáltatójuk által megosztható információk körét.

    Erasmusplus_ESI

    Erasmus+ és ESI

    Az Európai Hallgatói Kártya Kezdeményezés részeként az Európai Bizottság 2021 júniusától kezdve digitális formában kívánja támogatni az Erasmus programhoz kapcsolódó összes szolgáltatást, mint például az Online Learning Agreement (OLA) és az Erasmus+ mobilalkalmazást. A digitalizálás alapvető része a hallgatók azonosítása, amely az eduGAIN-en keresztül fog történni.Az eduGAIN szövetség hazai képviselője a KIFÜ, aki Magyarországon az eduID.hu szövetséget működteti, hogy az oktatás, kutatás és közgyűjtemények szereplői az intézményi hitelesítő adataikkal bejelentkezhessenek az eduGAIN szolgáltatásokba. Az eduGAIN-ben a szolgáltatások sikeres azonosítás esetén azonnal megkapják a felhasználók helyes azonosításához és jogosultság kezeléséhez szükséges információkat. Az MyAcademicID működéséhez, az európai hallgatói azonosító (European Student Identifier) helyes létrehozásához és az Erasmus+ szolgáltatásokban szükséges attribútumok beállításhoz szükséges információk az alábbiak.

    MyAcademicID proxy

    Az Erasmus+ szolgáltatásokhoz való hozzáférés a MyAcademicID projektben létrehozott és a GEANT által kezelt proxyn keresztül történik. Ez azt jelenti, hogy az Erasmus+ összes szolgáltatásának egyetlen szolgáltatója van a következő entitásazonosítóval:

    https://proxy.prod.erasmus.eduteams.org/metadata/backend.xml

    A Szolgáltatót az eduID.hu az eduGAIN-en keresztül teszi közzé, így ha az intézménye tagja az eduGAIN-nek is (lásd: Metaadatok), akkor nem kell további lépéseket tenni. Ellenkező esetben lépjen kapcsolatba először a KIFÜ eduID.hu csapatával, hogy kérje identitásszolgáltatójának exportálását az eduGAIN-ba, majd konfigurálja be az eduID.hu szolgáltatás által terjesztett eduGAIN metaadatokat (lásd: Metadata ).

    Attributumok

    Az Erasmus + szolgáltatások eléréséhez szükséges attribútumok a következők.

    Attributumok Leírás Példa
    eduPersonPrincipalName Állandó, nem célzott, nem újra kiosztható globálisan egyedi azonosító username@foobar.hu
    eduPersonTargetedID Nem átlátszó, célzott (minden szolgáltatónál más) azonosító, amely nem osztható ki újra https://idp.foobar.hu/idp/shibboleth!https://sp.example.com/shibboleth!a1b2c3d4-789a-4ca7-8ff9-43216789bd
    displayName A felhasználó megjelenítendő neve. Szükséges, ha nincsen cn, vagy givenName+sn.
    cn A felhasználó teljes neve. Szükséges, ha nincsen displayName vagy givenName+sn. Gipsz Jakab Aladár
    givenName Felhasználó keresztneve. Szükséges, ha nincsen displayName vagy cn. Jakab
    sn Felhasználó családi neve. Szükséges, ha nincsen displayName vagy cn. Gipsz
    eduPersonAffiliation Felhasználó és intézmény közti viszony leírása. [student](member,)
    eduPersonScopedAffiliation Felhasználó és intézmény közti viszony leírása. scope-al [student@foobar.hu](member@foobar.hu,)
    schacPersonalUniqueCode A szervezet által hozzárendelt személyes egyedi kód (URN). '''Az európai hallgatói azonosító kódolására és továbbítására szolgál. <nowiki>urn:schac:personalUniqueCode:int:esi:foobar.hu:123456789</nowiki>
    schacHomeOrganization Szervezete domainje. foobar.hu
    schacHomeOrganizationType Szervezet típusa (URN) <nowiki>urn:schac:homeOrganizationType:eu:higherEducationalInstitution</nowiki>

    European Student Identifier

    Az European Student Identifier (ESI) globálisan egyedi, tartós, nem célzott azonosító (minden szolgáltatónál ugyanaz marad). Titkosítva kerül továbbításra a schacPersonalUniqueCode attribútumon keresztül. Az ESI két fő módját támogatott:

    1. országos kód:ha rendelkezésre áll nemzeti hallgatói kód
    2. intézményenként:jelenleg ez támogatható Magyarországi szinten

    Az ESI három részből áll:

    Az így kapott teljes ESI: <nowiki>urn:schac:personalUniqueCode:int:esi:foo.bar:123456789</nowiki>

    Az ESI teljes specifikációja elérhető a GEANT wiki-n:

    https://wiki.geant.org/display/SM/European+Student+Identifier

    EWP adminisztrátori funkció

    Az eduGAIN közösség 2022 öszén definiálta EWP Admin szerepkört. EWP Admin szerepkör (Erasmus Without Paper Administrator szerepkör) lehetővé teszi az Erasmus+ tevékenységeiben részt vevő felsőoktatási intézmények (HEI) felhatalmazott képviselői számára, hogy szabványos módon bejelentkezzenek az EWP-eszközökbe és EWP-információik és -beállításaik kezelése egységes legyen. Erről bővebb információ itt található:

    https://wiki.geant.org/display/SM/EWP+Admin+Role

    További információk

    https://wiki.geant.org/display/SM/Identifier+in+Erasmus+mobility

    SAML

    SAML 1.1

    SAML 2.0

    Bindingok

    Profilok

    Shibboleth

    Architektúra

    Profilok

    Jelentés

    Common-lib-terms

    Meghatározás

    A common-lib-terms az eduPersonEntitlement attribútum egy speciális jelentéssel felruházott értéke. A teljes attribútum érték a következő: urn:mace:dir:entitlement:common-lib-terms. Ezen rögzített attribútumérték kiadását az egyes intézményekkel szerződéses viszonyban álló folyóirat-kiadók (pl. Ebscohost, Sciencedirect) várják el, amely érték az intézmény oktatóinak, kutatóinak és hallgatóinak járhat. (Ezek a faculity, staff és student affiliation értékkel bíró felhasználók).

    További információ (angolul): http://middleware.internet2.edu/urn-mace/urn-mace-dir-entitlement.html

    Technikai útmutató

    Az intézményi IdP attribútumszűrőjén egyfelől engedélyezni kell a megadott kiadókhoz tartozó SP-k számára az eduPersonEntitlement attribútum kiadását, másfelől be kell állítani, hogy a megadott affiliation értékkel rendelkező felhasználók megkapják a urn:mace:dir:entitlement:common-lib-terms értéket az eduPersonEntitlement attribútumban.

    Shibboleth IdP

    Shibboleth IdP-nél az attribute-resolver.xml-ben kell kibővíteni az eduPersonEntitlement definícióját az alábbiak szerint.

    <resolver:AttributeDefinition xsi:type="Script"
                                  xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                  id="eduPersonEntitlement"
                                  sourceAttributeID="eduPersonEntitlement">
        <!-- Dependency that provides the source attribute. -->
        <resolver:Dependency ref="myLDAP" />
        <resolver:Dependency ref="eduPersonAffiliation" />
        <!-- SAML 1 and 2 encoders for the attribute. -->
        <resolver:AttributeEncoder xsi:type="SAML1String"
                               xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                               name="urn:mace:dir:attribute-def:eduPersonEntitlement" />
        <resolver:AttributeEncoder xsi:type="SAML2String"
                                   xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                   name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7"
                                   friendlyName="eduPersonEntitlement" />
        <!-- The script, wrapped in a CDATA section so that special XML characters don't need to be removed -->
        <Script><![CDATA[
             importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
             // Create attribute to be returned from definition
             if (eduPersonEntitlement == null) eduPersonEntitlement = new BasicAttribute("eduPersonEntitlement");
             if (eduPersonAffiliation.getValues().contains("staff") || eduPersonAffiliation.getValues().contains("student")) {
                 eduPersonEntitlement.getValues().add("urn:mace:dir:entitlement:common-lib-terms");
             }
        ]]></Script>
    </resolver:AttributeDefinition>
    

    simpleSAMLphp

    Be kell szúrni az attribútumgeneráló folyamatba egy tetszőleges sorszámmal, amely már ismeri a felhasználóhoz tartozó affiliation értéket.

    70 => array(
        'class' => 'core:AttributeAlter',
        'subject' => 'affiliation',
        'pattern' => '/staff|student|faculity/',
        'replacement' => 'urn:mace:dir:entitlement:common-lib-terms',
        'target' => 'eduPersonEntitlement',
    ),
    

    SimpleSAMLMixedMetadata

    Ez a vázlatos leírás egy olyan SimpleSAMLphp IdP (vagy SP) konfigurálásában kíván segítséget nyújtani, amely az alábbi metaadatforrásokat használja:

    Ez utóbbi kettőt a föderáció MDX szolgáltatása biztosítja leghatékonyabban.

    Metaadatforrások beállítása

    A config/config.php állományban cseréljük le a metadata.sources részt az alábbira:

    'metadata.sources' => array(
            array('type' => 'flatfile'),
            array('type' => 'flatfile','directory' => 'metadata/metarefresh'),
            array('type' => 'mdx', 'server' => 'http://mdx.eduid.hu', 'cachedir' => '/var/simplesamlphp/mdx-cache', 'cachelength' => 7200,
    'validateFingerprint' => '91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43'
    ),
    ),
    

    Az MDX cache könyvtárat és a statikus metaadatok könyvtárát hozzuk létre, és tegyük a webszerver által írhatóvá:

     sudo mkdir /var/simplesamlphp/{mdx-cache,metadata/metarefresh}
     sudo chgrp www-data /var/simplesamlphp/{mdx-cache,metadata/metarefresh}
     sudo chmod g+w /var/simplesamlphp/{mdx-cache,metadata/metarefresh}
    

    Statikus metaadatok

    A fenti szakaszban a dinamikus metaadatok konfigurációját már megadtuk, a statikus metaadatokat viszont a cron modul által meghívott metarefresh program végzi, így ezeket is konfigurálni kell.

    !!! note

    Ha nem használunk belső SP-ket, akkor a szakaszban leírt konfigurációra nincs szükségünk, **készen vagyunk**!
    

    config/config-metarefresh.php:

    <?php
    
    $config = array(
       'sets' => array(
           'href' => array(
               'cron'      => array('hourly'),
               'sources'   => array(
                   array(
                       'src' => 'http://metadata.eduid.hu/2011/niifi.xml',
                       'validateFingerprint' => 'FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66',
                   ),
               ),
               'expireAfter'   => 60*60*24*7, // Maximum 4 days cache time.
               'outputDir'     => 'metadata/metarefresh/',
               'outputFormat'  => 'flatfile',
           ),
       ),
    );
    

    config/module_cron.php:

    <?php
    /*
     * Configuration for the Cron module.
     */
    
    $config = array (
    
            'key' => 'eztajelszotcsereldle',
            'allowed_tags' => array('daily', 'hourly', 'frequent'),
            'debug_message' => TRUE,
            'sendemail' => FALSE,
    
    );
    

    Engedélyezzük a cron és a metarefresh modulokat:

    sudo touch /var/simplesamlphp/modules/{cron,metarefresh}/enable
    

    Hozzuk létre azt a rendszer cron bejegyzést, amely időzítve meghívja a SimpleSAMLphp cron modulját:

    echo '03 * * * * www-data curl --silent "https://idp.example.org/simplesamlphp/module.php/cron/cron.php?key=eztajelszotcsereldle&tag=hourly" \
    >/dev/null 2>&1' > sudo tee /etc/cron.d/simplesamlphp
    

    Ezzel az IdP-nk készen áll az eduGAIN konföderációba való publikálásra. A haladó attribútumkiadás-konfiguráció leírása itt található: SSP EntityCategories.

    A Resource Registry felületen belépve állítsuk át az entitást az eduGAIN-ben való publikálásra: left

    Károkozási_táblázat

    /- X -> User IdP SP Föderáció
    User
  • Azonosító adatok ellopásával más felhasználó nevében vesz igénybe szolgáltatást
  • Hamis adatokat ad meg (vagy állíttat be)
  • Az SP rendszerével visszaélve rombolja az IdP presztízsét
  • Visszaél a szolgáltatással (abuse)
  • Hamis adatok alapján jogosulatlanul vesz igénybe szolgáltatást
  • Visszaélésekkel (ill. próbálkozásokkal) csökkenti a föderációba vetett bizalmat
  • IdP
  • Visszaélés a jelszóval
  • Pontatlan személyes adatok
  • Szükséges jogosultsági attribútumokat (pl. entitlement) nem adja meg
  • Visszaélés a személyes adatokkal
  • Személyes adatok túl tág körének átadása harmadik félnek
  • Azonosító szolgáltatás kiesése miatt a felhasználó nem tud igénybe venni szolgáltatásokat
  • X
  • Rossz Identity Management
  • Hamis scope megadása
  • Hamis attribútum-értékek megadása (pl. jogosulatlan hozzáférés biztosítása entitlement segítségével)
  • Hamis adatok megadása az IdP regisztrációjakor
  • Visszaélések vizsgálatakor az együttműködés megtagadása
  • Hamis adatok megadása az IdP regisztrációjakor
  • Rossz felhasználókezeléssel csökkenti a föderációba vetett bizalmat
  • Visszaélésekkel csökkenti a föderációba vetett bizalmat
  • Megbízhatatlanul üzemeltetett informatikai rendszerrel csökkenti a föderatív azonosításba vetett bizalmat
  • SP
  • Kicsalja a felhasználó jelszavát
  • Visszaél az IdP-től megkapott adatokkal
  • Visszaél a felhasználótól közvetlenül megkapott adatokkal
  • Szükségtelenül igényel adatokat felhasználókról (vö. unsolicited attribute query
  • )
  • DOS támadás
  • X
    FedOp
  • A metadata elrontásával, elérhetetlenségével vagy a frissítés elmulasztásával elérhetetlenné teszi a felhasználó számára a szolgáltatásokat.
  • Metaadatok szándékos meghamisítása
  • A Discovery Service helytelen működtetése miatt elérhetetlenné válnak a szolgáltatások
  • Lásd előbb
  • Intézményen belüli szolgáltatások is elérhetetlenné válhatnak
  • Lásd előbb
  • Föderációs szolgálatatások szakszerűtlen vagy rosszindulatú működtetésével rombolják a föderációba vetett bizalmat
  • Shibboleth_IdP

    !!! bug "Elavult információ"

    **Figyelem:** a Shibboleth szoftver ezen változata már nem támogatott. Az új verziókhoz a leírások itt találhatók:
    
    * [Shibboleth2_IdP](https://help.edu.hu/books/aai/page/shibboleth2-idp)
    * [Shibboleth2_SP](https://help.edu.hu/books/aai/page/shibboleth2-sp)
    

    Telepítési leírások

    Konfigurációs leírások


    ErrorNoStatement

    Első tipp: rosszul jár az SP vagy az IdP órája

    HREF_szolgáltatási_szint_megállapodás

    Műszaki szolgáltatások

    Metadata

    A metadata a föderáció tagjait leíró, a föderációs operátor által digitálisan aláírt állomány, mely létfontosságú a résztvevők egymással való kommunikációjának szempontjából. A metadata által tartalmazott információkkal és a metadata biztonságával kapcsolatban további információkat a Metadata Specifikáció tartalmaz.

    Elérhetőség kritériumai

    A legfontosabb szempont, hogy az elérhetetlenségből fakadó szolgáltatáskiesés megakadályozható legyen. A föderációban részt vevő komponensek a központi metadatát helyileg gyorstárazzák, így a metadata elérhetetlensége a gyorstárazási idő (cacheDuration) alatt nem okozhat szolgáltatáskiesési problémát - kivéve azon entitások esetén, melyek a kiesés időtartama alatt kerülnek újraindításra.

    Fontos kiemelni, hogy a központi metadata elérhetetlensége miatti szolgáltatáskiesés bármely föderációs komponensnél a fent leírt gyorstárazási és érvényességi időszakon belül mindenképpen helyi szoftver- (vagy konfigurációs) hiba következménye.

    A metadata akkor tekinthető elérhetőnek, ha legalább egy, a föderációs operátor hálózatán kívül levő IP címről elérhető, és az URL-ről egy szabványos SAML metadata állomány tölthető le, és aláírása egy ismert kulccsal ellenőrizhető. A metadata akkor tekinthető aktuálisnak, ha elérhető, és a letöltött állomány 2 óránál nem régebben keletkezett.

    Vállalt rendelkezésre állás

    A föderációs operátor vállalja, hogy a metadata tetszőleges 12 hónapos időtartamra nézve az idő 99.9%-ában elérhető, 99%-ában aktuális.

    Föderáció adminisztráció (Resource Registry)

    A Resource Registry a metaadat állományban található - az egész föderációt leíró - adatok szerkesztését lehetővé tevő alkalmazás. A Resource Registryben tárolt adatokat a föderációs operátor illetve az intézmények kapcsolattartói szerkeszthetik.

    Elérhetőség kritériumai

    A Resource Registry elérhetősége a benne tárolt adatok szerkesztésére vonatkozik, a metaadatok elérhetőségét nem érinti. Mivel azonban az esetleges kompromittálódott kulcsok visszavonása az intézmények részéről csak ezen az adminisztrációs rendszeren keresztül elvégezhető, ezért a rendszer elérhetősége a föderáció operatív működése szempontjából fontos.

    A Resource Registry elérhető, ha legalább egy, a föderációs operátor hálózatán kívül eső IP címről megnyitható, és bejelentkezés működőképes (feltételezve, hogy az azonosító szervezet rendben működik).

    Vállalt rendelkezésre állás

    Tetszőleges 12 hónapos időtartamra nézve a szolgáltatás az idő 98%-ában elérhető.

    Discovery Service

    A Discovery Service (keresőszolgáltatás) az SP-k számára a felhasználó azonosító szervezetét kiválasztó alkalmazás. Amennyiben egy SP adminisztrátora úgy dönt, hogy az SP a központi keresőszolgáltatást használja, úgy az adott SP-n történő belépések esetén a komponens elérhetősége kritikus.

    A keresőszolgáltatás a metaadatokból dolgozik, a metaadat változásait 1 napon (24 órán) belül átveszi.

    Elérhetőség kritériumai

    A keresőszolgáltatás elérhetőnek tekintendő, ha legalább 1, föderációs operátor hálózatán kívül eső IP címről elérhető, és a protokoll által leírt működést mutatja, valamint a metadatában szereplő azonosító szervezeteket ajánlja fel (figyelembe véve az előző pontban leírt időkorlátot a módosítások átvezetésére).

    Vállalt rendelkezésre állás

    Tetszőleges 12 hónapos időtartamra nézve a szolgáltatás az idő 99.9%-ában elérhető.

    Virtuális azonosítószervezet

    A föderációs operátor által biztosított virtuális azonosítószervezet biztosítja a saját azonosítószervezettel nem rendelkező intézmények számára a felhasználók AAI infrastruktúrába kapcsolását, illetve a többi azonosítószervezet számára a vendégfelhasználók regisztrálását és karbantartását.

    Elérhetőség kritériumai

    A virtuális azonosítószervezet két komponensből áll:

    A virtuális azonosítószerv elérhetőnek tekinthető, ha legalább egy, föderációs operátor hálózatán kívül eső IP címről elérhető az adminisztrációs felület (feltéve, hogy az adminisztrátor saját azonosító szervezete és a föderációs infrastruktúra megfelelően működik); illetve az azonosító szerver.

    Vállalt rendelkezésre állás

    A virtuális azonosítószervezet elérhető tetszőleges, 12 hónapos időtartamon számított teljes idő 99%-ában.

    Föderációs komponensek monitorozása

    A föderációs operátor az általa üzemeltetett komponenseket folyamatosan és automatikusan ellenőrzi. Ez az ellenőrzés kiterjed az infrastruktúra építőelemeire (switchek, hálózati elemek, szerverek), a szervereken futó operációs rendszerekre, és a föderációs szoftverekre is.

    A monitorozás az NIIF hálózatán (HBONE) belülről történik.

    Támogatás

    Helpdesk intézményi adminisztrátorok számára

    A föderációs operátor ügyfélszolgáltatot tart fenn a tagok és partnerek számára. Az ügyfélszolgálat feladata mind az incidensek kezelése, mind az általános segítségnyújtás (például csatlakozási szándék, vagy hibaelhárítás esetén).

    Az ügyfélszolgálat munkanaponként 09-17 óra között működik, és az intézményi megkeresésekre legfeljebb 1 munkanapon belül válaszol.

    Az esetleges incidensek 0-24 óráig bejelenthetők az NIIFI incidens-kezelő ügyeletén is (http://www.niif.hu/szolgaltatasok/middleware/csirt_kapcsolat).

    Egyéb támogatás

    A föderációs operátor a föderációs technológiákkal, trendekkel kapcsolatban folyamatosan frissülő tudásbázist tart fent, illetve rendszeres és eseti oktatásokkal segíti a tagok közötti tudásátadást. Ugyancsak elősegíti a használt szoftverekkel kapcsolatos információk, hibabejelentések terjedését a résztvevő intézmények és a szoftverek fejlesztői között. Az operátor feladata, hogy a felhasznált szoftverekkel kapcsolatos biztonsági frissítésekre felhívja a résztvevők figyelmét.

    Kiegészítő szolgáltatások

    A föderációs operátor az alábbi szolgáltatásokat garancia nélkül, best effort jelleggel működteti:

    Drupal_Shibboleth_module

    Drupal shib_auth module enables Shibboleth authentication for Drupal CMS.

    !!! warning

    This document is written for module version 3.3-x. Please consult the [Change log](#bkmrk-change log) for the revisions of this document for the previous releases.
    
    For documentation about the more recent 4.x version, please read [DrupalShibbolethReadmeDev](https://help.edu.hu/books/aai/page/drupalshibbolethreadmedev)
    

    !!! warning

    The following documentation assumes that
    * You [understand how Shibboleth works](https://wiki.shibboleth.net/confluence/display/SHIB2/FlowsAndConfig)
    * You have [successfully installed and configured Shibboleth SP](https://wiki.shibboleth.net/confluence/display/SHIB2/Installation) on your host running Drupal.
    

    Installation

    1. Download module source for your Drupal version from the project page.
    2. Uncompress archive to the modules/ directory
    3. Enable module at Administer -> Site building -> Modules

    Compatibility

    Module is being developed for Drupal 6.x. We have stopped backporting new features to the 5.x branch and Drupal 7 is not yet supported as long as it isn't the stable branch. If you want to contribute to development or porting, please contact aai AT niif DOT hu!

    Both Shibboleth 1.3 and Shibboleth 2.x are supported, although some features might require Shibboleth 2.x.

    Upgrading module

    If you are upgrading from the same major version, you only need to overwrite the files within your modules/shib_auth directory, then run update.php.

    Configuration

    Configuring Shibboleth

    You should be familiar with protecting resources with Shibboleth before using this module. (See Shibboleth Wiki) Please check that Shibboleth authentication is working for that location and all the necessary attributes are exported to the headers. You can enable DEBUG mode to dump the whole $_SERVER array. If you can see Shibboleth attributes there, you're fine.

    In Shibboleth there are two modes for protecting resources:

    !!! warning

    If you decide to use lazy sessions and you don't want your users to be able to log in with a password, [you have to disable changing passwords](#bkmrk-disallowing-password-change)
    

    Example Shibboleth configuration

    Note: this example uses lazy sessions. Configuration for Shibboleth 1.3 is quite similar.

    /etc/shibboleth/shibboleth2.xml snippet:

    <RequestMapper type="Native">
      <RequestMap applicationId="default">
        <Host name="your.host.name">
          <Path name="location_of">
            <Path name="your_Drupal">
              <Path name="installation" authType="shibboleth" requireSession="false" />
            </Path>
          </Path>
        </Host>
      </RequestMap>
    </RequestMapper>
    

    Apache config file snippet (ie. /etc/apache2/sites-enabled/your.host.name, or you can even use .htaccess without the <Location> tags):

    <Location /location_of/your_Drupal/installation>
      AuthType Shibboleth
      ShibRequireSession Off
      # the following single line is only valid for Shib2
      ShibUseHeaders On
      require shibboleth
    </Location>
    

    !!! danger "Figyelem"

    You **MUST** use `ShibUseHeaders On` if you use Shibboleth2 with **mod_rewrite**.
    
    mod_rewrite prefixes CGI environment variables with **REDIRECT_**, so you have to instruct Shibboleth2 to use headers instead.
    
    Shibboleth 1.3 always uses headers, therefore the `ShibUseHeaders` directive is invalid with Shibboleth 1.3.
    

    DEBUG mode

    If you enable DEBUG mode on the module configuration interface, you can dump the whole $_SERVER array. This shows you all the available attributes and helps you diagnosing possible Shibboleth attribute problems. * Keep in mind that some users might have a specific attribute while others don't.

    Debug path prefix

    Leave it empty, if you want to display debug information on every page. For example use user/ for display DEBUG messages on paths user/*

    Adding a prefix is useful, if you want to enable debugging on an online drupal installation without littering all of the pages with the debugging information. Can be set to a non-existent node as well, in this case, the information will be displayed over the built-in 404 page.

    Setting Shibboleth parameters for the module

    Handler settings

    If you are using lazy sessions, you have to define the Shibboleth SessionInitiator to which the user should be directed when she clicks on "Login with Shibboleth". SessionInitiator URL is constituted of the following:

    /etc/shibboleth/shibboleth2.xml snippet:

    <Sessions lifetime="28800" timeout="3600" checkAddress="false"
              handlerURL="/Shibboleth.sso" handlerSSL="false"
              exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
              idpHistory="false" idpHistoryDays"7">
      <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
                        relayState="cookie" entityID="https://idp.example.org/shibboleth">
        <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
        <SessionInitiator type="Shib1" defaultACSIndex="5"/>
      </SessionInitiator>
      <!-- other things -->
    </Sessions>
    

    For this example, you should have:

    Attribute settings

    Specify here the $_SERVER headers to look up the user's username and e-mail address. Please check DEBUG mode to look for the available headers. If you can not find the desired attribute, then something is wrong with your IdP-SP attribute release flow.

    Both fields can have the same value, if you wish.

    Using custom e-mail address

    Logging out

    Session expiry

    Enable the option "Destroy Drupal session when the Shibboleth session expires", if you want to force logout the users without a valid Shibboleth session. (This only applies to lazy sessions, otherwise you are always having a Shibboleth session.)

    !!! info

    Keep in mind if you leave this option off:
    
    * if the Shibboleth session is lost, all the Shibboleth-derived attributes disappear, therefore the user loses the [assigned Shibboleth roles](#bkmrk-automatic-role-assignment)
    	* on the other hand, the roles assigned to the *Drupal account of the user* persist as long as the Drupal session is valid
    * Shibboleth session might get lost if you use a clustered SP without a central session cache
    

    URL to redirect to after logout

    Define an URL here, where you want the user to be navigated after logout. The URL can be absolute or relative to the server base url. The relative paths will be automatically extended with the site base URL.

    SAML2 Logout

    At the moment, Shibboleth2 SP supports SAML2 logout while the Shibboleth2 IdP does not. It has a consequence that (if you have a standard Shibboleth2 installation), you will get a Shibboleth error message on logout, like this:

    Global Logout
    Status of Global Logout: Identity provider does not support SAML 2 Single Logout protocol.
    

    You can avoid this message by commenting out SAML2 global logout initiator from /Logout handler in /etc/shibboleth/shibboleth2.xml:

     <!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
     <LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
       <!-- The following line should be commented out to make Drupal logout work,
            as long as your IdPs do not support SAML2 logout -->
       <!--LogoutInitiator type="SAML2" template="bindingTemplate.html"/-->
       <LogoutInitiator type="Local"/>
     </LogoutInitiator>
    

    Automatic role assignment

    It's possible to assign roles to users based on their Shibboleth attributes.

    An assignment rule is made of three parameters:

    All these rules are evaluated at module initiation time. That means that revoking/adding a Shibboleth attribute rule will take effect immediately on next page refresh. The same applies when the set of headers is happened to be changed.

    Additional roles can be assigned statically to the user (as an individual) by the administrator as normally.

    !!! danger "Figyelem"

    Dynamic roles are not visible on the role administration page and on the user page. These roles are evaluated dynamically and are not saved to the database.
    

    Using module

    Automatic user creation

    Drupal CMS requires all users to be in its internal SQL database. If the module detects that no user exists in the database with the received Shibboleth user identifier, it creates a new (Drupal) user.

    Disallowing password change

    There is no way for the module to detect if a user has been deleted from Shibboleth. This simple fact has a number of consequences.

    When a user is first logged in, a Drupal account is automatically created for her. Because Drupal requires a password, a random string is generated for password. Normally the user doesn't need it.

    Now suppose that your user is about to leave your institution. If she is malicious enough, she can go to the password change form, reset her password to a known one, and even after she is deleted from the IdP, she still can log in to your precious resource with the (now known) password. (Note that it is only achievable with lazy sessions!).

    Therefore, if your requirements are such that only Shibboleth-authenticated users can log in, YOU MUST DISABLE PASSWORD CHANGE for users.

    Steps for disallowing your users to change their passwords:

    1. Install Drupal User Protect module
    2. At Administer -> User management -> User Protect -> Protected roles tab check password for the authenticated user role.
    3. At Administer -> Permissions -> userprotect module: uncheck change own password for authenticated user
    4. Log in with a normal account, go to "My account" -> Edit. You shouldn't see the possibility for changing password; except for the case when the user has user administrator rights.

    Administrator / password login

    If you are using lazy sessions, you can still login with password. If you disabled the username/password login block, append the following to your normal Drupal URL: /?q=user

    Administering Drupal with strict sessions

    If you use strict sessions, you can not log in with a password. It's quite tricky to circumvent it:

    1. Enable Shibboleth protection
    2. Login with your own user credentials, so that your Drupal user profile is created
    3. Disable Shibboleth protection
    4. Login as 'admin', grant your own user 'Administrator' rights.
    5. Enable Shibboleth protection
    6. Login with your own credentials, you should have 'Administrator' rights now.

    Change log

    Version 3.2 -> 3.3

    Module update problem was fixed. From now on one should run update.php on updates. Previous version

    Version 3.1 -> 3.2

    The module now works with caching, but requires disabling and re-enabling. Previous version

    Version 3.0 -> 3.1

    If you need documentation for 3.0, please use the previous version of the documentation

    Tanúsítványok_a_föderációban

    SAML2 föderációkban az entitásoknak ismerniük kell egymás publikus kulcsát (amelyet X.509 tanúsítványokban osztanak meg egymással) ahhoz, hogy biztonságosan kommunikálhassanak egymással. Eközben a felhasználókkal is interakcióba lépnek, ami miatt könnyű összekeverni a két fajta tanúsítványt:

    1. amit az IdP/SP a felhasználó felé használ;
    2. amit másik entitások (SP/IdP) felé használ.

    A felhasználók felé olyan tanúsítványt kell használni, amelyben a felhasználók böngészője megbízik. Ez a tanúsítvány nem szerepel a föderációs metadatában, ellenben a webszerver konfigurációjában hivatkozni kell rá. Jellemzően valamilyen jól ismert CA-val (pl. DigiCert vagy letsencrypt) aláírt tanúsítványt, ami azt is jelenti, hogy rendszeresen cserélni kell őket.

    A föderációs metadatában szereplő tanúsítványt elsősorban a föderációs alkalmazás (Shibboleth, SimpleSAMLphp) konfigurációjában kell megadni, mert ez az, amivel alá tudja írni az általa küldött üzeneteket, illetve dekódolni tudja a fogadott titkosított adatokat. Ez a tanúsítvány lehetőség szerint hosszú (10+ éves) lejáratú, self-signed tanúsítvány legyen.

    Shibenv-PHP

    Eredeti forrás: http://shib.kuleuven.be/download/sp/test_scripts/shibenv.php.txt

    <html>
    <head>
      <title>Shibboleth Attributes - <?php echo $_SERVER["SERVER_NAME"]; ?></title>
      <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
      <META HTTP-EQUIV="Expires" CONTENT="-1">
    <script language"JavaScript" type="text/JavaScript">
    <!--
      function decodeAttributeResponse() {
            var textarea = document.getElementById("attributeResponseArea");
            var base64str = textarea.value;
            var decodedMessage = decode64(base64str);
            textarea.value = tidyXml(decodedMessage);
            textarea.rows = 15;
            document.getElementById("decodeButtonBlock").style.display='none';
      }
    
      function tidyXml(xmlMessage) {
            //put newline before closing tags of values inside xml blocks
            xmlMessage = xmlMessage.replace(/([^>])</g,"$1\n<");
            //put newline after every tag
            xmlMessage = xmlMessage.replace(/>/g,">\n");
            var xmlMessageArray = xmlMessage.split("\n");
            xmlMessage="";
            var nestedLevel=0;
            for (var n=0; n < xmlMessageArray.length; n++) {
                    if ( xmlMessageArray[n].search(/<\//) > -1 ) {
                            nestedLevel--;
                    }
                    for (i=0; i<nestedLevel; i++) {
                            xmlMessage+="  ";
                    }
                    xmlMessage+=xmlMessageArray[n]+"\n";
                    if ( xmlMessageArray[n].search(/\/>/) > -1 ) {
                            //level status the same
                    }
                    else if ( ( xmlMessageArray[< 0 ) && (xmlMessageArray[n](n].search(/<\//)).search(/</) > -1) ) {
                            //only increment if this was a tag, not if it is a value
                            nestedLevel++;
                    }
            }
            return xmlMessage;
      }
    
      var base64Key = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
      function decode64(encodedString) {
        var decodedMessage = "";
        var char1, char2, char3;
        var enc1, enc2, enc3, enc4;
        var i = 0;
    
        //remove all characters that are not A-Z, a-z, 0-9, +, /, or =
        encodedString = encodedString.replace(/[^A-Za-z0-9\+\/\=]/g, "");
        do {
            enc1 = base64Key.indexOf(encodedString.charAt(i++));
            enc2 = base64Key.indexOf(encodedString.charAt(i++));
            enc3 = base64Key.indexOf(encodedString.charAt(i++));
            enc4 = base64Key.indexOf(encodedString.charAt(i++));
    
            char1 = (enc1 << 2) | (enc2 >> 4);
            char2 = ((enc2 & 15) << 4) | (enc3 >> 2);
            char3 = ((enc3 & 3) << 6) | enc4;
    
            decodedMessage = decodedMessage + String.fromCharCode(char1);
            if (enc3 != 64) {
                    decodedMessage = decodedMessage + String.fromCharCode(char2);
            }
            if (enc4 != 64) {
                    decodedMessage = decodedMessage + String.fromCharCode(char3);
            }
        } while (i < encodedString.length);
        return decodedMessage;
      }
    // -->
    </script>
    </head>
    
    
    <body>
    
    <b>-all SHIB headers-</b> (`HTTP_SHIB_ATTRIBUTES` is not shown in this list)
    <?php
    echo '<table>';
    foreach ($_SERVER as $key => $value)
    {
            $fkey='_'.$key;
            if ( strpos($fkey,'SHIB')>1 && $key!="HTTP_SHIB_ATTRIBUTES")
    #       if ( strpos($fkey,'SHIB')>1 )
            {
                    echo '<tr>';
                    echo '<td>'.$key.'</td><td>'.$value.'</td>';
                    echo '</tr>';
            }
    }
    echo '<tr><td>(REMOTE_USER)</td><td>'.$_SERVER['REMOTE_USER'].'</td></tr>';
    echo '<tr><td>(HTTP_REMOTE_USER)</td><td>'.$_SERVER['HTTP_REMOTE_USER'].'</td></tr>';
    echo '<tr><td>HTTP_SHIB_LOGOUTURL</td><td>'.$_SERVER['HTTP_SHIB_LOGOUTURL']
    .'<a href="/Shibboleth.sso/Logout?return='.$_SERVER['HTTP_SHIB_LOGOUTURL'].
    '%3Freturn%3Dhttps%3A%2F%2Fshib.kuleuven.be%2Flogout.shtml">[logout]</a> </td></tr>';
    echo '</table>';
    ?>
    <br/>
    
    attribute response from the IdP (`HTTP_SHIB_ATTRIBUTES`):<br/>
    <textarea id="attributeResponseArea" onclick="select()" rows="1" cols="130">
    <?php echo $_SERVER["HTTP_SHIB_ATTRIBUTES"]; ?></textarea><br/>
    <span id="decodeButtonBlock">
    <input type="button" id="decodeButton" value="decode base64 encoded attribute response using JavaScript"
    onClick="decodeAttributeResponse();"><br/></span>
    
    <br/>
    
    <small>
    notes:<br/>
    The AAP throws away invalid values (eg an unscopedAffiliation of value "myBoss@&lt;yourdomain&gt;" or a value
    with an invalid scope which scope is checked)<br/>
    The raw attribute response (`HTTP_SHIB_ATTRIBUTES`) is NOT filtered by the AAP and should therefore
    be disabled for most applications (`exportAssertion=false`).<br/>
    </small>
    
    <br/>
    <hr/>
    <br/>
    
    
    <b>$_REQUEST</b>
    <?php
    echo '<table>';
    foreach ($_REQUEST as $key => $value)
    {
            echo '<tr>';
            echo '<td>'.$key.'</td><td>'.$value.'</td>';
            echo '</tr>';
    
    }
    echo '</table>';
    ?>
    
    
    
    <br/>
    <hr/>
    <br/>
    
    <b>$_SERVER</b>
    <?php
    echo '<table>';
    foreach ($_SERVER as $key => $value)
    {
            echo '<tr>';
            echo '<td>'.$key.'</td><td>'.$value.'</td>';
            echo '</tr>';
    
    }
    echo '</table>';
    ?>
    
    <br/>
    <hr/>
    <br/>
    
    <b>$_SESSION</b>
    <?php
    echo '<table>';
    foreach ($_SESSION as $key => $value)
    {
            echo '<tr>';
            echo '<td>'.$key.'</td><td>'.$value.'</td>';
            echo '</tr>';
    
    }
    echo '</table>';
    ?>
    
    <br/>
    <hr/>
    <br/>
    
    </body>
    </html>
    

    ShibMessages

    HTTP headers

    Discovery Service, SAML2 Artifact

    Felhasználó -> SP (1)

    https://webadmin.iif.hu/ticketing/

    GET /ticketing/ HTTP/1.1
    
    HTTP/1.x 302 Found
    Set-Cookie: _shibstate_7ed01b05=https%3A%2F%2Fwebadmin.iif.hu%2Fticketing%2F; path=/
    Location: https://ds.niif.hu?entityID=https%3A%2F%2Fwebadmin.iif.hu%2Fshibboleth&return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05
    

    A felhasználó lekéri a védett szolgáltatást, ám a Shibboleth modul közbeavatkozik, mivel még nincs Shibboleth session. Beállít egy cookie-t, ami alapján később rekonstruálható, hogy a felhasználó milyen szolgáltatást (URL) akart igénybe venni.

    Mivel még nem lehet tudni a felhasználót azonosító IdP-t, ezért az SP átirányítja a felhasználót az Discovery Service-hez

    Felhasználó -> DS

    https://ds.niif.hu/?entityID=https%3A%2F%2Fwebadmin.iif.hu%2Fshibboleth&return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05

    GET /?entityID=https%3A%2F%2Fwebadmin.iif.hu%2Fshibboleth&return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05 HTTP/1.1
    
    HTTP/1.x 200 OK
    Set-Cookie: _redirection_state=checked; expires=Mon, 18-May-2009 07:10:01 GMT; path=/; domain=ds.niif.hu
    

    https://ds.niif.hu/?entityID=https%3A%2F%2Fwebadmin.iif.hu%2Fshibboleth&return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05

    POST /?entityID=https%3A%2F%2Fwebadmin.iif.hu%2Fshibboleth&return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05 HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 80
      user_idp=https%3A%2F%2Fidp.niif.hu%2Fshibboleth&Select=V%C3%A1laszt&session=true
    
    HTTP/1.x 302 Found
    Set-Cookie: _saml_idp=aHR0cHM6Ly9pZHAubmlpZi5odS9zaGliYm9sZXRo; expires=Sun, 12-Feb-2012 08:10:47 GMT; path=/; domain=ds.niif.hu
    Set-Cookie: _redirect_user_idp=https%3A%2F%2Fidp.niif.hu%2Fshibboleth; path=/; domain=ds.niif.hu
    Set-Cookie: _redirection_state=checked; expires=Wed, 26-Aug-2009 08:10:47 GMT; path=/; domain=ds.niif.hu
    Location: https://webadmin.iif.hu/Shibboleth.sso/DS?SAMLDS=1&target=cookie%3A7ed01b05&entityID=https%3A%2F%2Fidp.niif.hu%2Fshibboleth
    

    A példában egy PHP alkalmazás, a SWITCH WAYF (Discovery Service) egy legördülő listában felsorolja az IdP-ket (IP cím alapján előválasztást végez), majd a megfelelő kiválasztása után ezt egy cookie-ban eltárolja, mivel bejelöltük, hogy jegyezze meg a választást a munkamenet végéig. (Lehetőség van arra is, hogy megmaradó cookie-ban tárolja a kiválasztott IdP-t.)

    Felhasználó -> SP (2)

    https://webadmin.iif.hu/Shibboleth.sso/DS?SAMLDS=1&target=cookie%3A7ed01b05&entityID=https%3A%2F%2Fidp.niif.hu%2Fshibboleth

    GET /Shibboleth.sso/DS?SAMLDS=1&target=cookie%3A7ed01b05&entityID=https%3A%2F%2Fidp.niif.hu%2Fshibboleth HTTP/1.1
    Cookie: _shibstate_7ed01b05=https%3A%2F%2Fwebadmin.iif.hu%2Fticketing%2F
    
    HTTP/1.x 302 Found
    Location: https://idp.niif.hu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZJPT8JAEMW%2FSrN3um0BgQ0lqXCQBJVQ9ODFTNup3WS7W3e2ot%2Fe8kfBg9w2%0A2XnvzftlpgS1akTSukpv8L1Fct5nrTSJw0fMWquFAZIkNNRIwuUiTe5XIvID%0A0VjjTG4U8xIitE4aPTea2hptivZD5vi0WcWscq4hwfkOMyhqqX0pS79qeVrJ%0ALDMKXeUTGb63jXjS2ZSQO%2BYtul2khr3r2UMWja9P%2Bu7NuxVKqfAk3mAhLeaO%0Ap%2Bkj85aLmL1GkyEEEAEUWX9c9PtFCOUEokE5uMkzKEfdGFGLS00OtItZFAST%0AXjDsheNtMBZhIAajF%2BatT01vpS6kfruOJTsOkbjbbte9c6FntHQo0w2x2XQP%0AWBzC7QXy69bww5nN%2FqNKv1Sn%2FCLimNeIh85zuVgbJfMvL1HK7OYWwWHMQsZn%0AR8nfe5h9Aw%3D%3D%0A&RelayState=cookie%3A7ed01b05
    

    Az SP a HTTP requestben megkapott entityID paraméterből tudja meg, hogy ki a felhasználóhoz tartozó IdP. Ez alapján kikeresi a metaadatok közül az IdP SingleSignOnService URL-jét, és odairányítja a felhasználót, hogy azonosítsa magát.

    Felhasználó -> IdP

    https://idp.niif.hu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZJPT8JAEMW%2FSrN3um0BgQ0lqXCQBJVQ9ODFTNup3WS7W3e2ot%2Fe8kfBg9w2%0A2XnvzftlpgS1akTSukpv8L1Fct5nrTSJw0fMWquFAZIkNNRIwuUiTe5XIvID%0A0VjjTG4U8xIitE4aPTea2hptivZD5vi0WcWscq4hwfkOMyhqqX0pS79qeVrJ%0ALDMKXeUTGb63jXjS2ZSQO%2BYtul2khr3r2UMWja9P%2Bu7NuxVKqfAk3mAhLeaO%0Ap%2Bkj85aLmL1GkyEEEAEUWX9c9PtFCOUEokE5uMkzKEfdGFGLS00OtItZFAST%0AXjDsheNtMBZhIAajF%2BatT01vpS6kfruOJTsOkbjbbte9c6FntHQo0w2x2XQP%0AWBzC7QXy69bww5nN%2FqNKv1Sn%2FCLimNeIh85zuVgbJfMvL1HK7OYWwWHMQsZn%0AR8nfe5h9Aw%3D%3D%0A&RelayState=cookie%3A7ed01b05

    GET /idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZJPT8JAEMW%2FSrN3um0BgQ0lqXCQBJVQ9ODFTNup3WS7W3e2ot%2Fe8kfBg9w2%0A2XnvzftlpgS1akTSukpv8L1Fct5nrTSJw0fMWquFAZIkNNRIwuUiTe5XIvID%0A0VjjTG4U8xIitE4aPTea2hptivZD5vi0WcWscq4hwfkOMyhqqX0pS79qeVrJ%0ALDMKXeUTGb63jXjS2ZSQO%2BYtul2khr3r2UMWja9P%2Bu7NuxVKqfAk3mAhLeaO%0Ap%2Bkj85aLmL1GkyEEEAEUWX9c9PtFCOUEokE5uMkzKEfdGFGLS00OtItZFAST%0AXjDsheNtMBZhIAajF%2BatT01vpS6kfruOJTsOkbjbbte9c6FntHQo0w2x2XQP%0AWBzC7QXy69bww5nN%2FqNKv1Sn%2FCLimNeIh85zuVgbJfMvL1HK7OYWwWHMQsZn%0AR8nfe5h9Aw%3D%3D%0A&RelayState=cookie%3A7ed01b05 HTTP/1.1
    Cookie: _idp_authn_lc_key=_d1a773919fda20f6c4558c8784464ec0; JSESSIONID=2B35F7B27204BFE395EFB14C0BD27C2F; _idp_session=MTkzLjYuMjIyLjM%3D%7COWM0Y2Q5NzBoZDhhMJUwODdlMzgzNDk0NjLjNjA1ZLE2NmV1NjliMGFiMDRhZjBjOWY1MTA4ZjU0NDg3NjdjNA%3D%3D%7CWxuDg8LyyZtzzEUsqImA693l5yg%3D
    
    HTTP/1.x 302 Moved Temporarily
    Set-Cookie: _idp_authn_lc_key=_2594d4018d24a282156d9b9fc758d78b; Path=/idp; Secure
    Set-Cookie: _idp_authn_lc_key=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT
    Location: https://webadmin.iif.hu/Shibboleth.sso/SAML2/Artifact?SAMLart=AAQAAhzkZRgbhm%2BltdAF2yKfBGO7t%2BpaTrn3F1DpnZKFEAFI451jQHWhtBs%3D&RelayState=cookie%3A7ed01b05
    

    A felhasználó korábban már azonosítva lett, ezért létezik session-je az IdP oldalán. Ezért nem történik meg a felhasználónév és jelszó bekérése.

    Az IdP elkészíti a válasz SAML üzenetet, majd ebből Artifact-ot képez, és ezt GET paraméterként visszaküldi az SP-nek.

    Felhasználó -> SP (3)

    https://webadmin.iif.hu/Shibboleth.sso/SAML2/Artifact?SAMLart=AAQAAhzkZRgbhm%2BltdAF2yKfBGO7t%2BpaTrn3F1DpnZKFEAFI451jQHWhtBs%3D&RelayState=cookie%3A7ed01b05

    GET /Shibboleth.sso/SAML2/Artifact?SAMLart=AAQAAhzkZRgbhm%2BltdAF2yKfBGO7t%2BpaTrn3F1DpnZKFEAFI451jQHWhtBs%3D&RelayState=cookie%3A7ed01b05 HTTP/1.1
    Cookie: _shibstate_7ed01b05=https%3A%2F%2Fwebadmin.iif.hu%2Fticketing%2F
    
    HTTP/1.x 302 Found
    Set-Cookie: _shibstate_7ed01b05=; path=/; expires=Mon, 01 Jan 2001 00:00:00 GMT
    Set-Cookie: _shibsession_64656661756c7468747470733a2f2f77656261646d696e2e6969662e68752f73686962626f6c657468=_5aec103f1a8edb85ee42e4124ec0d222; path=/
    Location: https://webadmin.iif.hu/ticketing/
    

    Az IdP artifact üzenetét ellenőrzi az SP, majd - amennyiben a felhasználó jogosult az erőforrás igénybevételére - az SP tovább irányítja az alkalmazáshoz. Létrejön egy SP oldali session, ehhez a böngészőben cookie tartozik (_shibsession_).

    SP -> IdP

    Az SP SOAP kapcsolatot nyit az IdP ArtifactResolutionService URL-jére, ahol az Artifact alapján megkapja a teljes SAML response-t.

    Felhasználó -> Alkalmazás

    https://webadmin.iif.hu/ticketing/

    GET /ticketing/ HTTP/1.1
    Cookie: _shibsession_64656661756c7468747470733a2f2f77656261646d696e2e6969662e68752f73686962626f6c657468=_5aec103f1a8edb85ee42e4124ec0d222
    
    HTTP/1.x 200 OK
    

    Discovery Service, POST

    SAML üzenetek

    AuthN request

    <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
     xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
     ID="_afb021be7729adaa166dfb31b7c2c212c9d83183b9" Version="2.0"
     IssueInstant="2009-05-19T08:07:26Z" ForceAuthn="false" IsPassive="false"
     Destination="https://idptest.aai.niif.hu/idp/profile/SAML2/Redirect/SSO"
     ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
     AssertionConsumerServiceURL="https://papigw.aai.niif.hu/simplesaml/saml/sp/AssertionConsumerService.php">
      <saml:Issuer>https://papigw.aai.niif.hu/simplesaml/saml2</saml:Issuer>
      <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" AllowCreate="true"/>
    </samlp:AuthnRequest>
    

    HTML Form

    POST profil használata esetén az IdP az alábbi formot küldi a felhasználó böngészőjének:

    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
    
        <body onload="document.forms[0].submit()">
            <noscript>
                <p>
                    <strong>Note:</strong> Since your browser does not support JavaScript,
                    you must press the Continue button once to proceed.
                </p>
            </noscript>
    
            <form action="https://register.ca.niif.hu/Shibboleth.sso/SAML/POST" method="post">
                <div>
                    <input type="hidden" name="SAMLResponse" value="PD94bWwgdmVyc2l ... wb25zZT4="/>
                    <input type="hidden" name="TARGET" value="cookie"/>
                </div>
                <noscript>
                    <div>
                        <input type="submit" value="Continue"/>
                    </div>
                </noscript>
            </form>
    
        </body>
    </html>
    

    A form JavaScript-et támogató böngészők esetén automatikusan, a felhasználó közreműködése nélkül elküldésre kerül az SP-nek. A SAML válaszüzenet a SAMLResponse (rejtett) HTML mezőben található, base64 kódolással.

    A SAMLResponse egy aláírt struktúra, opcionálisan titkosítható is. A válaszban opcionálisan szerepelhetnek a felhasználó attribútumai is (Attribute Push).

    SAML response, attribute push

    <?xml version="1.0" encoding="UTF-8"?>
    <samlp:Response Destination="https://be.aai.niif.hu/Shibboleth.sso/SAML2/POST" ID="_aecdf7920af52601ec97c78081968367" InResponseTo="_37534da3d36f1d629638c464f2614881" IssueInstant="2009-05-12T08:19:27.303Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
      <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.niif.hu/shibboleth</saml:Issuer>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <ds:Reference URI="#_aecdf7920af52601ec97c78081968367">
            <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
              <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                <ec:InclusiveNamespaces PrefixList="ds saml samlp xs" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
              </ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>6BFgTMoHL9ynMIZpyYC+FG6v7mY=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
    nFsKAKnKhCr0J3W7yNoj8ulFPbB4Ba3ZUxJvtwahzCXMSCCEdUUNhIUntMhK3BpP10NGvf45SsH3
    Ff0Vy0LvGe3hlmK/YmI+8oou/U0vJoQ2W8y4SBVtUXoJBb1GP2uhqnyW9Skmn8C7/bj0qc2ezieH
    aOHEf1AGQyVnQxVJ64WIjlGT4AUTIMQzLTQ8+4yWNu2xJNHd5Pu55oqg7OhmWXDoaHGg46Gs+iXV
    vD8wVi4Im4HlM3UL3VdOCwH0/aSGuy1yVoLAjvPTk/Dit2caB07HMMBVFErLW/alUm31L57QG8iW
    iGkJi8GVZIL1Z1M0CxYrFG6TCSjlgNXBvFBGRA==
    </ds:SignatureValue>
        <ds:KeyInfo>
          <ds:X509Data>
            <ds:X509Certificate>MIIEmDCCA4CgAwIBAgILAQAAAAABGt7sf+4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCQkUx
    EzARBgNVBAoTCkN5YmVydHJ1c3QxFzAVBgNVBAsTDkVkdWNhdGlvbmFsIENBMSIwIAYDVQQDExlD
    eWJlcnRydXN0IEVkdWNhdGlvbmFsIENBMB4XDTA4MDcwMTE0MDAwOFoXDTExMDcwMTE0MDAwOFow
    SDELMAkGA1UEBhMCSFUxFTATBgNVBAoTDE5JSUYgSW50ZXpldDEMMAoGA1UECxMDQUFJMRQwEgYD
    VQQDEwtpZHAubmlpZi5odTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN06iS7LKoLF
    5t5bUWBBUKnoMTVaufs1YMpiZKtEmbLqI/bNC4oq84JIf7118r698SjrZrLUbXLdnp9WIt4iAcHp
    iY0Fa+0EJbtuylPuJ9iSzkqp9LIHwDbDid88kYAhM/MgELmKnn5xKUriskP2Z9He73j2JcLIeCUL
    r20g4cwwhOed8fdJHqTVrDhYn6tao4/gbInNA28t86oACFzPGCWarU2J1RMSDPK/5J8DDf/ZjYFj
    ebiBgIVjNboj/YO/il4Syi3/dcw+4B6pMQvG/VkcMiB4/AnZ3nfSbuEuqDCz/SA1/lxXqYuRS+Qy
    +KF9mh5dwHvxIw/OknAOkFgqnrMCAwEAAaOCAWowggFmMFAGA1UdIARJMEcwRQYHKoZIsT4BADA6
    MDgGCCsGAQUFBwIBFixodHRwOi8vd3d3Lmdsb2JhbHNpZ24ubmV0L3JlcG9zaXRvcnkvY3BzLmNm
    bTAOBgNVHQ8BAf8EBAMCBaAwHwYDVR0jBBgwFoAUZWWjPdc7EaMKByU3yUJKW3Z3UOEwHQYDVR0O
    BBYEFHCsimk81XhEkoU79Q2SVj85b8OdMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZ2xv
    YmFsc2lnbi5uZXQvZWR1Y2F0aW9uYWwuY3JsME8GCCsGAQUFBwEBBEMwQTA/BggrBgEFBQcwAoYz
    aHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLm5ldC9jYWNlcnQvZWR1Y2F0aW9uYWwuY3J0MB0GA1Ud
    JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAWBgNVHREEDzANggtpZHAubmlpZi5odTANBgkqhkiG
    9w0BAQUFAAOCAQEATd78nlxnA5rMRwmbsa7yUssbx0sO86A3sFc28OLp92uYdgLMc0/Vg/hG3mAH
    wA9CwaSeBbBRB2GK34vFFi6nCgWQomf+QuWkbarYBrFbG1LZ1VfvKdy3HewLwGI2cTsxVN67uUjE
    +EsYna1yDWJY8GcaAvnkuey+O6HDSgmLy4lLdLKFbIcx4zL6ZBrXmFARc1oemRmZ3gJROTylfL8n
    lM8T8MmiZESdDLoldxAHhMLtnLBWJcyfzfu70qPX/aXxnoLkoMl6Qz1CRQYjWOnn88g1MvWbg7aG
    8thm/tTFesjf9uo4Ma9Rs86CwS21iaJNp/joRYmb0NfN9tLpAP2Kjw==</ds:X509Certificate>
          </ds:X509Data>
        </ds:KeyInfo>
      </ds:Signature>
      <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
      </samlp:Status>
      <saml:Assertion ID="_914a5a444f1802bfaa78fd151855642a" IssueInstant="2009-05-12T08:19:27.303Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.niif.hu/shibboleth</saml:Issuer>
        <saml:Subject>
          <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_1ea7e9633566f74726244c463af2e397</saml:NameID>
          <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml:SubjectConfirmationData Address="193.6.223.101" InResponseTo="_37534da3d36f1d629638c464f2614881" NotOnOrAfter="2009-05-12T08:24:27.303Z" Recipient="https://be.aai.niif.hu/Shibboleth.sso/SAML2/POST"/>
          </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions NotBefore="2009-05-12T08:19:27.303Z" NotOnOrAfter="2009-05-12T08:24:27.303Z">
          <saml:AudienceRestriction>
            <saml:Audience>urn:niif.hu:aai:HREF:be:be.aai.niif.hu</saml:Audience>
          </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2009-05-12T08:19:27.145Z" SessionIndex="35dd1f81812518aa35822c97780abed2e137b049fcbb66d5dd89d78560cc8bc9">
          <saml:SubjectLocality Address="193.6.223.101"/>
          <saml:AuthnContext>
            <saml:AuthnContextDeclRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</saml:AuthnContextDeclRef>
          </saml:AuthnContext>
        </saml:AuthnStatement>
        <saml:AttributeStatement>
          <saml:Attribute FriendlyName="schacHomeOrganizationType" Name="urn:oid:1.3.6.1.4.1.25178.1.2.10" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:mace:terena.org:schac:homeOrganizationType:int:nren</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute FriendlyName="cn" Name="urn:oid:2.5.4.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Bajnok Kristóf</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">bajnokk@niif.hu</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">employee@niif.hu</saml:AttributeValue>
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">staff@niif.hu</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute FriendlyName="sn" Name="urn:oid:2.5.4.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Bajnok</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute FriendlyName="givenName" Name="urn:oid:2.5.4.42" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Kristóf</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute FriendlyName="schacHomeOrganization" Name="urn:oid:1.3.6.1.4.1.25178.1.2.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">niif.hu</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute FriendlyName="eduPersonOrgDN" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">o=niifi,o=niif,c=hu</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">bajnokk@niif.hu</saml:AttributeValue>
          </saml:Attribute>
          <saml:Attribute FriendlyName="eduPersonEntitlement" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:niif.hu:services:aai:entitlement:test1</saml:AttributeValue>
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:niif.hu:services:aai:entitlement:test2</saml:AttributeValue>
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:mace:rediris.es:entitlement:wiki:jra5</saml:AttributeValue>
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:geant:edugain:entitlement:eduroam:TTS</saml:AttributeValue>
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:geant:edugain:entitlement:eduroam:wiki</saml:AttributeValue>
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">urn:mace:rediris.es:entitlement:wiki:tfemc2</saml:AttributeValue>
          </saml:Attribute>
        </saml:AttributeStatement>
      </saml:Assertion>
    </samlp:Response>
    

    HREFPolicyStub

    Általános elvárások

    Adatvédelmi elvárások

    Identitás kezeléssel kapcsolatos elvárások

    A Tag és Partner egyéb kötelezettségei az NIIF AAI üzemeltetés érdekében

    AboutEduID.hu

    Purpose of this document

    This document is a collection of the information specified in several specific documents written in Hungarian. Since only Hungarian educational and research institutions are expected to be Federation Members (ie. operate an Identity Provider), this document focuses on rules what are relevant to (international) Federation Partners.

    About the federation

    Hungarian Research and Educational Federation (HREF) is a SAML2-based Identity Federation of Hungarian higher education and research institutions, public collections and other content providers. For the end-users, the federation aims to be transparent, therefore the login procedure is communicated as eduID login.

    Contacts

    The Federation is operated by NIIF Institute as a Federation Operator. Questions, concerns or any kind of requests about the Federation should be directed to any of the following addresses:

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

    Policy and principles of interoperation

    Basic principles

    1. The aim of the Federation is to allow the use of services of its Members and Partners, where authorisation is based on the user information originating from the users' Home Institutions.
    2. Home Institutions must only authenticate users having a known affiliation to them.
    3. IdPs and SPs must not give false or misleading information about themselves.
    4. User information provided by IdPs should be as accurate as possible. SPs must take into account that parts of the received information may be at the discretion of the user.
    5. User credentials (i.e. passwords) stored by IdPs must be protected and verified only through secure procedures.
    6. SPs must request only the user attributes which are absolutely necessary for their operation.
    7. SPs must not ask users for their federation passwords.
    8. SPs must handle personal data according to the local privacy laws.
    9. IdPs and SPs must cooperate in the investigation of possible abuse/fraud.
    10. IT systems running IdPs and SPs must be operated with due diligence.

    Data protection

    Rules of membership

    The Federation is operated by the Federation Operator, that also operates the national research network. Further participants are Members and Partners that must have a signed contract with the Operator.

    1. The following institutions may be Members of the federation:
      • Institutions of the higher education;
      • Institutions of the Hungarian Research Academy and other research institutions;
      • Institutions of secondary education;
      • Public collections.
    2. Any organisation might join as a Partner.
    3. All Members and Partners of the Federation might provide services.
    4. A Partner might participate in the meeting of the Members' Board as an observer, without having rights to vote.
    5. Only Members are entitled to
      • supply user identity information to the federation
      • send representatives into the Members' Board with a right to vote.

    Governance

    The governance body of the federation is the Members' Board (MB). Every Federation Member may send one representative person to the Members' Board, who has one vote.

    The working language of the MB is Hungarian. The Board publishes its decisions and guidelines at http://eduid.hu/dokumentumok in Hungarian, although whenever the topic is of interest of any international Partner, it shall be translated to English and the administrative contacts shall be notified.

    MB is authorised to

    Partners may also send representatives for MB meetings, without voting rights.

    The Federation itself is not a legal entity, Members and Partners establish a legal connection to the Federation Operator. Any legal claims between Members and/or Partners shall be directed to the organisation operating the Identity Provider or the Service Provider.

    The Service Agreement between the Federation Operator and Partner is available here.

    Technical information

    Operational requirements

    Attributes

    Attribute Specification is maintained in a separate document.

    As a brief summary, the following attributes are mandatory or recommended: | Mandatory attributes | Recommended attributes | |---| |eduPersonPrincipalName |displayName | |eduPersonTargetedID |mail | |eduPersonScopedAffiliation |eduPersonEntitlement | |schacHomeOrganizationType |

    IdPs may implement other attributes.

    Metadata

    Metadata Specification is maintained in a separate document.

    How to join

    Production federation

    In order to join the production federation as a Partner, you need to send the following information:

    This information should be sent to the Federation Operator (see above) in email. Two copies of the signed Service Agreement (available at http://eduid.hu/documents) should be sent by traditional post, one copy will be returned after counter-signing.

    After the application has been reviewed by the Federation Operator, it is forwarded to the Members' Board. It usually takes 3-5 working days for the Board to accept the application, after which the entity metadata is be added to the production federation metadata.

    Testing metadata

    The following information is necessary to enter into the testing metadata:

    You can ask for test accounts in our Virtual Home Organization. During testing, you might want to use the production federation metadata, because the VHO is present in both metadata files.

    You do not need to re-register your entity to proceed to the production federation. If we have all the necessary information, the starting of the joining process is at your discretion.

    Shib2IdpRHELQuickStart

    Ideális esetben az alábbi lépéseket végigjárva működő IdP-t kaphatunk RHEL, vagy ezzel rokonrendszereken.

    Előkészületek

    Tűzfal

    Shibboleth IdP letöltése

    cd /tmp
    wget http://software.niif.hu/maven2/edu/internet2/middleware/shibboleth-identityprovider/2.2.1-slo10/shibboleth-identityprovider-2.2.1-slo10-bin.tar.gz
    tar xzf shibboleth-identityprovider-2.2.1-slo10-bin.tar.gz
    

    Telepíteni is fogjuk később, de előbb beállítjuk a környezetet. A kicsomagolt állományból is kell majd ezt-azt másolni, ezért vettük előre a folyamatot.

    Tomcat

    A /etc/tomcat6/tomcat6.conf állományba tegyük be az alábbi sort: JAVA_ENDORSED_DIRS="/usr/share/tomcat6/endorsed"

    A fájl tartalma pedig a következő legyen (úgy tervezzük, hogy a /usr/local/shibboleth-idp alá telepítünk mindjárt)

    <Context
           docBase="/usr/local/shibboleth-idp/war/idp.war"
           privileged="true"
           antiResourceLocking="false"
           antiJARLocking="false"
           unpackWAR="false" />
    

    Apache

    A webszervernek meg kell mondani, hogy egyfelől hallgasson a 8443-as porton is, másfelől, hogy a /idp-re érkező kéréseket proxyzza tovább a tomcat felé

    SSO URL (443-as port)

    Be kell állítani a virtuális hosztot, amelyhez az IdP-t rendeltük. Először a 443-as portot konfiguráljuk. A 443-as porthoz tartozó tanúsítványok nem azonosak a 8443-as porthoz tartozóéval.

     <VirtualHost _default_:443>
       ServerName aai.example.org:443
       SSLEngine On
       SSLCertificateFile /etc/ssl/certs/aai.example.org.crt
       SSLCertificateKeyFile /etc/ssl/private/aai.example.org.key
       SSLCertificateChainFile /etc/ssl/certs/aai.example.org.crt
       ProxyRequests Off
       <Proxy ajp://localhost:8009>
         Allow from all
       </Proxy>
       ProxyPass /idp ajp://localhost:8009/idp retry=5
     </VirtualHost>
    

    Ezen a porton valamilyen széles körben ismert tanúsítványt kell használni, mivel a felhasználók böngészőjének ismerniük kell(ene) a kibocsátót.

    AA ill. Artifact (8443-as port)

    Ezen keresztül az SP és az IdP közvetlenül kommunikálnak egymással. Ide arra a tanúsítványra van szükség, amely a föderációs metadatában szerepel - az aláírója nem érdekes.

    A csatorna felépítésekor az IdP és az SP is autentikálja magát. Az SP autentikációját az Apache végzi, ami nem végez kibocsátó-ellenőrzést (optional_no_ca). Ez utóbbit az IdP alkalmazás végzi el, ezért nagyon fontos, hogy a kliens tanúsítványát az Apache továbbadja az alkalmazásnak (ExportCertData).

     <VirtualHost _default_:8443>
       ServerName aai.example.org:8443
       SSLEngine On
       SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:!SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
       SSLCertificateFile /usr/local/shibboleth-idp/credentials/idp.crt
       SSLCertificateKeyFile /usr/local/shibboleth-idp/credentials/idp.key
       SSLVerifyDepth 10
       SSLVerifyClient optional_no_ca
       SSLOptions -StdEnvVars +ExportCertData
       ProxyRequests Off
       <Proxy ajp://localhost:8009>
         Allow from all
       </Proxy>
       ProxyPass /idp ajp://localhost:8009/idp retry=5
     </VirtualHost>
    

    A virtuális hoszt engedélyezése után be kell tölteni az ssl és proxy_ajp modulokat, majd újra kell indítani az apache-ot.

    Telepítés

    cd /tmp/shibboleth-identityprovider-2.2.1-slo10
    ./install.sh
    

    Utómunkálatok

    Jogosultságok beállítása

    Engedjük meg, hogy a tomcat írja a log ill. a metadata könyvtárat

    chown -R tomcat:tomcat /usr/local/shibboleth-idp/logs /usr/local/shibboleth-idp/metadata
    

    Naplófájlok rotálása

    Az alapértelmezett logging.xml nem törli a régi állományokat, ezért ezek egy idő után megtöltik a diszket.

    Erre a korrekt megoldás az (lenne), ha a Logback alrendszert utasítjuk, hogy az N (a példában 90) napnál régebbi fájlokat rotálja ki. Ehhez a logging.xml-ben adjuk meg a maxHistory paramétert az összes rollingPolicy-nál, valahogy így:

     <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
       <FileNamePattern>/usr/local/shibboleth-idp/logs/idp-access-%d{yyyy-MM-dd}.log</FileNamePattern>
       <maxHistory>4</maxHistory>
     </rollingPolicy>
    

    Sajnos azonban jelenleg a logback csak egy állományt töröl, a régi file-okat megtartja (pl. akkor is, ha több, mint egy napig nem futott az IdP. Amíg ez nincs megoldva, addig kerülő megoldás lehet cron-ból törölni a régi file-okat

    sudo crontab -u tomcat -e
    
    MAILTO=mail@example.com
    #m h  dom mon dow   command
    52 18 *   *   *     find /var/log/shibboleth-idp/ -mtime +90 -delete
    

    Ellenőrzés

    Ahhoz, hogy kiderítsük, működik-e (ill. fut-e :) ) az IdP webalkalmazásunk, ahhoz böngészőben hívjuk meg az alábbi urlt: https://idp.example.org/idp/profile/Status, amennyiben az oldalon egy ok-t látunk, akkor az alkalmazásunk fut, és elkezdhetjük beállítani az attribútumok feloldását és kiadását.

    Konfiguráció

    Ha idáig rendben vagyunk, nyergeljünk át erre a szócikkre

    NIIFSchema

    NIIF LDAP Schema

    Versioning

    Current version: 2.3

    Change log

    Schema files

    ObjectClasses

    niifPerson

    niifPerson
    Parent inetOrgPerson
    OID 1.3.6.1.4.1.11914.0.0.0
    Description -
    Mandatory attributes -
    Optional attributes

    niifEduPerson

    niifEduPerson
    Parent eduPerson
    OID 1.3.6.1.4.1.11914.0.0.9
    Description -
    Mandatory attributes -
    Optional attributes

    niifAuthenticatedObject

    niifAuthenticatedObject
    Parent -
    OID 1.3.6.1.4.1.11914.0.0.10
    Description An object having extra passwords or time-limited validity
    Mandatory attributes -
    Optional attributes

    Defined attributes

    Attributes of niifPerson

    niifUniqueID

    niifUniqueID
    OID 1.3.6.1.4.1.11914.0.1.3
    Description Unique ID of a person.
    Semantics <unique-local-ID>@<organization-domain> The <organization-domain> part equals to the main internet domain of the organization (i.e.: 'sztaki.hu').The <unique-local-ID> part is a sequence of letters (case insensitive) and numbers. It can be freely chosen by the home organization provided that the ID is unique within the scope of the organization and one and only one ID is assigned to every single person.
    Values nincs korlátozás
    # of values single
    Availability organizational
    Syntax Directory String
    Examples gmx3f0@bme.hu
    Notes It is up to the local policy to define how the <unique-local-ID> is generated and how long does it represent a user. However, assigning the same ID to another person (after the first person entry has been removed from the directory) is deprecated.It is recommended to import the user ID into <unique-local-ID> from a comprehensive user database (like Neptun and ETR at Hungarian Universities) if such a database exists.
    Use in federation -

    niifPrefix

    niifPrefix
    OID 1.3.6.1.4.1.11914.0.1.0
    Description OBSOLETED, use niifPersonPrefix
    Semantics -
    Values nincs korlátozás
    # of values multi
    Availability -
    Syntax Directory String
    Examples -
    Notes -
    Use in federation -

    niifPersonPrefix

    niifPersonPrefix
    OID 1.3.6.1.4.1.11914.0.1.165
    Description Prefix of the person's name
    Semantics A name should have only one prefix, multiple entitlements may be listed one after the other in the same value
    Values nincs korlátozás
    # of values single
    Availability public
    Syntax Directory String
    Examples Prof. Dr.
    Notes -
    Use in federation HREF_attribútum_specifikáció#schacPersonalTitle

    niifStatus

    niifStatus
    OID 1.3.6.1.4.1.11914.0.1.1
    Description OBSOLETED, use niifPersonDegree
    Semantics -
    Values nincs korlátozás
    # of values multi
    Availability -
    Syntax Directory String
    Examples -
    Notes -
    Use in federation -

    niifPersonDegree

    niifPersonDegree
    OID 1.3.6.1.4.1.11914.0.1.166
    Description Scientific degree of the person
    Semantics Only the highest degree should be stored.
    Values nincs korlátozás
    # of values multi
    Availability public
    Syntax Directory String
    Examples kandidátus
    Notes May be specified in multiple languages by the use of language tags
    Use in federation -

    niifTitle

    niifTitle
    OID 1.3.6.1.4.1.11914.0.1.2
    Description OBSOLETED, use niifPersonPosition
    Semantics -
    Values nincs korlátozás
    # of values multi
    Availability -
    Syntax Directory String
    Examples -
    Notes -
    Use in federation -

    niifPersonPosition

    niifPersonPosition
    OID 1.3.6.1.4.1.11914.0.1.167
    Description Position of the person within a department or organization
    Semantics -
    Values nincs korlátozás
    # of values multi
    Availability -
    Syntax Directory String
    Examples dékán
    Notes May be specified in multiple languages by the use of language tags.When a person is in relationship with multiple departments or organizations, no exact match between a status and a particular organization can be defined within an entry. To solve this situation, some relation-representing entry may be used, eg. use of the schacPersonalPosition attribute, which defines an URN format for this purpose.
    Use in federation -

    niifCertificateSubjectDN

    niifCertificateSubjectDN
    OID 1.3.6.1.4.1.11914.0.1.151
    Description Subject DN of the certificate of the entity. This attribute is OBSOLETED, use niifCertificateSHA1Fingerprint instead.
    Semantics The value must describe a DN which identifies the certificate subject of the entity.
    Values Unlike standard LDAP DN, this value must contain the same number of spaces between DN elements as it is tied in the certificate.
    # of values multi
    Availability -
    Syntax Directory String
    Examples -
    Notes Although it is possible for an entity to have more than one certificates at the same time, this kind of usage is deprecated.When used, this attribute must be indexed. This attribute may be applied to any kind of entities that can be certified with an X.509 certificate, including persons, servers, network nodes, etc.
    Use in federation -

    niifCertificateSHA1Fingerprint

    niifCertificateSHA1Fingerprint
    OID 1.3.6.1.4.1.11914.0.1.173
    Description Fingerprint of a certificate which belongs to the subject.
    Semantics Multiple fingerprints may be stored in this attribute, if a subject has multiple valid certificates. This attribute uses case insensitive matching rule.
    Values SHA-1 hash in hexadecimal string format without any separator characters.
    # of values multi
    Availability -
    Syntax IA5String
    Examples fe6d5980e2c02912024054cec114ee53ebeb2e6c
    Notes -
    Use in federation -

    niifPersonDateOfBirth

    niifPersonDateOfBirth
    OID 1.3.6.1.4.1.11914.0.1.152
    Description Date of birth of the person
    Semantics -
    Values YYYYMMDD date format according to RFC 3339 'full-date' format
    # of values single
    Availability confidential
    Syntax Directory String
    Examples 19800316
    Notes It's recommended to use the schacDateOfBirth attribute instead, as it has the same syntax and semantics.
    Use in federation HREF_attribútum_specifikáció#schacDateOfBirth,HREF_attribútum_specifikáció#schacYearOfBirth

    niifPersonActivityStatus

    niifPersonActivityStatus
    OID 1.3.6.1.4.1.11914.0.1.153
    Description Activity status
    Semantics Describes whether the person is an active employee/student of the home organization
    Values One of the term 'active' or 'inactive'
    # of values single
    Availability organizational
    Syntax Directory String
    Examples -
    Notes -
    Use in federation -

    niifActiveMemberOf

    niifActiveMemberOf
    OID 1.3.6.1.4.1.11914.0.1.168
    Description DN of a group entry to which the entity currently belongs.
    Semantics -
    Values nincs korlátozás
    # of values multi
    Availability -
    Syntax Directory String
    Examples -
    Notes As a special case, this attribute may be used to keep a record of a student's active major(s), but it's recommended to use niifEduPersonMajor instead.
    Use in federation -

    niifPersonJoinDate

    niifPersonJoinDate
    OID 1.3.6.1.4.1.11914.0.1.169
    Description Date of joining to the organization
    Semantics Date of joining to the organization. For students it may represent the first date of enrollment.
    Values YYYYMMDD date format according to RFC 3339 'full-date' format
    # of values single
    Availability organizational
    Syntax Integer
    Examples 19980901
    Notes -
    Use in federation -

    niifPersonQuitDate

    niifPersonQuitDate
    OID 1.3.6.1.4.1.11914.0.1.170
    Description Date of leaving the organization
    Semantics -
    Values YYYYMMDD date format according to RFC 3339 'full-date' format.
    # of values single
    Availability organizational
    Syntax Integer
    Examples 20030627
    Notes If this date is in the past, niifPersonActivityStatus must be 'inactive', and the user should be locked out.
    Use in federation -

    niifPersonOrgID

    niifPersonOrgID
    OID 1.3.6.1.4.1.11914.0.1.154
    Description Organizational ID of a person
    Semantics ID of a person in a comprehensive organizational user database if such a database exists. This ID shall be unique within the organization.It is strongly recommended to use the <unique-local-ID> part of the niifUniqueID as a value for niifPersonOrgID.
    Values For integration with niifUniqueID, value must not contain the '@' mark.
    # of values single
    Availability -
    Syntax Directory String
    Examples -
    Notes It is recommended to import the user ID into <unique-local-ID> from a comprehensive user database (like Neptun and ETR at Hungarian Universities) if such a database exists.This attribute is for facilitating the use of user ID's in intra-organizational applications in cases when standard uid attribute can not be applied for some reason.
    Use in federation -

    niifPersonCityOfBirth

    niifPersonCityOfBirth
    OID 1.3.6.1.4.1.11914.0.1.155
    Description The city or settlement where the person was born
    Semantics Name of the city or settlement where the person was born. If the place of birth is outside the borders of Hungary, the name may be given in Hungarian.
    Values nincs korlátozás
    # of values single
    Availability confidential
    Syntax Directory String
    Examples Kolozsvár
    Notes It's recommended to use the schacPlaceOfBirth attribute instead.
    Use in federation -

    niifPersonCountryOfBirth

    niifPersonCountryOfBirth
    OID 1.3.6.1.4.1.11914.0.1.156
    Description The country where the person was born
    Semantics Name of the country where the person was born. If the place of birth is outside the borders of Hungary, the name must be given in Hungarian.
    Values nincs korlátozás
    # of values single
    Availability confidential
    Syntax Directory String
    Examples Románia
    Notes It's recommended to use the schacPlaceOfBirth attribute instead.
    Use in federation -

    niifPersonMothersName

    niifPersonMothersName
    OID 1.3.6.1.4.1.11914.0.1.157
    Description Name of the mother of the person
    Semantics Maiden name of the mother of the person.
    Values nincs korlátozás
    # of values single
    Availability confidential
    Syntax Directory String
    Examples -
    Notes -
    Use in federation -

    niifPersonIdentityNumber

    niifPersonIdentityNumber
    OID 1.3.6.1.4.1.11914.0.1.158
    Description Number of the Identity Card
    Semantics Number of the Identity Card of the person or Passport Number for those who are non-Hungarian citizens
    Values nincs korlátozás
    # of values single
    Availability confidential
    Syntax Directory String
    Examples 329906AA
    Notes Every Hungarian citizen by the age of 14 receives an Identity Card. For foreigners, Passport Number should be used. This number should never be made public.Format of the code may vary as numbering scheme has been changed in the recent years.It's recommended to use the URN-formatted schacPersonalUniqueID attribute instead.
    Use in federation -

    niifPersonResidentialAddress

    niifPersonResidentialAddress
    OID 1.3.6.1.4.1.11914.0.1.159
    Description Home address of the person
    Semantics Permanent home address of the person. The postal code, the name of the city, street and apartment number shall be included.
    Values nincs korlátozás
    # of values single
    Availability confidential
    Syntax Directory String
    Examples 1234 Budapest, Harap u. 3.
    Notes -
    Use in federation -

    Attributes of niifEduPerson

    niifEduPersonFaculty

    niifEduPersonFaculty
    OID 1.3.6.1.4.1.11914.0.1.160
    Description Faculty of the person
    Semantics Full name of the faculty the person belongs to. List of accredited faculties can be found here (in institutional order): http://www.mab.hu/doc/akkrint040106.doc (in Hungarian)
    Values nincs korlátozás
    # of values multi
    Availability organizational
    Syntax Directory String
    Examples Villamosmérnöki és Informatikai Kar
    Notes Local directory policy may mark this attribute as mandatory.It is recommended if an LDAP entry has niifEduPersonFaculty attribute set, it should also have an eduPersonFacultyDN attribute pointing to the entry of the faculty.
    Use in federation -

    niifEduPersonFacultyDN

    niifEduPersonFacultyDN
    OID 1.3.6.1.4.1.11914.0.1.161
    Description Pointer to the faculty of the person
    Semantics -
    Values nincs korlátozás
    # of values multi
    Availability organizational
    Syntax DN
    Examples -
    Notes This attribute has a meaning only if the person participates in education (eduPersonAffiliation=student or faculty)Local directory policy may mark this attribute as mandatory.
    Use in federation -

    niifEduPersonMajor

    niifEduPersonMajor
    OID 1.3.6.1.4.1.11914.0.1.162
    Description Major(s) of the student
    Semantics Majors are defined at http://www.mab.hu/listak2.html (in Hungarian)
    Values nincs korlátozás
    # of values multi
    Availability organizational
    Syntax Directory String
    Examples műszaki informatikai
    Notes This attribute has a meaning only if the person is a student (eduPersonAffiliation=student)Local directory policy may mark this attribute as mandatory for students.
    Use in federation -

    niifEduPersonAcademicYear

    niifEduPersonAcademicYear
    OID 1.3.6.1.4.1.11914.0.1.163
    Description Current academic year of the student. This attribute is DEPRECATED.
    Semantics -
    Values Integer numbers from 1 to the number of years required for graduation
    # of values multi
    Availability confidential
    Syntax Directory String
    Examples -
    Notes This attribute has a meaning only if the person is a student (eduPersonAffiliation = student)It is unclear that if a student has more than one majors, the number of which should be stored in this attribute and how a connection between major and year can be set up. As the concept of academic year gets lesser important (and not well-defined), depending on the value of this attribute is deprecated.
    Use in federation -

    niifEduPersonAttendedCourse

    niifEduPersonAttendedCourse
    OID 1.3.6.1.4.1.11914.0.1.164
    Description Code of the courses the student attends to in the current semester
    Semantics -
    Values Course codes defined in the student calendar.
    # of values multi
    Availability -
    Syntax Directory String
    Examples
  • BMEVIMM1234
  • BMEVIMA3214
  • Notes This attribute has a meaning only if the person is a student (eduPersonAffiliation = student), and the values should be taken from the student calendar.
    Use in federation -

    niifEduPersonArchiveCourse

    niifEduPersonArchiveCourse
    OID 1.3.6.1.4.1.11914.0.1.171
    Description Code of the courses the student have ever attended
    Semantics -
    Values Course codes defined in the student calendar.
    # of values multi
    Availability -
    Syntax Directory String
    Examples -
    Notes This attribute has a meaning only if the person is a student (eduPersonAffiliation = student), and the values should be taken from the student calendar.
    Use in federation -

    niifEduPersonHeldCourse

    niifEduPersonHeldCourse
    OID 1.3.6.1.4.1.11914.0.1.172
    Description Code of the courses which are associated with the faculty member or professor in the current semester.
    Semantics -
    Values Course codes defined in the student calendar.
    # of values multi
    Availability -
    Syntax Directory String
    Examples -
    Notes This attribute has a meaning only if the person is a faculty (eduPersonAffiliation = faculty), the values should be taken from the student calendar.For authorization decision reasons, courses from previous semester(s) might appear in this attribute if the local policy needs these additional values.
    Use in federation -

    Attributes of niifAuthenticatedObject

    niifEduroamPassword

    niifEduroamPassword
    OID 1.3.6.1.4.1.11914.0.1.4
    Description Clear text password for eduroam authentication
    Semantics -
    Values nincs korlátozás
    # of values multi
    Availability -
    Syntax Octet String
    Examples -
    Notes SUP userPassword
    Use in federation -

    niifValidityStart

    niifValidityStart
    OID 1.3.6.1.4.1.11914.0.1.5
    Description When to enable this account
    Semantics -
    Values nincs korlátozás
    # of values single
    Availability -
    Syntax Generalized Time
    Examples -
    Notes -
    Use in federation -

    niifExpireTime

    niifExpireTime
    OID 1.3.6.1.4.1.11914.0.1.6
    Description When to disable this account
    Semantics -
    Values nincs korlátozás
    # of values single
    Availability -
    Syntax Generalized Time
    Examples -
    Notes -
    Use in federation -

    Shib2SP

    Az SP-t a shibboleth2.xml állományon keresztül konfigurálhatjuk. Ebben a leírásban feltételezzük, hogy az SP konfigurációja a /etc/shibboleth könyvtárban van.

    Előkészületek

    Működő példa konfiguráció 1

    <SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
        xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
        xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
        clockSkew="180">
    
        <!--
        By default, in-memory StorageService, ReplayCache, ArtifactMap, and SessionCache
        are used. See example-shibboleth2.xml for samples of explicitly configuring them.
        -->
    
        <!--
        To customize behavior for specific resources on Apache, and to link vhosts or
        resources to ApplicationOverride settings below, use web server options/commands.
        See https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPConfigurationElements for help.
    
        For examples with the RequestMap XML syntax instead, see the example-shibboleth2.xml
        file, and the https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRequestMapHowTo topic.
        -->
    
        <!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
        <ApplicationDefaults entityID="https://events.prace-ri.eu/shibboleth"
                             REMOTE_USER="eppn"
                             cipherSuites="ECDHE+AESGCM:ECDHE:!aNULL:!eNULL:!LOW:!EXPORT:!RC4:!SHA:!SSLv2">
    
            <!--
            Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
            You MUST supply an effectively unique handlerURL value for each of your applications.
            The value defaults to /Shibboleth.sso, and should be a relative path, with the SP computing
            a relative value based on the virtual host. Using handlerSSL="true", the default, will force
            the protocol to be https. You should also set cookieProps to "https" for SSL-only sites.
            Note that while we default checkAddress to "false", this has a negative impact on the
            security of your site. Stealing sessions via cookie theft is much easier with this disabled.
            -->
            <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
                      checkAddress="false" handlerSSL="false" cookieProps="http">
    
                <!--
                Configures SSO for a default IdP. To allow for >1 IdP, remove
                entityID property and adjust discoveryURL to point to discovery service.
                (Set discoveryProtocol to "WAYF" for legacy Shibboleth WAYF support.)
                You can also override entityID on /Login query string, or in RequestMap/htaccess.
                -->
    
                    <SSO discoveryProtocol="SAMLDS" discoveryURL="https://mdx.eduid.hu/role/idp.ds">
                     SAML2 SAML1
                    </SSO>
    
    
                <!-- SAML and local-only logout. -->
                <Logout>SAML2 Local</Logout>
    
                <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
                <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
    
                <!-- Status reporting service. -->
                <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>
    
                <!-- Session diagnostic service. -->
                <Handler type="Session" Location="/Session" showAttributeValues="false"/>
    
                <!-- JSON feed of discovery information. -->
                <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
    
            </Sessions>
    
            <!--
            Allows overriding of error template information/filenames. You can
            also add attributes with values that can be plugged into the templates.
            -->
            <Errors supportContact="prace-indico-admin@niif.hu"
                helpLocation="/about.html"
                styleSheet="/shibboleth-sp/main.css"/>
    
            <MetadataProvider type="Dynamic" ignoreTransport="true">
                  <Subst>https://mdx.eduid.hu/entities/$entityID</Subst>
                  <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
            </MetadataProvider>
    
            <!-- Example of remotely supplied batch of signed metadata. -->
            <!--
            <MetadataProvider type="XML" validate="true"
                  uri="http://example.org/federation-metadata.xml"
                  backingFilePath="federation-metadata.xml" reloadInterval="7200">
                <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
                <MetadataFilter type="Signature" certificate="fedsigner.pem"/>
                <DiscoveryFilter type="Blacklist" matcher="EntityAttributes" trimTags="true"
                  attributeName="http://macedir.org/entity-category"
                  attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                  attributeValue="http://refeds.org/category/hide-from-discovery" />
            </MetadataProvider>
            -->
    
            <!-- Example of locally maintained metadata. -->
            <!--
            <MetadataProvider type="XML" validate="true" file="partner-metadata.xml"/>
            -->
    
            <!-- Map to extract attributes from SAML assertions. -->
            <AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>
    
            <!-- Use a SAML query if no attributes are supplied during SSO. -->
            <AttributeResolver type="Query" subjectMatch="true"/>
    
            <!-- Default filtering policy for recognized attributes, lets other data pass. -->
            <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>
    
            <!-- Simple file-based resolver for using a single keypair. -->
            <CredentialResolver type="File" key="events-shib.key" certificate="events-shib.cert"/>
    
            <!--
            The default settings can be overridden by creating ApplicationOverride elements (see
            the https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride topic).
            Resource requests are mapped by web server commands, or the RequestMapper, to an
            applicationId setting.
    
            Example of a second application (for a second vhost) that has a different entityID.
            Resources on the vhost would map to an applicationId of "admin":
            -->
            <!--
            <ApplicationOverride id="admin" entityID="https://admin.example.org/shibboleth"/>
            -->
        </ApplicationDefaults>
    
        <!-- Policies that determine how to process and authenticate runtime messages. -->
        <SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
    
        <!-- Low-level configuration about protocols and bindings available for use. -->
        <ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>
    
    </SPConfig>
    
    Működő példa konfiguráció 2
    
    <SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
        xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
        xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
        logger="syslog.logger" clockSkew="180">
    
        <!-- The OutOfProcess section contains properties affecting the shibd daemon. -->
        <OutOfProcess logger="shibd.logger">
            <!--
            <Extensions>
                <Library path="odbc-store.so" fatal="true"/>
            </Extensions>
            -->
        </OutOfProcess>
    
        <!-- The InProcess section conrains settings affecting web server modules/filters. -->
        <InProcess logger="native.logger">
        </InProcess>
    
        <!-- Only one listener can be defined, to connect in process modules to shibd. -->
        <UnixListener address="shibd.sock"/>
        <!-- <TCPListener address="127.0.0.1" port="12345" acl="127.0.0.1"/> -->
    
        <!-- This set of components stores sessions and other persistent data in daemon memory. -->
        <StorageService type="Memory" id="mem" cleanupInterval="900"/>
        <SessionCache type="StorageService" StorageService="mem" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
        <ReplayCache StorageService="mem"/>
        <ArtifactMap artifactTTL="180"/>
    
        <!-- This set of components stores sessions and other persistent data in an ODBC database. -->
        <!--
        <StorageService type="ODBC" id="db" cleanupInterval="900">
            <ConnectionString>
            DRIVER=drivername;SERVER=dbserver;UID=shibboleth;PWD=password;DATABASE=shibboleth;APP=Shibboleth
            </ConnectionString>
        </StorageService>
        <SessionCache type="StorageService" StorageService="db" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
        <ReplayCache StorageService="db"/>
        <ArtifactMap StorageService="db" artifactTTL="180"/>
        -->
    
        <!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->
        <RequestMapper type="Native">
            <RequestMap applicationId="default">
                <!--
                The example requires a session for documents in /secure on the containing host with http and
                https on the default ports. Note that the name and port in the <Host> elements MUST match
                Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element
                below.
                -->
    		<Host name="wiki.aai.niif.hu" authType="shibboleth"
    			  requireSession="false" applicationId="wiki.aai"
    			  redirectErrors="https://wiki.aai.niif.hu/index.php/Kezd%C5%91lap">
    			<Path name="secure" requireSession="true" />
    		</Host>
    		<Host name="www.aai.niif.hu" authType="shibboleth"
    			  requireSession="false" applicationId="www.aai">
    			<Path name="secure" requireSession="true" />
    		</Host>
            </RequestMap>
        </RequestMapper>
    
        <!--
        The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined.
        Resource requests are mapped by the RequestMapper to an applicationId that
        points into to this section.
        -->
        <ApplicationDefaults id="default" policyId="default"
            entityID="https://lipton.aai.niif.hu/shibboleth"
            homeURL="https://lipton.aai.niif.hu/shib-error.php"
            REMOTE_USER="eppn persistent-id targeted-id"
            signing="false" encryption="false"
            >
    
            <!--
            Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
            You MUST supply an effectively unique handlerURL value for each of your applications.
            The value can be a relative path, a URL with no hostname (https:///path) or a full URL.
            The system can compute a relative value based on the virtual host. Using handlerSSL="true"
            will force the protocol to be https. You should also add a cookieProps setting of "; path=/; secure"
            in that case. Note that while we default checkAddress to "false", this has a negative
            impact on the security of the SP. Stealing cookies/sessions is much easier with this disabled.
            -->
            <Sessions lifetime="28800" timeout="3600" checkAddress="false"
                handlerURL="/Shibboleth.sso" handlerSSL="true"
                exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
                idpHistory="false" idpHistoryDays="7">
    
                <!--
                SessionInitiators handle session requests and relay them to a Discovery page,
                or to an IdP if possible. Automatic session setup will use the default or first
                element (or requireSessionWith can specify a specific id to use).
                -->
    
                <!-- Directly to the IdP -->
                <SessionInitiator type="Chaining" Location="/Login" id="Intranet"
                        relayState="cookie" entityID="https://idp.niif.hu/shibboleth">
                    <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
                    <SessionInitiator type="Shib1" defaultACSIndex="5"/>
                </SessionInitiator>
    
    			<!-- Discovery Service -->
                <SessionInitiator type="Chaining" Location="/DS" id="DS"
    	                      relayState="cookie" acsByIndex="false"
    			      isDefault="true" >
                    <SessionInitiator type="SAML2" template="bindingTemplate.html"
    				  defaultACSIndex="3" />
                    <SessionInitiator type="Shib1" defaultACSIndex="5" />
                    <SessionInitiator type="SAMLDS" URL="https://ds.niif.hu/"/>
                </SessionInitiator>
    	    <SessionInitiator type="Chaining" Location="/SAML1DS" acsByIndex="false" relayState="cookie"
    			      id="Saml1Only">
                	<SessionInitiator type="Shib1" defaultACSIndex="6"/>
                	<SessionInitiator type="SAMLDS" URL="https://ds.niif.hu" />
                </SessionInitiator>
    
                <!--
                md:AssertionConsumerService locations handle specific SSO protocol bindings,
                such as SAML 2.0 POST or SAML 1.1 Artifact. The isDefault and index attributes
                are used when sessions are initiated to determine how to tell the IdP where and
                how to return the response.
                -->
                <md:AssertionConsumerService Location="/SAML2/POST" index="1"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
                <md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
                <md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
                <md:AssertionConsumerService Location="/SAML2/ECP" index="4"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
                <md:AssertionConsumerService Location="/SAML/POST" index="5"
                    Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
                <md:AssertionConsumerService Location="/SAML/Artifact" index="6"
                    Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>
    
                <!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
                <LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
                    <LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
                    <LogoutInitiator type="Local"/>
                </LogoutInitiator>
    
                <!-- md:SingleLogoutService locations handle single logout (SLO) protocol messages. -->
                <md:SingleLogoutService Location="/SLO/SOAP"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
                <md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
                <md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
                <md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
    
                <!-- md:ManageNameIDService locations handle NameID management (NIM) protocol messages. -->
                <md:ManageNameIDService Location="/NIM/SOAP"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
                <md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
                <md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
                <md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
    
                <!--
                md:ArtifactResolutionService locations resolve artifacts issued when using the
                SAML 2.0 HTTP-Artifact binding on outgoing messages, generally uses SOAP.
                -->
                <md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
                    Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
    
                <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
                <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
    
                <!-- Status reporting service. -->
                <Handler type="Status" Location="/Status" acl="127.0.0.1"/>
    
                <!-- Session diagnostic service. -->
                <Handler type="Session" Location="/Session"/>
    
            </Sessions>
    
            <!--
            You should customize these pages! You can add attributes with values that can be plugged
            into your templates. You can remove the access attribute to cause the module to return a
            standard 403 Forbidden error code if authorization fails, and then customize that condition
            using your web server.
            -->
            <Errors session="sessionError.html"
                metadata="metadataError.html"
                access="accessError.html"
                ssl="sslError.html"
                localLogout="localLogout.html"
                globalLogout="globalLogout.html"
                supportContact="root@localhost"
                logoLocation="/shibboleth-sp/logo.jpg"
                styleSheet="/shibboleth-sp/main.css"/>
    
            <!-- Uncomment and modify to tweak settings for specific IdPs or groups. -->
            <!-- <RelyingParty Name="SpecialFederation" keyName="SpecialKey"/> -->
    
            <!-- Chains together all your metadata sources. -->
            <MetadataProvider type="Chaining">
               <MetadataProvider type="XML" uri="https://metadata.eduid.hu/current/href.xml"
                   backingFilePath="href.xml" reloadInterval="7200">
                  <SignatureMetadataFilter certificate="href-metadata-signer-2010.crt"/>
              </MetadataProvider>
               <MetadataProvider type="XML" uri="https://metadata.eduid.hu/current/niifi.xml"
                   backingFilePath="niifi.xml" reloadInterval="7200">
                  <SignatureMetadataFilter certificate="href-metadata-signer-2010.crt"/>
              </MetadataProvider>
            </MetadataProvider>
    
            <!-- Chain the two built-in trust engines together. -->
            <TrustEngine type="Chaining">
                <TrustEngine type="ExplicitKey"/>
                <TrustEngine type="PKIX"/>
            </TrustEngine>
    
            <!-- Map to extract attributes from SAML assertions. -->
            <AttributeExtractor type="XML" path="attribute-map.xml"/>
    
            <!-- Use a SAML query if no attributes are supplied during SSO. -->
            <AttributeResolver type="Query"/>
    
            <!-- Default filtering policy for recognized attributes, lets other data pass. -->
            <AttributeFilter type="XML" path="attribute-policy.xml"/>
    
            <!-- Simple file-based resolver for using a single keypair. -->
            <!-- <CredentialResolver type="File" key="example.key" certificate="example.crt"/> -->
    
            <!-- Example of a second application (using a second vhost) that has a different entityID. -->
            <!-- <ApplicationOverride id="admin" entityID="https://admin.example.org/shibboleth"/> -->
    	<ApplicationOverride id="wiki.aai" entityID="https://wiki.aai.niif.hu/shibboleth" >
    		<CredentialResolver type="File" key="wiki.aai.niif.hu.key"
    				    certificate="wiki.aai.niif.hu.crt"/>
    	</ApplicationOverride>
    	<ApplicationOverride id="www.aai" entityID="https://www.aai.niif.hu/shibboleth" >
    		<CredentialResolver type="File" key="www.aai.niif.hu.key"
    				    certificate="www.aai.niif.hu.crt"/>
    	</ApplicationOverride>
        </ApplicationDefaults>
    
        <!-- Each policy defines a set of rules to use to secure messages. -->
        <SecurityPolicies>
            <!--
            The predefined policy enforces replay/freshness, standard
            condition processing, and permits signing and client TLS.
            -->
            <Policy id="default" validate="false">
                <PolicyRule type="MessageFlow" checkReplay="true" expires="60"/>
                <PolicyRule type="Conditions">
                    <PolicyRule type="Audience"/>
                    <!-- Enable Delegation rule to permit delegated access. -->
                    <!-- <PolicyRule type="Delegation"/> -->
                </PolicyRule>
                <PolicyRule type="ClientCertAuth" errorFatal="true"/>
                <PolicyRule type="XMLSigning" errorFatal="true"/>
                <PolicyRule type="SimpleSigning" errorFatal="true"/>
            </Policy>
        </SecurityPolicies>
    
    
    </SPConfig>
    

    Minimális beállítások

    Környezeti beállítások

    A konfigurációs fájl első negyedében lévő szekciókban elsősorban a Shibboleth futásával kapcsolatos beállítások találhatók, amelyek alapértelmezett értékei legtöbbször megfelelőek az általunk elvárt működéshez.

    RequestMap

    A RequestMap megadja azokat a címeket (Host és Path), amelyeket a Shibboleth SP kezelni fog. Szerkezete:

            <RequestMap applicationId="default">
    		<Host name="wiki.aai.niif.hu" authType="shibboleth"
    			  requireSession="false" applicationId="wiki.aai"
    			  redirectErrors="https://wiki.aai.niif.hu/index.php/Kezd%C5%91lap">
    			<Path name="secure" requireSession="true" />
    		</Host>
    		<Host name="www.aai.niif.hu" authType="shibboleth"
    			  requireSession="false" applicationId="www.aai">
    			<Path name="secure" requireSession="true" />
    		</Host>
            </RequestMap>
    

    A RequestMap több Host elemet is tartalmazhat, a Host elem 0 vagy több Path elemet tartalmazhat.

    !!! danger "Figyelem"

    Ha 1-nél nagyobb mélységű könyvtárat (pl. a `/shibtest/shibreq` nevűt) szeretnénk védeni, akkor **nem** adhatjuk meg a *name* paraméterben a "shibtest/shibreq" értéket, hanem egymásba ágyazott Path elemeket kell használni. A *name* paraméter nem tartalmazhat '/' karaktert.
    

    Az egyes elemeknél paraméterekkel szabályozhatjuk, hogy az SP milyen módon kezelje a hostot vagy az útvonalat. A paraméterek felüldefiniálhatók. A legfontosabb paraméterek az alábbiak (ezek ugyanúgy használhatók Host-nál mint Path-nál):

    ApplicationDefaults

    Ennél a szekciónál tudjuk megadni az általános, minden alkalmazásra érvényes alapbeállításokat. Ezek a beállítások természetesen minden egyes alkalmazás tekintetében felüldefiniálhatók.

    Alapattribútumok

    Sessions

    Ennél a szekciónál állíthatjuk be, hogy az SP miként kezelje a Single Sign-on (SSO) folyamatának egyes részeit. Az alapparamétereken túl (session lejárati idő...stb) ún. handlerek találhatók benne. Természetesen az alapbeállítások alkalmazásonként felülírhatók az <ApplicationOverride> résznél.

    Handlerekről

    A handlerek az SP-n belül működnek, de a fő folyamatoktól leválasztva. Egy-egy speciális feladatot látnak el - mintegy szkript jelleggel. Egy handler a megfelelő URL meghívásával érhető el. Ezen URL meghívásakor az SP felismeri, hogy mely handlert illeti az adott részfeladat megoldása, és átadja neki a feladat ellátásához szükséges paramétereket. Az SP-n belül egy "alaphandler" található, amely felel a handlereket illető feladatok kiosztásáért, ez jelenti majd a handlerek elérési útvonalában a gyökeret.

    Alapattribútumok

    SessionInitiator

    Ennél a szekciónál kerülnek beállításra azok a paraméterek, melyek meghatározzák, hogy az SP kihez-mihez irányítsa a felhasználót, mikor az érvényes session nélkül (tehát autentikáció előtt) próbálja elérni a Shibboleth által védett tartalmat.

    Alapattribútumok
    SessionInitiator főbb típusai

    MetadataProvider

    Ennél a szekciónál kell beállítani, hogy az SP milyen forrásokból jut hozzá a szükséges metaadatokhoz.

    A források 3 fő típusa

    A tanúsítvány innen szerezhető be: https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt

    ApplicationOverride

    Amennyiben az SP több alkalmazást kezel, és ezek között az alkalmazások között vannak olyanok, melyeknek valamely tulajdonsága nem egyezik az SP alapértelmezettként megadott tulajdonságaival (jellemzően ilyen lehet pl. az entityID), akkor ezeket ebben a szekcióban felül lehet definiálni.

    Kiegészítő beállítások

    POST preservation

    Ha legalább 2.2-es verziójú Shibboleth SP-t használunk, úgy lehetőségünk van egy olyan funkció beállítására, amely lehetővé teszi, hogy ha egy felhasználó valamilyen formba ír (pl. egy wikibe), akkor a küldés gomb megnyomásakor a shibboleth egy átmeneti helyen eltárolja a beírt adatokat. Ennek jelentősége, hogy ha írás közben lejárt volna a felhasználó sessionje, így alapértelmezés szerint a bejelentkező oldalra dobná a rendszer, ami által elveszne, amit begépelt, úgy bekapcsolt post preservation esetén ezek az adatok megmenekülnek, nem kell őket újra beírni.

    A funkció bekapcsolásához a <Sessions> elem attribútumaként kell megadni az alábbi két név-érték párt.

    Hiányossága a funkciónak, hogy ha a form tartalmaz file típusú input mezőt, akkor nem fog működni.

    HREF integráció

    1. Az SP-t regisztrálni kell a Resource Registry-ben
    2. Le kell tölteni a metadatához tartozó tanúsítványt a https://metadata.eduid.hu/current/ címről, és elmenteni a shibboleth kofigurációs fájljait tartalmazó könyvtárba
    3. A Metadata beállításoknál meg kell adni a HREF metadata elérhetőségét: https://metadata.eduid.hu/current/href.xml
    4. Az attribute-map.xml fájlban el kell távolítani a kommentjeleket azon attribútumok elől, melyeket az SP használni kíván.
    5. Újra kell indítani a shibboleth démont.

    Resource_Registry

    !!! bug "Elavult információ"

    **Figyelem:** ez a szócikk elavult, a Resource Registry megújult egy ideje!
    

    Alapfogalmak

    Áttekintés

    A Resource Registry az alakuló magyarországi felsőoktatási és kutatási föderáció (HREF) központi eleme, mellyel a föderációban résztvevő szolgáltatások (SP-k) és azonosító szervezetek (IdP-k) adminisztrálását lehet egy letisztult környezetben, elosztott jogosultságokkal végezni. A rendszer az egyes entitásokért felelős adminisztrátorok számára készül.

    A rendszer a svájci SWITCH Intézet által fejlesztett rendszer alapjaira épül, PHP nyelven íródott, adatbázisként MySQL-t használ.

    Funkciók

    A rendszer saját adatbázisból dolgozik, minden funkciójának kimenete ezeken az adatokon alapul.

    Shibboleth 2.x SP-hez:

    Fontos, hogy ezt akkor lehet szinte egy az egyben használni, amennyiben az adott SP csak egy alkalmazást véd. Amennyiben több alkalmazás is igényel Shibbolethet egyazon hoszton, úgy kézzel kell szerkeszteni az xml-t.

    Ez a két fájl egy az egyben használható letöltés után, további konfigurációt alapesetben nem igényel.

    Shibboleth 2.x IdP-hez:

    Ez csak egy keret fájl, a legtöbb olyan elem szerepel benne, amelyeket a helyi viszonyokra szabva már működhet az IdP, ám itt muszáj kézzel is szerkeszteni, pl. LDAP adatok...

    A fájl egyből használható - további információk a fájl előállításának menetéről.

    SimpleSamlPHP-hoz:

    A fájl egyből használható - további információk a fájl előállításának menetéről.

    Bejelentkezés a rendszerbe

    A Resource Registry a https://rr.eduid.hu címen érhető el, és bejelentkezni csak föderatív azonosítás után lehet. A nyitóképernyőn a bejelentkezési lehetőségen túl mindössze általános, nyilvános információk érhetők el a föderáció aktuális állapotával kapcsolatban, ill. a rendszer használatához található segítség.

    A rendszerbe történő bejelentkezéshez elengedhetetlen, hogy a felhasználót azonosító IdP az alábbi attribútumokat átadja a Resource Registry-nek.

    Szerepek a rendszerben

    A Resource Registrybe csak föderatív azonosítás után lehet belépni.

    Felhasználó

    SP adminisztrátor

    IdP adminisztrátor

    RR adminisztrátor

    Alapértelmezés szerint, aki be tud lépni, a legegyszerűbb felhasználói jogosultságokat kapja, bármilyen magasabb szintű szerepkört RR adminisztrátor delegálhat számára, a magasabb jogkörrel járó felelősségi kört pontosan körülhatárolva. (Pl. A RR adminsiztrátor a felhasználót az őt azonosító IdP adminisztrátorává tehet, amely nyomán a felhasználó pontosan ezt az egy IdP-t hangolhatja, de felhasználói jogosultságokat már nem oszthat tovább)

    Fontos, hogy az RR-ben az egyes szerepek egy-egy intézmény adminisztrálásához köthetők, ily módon megvalósítva az elosztott jogosultságkezelést. Egy példán keresztül bemutatva ez azt jelenti, hogy egy felhasználó ha szeretne SP-t felvenni a föderációba, akkor azt csak az őt azonosító intézmény hatókörébe teheti meg, ami azt is jelenti, hogy az adott intézményhez tartozó, RR adminisztrátor jogosultsággal rendelkező felhasználó hagyhatja ezt a regisztrációs-, vagy módosítási kérelmet jóvá. Ugyanez az adminisztrátor csak a saját intézményéhez tartozó entitásokra vonatkozóan oszthat, vagy vonhat vissza jogosultságokat.

    Természetesen létezik Power User, aki mindent lát, mindenhez van jogosultsága, de csak nem várt esemény esetén aktivizálódik valahol az NIIF AAI környékén :), amúgy rendeltetésszerű működés esetén a szubszidiaritás elvét képviselve az intézményeké az őket érintő ügyekben a döntési jog.

    Folyamatok

    SP regisztráció

    Bárki, akit a rendszer föderatív azonosítással beléptetett, kezdeményezheti egy SP föderációba történő felvételét, ehhez az „SP adminisztráció“ oldalon az „Új SP regisztrálása“ c. menüpontot kell választani. Varázsló segít a regisztrációban, melynek mindössze a telepített SP metaadatának nyilvánosan elérhető url-jét kell megadni (alapértelmezés szerint: https://#HOSTNAME#/Shibboleth.sso/Metadata), majd az automata a lehető legtöbb beállítási paramétert megpróbálja kiolvasni az xml-ből, és egyből beírni az adatbázisba az új SP adatai közé. Mivel minden adatot nem lehetséges az alapértelmezett metaadatból kinyerni, így a regisztráló felhasználónak néhány további adatot kell megadnia ahhoz, hogy véglegesíthesse az SP regisztrációs kérelmet. Ezeket hat csoportra lehet osztani.

    SP módosítás

    Egy jóváhagyott SP-t csak a megfelelő jogosultsággal rendelkező felhasználó tud módosítani. Általában egy-egy SP-hez tartozó adminisztrációs jogot az intézmény RR adminisztrátor jogkörrel rendelkező felhasználója osztja ki az adott SP jóváhagyásával egy ütemben.

    A módosítás folyamata teljesen analóg a regisztrációéval, ami a funkciókat illeti.

    FONTOS: Akár regisztráltunk, akár módosítottunk, a változásokat jóvá kell hagynia az Önt azonosító intézet RR adminisztrátorai közül valakinek. Amíg ezek a változtatások bekerülnek a föderációs metaadatba, az legfejjebb egy óra, ám amíg minden föderációs entitás frissíti a metaadatot, így értesül a változásról.

    IdP regisztráció

    A föderációba új IdP-t - mivel a regisztrálandó IdP-t üzemeltető kolléga még nem tud belépni a Resource Registry-be - egy, a föderációs adminisztrációért felelős kolléga tud regisztrálni. Ehhez szükséges, hogy az IdP, minden kapcsolódó programmal együtt telepítve legyen, és az alapértelmezett, telepítéskor generált metaadat egy meghatározott url-en elérhető legyen.

    A telepítéshez - Shibboleth esetében - pl. a Shib2IdpInstall wikilapon található leírás szolgál segítségül. Attribútumokat, autentikációt konfigurálni nem kell, elegendő, ha a Teszt pontnál látjuk a megnyugtató ok szöveget, és minimális beállításokat megejtettük

    Amennyiben ez működik, úgy írni kell egy e-mailt az aai@niif.hu címre, valaki a föderációs adminisztrátorok közül regisztrálja az IdP-t, és a válasz e-mailben elküld két linket, amelyek tartalmaznak két linket az attribute-resolver.xml és attribute-filter.xml már testreszabott konfigurációs fájlokra mutatva. Ezeket letöltve, bemásolva az IdP-nek már működnie kell alapszinten, így már lehetségessé válik a Resource Registry-be történő belépés. Sikeres belépés után az intézményhez tartozó RR jogosultságokat átadjuk, s a továbbiakban mehet minden a maga utáján, intézményi szinten.

    Nagyon fontos, hogy az IdP-n bármilyen módosítás azonnal érvénybe lép, így rossz beállítás esetén akár az IdP által hitelesíthető felhasználók belépése is ellehetetlenülhet.

    A beállítási lehetőségek az alábbiak

    A további négy beállítás némi hozzáértést igényel, lévén az alapértelmezett metaadatból nem olvashatók ki. A rendszer ezeket az értékeket a föderációs szabályoknak, megállapodásoknak megfelelően készíti elő, legtöbb esetben nincs szükség módosításra, ám ha mégis, bármilyen speciális igény okán, akkor nagy odafigyeléssel kell beállítani.

    Attribútumok kezelése

    A föderációban használható attribútumok részletes listája a föderációs attribútum specifikációban található.

    Az egyes attribútumokkal kapcsolatban négy irányból lehetséges beállításokat eszközölni

    További információ az attribútumok implementációjáról, kapcsolódó fogalmakról A fenti beállítások eredőjeként generálódik az IdP-k által használandó XML alapú attirbútum filter fájl

    A generált attribútum filter alapvetően tiltó jellegű, tehát az IdP pontosan azokat az attribútumokat és pontosan azoknak az SP-knek adhatja ki, melyek megadásra kerültek a beállításoknál, egyébként semmit.

    Néhány példa a "leképződésre"

    XML alapú filter

    A filter fájlok Resource Registry által előállított változatát használni nem kötelező, de fokozottan ajánlott, hiszen ezzel garantálható egyfelől, hogy az IdP-n keresztül autentikáló felhasználók azokat az SP-ket, melyeket el kell tudniuk érni, jól fogják, megfelelő attribútumokkal "a zsebükben" fogják tudni elérni, másfelől így tudnak érvényesülni a feljebb részletezett korlátozó szabályzások.

    Adatvédelmi szempontok

    Ha egy SP megváltoztatja attribútum igényeit pozitív irányba (új attribútumokat kér), úgy a változtatás csak akkor fog belekerülni az IdP-k attirbútum filterébe, amennyiben ezt a változtatást tudomásul veszi az IdP oldaláról az illetékes adatvédelmi felelős. Amennyiben egy SP-nél ilyen jellegű változás történik, a rendszer e-mailben értesíti az érintett IdP-k gazdáit, adatvédelmi felelőseit.

    Gyakorlati ajánlás

    Kihasználandó a Resource Registry által biztosított lehetőségeket ajánljuk, hogy az IdP-hez tartozó generált attribútum filter fájlt automatikusan töltsék le az IdP-k, bizonyos időközönként (óránként, naponta párszor...), hiszen ezekbe csak úgy kerülhet változtatás, ha azt az IdP adatvédelmi felelőse jóváhagyta, akkor viszont egyből átvezetődik a változtatás, nem szükséges kézzel letölteni, ill. újraindítani az IdP-t. (Shibboleth esetében be kell állítani egy kapcsolót, SSP-nél automatikusan újratölti a friss XML-t)

    A filter elérhetősége

    Útmutató a beállításhoz

    SSP_EntityCategories

    Ez a lap a simpleSAMLphp EntityCategories moduljának továbbfejlesztett változatához tartozó beállításokat ismerteti. Reményeink szerint a modul valamikor a simpleSAMLphp alapcsomagjának is része lesz, ám amíg ez nem történik meg, addig az alábbiak szerint érdemes eljárni, ha használni szeretnénk.

    A modul forrása: https://github.com/sitya/simplesamlphp-module-entitycategories.git

    Fontos, hogy a modul nem helyettesíti a core:AttributeLimit, vagy a niif:AttributeLimit modult, valamelyikkel együtt használandó!

    Telepítés composeren keresztül

    cd /path/to/simplesamlphp
    composer require simplesamlphp/simplesamlphp-module-entitycategories:dev-master
    composer config repositories.simplesamlphp/simplesamlphp-module-entitycategories vcs https://github.com/sitya/simplesamlphp-module-entitycategories.git
    composer update
    

    Beállítás

    Lévén egy AuthProc modullal van dolgunk, így a rendes authproc szekcióba kell elhelyeznünk valahol a sorban, a core:AttributeLimit, vagy niif:AttrobuteLimit előtt. Az alább részletezett alapbeállításokon túl (default, strict, allowRequestedAttributes) az egyes entityCategory-k URI-jait kell megadni, mint egy tömb kulcsát, és a hozzátartozó tömb értékeiként pedig a megengedett attribútumok URN-jeit. Tetszőleges számú entityCategory-t megadhatunk, a korábbi beállítások elsősorban azt szabályozzák, hogy mi történjen akkor, olyan entitással van dolgunk, akinek nincs a metadatájában megadva EntityCategory, vagy ha van, nem illeszkedik az általunk explicit beállított listában található EntityCategory-k valamelyikére.

    Működő példa

    
      75  => array(
             'class' => 'entitycategories:EntityCategory',
             'default' => true,
             'strict' => true,
             'allowRequestedAttributes' => true,
             'http://eduid.hu/category/registered-by-eduidhu' => array (),
             'http://www.geant.net/uri/dataprotection-code-of-conduct/v1' => array (),
             'http://refeds.org/category/research-and-scholarship' => array(
                 'urn:oid:2.16.840.1.113730.3.1.241', #displayName
                 'urn:oid:2.5.4.4', #sn
                 'urn:oid:2.5.4.42', #givenName
                 'urn:oid:0.9.2342.19200300.100.1.3', #mail
                 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', #eduPersonPrincipalName
                 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9', #eduPersonScopedAffiliation
             ),
      ),
    
      80 => array(
            'class' => 'niif:AttributeLimit',
            'default' => true,
            'bilateralSPs' => array(
                'google.com' => array('mail'),
                'urn:federation:MicrosoftOnline' => array('IDPEmail', 'ImmutableID'),
             ),
      ),
    

    A fenti példa az alábbiakat végzi:

    1. a magyar föderáció által regisztrált entitások számára a Resource Registry-ben beállított attribútumok (RequestedAttributes) alapján történik az attribútum kiadás;
    2. a GÉANT Code of Conduct entitás kategóriájú eduGAIN-es SP-k számára szintén RequestedAttributes alapján történik az attribútum kiadás;
    3. a Research & Scholarship entitás kategóriájú eduGAIN-es SP-k számára kiadjuk a kategória által igényelt attribútumcsomagot
      • az ilyen SP-k RequestedAttributes alapján módosíthatnak az attribútum igényeiken
    4. a fenti kategóriáknak nem megfelelő SP-k közül kizárólag a bilateralSPs tömbben megadott entitásoknak adunk ki attribútumot.

    !!! warning

    Az *entitycategories:EntityCategory* modul *strict* beállítása esetén a lokálisan felvett SP-k esetén nem lesz figyelembe véve az *attributes* tömbelem! Ez azt jelenti, hogy a nem a központi metaadatokból származó SP-ket fel kell venni az *niif:AttributeLimit* modul listájába. Ebből fakadóan ilyen esetben nem is használhatjuk a  *core:AttributeLimit* modult.
    

    Opciók

    default

    Logikai kapcsoló, true/false értékeket vehet fel. Amennyiben true, úgy a beállított EntityCategory-k alatt megadott attribútumkészletet akkor is kiadjuk az adott EntityCategory-val érkező SP-nek, ha az attribútumokat explicit, a RequestedAttribute-ok között nem kérte felsorolva. Ennek az R&S EntityCategorynál van különös jelentősége (a példában is ez szerepel), mert ott a specifikáció kimondja, hogy a meghatározott attributúmkészletet akkor is ki kell adni az R&S-t támogató IdP-nek, amennyiben nincsenek ezen attribútumok tételesen felsorolva, mint RequestedAttributes.

    strict

    Logikai kapcsoló, true/false értékeket vehet fel. Amennyiben true, úgy csak és kizárólag a modul konfigurációjában megadott EntityCategory-val érkező SP-k számára kerülnek attribútumok kiadásra, "ismeretlen" EntityCategory-val bíró, és EntityCategory nélküli SP-k számára nem kerül kiadásra semmi.

    allowRequestedAttributes

    Logikai kapcsoló, true/false értékeket vehet fel. Amennyiben true, úgy megengedjük, hogy egy SP a hozzátartozó EntityCategory konfigurációjában megadott attribútumlistán túl kért attribútumot kiadásra RequestedAttributes-on keresztül, false esetén csak a listában szereplő attribútumok kiadását engedi a modul. Amennyiben az érték true és a strict értéke false, úgy az "ismeretlen" EntityCategory-val bíró SP-k számára is a RequestedAttributes alapján kerülnek kiadásra az attribútumok.

    FedEntitiesLogging

    Naplózási szintek

    ** Shibboleth naplózási szintek:**

    Shibboleth IdP audit naplózás

    Az IdP audit logok az alábbi információkat tartalmazzák:

    Naplózott adatok

    IdP

    Apache

    Tomcat

    IdP alkalmazás

    SP

    Webszerver

    Shibboleth SP

    SimpleSAMLphp SP

    Discovery Service

    SWITCH DS

    A webszerver hasonló adatokat naplózhat (kivéve: IdP választás)

    Internet2 DS

    SimpleSAMLphp DS

    Rotálás

    Statisztikák

    HREF_műszaki_előírások

    A dokumentum célja, hogy a HREF Föderációhoz csatlakozó Tagok és Partnerek számára elvárásokat és ajánlásokat fogalmazzon meg, melyek a csatlakozáshoz szükséges identitás-menedzsment, valamint üzemeltetési területeket fednek le.

    A dokumentumban a KÖTELEZŐ, TILOS, AJÁNLOTT, NEM AJÁNLOTT kifejezések értelmezése az alábbiak szerinti:

    1. Identitás-menedzsment

    2. Szolgáltatás-menedzsment

    3. Üzemeltetési kérdések

    OpenSSO_IdP_-_Shibboleth2_SP

    Cél

    http://maszat.sch.bme.hu -n futó OpenSSO-n IdP létrehozása, és a https://sandbox.aai.niif.hu/shibboleth alatt futó Shibboleth 2 SP-vel való federáció.

    OpenSSO IdP létrehozása

    lásd: OpenSSO

    Cél Realm: /niif-teszt IDP entityID: https://idp.sch.bme.hu/niif-teszt Legalább a "signing certificate alias" -t állítsuk be

    A /opensso/famadm.jsp -> export-entity parancssal tudjuk XML-ként exportálni az létrehozott IDP metaadatát. (Vagy, a /opensso/saml2/jsp/exportmetadata.jsp?entityID=https://idp.sch.bme.hu/niif-teszt&realm=/niif-teszt URL-ről közvetlenül elérhetjük).

    Shibboleth 2 SP beállítása

    /etc/shibboleth/shibboleth2.xml:

    ...
    <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="teszt"
                   relayState="cookie" entityID="https://idp.sch.bme.hu/niif-teszt">
      <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
    </SessionInitiator>
    ...
    <MetadataProvider type="XML" file="maszat-idp.xml"/>
    ...
    

    Shibboleth SP Metadata importálása OpenSSO-ba

    A lementett XML-ből töröljük ki az <md:Extension> node-ot, mivel a parszolás során hibaüzenetet dob, ami a teljes SAML2Meta konfigurációt megfekteti.

    ERROR: SAML2MetaManager.getEntityDescriptor
    javax.xml.bind.UnmarshalException: Unexpected end of element {urn:oasis:names:tc:SAML:2.0:metadata}:Extensions
    ...
    

    Ha ez a hiba előjön, akkor a konfigurációs címtárból kell törölni az entity-t, ugyanis ilyenkor teljesen használhatatlan lesz a felület (ez egy bug sajnos)

    $ ldapmodify ...
    dn: ou=<entityid>,ou=default,ou=OrganizationConfig,ou=1.0,ou=sunFMSAML2MetadataService,ou=services,
     o=<realm>,ou=services,<basedn>
    changetype: delete
    

    A problémát az okozza, hogy amikor a metadata xml-t beolvassa a SAX parszer, akkor JAXB-vel mappeli java objektumokra, és ezt marshallolja ki a konfigurációs store-ba. Viszont az Extensions belseje egy teljesen külön névtér és külön séma, ezért arra nincsenek generált osztályok. Ezt úgy veszi a JAXB, hogy egy <Extensions/> -t ír ki, ami viszont unmarshal időben nem felel meg már a sémának (ugyanis xsd szerint ott legalább egy elemnek lennie kell).

    Egyelőre azt a megoldást javasolták, hogy kézzel szedjem ki az <Extensions> -t, aminek továbbra sem örülök az xml aláírás és a kézi hegesztés miatt. Idővel egy olyan javítást fognak készíteni, amivel user osztálykönyvtárat meg lehet adni az opensso-nak, hogy a metaadat bizonyos részeit (pl. extensions belseje) arra mappelje le. Illetve tettem egy olyan javaslatot, hogy ilyen esetben amikor kinullozza a node belsejét a JAXB, akkor a teljes <Extensions> node-ot töröljék, így legalább az xml valid marad. Talán azt is javítják, hogy ilyenkor a teljes metaadat rész összeomlik és semmilyen műveletet nem lehet végezni. (https://opensso.dev.java.net/issues/show_bug.cgi?id=2736)

    A ManageNameIDService ill. AssertionConsumerService közé írjuk be a következő node-okat:

    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    

    Ha nem adunk meg NameIDFormat -ot, akkor az OpenSSO IdP vissza fogja utasítani a kérést. Megj. https://opensso.dev.java.net/issues/show_bug.cgi?id=2172 hosszútávon ezt a viselkedést valószínű megváltoztatják.

    Ezt a metaadatot a Federation fül Entities -> Import Entity parancssal tudjuk importálni. Itt ki kell választani a /niif-teszt realm-et, és feltölteni az XML-t (vagy megadni az URL-jét). Ezután felül a Circle of Trust-nál hozzá tudjuk már adni a SAML2 SP-t.

    Ha mindezt végigcsináltuk, máris működik minden.

    Problémák

    Ha Shibboleth2 SP-ben külön application-be tesszük a metaadatot, akkor nem találja meg a SAML Response issuer-alapján.

    Az OpenSSO nem jelzi a saml attribútum névformátumát (<saml:Attribute NameFormat="...">). A Shibboleth pedig csak az urn:oasis:names:tc:SAML:2.0:attrname-format:uri típusú nevet fogadja el.

    Emiatt a következő probléma adódik:

    shibd.log:
    
    2008-05-14 18:33:25 INFO Shibboleth.AttributeExtractor : creating mapping for Attribute urn:mace:dir:attribute-def:mail
    ...
    <saml:Attribute Name="urn:mace:dir:attribute-def:mail">
       <saml:AttributeValue
              xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:type="xs:string">hege@*********</saml:AttributeValue>
    </saml:Attribute>
    ...
    2008-05-14 18:33:31 INFO Shibboleth.AttributeExtractor [1]: skipping unmapped SAML 2.0 Attribute
    with Name:  urn:mace:dir:attribute-def:mail, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:unspecifiedd
    

    Itt egy patch OpenSSO-hoz ami megoldja a problémát: https://opensso.dev.java.net/issues/show_bug.cgi?id=2775 Ezen patch használatával a következő módon kell megadni az IDP attribútum mappelést az IDP > Attribute Processing fülön:

    # [NameFormat|]SAMLAttributeName=LocalAttributeName
    urn:oasis:names:tc:SAML:2.0:attrname-format:uri|urn:mace:dir:attribute-def:mail=mail
    

    MTA_Sztaki_IdP

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

    Dunaújvárosi_Főiskola_IdP

    Tulajdonság Érték
    Intézmény (IdP) neve Dunaújvárosi Főiskola (idp2.duf.hu)
    IdP szoftver nincs megadva
    Technikai kapcsolattartó Kovács Csaba, cs.kovacs@mail.duf.hu; Botka István, boti@makacs.duf.hu
    Azonosítható felhasználók száma 280
    Hallgatók száma 5200
    Alkalmazottak száma 130
    Külsősök száma 0
    Nem felhasználóhoz köthető bejegyzések száma 5
    Hallgatók felvételének folyamata Neptun rendszerben regisztrált hallgató adatai folyamatosan szinkronizálásra kerülnek a címtárral.
    Alkalmazottak felvételének folyamata Minden oktató és nem oktató dolgozó a Netware eDirectoryba kerül felvételre a Humánerőforrás Igazgatóságon (HR szervezet). A címtárral való szinkronizásás a dolgozó számára ismertetett jelszómódosítási eljárás alkalmával történik meg. Ettől kezdve tudják használni a föderatív és belső szolgáltatásokat (Shibboleth, Eduroam, SSO).
    Külsősök felvételének folyamata -
    Hallgatók törlésének folyamata Végzett, vagy eltávozott hallgató aktív statusa törlésre kerül. A tanulmányi előadó eltávolítja az edupersonAffiliation: student attribútumot
    Alkalmazottak törlésének folyamata A munkatárs kilépésekor a HR szervezeti előadó eltávolítja az edupersonAffiliation: employee attribútumot, az esetleg használt edupersonEntitlement értékeket. Inaktív felhasználói bejegyzését a címtárból egyelőre nem törlünk. (Kialakítandó az archiválási és törlési szabályozás.)
    Külsősök törlésének folyamata -
    Felhasználó intézményhez való kapcsolatát leíró attribútum/érték
  • Oktató/dolgozó: edupersonAffiliation: employee
  • Hallgató: edupersonAffiliation: students
  • Egyéb alkalmazott: edupersonAffiliation: member
  • 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.A teszt felhasználóknak generált (kis- és nagybetűket, számokat, opcionálisan egyéb karaktereket) tartalmazó jelszavakat állítunk elő.
    Naplóállományok rendelkezésre állási ideje Jelenleg nincs log rotálás
    Autentikációs backend LDAP
    Autentikációs mód Apache
    Vállalt rendelkezésre állás Az Identity Provider funkciót egy virtuális szerverkörnyezetben (Vmware) futó szerver biztosítja. A rendelkezésre állásnak nincs meghatározott értéke (belső szolgáltatás).

    AA_Testing

    The following shell script uses curl to query a SAML2 Attribute Authority.

    You need a valid principal (eduPersonPrincipalName) and the X.509 credentials of an existing Service Provider to use this script.

    Source

    #!/bin/bash
    
    basedir=$(dirname $0)
    
    # URL of the Attribute Authority
    AA_URI="https://hexaa.eduid.hu:8443/simplesaml/module.php/aa/attributeserver.php"
    
    # Testing principal (subject)
    Principal="bajnokk@niif.hu"
    
    # HEXAA cert
    AACert="$basedir/keys/hexaa.eduid.hu-aa.crt"
    
    # EntityID and credentials of the SP on behalf of which
    # the request is made
    ReqSP="https://sp.hexaa.eduid.hu/test"
    ReqCert="$basedir/keys/test.sp.hexaa.eduid.hu-fed.crt"
    ReqKey="$basedir/keys/test.sp.hexaa.eduid.hu-fed.key"
    
    
    usage () {
            cat <<EOS
    Usage: $0 [options]
    
    Options:
      -a uri       Attribute Authority URI. Defaults to '$AA_URI'
      -C certfile  Attribute Authority metadata certificate in PEM format. Defaults to '$AACert'.
      -p principal Testing principal (user name / subject). Defaults to '$Principal'.
      -s entity    EntityID of the SP on behalf of which the request is made. Defaults to '$ReqSP'
      -k keyfile   Key file in PEM format containing the key of the SP used for the request. Defaults to '$ReqKey'
      -c certfile  Cert file in PEM format containing the certificate of the SP used for the request. Defaults to '$ReqCert'
    EOS
            exit 3
    }
    
    # Get command line arguments
    while getopts "a:p:s:k:c:h" opt; do
            case $opt in
                    a)
                            AA_URI=$OPTARG
                            ;;
                    C)
                            AACert=$OPTARG
                            ;;
                    p)
                            Principal=$OPTARG
                            ;;
                    s)
                            ReqSP=$OPTARG
                            ;;
                    k)
                            ReqKey=$OPTARG
                            ;;
                    c)
                            ReqCert=$OPTARG
                            ;;
                    h)
                            usage
                            ;;
                    \?)
                            usage
                            ;;
            esac
    done
    
    DATE=$(date --utc +%FT%TZ)
    ReqID=$(hexdump -n 16 -e '4/4 "%08x" 1 "\n"' /dev/urandom)
    
    
    read -r -d '' REQ_XML <<EOS
    <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
      <S:Body>
        <samlp:AttributeQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_$ReqID" IssueInstant="$DATE" Version="2.0">
          <saml:Issuer>$ReqSP</saml:Issuer>
          <saml:Subject>
            <saml:NameID Format="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">$Principal</saml:NameID>
          </saml:Subject>
        </samlp:AttributeQuery>
      </S:Body>
    </S:Envelope>
    EOS
    
    #debug echo "$REQ_XML"
    
    echo "$REQ_XML" | \
      curl --silent --show-error --cacert $AACert --cert $ReqCert --key $ReqKey \
           --header "Content-Type: text/xml;charset=UTF-8" --data @- $AA_URI
    

    Validation of response

    Signature validation:

    xmlsec1 --verify --id-attr:ID "urn:oasis:names:tc:SAML:2.0:protocol:Response" --trusted-pem $aacert $response 2>/dev/null
    

    Content validation:

    xmllint --xpath "//*['Attribute'](local-name()#bkmrk-)[@Name'$attribute']/*[local-name()='AttributeValue']/text()" $response
    

    IdP_whichone

    A legfontosabb, hogy föderációs oldalról nincs különbség a Shibboleth és a SimpleSAML között, azaz bármelyik IdP bármelyik SP-vel képes együttműködni. Föderációs szempontból a különbség mindössze két apróság :

    1. Single Logout: A Shibboleth nem támogatja a Single Logout-ot, mert a fejlesztők úgy gondolják, hogy ezt nem lehet rendesen implementálni. A régi IdP-hez az NIIF csinált SLO-t, de ez nem került a hivatalos kiadásba és a friss verziókkal már nem működik. Az új IdP-kben van olyan funkcionalitás, hogy a logout-ot kezdeményező SP-ből és az IdP-ből kiléphet a felhasználó, de ez a többi SP-nél esetleg érvényes session-jét nem érinti. A SimpleSAMLphp támogatja az SLO-t, minden örökletes betegségével együtt.
    2. ECP: A Shibboleth támogatja az ECP profilt, ami akkor használható, ha nem webes kliensekkel akarjuk használni az IdP-t. Praktikusan az Office365 és néhány (nálunk nem használatos) grides alkalmazás tartozik ide. A SimpleSAML ECP támogatásán még dolgoznak, de addig is van arra megoldás, hogy ECP nélkül is lehessen Office365-öt használni.

    Ezek a gyakorlatban nem fontos dolgok. Az érdemi döntési pont az, hogy melyik környezethez értetek jobban:


    Az IdP-hez javasolt konfiguráció:

    Shibboleth_troubleshooting

    Lásd még: Internet2 Shibboleth wiki (angol)

    !!! info

    **Ha semmi sem segít...**
    
    * Győződjünk meg róla, hogy nincs-e betelve a diszk
    * Ellenőrizzük, hogy a rendszerórák szinkronban járnak-e
    * Ellenőrizzük, hogy a böngészőben a cookie-k engedélyezve vannak-e
    * Indítsuk újra a böngészőt
    * Indítsuk újra az apache-ot és a shibd-t
    

    Intézmény_átnevezés

    Sok esetben merül fel az a kérdés, hogy eduID tagintézmény névváltozása esetén mi a teendő. Alább egy konkrét levelezés másolata következik, amely remélhetőleg általános információkat tartalmaz.

    Kérdés

    Kecskemét és Szolnok egyesítésével létrejött a Pallasz Athéné Egyetem. Mit kell ilyenkor tennünk? Mert a weboldalakat át kéne neveznem az új dominre. Kell csinálnom új IDP-t és új SP-ket? vagy csak SP-ket?

    Szerződés

    Ha a PAE jogutódja a KeFo-nak, akkor nem kell új szerződést kötni. Egyébként igen.

    Átnevezni vagy nem átnevezni?

    entityID

    Az entitások átnevezése problémás, ezért azt célszerű kerülni. A legtöbb gond az eduPersonTargetedId-vel van, ugyanis az "targeted" azonosító, ami azt jelenti, hogy akár az IdP, akár az SP entityID-je megváltozik, az azonosító értéke is megváltozik, azaz a felhasználó "élettörténete" újraindul az SP-nél. Ráadásul az azonosítók kézi átállítása is meglehetősen körülményes. Kérdés, hogy mely általatok használt SP-k használnak eduPersonTargetedId-t. A Videotorium például igen, ill. lásd még a href.xml-ben a RequestedAttributes elemet. Mivel az entityID nem jelenik meg a felhasználóknak (normális esetben), emiatt nem valószínű, hogy bárki arra kötelezne titeket, hogy változtassátok meg.

    További probléma az entityID megváltoztatásával, hogy a kereskedelmi adatbázis-szolgáltatók jellemzően kézzel tartják karban azt a listát, hogy mely intézmények számára elérhető a szolgáltatás, és az entityID változtatása miatt az intézményünk kikerülhet ezekből a listákból.

    Scope

    Az eduPersonPrincipalName és az eduPersonScopedAffiliation használja a scope-okat. Az minden további nélkül működik, hogy újabb scope-okat IS elkezdjetek használni (új felhasználóknál), de ha egy létező felhasználó scope-ját lecserélitek, akkor ő a fentihez hasonló módon új felhasználóként jelenik meg az összes SP-nél. És eduPersonPrincipalname-et és/vagy eduPersonScopedAffiliationt nagyon sok SP használ, valamint a legtöbb belső SP is valószínűleg úgy van konfigurálva, hogy scope alapon végezze az autorizációt. Az autorizációs szabályok (pl. require affiliation member@kefo.hu vagy require eppn bekre.pal@kefo.hu) szabályok módosítása triviális. Az élettörténet megtartása sajnos már alkalmazásspecifikus, jellemzően kézi adatbázisműveleteket igényel. Annyival egyszerűbb ez, mint az eduPersonTargetedId módosítása, hogy pontosan tudod az átírási szabályt, pl:

    s/([^@]+)@kefo.hu/$1@pae.hu/
    

    A tanácsom az, hogy nézzétek át, hogy mely SP-k esetén fontos az élettörténet megtartása, és ezeket kérjétek meg a fenti változtatásra. (Pl. ha vannak olyan HBONE-adminisztrációs szolgáltatások, amiket eddig kefo.hu-s azonosítóval használtál, akkor azok ilyenek.)

    mail

    A mail cím megváltoztatása jellemzően nem jelent problémát. Azt érdemes észben tartani, hogy a Drupal megköveteli az e-mail címek egyediségét, azaz ha megváltozik az eppn, miközben nem változik a mail, akkor az "új" felhasználó létrehozása nem fog sikerülni.

    IdP URL

    Mellékhatások nélkül módosítható, hogy az IdP milyen URL-en azonosítsa a felhasználókat (vagy válaszoljon az AttributeQuery-kre, de ez nagyon ritka funkció). Ehhez a SingleSignOnService és SingleLogoutService végpontokat kell lecserélni a Resource Registry-ben a haladó beállítások között, valamint természetesen az IdP webszerverét megfelelően kell konfigurálni. Ez a módosítás kizárólag azt befolyásolja, hogy milyen URL jelenik meg a felhasználók böngészőjében, amikor azonosításra átirányítják őket az SP-k. Nyilván megfelelő SSL tanúsítvány is kell az új URL-re.

    Discovery leírás

    Ez is mellékhatások nélkül módosítható, és ez az, ami a leginkább szembetűnő a felhasználók számára. Ezt is a Resource Registry-ben, a Leírók-nál kell módosítani. (Légyszi küldjetek egy értesítést az info @ eduid.hu-ra, ha módosítjátok, mert a központi Discovery Service-t jelenleg még kézzel kell frissítenünk.)

    Scope

    A scope egy intézményhez tartozó DNS domain, amely az intézmény birtokában van vagy rendelkezésére áll. Javasolt, de nem kötelező a scope értékét ténylegesen is a DNS-be bejegyezni.

    A HREF Föderációhoz történő csatlakozáskor a csatlakozó Azonosító Szervezetnek kötelező megadnia legalább egy scope-ot.

    A megadott scope-ok megjelennek a metadatában, ez alapján az SP-k ellenőrizhetik, hogy az IdP jogosult-e bizonyos attribútum-értékeket kiadni. Az attribútum specifikáció az alábbi scope-ot használó attribútumokat használja:


    Célszerű, hogy a felhasználókhoz tartozó scope lehetőleg ne változzon meg. Amennyiben mégis meg kellene változtatni, itt találhatók hasznos információk a domain név változtatásával kapcsolatban.

    HREF_attribútum_specifikáció

    A specifikáció célja

    A föderációban az IdP SAML attribútumokban ad meg adatokat a felhasználóról az SP-nek. Ahhoz, hogy az adatokban hordozott információ átadása pontos legyen, fontos, hogy a használt attribútumokat a két fél ugyanúgy értelmezze.

    Az attribútumok pontos meghatározása az attribútumok sémájában található. A specifikációban az alábbi sémákat használtuk fel:

    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ós szintek

    SP attribútum-igények

    Az SP-k a Resource Registry-ben, és ezen keresztül a metadata állományban jelezhetik, hogy egy attribútum számukra megkövetelt (required) vagy ajánlott (desired).

    Hibakezelés

    Abban az esetben, ha egy IdP nem adja ki egy vagy több az SP számára elengedhetetlen attribútumot, az SP-nek KÖTELEZŐ a felhasználónak hibaüzenetet adnia. (Ugyanis egy SP csak abban az esetben jelölhet meg egy attribútumot megkövetelt attribútumnak, ha ez az alkalmazás működéséhez elengedhetetlen, minden egyéb esetben ajánlott-nak kell megjelölnie.) Azonban ez a hibaüzenet lehetséges, hogy a felhasználó számára nehezen értelmezhető (pl: Authorization Required).

    Ezért az IdP-k számára AJÁNLOTT kiadni azokat az attribútumokat, amelyeket az SP-k megkövetelt-nek jelölnek meg.

    Attribútumok listája

    Lista

    Kötelező attribútumok

    eduPersonScopedAffiliation
    schacHomeOrganizationType
    eduPersonPrincipalName

    Ajánlott attribútumok

    mail
    eduPersonEntitlement

    Állandó felhasználói azonosítók

    Bizonyos alkalmazások esetén szükséges alkalmazás-specifikus adatokat is tárolni. Ilyen példa lehet egy webes naptárnál a felhasználóhoz kötődő bejegyzések, vagy egy wikinél a felhasználó szerkesztései. Ezeket az alkalmazások valamilyen helyi adatbázisban tárolják, a kulcs a felhasználó és az adatbázis bejegyzés között pedig egy állandó azonosító.

    Az állandó azonosítók lehetnek:

    Az azonosítók az alábbi tulajdonságokkal rendelkezhetnek:

    Az állandó azonosító kiadható attribútumként, illetve a SAML Assertion NameID mezőjében. Bizonyos SP implementációk (pl. a Shibboleth 2.x) képesek arra, hogy az alkalmazás részére elfedjék azt, hogy az azonosító pontosan milyen attribútumban vagy NameID-ben érkezett, pl. úgy, hogy az azonosítót a REMOTE_USER változóban adják ki az alkalmazás számára.

    NameID formátumok - melyiket válasszam?

    A föderáció elvárja, hogy az IdP-k támogassák mind a tranziens NameID formátumot, mind a célzott, átlátszatlan azonosítót (melyek lehetnek tároltak vagy számítottak). A tárolt azonosítót célszerű SAML2 perszistens NameID-ként kiadni, a számított azonosító azonban csak az eduPersonTargetedID attribútumban adható ki, mivel nem rendelkezik a perszisztens NameID szemantikájával.

    A Shibboleth IdP implementáció esetén a számított azonosítókról a tárolt azonosítókra való áttérés nem változtatja meg a kiadott azonosítókat, ezért az SP-k számára ez az áttérés transzparens.

    Ha SP-t üzemeltetünk, akkor célszerű már az üzemeltetés kezdetén eldönteni, hogy melyik formátum mellett tesszük le a voksunkat (ez elsősorban az SP által védett alkalmazás képességeitől függ), mert menet közben átállni körülményes, sok energiát igényel. A problémára reméljük könnyebb lesz a megfelelő választ megtalálni az alábbi kérdés átgondolásával: Szükséges-e az SP számára, hogy egy-egy felhasználójához tartozzon egy-egy állandó azonosító?

    1. Ha nem, akkor egyértelmű a választás: tranziens formátumot kell használni.
    2. Ha igen, és nem szükséges, hogy az állandó azonosító a felhasználóra jellemző legyen, ill. az SP mögötti alkalmazás felkészült ilyen azonosító fogadására ( az alkalmazás szempontjából mindegy, hogy milyen úton, tehát eduPersonTargetedID attribútumként, vagy perzisztens NameID-ként érkezik az érték az SP-hez ), akkor az SP-nek Nem kell meghatároznia, hogy milyen NameID formátumot támogat, hiszen ezesetben
      • a) Ha az IdP nem támogatja a tárolt azonosítókat, akkor a tranziens NameID mellé az eduPersonTargetedID attribútumban ki fogja adni a számított (és célzott) azonosítót.
      • b) Ha az IdP támogatja a tárolt azonosítókat, akkor azt perzisztens NameID-ként fogja kiadni (illetve, ha az SP kéri az eduPersonTargetedID attribútumot, az IdP képes ugyanezt a tárolt értéket ilyen formában is kiadni).
      • Az alkalmazáshoz mindkét esetben ugyanaz az érték jut el, mint felhasználói azonosító.
    3. Ugyanaz, mint a 2., kivéve, hogy magasabb szintű felhasználókezelést (például SAML NameID menedzsmentet) is szeretne az SP használni, akkor kizárólag perzisztens NameID-t kell kérnie. A HREF föderáció jelenleg nem rendelkezik a magasabb szintű SAML protokollokról, ezért ezek használata kizárólag az adott SP és IdP közötti megállapodáson alapulhat.
    4. Ha szükséges, hogy az állandó azonosító a felhasználóra jellemző legyen, őt egyértelműen azonosítsa, akkor a választás tranziens NameID, amely mellé meg kell követelni az eduPersonPrincipalName kiadását.

    A HREF föderációban az IdP-k részéről elvárt, hogy a fenti 1-2. megoldásokat támogassák. A 3-4. esetében minden további nélkül előfordulhat, hogy az IdP és SP közötti kommunikáció hibát jelez, mert valamelyik fél nem támogatja a másik fél által megkövetelt / biztosított azonosító formátumot...

    !!! info

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

    eduPersonTargetedID

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

    eduPersonPrincipalName

    eduPersonPrincipalName
    Elnevezés URI: urn:mace:dir:attribute-def:eduPersonPrincipalName OID: 1.3.6.1.4.1.5923.1.1.1.6
    Rövid leírás Állandó, nem célzott, nem újra kiosztható egyedi azonosító
    Implementáció kötelező
    Részletes leírás Formátum: <egyedi_lokális_azonosító>@Ahol
  • <egyedi_lokális_azonosító>: 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.
  • Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    Adatgazda intézmény
    Példa gipsz.jakab@example.org

    niifPersonOrgID

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

    schacPersonalUniqueCode

    schacPersonalUniqueCode
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.25178.1.2.14
    Rövid leírás Állandó egyedi azonosító interföderációs környezetben való használatra
    Implementáció opcionális
    Részletes leírás -
    Lehetséges értékek nincs korlátozás
    Értékek száma multi
    Szintaktika Directory String
    Példa urn:schac:personalUniqueCode:hu:bme.hu:Neptun:gmx3f0

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

    sn

    sn
    Elnevezés URI: urn:mace:dir:attribute-def:sn OID: 2.5.4.4
    Rövid leírás A felhasználó vezetékneve
    Implementáció opcionális
    Részletes leírás A felhasználó vezetékneve. Amennyiben több vezetékneve van a felhasználónak, akkor ezeket egyetlen értékben kell tárolni.
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    Példa
  • Gipsz
  • Gipszné Kiss
  • givenName

    givenName
    Elnevezés URI: urn:mace:dir:attribute-def:givenName OID: 2.5.4.42
    Rövid leírás A felhasználó keresztneve
    Implementáció opcionális
    Részletes leírás Amennyiben több keresztneve van a felhasználónak, ezeket egyetlen értékben kell tárolni.
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    Példa
  • Jakab
  • Mária Lujza
  • displayName

    displayName
    Elnevezés URI: urn:mace:dir:attribute-def:displayname OID: 2.16.840.1.113730.3.1.241
    Rövid leírás A felhasználó megjelenítendő neve
    Implementáció ajánlott
    Részletes leírás A felhasználó neve abban a formában, ahogy a felhasználó, vagy a felhasználó intézménye meg kívánja jeleníteni.
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    Példa Gipsz Jakab Aladár

    mail

    mail
    Elnevezés URI: urn:mace:dir:attribute-def:mail OID: 0.9.2342.19200300.100.1.3
    Rövid leírás A felhasználó email címe
    Implementáció ajánlott
    Részletes leírás A felhasználó értesítési e-mail címe. Az így átadott email címről az intézmény biztosítja, hogy
  • 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.
  • Lehetséges értékek Létező e-mail cím
    Értékek száma multi
    Szintaktika Lásd: [RFC 2822](http://www.faqs.org/rfcs/rfc2822.html)
    Példa gipsz.jakab@example.org

    preferredLanguage

    preferredLanguage
    Elnevezés URI: urn:mace:dir:attribute-def:preferredLanguage OID: 2.16.840.1.113730.3.1.39
    Rövid leírás Előnyben részesített nyelv
    Implementáció opcionális
    Részletes leírás A felhasználó által elsődlegesen használni kívánt, általa előnyben részesített nyelv
    Lehetséges értékek RFC 2068 Language Tags szekcióban meghatározott formátumú nyelvkódok
    Értékek száma single
    Szintaktika Directory String
    Példa hu

    schacDateOfBirth

    schacDateOfBirth
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.25178.1.2.3
    Rövid leírás A felhasználó születési dátuma
    Implementáció opcionális
    Részletes leírás -
    Lehetséges értékek YYYYMMDD (RFC 3339 'full-date') formátumú dátum
    Értékek száma single
    Szintaktika Directory String
    Példa 19700101

    schacYearOfBirth

    schacYearOfBirth
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.25178.1.0.2.3
    Rövid leírás A felhasználó születési éve (amennyiben csak az évre van szükség, egyébként ajánlott a schacDateOfBirth használata)
    Implementáció opcionális
    Részletes leírás -
    Lehetséges értékek YYYY formátumú év
    Értékek száma single
    Szintaktika Directory String
    Példa 1970

    schacPersonalTitle

    schacPersonalTitle
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.25178.1.2.8
    Rövid leírás A felhasználó személyes megszólítása.
    Implementáció opcionális
    Részletes leírás A felhasználó nevéhez kapcsolódó megszólítás, mely a teljes név elé fűzhető. A címtárban tárolható a niifPersonPrefix attribútumban is.
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    Példa
  • Dr.
  • Prof.
  • niifPersonMothersName

    niifPersonMothersName
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.157
    Rövid leírás Felhasználó anyja neve
    Implementáció opcionális
    Részletes leírás A felhasználó anyjának születési neve a felhasználó hivatalos irataiban.
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    Példa Kőkori Vilma

    niifPersonResidentalAddress

    niifPersonResidentalAddress
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.159
    Rövid leírás A felhasználó állandó lakcíme
    Implementáció opcionális
    Részletes leírás -
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    Példa 1111 Budapest, Villányi út 155.

    homePostalAddress

    homePostalAddress
    Elnevezés URI: nincs megadva OID: 0.9.2342.19200300.100.1.39
    Rövid leírás A felhasználó ideiglenes lakcíme
    Implementáció opcionális
    Részletes leírás -
    Lehetséges értékek nincs korlátozás
    Értékek száma multi
    Szintaktika Directory String
    Példa 1111 Budapest, Villányi út 155.

    telephoneNumber

    telephoneNumber
    Elnevezés URI: nincs megadva OID: 2.5.4.20
    Rövid leírás A felhasználó vezetékes telefonszáma
    Implementáció opcionális
    Részletes leírás -
    Lehetséges értékek A telefonszámot az ITU-T E.123 szabvány szerint kell tárolni. A melléket a / jellel elválasztva jelölhető.
    Értékek száma multi
    Szintaktika Directory String
    Példa
  • +36 1 123 1234
  • +36 1 123 1234 / 102
  • mobile

    mobile
    Elnevezés URI: nincs megadva OID: 0.9.2342.19200300.100.1.41
    Rövid leírás A felhasználó mobilszáma
    Implementáció opcionális
    Részletes leírás -
    Lehetséges értékek A telefonszámot az ITU-T E.123 szabvány szerint kell tárolni.
    Értékek száma multi
    Szintaktika Directory String
    Példa +36 30 123 1234

    eduPersonNickName

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

    cn
    Elnevezés URI: nincs megadva OID: 2.5.4.3
    Rövid leírás A felhasználó teljes neve
    Implementáció opcionális
    Részletes leírás A felhasználó vezetéknevének és keresztnevének valamilyen módon történő, szóközzel elválasztott összefűzése. Használata intézményenként és országonként eltérő. Jellemző, hogy több értékben különböző módokon előállított értékeket is tartalmaz.Helyette a displayName használata javasolt.
    Lehetséges értékek nincs korlátozás
    Értékek száma multi
    Szintaktika Directory String
    Példa
  • Gipsz Jakab
  • Kovács Áron;Kovacs Aron;Aron Kovacs
  • jpegPhoto

    jpegPhoto
    Elnevezés URI: nincs megadva OID: 0.9.2342.19200300.100.1.60
    Rövid leírás Kis méretű fotó a felhasználóról JPEG formátumban
    Implementáció opcionális
    Részletes leírás -
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String

    labeledUri

    labeledUri
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.250.1.57
    Rövid leírás Felhasználóhoz tartozó URI-k
    Implementáció opcionális
    Részletes leírás A felhasználó által megadott, vagy rá valamilyen formában jellemző URI-k (gyakran URL-ek) gyűjteménye, mint pl. a személyes honlapjának címe. Minden azonosítóhoz opcionálisan kapcsolható szöveges leírás.
    Lehetséges értékek Az URL-t urlencode-olva kell tárolni (RFC 2079).
    Értékek száma multi
    Szintaktika Directory String
    Példa
  • http://example.com/%7Euser/foo Foo page
  • ftp://ftp.example.com
  • Felhasználó és az intézmény viszonyát leíró attribútumok

    eduPersonScopedAffiliation

    eduPersonScopedAffiliation
    Elnevezés URI: urn:mace:dir:attribute-def:eduPersonScopedAffiliation OID: 1.3.6.1.4.1.5923.1.1.1.9
    Rövid leírás Felhasználó és intézmény közti viszony leírása
    Implementáció kötelező
    Részletes leírás <viszony>@<\scope>
  • <viszony>: 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
  • <scope>: 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#eduPersonAffiliationEgy lehetséges vizuális ábrázolás, azonban a halmazok pontos meghatározása az intézmény feladata.
    Lehetséges értékek A következő értékek egyike: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, valamint a Scope
    Értékek száma multi
    Szintaktika Directory String
    Adatgazda intézmény
    Példa
  • 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
  • eduPersonEntitlement

    eduPersonEntitlement
    Elnevezés URI: urn:mace:dir:attribute-def:eduPersonEntitlement OID: 1.3.6.1.4.1.5923.1.1.1.7
    Rövid leírás A felhasználó által jogosan használt erőforrás(ok)
    Implementáció ajánlott
    Részletes leírás Azon erőforrások listája, melyet a felhasználó használhat. Sok erőforrást minden felhasználó elérhet, néhányat csak korlátozott kör - ez utóbbi esetben válik fontossá ez az attribútum
    InfoAz eduPersonEntitlement attribútumnak csak azon értékeit szabad kiadni az SP-nek, amelyek rá vonatkoznak. Ennek meghatározása kézi adminisztráció esetén igen nehéz lehet, ezért erre célszerű valamilyen adminisztrációs felületet használni. (Sajnos jelenleg nem létezik ilyen alkalmazás.)
    Lehetséges értékek nincs korlátozás
    Értékek száma multi
    Szintaktika Directory String
    Adatgazda intézmény
    Példa urn:geant:niif.hu:niif:entitlement:vhoadmin

    schacHomeOrganizationType

    schacHomeOrganizationType
    Elnevezés URI: urn:mace:dir:attribute-def:schacHomeOrganizationType OID: 1.3.6.1.4.1.25178.1.2.10
    Rövid leírás Az intézmény jellege
    Implementáció kötelező
    Részletes leírás
  • 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ó
  • Lehetséges értékek urn:schac:homeOrganizationType:hu:{university,nren,library,vho,school,business,other,test}
    Értékek száma single
    Szintaktika URN
    Adatgazda intézmény

    ou

    ou
    Elnevezés URI: urn:mace:dir:attribute-def:ou OID: 2.5.4.11
    Rövid leírás Az intézményen belüli egység teljes neve (organizationalUnit)
    Implementáció opcionális
    Részletes leírás Azon egység (tanszék, intézet, könyvtár, stb) neve, amelyhez a felhasználó tartozik.
    Lehetséges értékek nincs korlátozás
    Értékek száma single
    Szintaktika Directory String
    Példa Automatizálási és alkalmazott informatikai tanszék

    eduPersonOrgUnitDN

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

    eduPersonPrimaryOrgUnitDN

    eduPersonPrimaryOrgUnitDN
    Elnevezés URI: urn:mace:dir:attribute-def:eduPersonPrimaryOrgUnitDN OID: 1.3.6.1.4.1.5923.1.1.1.8
    Rövid leírás A felhasználóhoz hozzárendelhető elsődleges szervezeti egység azonosítója.
    Implementáció opcionális
    Részletes leírás Az eduPersonOrgUnitDN-ben tárolt egység-azonosítók közül azon elem, amelyhez a felhasználó elsődlegesen köthető.
    Lehetséges értékek Egy olyan azonosító, mely szerepel az eduPersonOrgUnitDN értékei között.
    Értékek száma single
    Szintaktika DN
    Adatgazda intézmény

    Oktatásban használt attribútumok

    niifEduPersonAttendedCourse

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

    niifEduPersonArchiveCourse
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.171
    Rövid leírás A felhasználó által valaha hallgatott kurzusok
    Implementáció opcionális
    Részletes leírás Azon tantárgyak kódja, amelyet a felhasználó valaha hallgatott az adott intézményben.
    Lehetséges értékek A tanulmányi rendszerben meghatározott tantárgykódok
    Értékek száma multi
    Szintaktika Directory String
    Adatgazda intézmény

    niifEduPersonHeldCourse

    niifEduPersonHeldCourse
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.172
    Rövid leírás A felhasználó által aktuálisan oktatott tárgyak
    Implementáció opcionális
    Részletes leírás Azon tantárgyak kódja, amelyet a felhasználó az adott félévben (esetleg előző félévben) oktatott.
    Lehetséges értékek A tanulmányi rendszerben meghatározott tantárgykódok
    Értékek száma multi
    Szintaktika Directory String
    Adatgazda intézmény

    niifEduPersonMajor

    niifEduPersonMajor
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.162
    Rövid leírás A hallgató főszakja
    Implementáció opcionális
    Részletes leírás A hallgató főszakja - a mab.hu oldalán található lista alapján
    Lehetséges értékek nincs korlátozás
    Értékek száma multi
    Szintaktika Directory String
    Adatgazda intézmény
    Példa
  • műszaki informatikus mérnök
  • elméleti fizikus
  • niifEduPersonFaculty

    niifEduPersonFaculty
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.160
    Rövid leírás Kar neve
    Implementáció opcionális
    Részletes leírás Teljes neve annak a karnak, amelyhez a hallgató tartozik
    Lehetséges értékek nincs korlátozás
    Értékek száma multi
    Szintaktika Directory String
    Adatgazda intézmény
    Példa Villamosmérnöki és Informatikai Kar

    niifEduPersonFacultyDN

    niifEduPersonFacultyDN
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.161
    Rövid leírás A hallgató karának DN-je
    Implementáció opcionális
    Részletes leírás -
    Lehetséges értékek nincs korlátozás
    Értékek száma multi
    Szintaktika DN
    Adatgazda intézmény

    niifEduPersonStudentCategory

    niifEduPersonStudentCategory
    Elnevezés URI: nincs megadva OID: 1.3.6.1.4.1.11914.0.1.174
    Rövid leírás Tanuló/hallgató képzési szintjének meghatározása
    Implementáció opcionális
    Részletes leírás A hallgató képzési szintjének pontosabb meghatározása (az eduPersonScopedAffiliation kiegészítése)
  • bachelor: bachelor képzésben részt vevő hallgató (javasolt affiliation: student,member)
  • master: master képzésben részt vevő hallgató (javasolt affiliation: student,member)
  • * doctor: doktori képzésben részt vevő hallgató (javasolt affiliation: student,member)
  • exchange-student: vendéghallgató (javasolt affiliation: student,member)
  • qualifying-studies: előkészítős hallgató (javasolt affiliation: member)
  • open-university: nyílt egyetemi képzésben részt vevő hallgató (javasolt affiliation: 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!
    Lehetséges értékek nincs korlátozás
    Értékek száma multi
    Szintaktika Directory String
    Adatgazda intézmény

    Attribútum_kiadás

    !!! bug "Elavult információ"

    **Figyelem**: a Shibboleth szoftver ezen változata már nem támogatott. Az új verziókhoz a leírások itt találhatók:
    
    * [Shibboleth2_IdP](https://help.edu.hu/books/aai/page/shibboleth2-idp)
    * [Shibboleth2_SP](https://help.edu.hu/books/aai/page/shibboleth2-sp)
    

    Az Attribute Release Policy (ARP) határozza meg, hogy az attribútum feloldás után rendelkezésre álló attribútumok közül mely attribútumokat lehet az SP-nek kiadni. Egy ARP vonatkozhat a teljes IdP-re ("site" ARP), illetve az azonosított felhasználóra is. A site-ARP-k általában a arps/arp.site.xml állományban, a felhasználói ARP-k pedig az arps/arp.user.$PRINCIPAL.xml állományban találhatók, ahol $PRINCIPAL megegyezik a REMOTE_USER változóban megkapott értékkel.

    Működő példa

    <?xml version="1.0" encoding="UTF-8"?>
    <AttributeReleasePolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    						xmlns="urn:mace:shibboleth:arp:1.0"
    						xsi:schemaLocation="urn:mace:shibboleth:arp:1.0 shibboleth-arp-1.0.xsd" >
    	<Description>Not The Simplest Possible ARP.</Description>
    	<Rule>
    		<Description>Mindenkire vonatkozó szabályok</Description>
    		<Target>
    			<AnyTarget/>
    		</Target>
    		<Attribute name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation">
    			<AnyValue release="permit"/>
    		</Attribute>
    		<Attribute name="urn:mace:dir:attribute-def:eduPersonOrgDN">
    			<AnyValue release="permit"/>
    		</Attribute>
    	</Rule>
    	<Rule>
    		<Description>NIIFI által üzemeltetett SP-kre vonatkozó szabályok</Description>
    		<Target>
    			<Requester matchFunction="urn:mace:shibboleth:arp:matchFunction:regexMatch">.*\.n?iif\.hu\/.*</Requester>
    		</Target>
    		<Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName">
    			<AnyValue release="permit"/>
    		</Attribute>
    		<Attribute name="urn:mace:dir:attribute-def:mail">
    			<AnyValue release="permit"/>
    		</Attribute>
    		<Attribute name="urn:mace:dir:attribute-def:cn">
    			<AnyValue release="permit"/>
    		</Attribute>
    		<Attribute name="urn:mace:dir:attribute-def:eduPersonEntitlement">
    			<Value release="permit"
    				   matchFunction="urn:mace:shibboleth:arp:matchFunction:regexMatch">
    ^urn:niif.hu:services:aai:entitlement:.*
    			</Value>
    		</Attribute>
    	</Rule>
    </AttributeReleasePolicy>
    

    ARP feldolgozás menete

    Az Attribute Authority a rendelkezésre álló ARP-kből (tehát site és felhasználói ARP-kből) egy ún. effective ARP-t állít elő.

    1. Meghatározza, hogy melyik ARP file-okat kell feldolgozni.
    2. Meghatározza, hogy melyek azok a szabályok, amelyek az attribútum lekérdezéshez kapcsolódnak
      • Minden ARP szabály, amely alapértelmezettnek vannak megjelölve, automatikusan bekerül az ARP-be, anélkül, hogy az illesztési függvényeket (matchFunction) végrehajtaná
      • Minden nem alapértelmezett szabály illesztési függvénye alapján megállapítja, hogy a providerId alapján vonatkozik-e a kérést indító félre.
    3. Attribútum filter létrehozása
      1. Minden attribútumhoz megállapítja a vonatkozó Rule-ok listáját
      2. Ebből a listából az összes olyan attribútum értéket kiveszi, amelyre deny szabály vonatkozik
      3. Ha egy szabály úgy rendelkezik, hogy minden érték kiadható, akkor az egyes értékekre vonatkozó deny szabályok szűkítik a kiadható értékek listáját. Ha egy szabály az attribútumok összes értékének kiadását megtiltja, akkor az egyes értékekre vonatkozó engedélyek figyelmen kívül lesznek hagyva.

    ARP Rule

    Az ARP szabályok különböző illeszkedési vizsgálatok segítségével megállapítják, hogy egy SP-nek egy-egy attribútum milyen feltételekkel adható ki.

    matchFunction

    Ez az attribútum adja meg, hogy milyen illesztési eljárást kell használni az illeszkedési vizsgálatnál. Lehetséges értékei:

    Target

    A Target elemnek kétféle gyermeke lehet:

    Attribute

    Egy Rule 0 vagy több Attribute elemet tartalmazhat. Tartalmaznia kell egy name paramétert, amely az attribútum teljes neve (általában URN, lásd az attribútum feloldás leírását). Az elemnek kétféle gyermeke lehet:

    Constraint

    A Constraint-ek használatával attribútumok kiadását más attribútumok értékéhez is köthetjük, így pl. megtehetjük, hogy a "hozzajarulasBeszerezve" nevű attribútum true értékéhez kössük az attribútumok kiadását.

    A megkötések konfigurációjához lásd: https://spaces.internet2.edu/display/SHIB/ArpConstraint

    Tesztelés

    A Shibboleth IdP-hez tartozik egy resolvertest névre hallgató program, amellyel ellenőrizhetjük az attribútumok kiadását is. Használatához először be kell állítani a telepítésnek megfelelően az IDP_HOME és a JAVA_HOME változókat.

    Példa: /usr/local/shibboleth-idp/bin/resolvertest --idpXml=file:///etc/shibboleth-idp/idp.xml --user=bajnokk (Azonosítatlan SP-nek kiadott attribútumok)

    <Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    		   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    		   AttributeName="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"
    		   AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
      <AttributeValue Scope="niif.hu">employee</AttributeValue>
    </Attribute>
    
    <Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    		   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    		   AttributeName="urn:mace:dir:attribute-def:eduPersonOrgDN"
    		   AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
      <AttributeValue>o=niifi,o=niif,c=hu</AttributeValue>
    </Attribute>
    

    Példa 2.:/usr/local/shibboleth-idp/bin/resolvertest --idpXml=:///etc/shibboleth-idp/idp.xml --user=bajnokk --requester=https://dev.aai.niif.hu/shibboleth (Azonosított SP-nek kiadott attribútumok.)

    ...
    <Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    		   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    		   AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName"
    		   AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
      <AttributeValue Scope="niif.hu">bajnokk</AttributeValue>
    </Attribute>
    ...
    

    Hivatkozások

    ShibSPInstallDebian

    Ez egy elavult lap, használd ezt helyette!

    A Debian 4.0 (Etch) már tartalmazza a Shibboleth SP-t (és függőségeit), ezért csak a megfelelő csomagokat kell telepítenünk.

    A telepítés után az Apache webszervert újra kell indítani.

    ShibTest

    Ha már úgy gondoljuk, hogy készen vagyunk

    Erre jó kis eszköz a Shibenv. Segítségével kilistázhatjuk a felhasználói attribútumokat, a webszerver változókat, illetve a teljes megkapott SAML Response-t (amennyiben az exportAssertion="true" be van állítva; ezt a tesztelés idejére érdemes beállítani).

    Hibaelhárítás

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

    Shibboleth hibaüzenet

    Lásd: Shibboleth troubleshooting

    Nincsenek attribútumok

    Megtörténik-e a session létrehozás?

    Van session

    Nincs session

    Hiányoznak bizonyos attribútumok

    Lehetséges okok:

    Szövetségi_alapon_történő_felhasználó_azonosítás_Huntéka_könyvtári_alkalmazásokban

    Könyvtári alkalmazás használati esetei

    Könyvtári és föderatív azonosságok

    A könyvtári alkalmazás olvasói nyilvántartásában szereplő és a föderatív azonosítás szolgáltatónál lévő azonosságokat a könyvtári alkalmazásban célszerűen össze kell kapcsolni. Ez az identitás összekapcsolás mindig feltételezi a felhasználó aktív közreműködését, e nélkül az identitások összekapcsolása nem jöhet létre.

    Egy föderatív azonosítással elérhető, SP-vel védett Online könyvtári beiratkozás szolgáltatásnál ez egy tájékoztató szöveg megjelenése és tudomásul vétele után történik meg, a már hagyományos módon beiratkozott, az alkalmazás olvasói nyilvántartásában már szereplő olvasók “könyvtári identitását” viszont külön eljárással kell összekapcsolni az IdP által azonosítottakkal.

    Ha a könyvtári alkalmazásban már létezik webes azonosítás, akkor célszerű egy olyan komponenst beilleszteni, ahol a felhasználó mind a könyvtári azonosságát (könyvtári azonosító - jelszó), mind a föderatív azonosságát tudja bizonyítani, és a komponens összeköti a két azonosítót a kapcsoló táblában (account linking). A tájékoztató szöveg megjelenítése és annak elfogadása ekkor történhet meg.

    Az MTA SZTAKI könyvtára esetében a felhasználók nem tudtak bejelentkezni a webes felületen, az identitás összekapcsolást segítő kulcs az email cím lehetett, ez alapján az összerendelések nagy tömegét elvégezhettük, a maradék azonosítót pedig kézzel, további adatok összehasonlításával, vagy közvetlenül az olvasó megkeresésével lehetett elvégezni.

    Identitások összekapcsolása

    A könyvtári rendszert fel kell készíteni a szövetségi azonosítás során használt azonosítójukkal érkező felhasználók fogadására. Ehhez szükség van egy kapcsoló táblára, ahol a könyvtári azonosítót és a föderált azonosítókat tároljuk.ű

    img

    Bejelentkezés során bármely eduid-vel azonosítja a felhasználót a szóbanforgó Home IdP, az alkalmazás kikeresi a megfelelő könyvtári alkalmazásbeli azonosítót, és a továbbiakban az alkalmazás ezt használja a munkamenet során.

    Beiratkozás

    Ha a felhasználó olyan azonosítóval jön a Home IdP-től, ami nincs egyetlen alkalmazás azonosítóhoz sem kapcsolva, a beiratkozás folyamatát kell végrehajtani.

    A beiratkozás folyamán létre kell hozni az olvasó táblában az új olvasót, és a Home IdP-től kapott személyes adatokkal fel kell tölteni az olvasó rekordot.

    A “Föderált azonosító” kapcsolótáblában létre kell hozni a könyvtári azonosítót és a föderált azonosítót összerendelő rekordot.

    Kiiratkozás

    Felhasználó kiiratását az OIOSAML.java nem támogatja, az azonosító lejáratásával lehet a felhasználó jogosultságait korlátozni. Tervezésnél meg kell fontolni, hogy egy-egy IdP által azonosított felhasználó beiratásánál mennyi az az idő, amíg az olvasót aktívnak szeretnénk tudni. Megvizsgálva néhány könyvtár Használati szabályzatát a megoldás megfelel az általános gyakorlatnak. A könyvtárak beiratkozáskor kiállított olvasójegyét bizonyos időre szóló érvényességgel (általában 1 év) állítják ki, ha az olvasó ennek elteltével nem hosszabbítja meg olvasójegye érvényességét, az lejár.

    Azonosítás és attribútumok átadása

    A LoginFilter által védett URL-re irányuló kéréskor a SAML Assertion és az általa hordozott attribútumok a dk.itst.oiosaml.sp.UserAssertion objektumból lekérdezhetőek. Ezen objektum csak a védett URL-eken érhető el a dk.itst.oiosaml.sp.UserAssertionHolder.get() metódus meghívásával.

    Ha csak a login funkciót védjük SAML SP-vel, érdemes a user session-be átmenteni a szükséges attribútumokat, ha azokat más funkciókkal is el kell érni.

    Attribútum mappingről igény szerint a fejlesztés során kell gondoskodnunk, az OIOSAML.java nem támogat ilyen funkciót.

    Példa az eduPersonPrincipalName attribútum kinyeréséről:

    UserAssertion ua = UserAssertionHolder.get();
    String eppn = ua.getAttribute(“urn:oid:1.3.6.1.4.1.5923.1.1.1.6 ”);
    

    A rendszerfejlesztéshez kapcsolódó dokumentáció az alábbi URL-en található:

    [https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/developers.html]

    Attribútumok frissítése

    Hogy a könyvtári rendszerben nyilvántartott olvasók adatai naprakészek legyenek, a Home IdP-től származó attribútumokat nem csak a beiratkozáskor, hanem a mindennapi használatkor is igénybe vehetjük.

    Az IdP-től kapott attribútumokat a könyvtári alkalmazás ellenőrzi, és ha az adott attribútum még nem szerepel a nyilvántartásában, azt rögzíti.

    Az alkalmazás saját szabály-rendszere döntheti el, hogy a meglévő értékeket lecseréli az Home IdP-től kapottal, vagy csak hozzáadja új értékként a már meglévőhöz.

    Kijelentkezés

    SP által kezdeményezett SLO

    Az alkalmazásból történő kijelentkezést a session-változók törlésével kell megoldani, és biztosítani kell a Single Logout folyamat elindítását. Az OIOSAML.java esetében ezt a saml/Logout URL-re történő redirect-tel lehet kezdeményezni.

    HttpSession session = req.getSession(false);
    res.sendRedirect("saml/Logout");
    

    img

    IdP által kezdeményezett SLO

    Ha a Single Logout-ot a felhasználó egy másik alkalmazásnál kezdeményezte, és kérte, hogy valamennyi aktív alkalmazásból léptesse ki a rendszer, az IdP a könyvtári alkalmazásnak egy Logout Request-et küld a böngésző átirányításának segítségével. A kérésről a SAML SP-n kívül az alkalmazásnak is tudnia kell, hogy a felhasználó session-jén a kilépést érvényre juttassa. Ezt a SAML SP SLO endpoint-jai elé tett filter segítségével lehet a legegyszerűbben végrehajtani.

    LogoutFilter.java
    
    import java.io.IOException;
    import javax.servlet.Filter;
    import javax.servlet.FilterChain;
    import javax.servlet.FilterConfig;
    import javax.servlet.ServletException;
    import javax.servlet.ServletRequest;
    import javax.servlet.ServletResponse;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpSession;
    
    import org.apache.log4j.Logger;
    
    /**
    * Servlet Filter implementation class LogoutFilter
    */
    public class LogoutFilter implements Filter {
    
       /**
       * Default constructor.
       */
      private static final Logger log = Logger.getLogger(LogoutFilter.class);
    
       public LogoutFilter() {
       }
    
      /**
       * @see Filter#destroy()
       */
      public void destroy() {
      }
    
      /**
       * @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
       */
      public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
          chain.doFilter(request, response);
          log.debug("Enter into LoginFilter");
          HttpServletRequest servletRequest = ((HttpServletRequest) request);
          HttpSession session = servletRequest.getSession(false);
          if (session != null){
              log.debug("Remove application related session attributes.");
              session.removeAttribute("aai_auth");
          }
      }
    
      /**
       * @see Filter#init(FilterConfig)
       */
      public void init(FilterConfig fConfig) throws ServletException {
      }
    }
    

    web.xml

    ...
     <filter>
       <filter-name>LogoutFilter</filter-name>
       <filter-class>LogoutFilter</filter-class>
    </filter>
    <filter-mapping>
       <filter-name>LogoutFilter</filter-name>
       <url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
       <url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
    </filter-mapping>
    ...
    

    img

    Rendszer architektúra

    img

    OIOSAML.java, mint SP komponens

    Telepítés

    Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

    1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába
    2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:
    <context-param>
       <param-name>oiosaml-j.home</param-name>
       <param-value>/path/to/oiosaml.home</param-value>
    </context-param>
    
    <servlet>
       <servlet-name>SAMLDispatcherServlet</servlet-name>
       <servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
    </servlet>
    
    <servlet-mapping>
       <servlet-name>SAMLDispatcherServlet</servlet-name>
       <url-pattern>/saml/*</url-pattern>
    </servlet-mapping>
    
    <filter>
       <filter-name>LoginFilter</filter-name>
       <filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
    </filter>
    <filter-mapping>
       <filter-name>LoginFilter</filter-name>
       <url-pattern>/protected/*</url-pattern>
    </filter-mapping>
    

    A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.

    A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.

    Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.

    Konfiguráció

    Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.

    Telepítés után a következő módosításokat érdemes megtenni a fileban:

    oiosaml-sp.assurancelevel=0
    

    Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

    oiosaml-sp.uri.home=../
    

    Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

    A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:

    https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html

    Meta-adat kezelés

    A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.

    Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.

    Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.

    Discovery Service

    Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.

    Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.

    Telepítése az oiosaml.java-discovery..war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery. változók használhatóak.

    A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található: https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html

    Metadata frissítés

    A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.

    Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.

    Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.

    A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

    Shib3IdpProd

    Shibboleth 3 IdP éles szolgáltatás építése

    Linux rendszer-szolgáltatás Debian-on

    Az alábbi parancsokat root felhasználóként futtassuk.

    mkdir /opt/jetty-home
    useradd -d /opt/jetty-home -U -r -s /bin/false jetty
    chown jetty:jetty jetty-home
    echo "JETTY_USER=\"jetty\"
    JETTY_HOME=/opt/jetty-distribution-9.2.<legutóbbi stabil verzió>
    JETTY_BASE=/opt/jetty-shibboleth-idp" > /etc/default/jetty
    cp /opt/jetty-distribution-9.2.<legutóbbi stabil verzió>/bin/jetty.sh /etc/init.d/jetty
    update-rc.d jetty defaults
    

    Dokumentáció

    UApprove

    !!! warning

    Ez jelen formájában egy elavult lap, hamarosan frissítésre kerül
    

    uApprove

    Felépítés

    Az uApprove a SWITCH.ch által fejlesztett alkalmazás, ami a Shibboleth2 IdP-vel együttműködve képes a felhasználótól attribútum-kiadás hozzájárulást kérni.

    A uApprove két részből áll. Egy szervlet filterből (IdP plugin), ami a Shibboleth2 IdP webalkalmazásba beépülve elkapja és elemzi a kéréseket, illetve egy különálló webalkalmazásból (Viewer), ami a felhasználói hozzájárulást kéri el.

    A felhasználói hozzájárulásnak két szintje van: a globális felhasználási feltételek elfogadása, illetve minden SP esetén egy ún. digitális identitás elfogadása. Ez utóbbi felület lehetőséget ad a felhasználó számára hogy lássa az adott SP felé kiadandó attribútumait, és beleegyezzen azok kiadásába.

    A hozzájárulások XML fájlban vagy relációs adatbázisban is tárolhatók. A uApprove lehetőséget ad arra, hogy az SP-hez történő hozzáféréseket naplózza, az attribútum-kiadástól függetlenül (tehát elég az IdP plugin komponenst használni ahhoz hogy a naplózás működjön - ezt Monitoring módnak hívjuk).

    uApprove viewer webalkalmazás telepítése

    cd uApprove-2.1.4/
    unzip viewer-2.1.4-bin.zip
    sudo cp viewer-2.1.4/conf-template/* /path/to/uApprove/uApprove
    sudo cp -r viewer-2.1.4/webapp /path/to/tomcat/webapps/uApprove
    

    A uApprove közös konfiguráció a common.properties fájlban található:

    storageType = Database
    databaseConfig = /path/to/uApprove/database.properties
    #storageType = File
    #flatFile = /path/to/uApprove/uApprove-log.xml
    
    # A globális felhasználási feltételeket tároló fájl
    # Ebben az XML-ben több verzió is tárolható,
    # verzióváltás esetén a felhasználónak újra el kell fogadnia.
    termsOfUse = /path/to/uApprove/terms-of-use.xml
    
    # Kommunikáció titkosításához
    SharedSecret = some-very-random-string
    

    database.properties (a támogatott RDBMS a MySQL):

    driver = com.mysql.jdbc.Driver
    url = jdbc:mysql://localhost:3306/*dbname*
    user = *username*
    password = *password*
    sqlCommands = /path/to/ArpViewer/mysql.commands
    

    viewer.properties:

    # amennyiben a böngésző nem küld lokalizációs információt, ezen beállítás jut érvényre
    useLocale = HU_hu
    # felajánljuk-e a felhasználónak az sp-től független beleegyezést
    globalConsentPossible=true
    loggingConfig = /path/to/uApprove/logging.xml
    

    attribute-list: az attribútumok sorrendezését és egyes nem kívánt attribútumok (pl transientid) elrejtését állíthatjuk be benne. Az attribútumnevek a Shibboleth2 attribute-resolver.xml -ben deklaráltaknak kell megfeleljenek.

    web.xml (/path/to/tomcat/webapps/uApprove/WEB-INF):

     <context-param>
    	 <param-name>Config</param-name>
    	 <param-value>
    		/path/to/uApprove/viewer.properties;
    		/path/to/uApprove/common.properties;
    	 </param-value>
     </context-param>
    

    IdP plugin beállítása

    Csomagoljuk ki a plugint és másoljuk a konfigurációt illetve a szükséges library fájlokat a helyükre

     cd uApprove-2.1.4/
     unzip idp-plugin-2.1.4-bin.zip
     sudo cp idp-plugin-2.1.4/conf-template/* /path/to/uApprove
     sudo cp idp-plugin-2.1.4/lib/* /path/to/idp-setup/src/main/webapp/WEB-INF/lib/
    

    Ezután szerkesszük az IdP web.xml konfigurációját

    <web-app>
    	...
    
    	<filter>
    		<filter-name>uApprove IdP plugin</filter-name>
    		<filter-class>ch.SWITCH.aai.uApprove.idpplugin.Plugin</filter-class>
    		<init-param>
    			<param-name>Config</param-name>
    			<param-value>
    				/path/to/uApprove/idp-plugin.properties;
    				/path/to/uApprove/common.properties;
    			</param-value>
    		</init-param>
    	</filter>
    
    	<filter-mapping>
    		<filter-name>uApprove IdP plugin</filter-name>
    		<url-pattern>/profile/*</url-pattern>
    		<dispatcher>REQUEST</dispatcher>
    		<dispatcher>FORWARD</dispatcher>
    	</filter-mapping>
    
    </web-app>
    

    Ezután a Shibboleth IdP setup.sh szkriptjével készítsük el a webarchívumot (idp.war), amit telepítsünk újra.

    A uApprove IdP plugin egyedi beállításai az idp-plugin.properties-ben találhatóak:

    # Azon SP-hez amihez nem akarunk ArpFiltert használni
    spBlacklist = /path/to/config/sp-blacklist
    # SP logolás
    LogProviderAccess = false
    # Csak SP logolás
    MonitoringOnly = false
    # ArpViewer alkalmazás helye
    uApproveViewer = https://idp.example.org/uApprove/Controller
    # Támogassuk-e a passzív authentikációt
    isPassiveSupport = false
    

    Attribútumnevek beállítása

    Az attribútumnevek helyes megjelenítéséhez az ArpViewer a Shibboleth2 IdP attribute-resolver.xml fájlt használja. Ebben a fájlban kell beállítani a lokalizált attribútumneveket a következőképpen:

    Shibboleth2 IdP conf/attribute-resolver.xml:

     <resolver:AttributeDefinition id="postalAddress"
    	xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
    	sourceAttributeID="postalAddress">
    
    	<resolver:Dependency ref="myLDAP" />
    	<resolver:DisplayName xml:lang="en">Business postal address</resolver:DisplayName>
    	<resolver:DisplayName xml:lang="hu">Hivatalos postai cím</resolver:DisplayName>
    	<resolver:DisplayDescription xml:lang="en">Business postal address: Campus or office address</resolver:DisplayDescription>
    	<resolver:DisplayDescription xml:lang="hu">Az intézmény hivatalos postai címe</resolver:DisplayDescription>
    

    Megjegyzés: a Resource_Registry által előállított attribute-resolver.xml template fájl tartalmazza az attribútumok magyar nyelvű leírásait.

    ArpFilter before the profile servlet - support for other authentication modules

    Lásd: ArpFilterProposal (angol)

    URN

    Registrations in the urn:geant:niif.hu Namespace

    GEANT has delegated the operation of urn:geant:niif.hu namespace to NIIFI -> KIFÜ. KIFÜ administers the Uniform Resource Name namespace urn:geant:niif.hu, which enables all scientific institutions in Hungary to assign unique, permanent and globally valid names to different resources. The exact use of the entries is not prescribed. GÉANT primarily wants to promote standardization within the scientific community and especially the interoperability of middleware with the namespace.

    If you want to request a delegation, please send an email to urn@niif.hu.

    Namespaces administered by KIFÜ

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

    Shib2IdpRHEL

    Előkészületek

    entityID

    Tanúsítvány

    JDK

    https://wiki.shibboleth.net/confluence/display/SHIB2/JVMTuning

    [idp2:~/java]$ sudo_ssh rpm -Uvh jdk-6u7-linux-i586.rpm
    Preparing...                ########################################### [100%]
      1:jdk                    ########################################### [100%]
    Unpacking JAR files...
           rt.jar...
           jsse.jar...
           charsets.jar...
           tools.jar...
           localedata.jar...
           plugin.jar...
           javaws.jar...
           deploy.jar...
    

    A többi rpm-mel nem törődünk.

    Shibboleth Security Provider

    Be kell másolni a lib/shib-jce-1.0.jar állományt a $JAVA_HOME/jre/lib/ext könyvtárba. Ha az ext/ könyvtár nem létezik, akkor hozzuk létre.

    cp lib/shib-jce-1.0.jar $JAVA_HOME/jre/lib/ext
    

    Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a $JAVA_HOME/jre/lib/security/java.security fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort:

    security.provider.7=edu.internet2.middleware.shibboleth.DelegateToApplicationProvider
    

    Bouncy Castle JCE

    A JVM-mel jövő Java Cryptography Engine (JCE) nem támogatja az összes kriptográfiai algoritmust, amelyre az Identity Providernek szüksége lehet (pl. XML Digital Signature, XML Encryption). A Bouncy Castle JCE ezek mellett még olyan algoritmusokat is tartalmaz (általában hatékonyabb és szabványosabb formában), amelyek benne vannak a Java JCE-ben.

    Ehhez először le kell tölteni a Bouncy Castle JCE-t. A JCE állományok a Provider oszlopban, a "Signed Jar Files" részben találhatók. (A nevük bcprov-jdk-VERZIO.jar.) Letöltés után a .jar fájlokat a $JAVA_HOME/jre/lib/ext könyvtárba kell tenni.

    wget http://www.bouncycastle.org/download/bcprov-jdk15-141.jar
    cp bcprov-jdk15-141.jar $JAVA_HOME/jre/lib/ext
    

    Ezek után be kell állítani, hogy a JRE használni is tudja ezt a providert. Ehhez a $JAVA_HOME/jre/lib/security/java.security fájlban keressük meg az ún. "security provider"-eket, és írjuk hozzá a következő sort:

    security.provider.8=org.bouncycastle.jce.provider.BouncyCastleProvider
    

    Tomcat

    Tomcat 6-ot fogunk használni, AJP connectorral

    https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare

    #XXX-TODO useradd tomcat
    cd /usr/local
    tar xzf ~/apache-tomcat-6.0.18.tar.gz
    ln -s apache-tomcat-6.0.18 tomcat
    cd tomcat
    mv conf /etc/tomcat ; ln -s /etc/tomcat conf
    mv logs /var/log/tomcat; ln -s /var/log/tomcat logs
    mkdir /var/lib/tomcat
    mv temp /var/lib/tomcat; ln -s /var/lib/tomcat/temp .
    mv webapps /var/lib/tomcat; ln -s /var/lib/tomcat/webapps .
    mv work /var/lib/tomcat; ln -s /var/lib/tomcat/work .
    chown -R tomcat:tomcat /etc/tomcat /var/log/tomcat /var/lib/tomcat
    

    Konfiguráció

    A /etc/tomcat/server.xml -ben módosítani kell a 8009-es porton figyelő Connectort az alábbira:

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector  port="8009"
                protocol="AJP/1.3" redirectPort="8443"
                enableLookups="false" tomcatAuthentication="false"
                address="127.0.0.1"/>
    

    Init script

    Az alábbi házi készítésű init script használható a tomcat elindításához:

    #!/bin/bash
    #
    # chkconfig: - 85 15
    # processname: tomcat
    # description:  Start up the Tomcat servlet engine.
    
    # Source function library.
    . /etc/init.d/functions
    
    PATH=/bin:/usr/bin:/sbin:/usr/sbin
    export JAVA_HOME=/usr/java/default
    CATALINA_HOME="/usr/local/tomcat"
    TOMCAT_USER=tomcat
    
    # Max. heap size: 512 MB
    # Memory allowed for the permanent generation object space: 256 MB
    export JAVA_OPTS="-Xmx512m -XX:MaxPermSize=256m"
    
    if [`id -u` -ne 0 ](); then
       echo "You need root privileges to run this script"
       exit 1
    fi
    
    case "$1" in
     start)
           if [-f $CATALINA_HOME/bin/startup.sh ]();
             then
               echo $"Starting Tomcat"
               su -c "$CATALINA_HOME/bin/startup.sh" -s /bin/bash $TOMCAT_USER
           fi
           ;;
     stop)
           if [-f $CATALINA_HOME/bin/shutdown.sh ]();
             then
               echo $"Stopping Tomcat"
               su -c "$CATALINA_HOME/bin/shutdown.sh" -s /bin/bash $TOMCAT_USER
           fi
           ;;
     restart)
           $0 stop
           sleep 2;
           $0 start
           ;;
     *)
           echo $"Usage: $0 {start|stop|restart}"
           exit 1
           ;;
    esac
    
    exit $?
    

    A következő parancsok hatására a Tomcat automatikusan elindul bootoláskor:

    chkconfig --add tomcat
    chkconfig tomcat on
    

    Shibboleth_SP

    Telepítési leírások

    Konfigurációs leírások



    AAIGettingStarted

    AAI Getting Started

    ElsevierSP

    Speciális eduPersonTargetedID kiadásának beállítása

    Shibboleth IdP alatt

    vim [/path/to]/shibboleth-idp/conf/attribute-resolver.xml
    

    Szúrjuk be az alábbi attribútumdefiníciót, ahol

        <!-- Buggy edupersonTargetedId required for Elsevier: -->
        <resolver:AttributeDefinition id="elsevierId" xsi:type="Scoped" scope="niif.hu" sourceAttributeID="persistentId"
                                      xmlns="urn:mace:shibboleth:2.0:resolver:ad" >
          <resolver:Dependency ref="storedIdConnector" />
          <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString"
                                     name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="buggy-eduPersonTargetedID"
                                     xmlns="urn:mace:shibboleth:2.0:attribute:encoder" />
        </resolver:AttributeDefinition>
    
    vim [/path/to]/shibboleth-idp/conf/attribute-filter.xml
    

    Fontos, hogy amennyiben az ajánlásnak megfelelően a Resource Registry által előállított attribute filtert használjuk, akkor ne ezt a dinamikusan frissülő fájlt szerkesszük, hanem az attribute-filter-local.xml-t, és ebben a fájlban végezzük el az alábbi módosításokat.

    1. Szúrjuk be az alábbi részletet, amely megmondja, hogy az Elsevier SP számára mely attribútumok adandók ki:

          <AttributeFilterPolicy id="buggy-eptid">
                  <PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://sdauth.sciencedirect.com/" />
                  <AttributeRule attributeID="elsevierId">
                      <PermitValueRule xsi:type="basic:ANY" />
                  </AttributeRule>
                  <AttributeRule attributeID="eduPersonScopedAffiliation">
                      <PermitValueRule xsi:type="basic:ANY" />
                  </AttributeRule>
          </AttributeFilterPolicy>
      
    2. A releaseIDsToAnyone alapértelmezett szabályt módosítsuk az alábbiakra:

          <!--  Release IDs to anyone -->
          <AttributeFilterPolicy id="releaseIDsToAnyone">
              <PolicyRequirementRule xsi:type="basic:NOT">
                      <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://sdauth.sciencedirect.com/" />
              </PolicyRequirementRule>
              <AttributeRule attributeID="transientId">
                  <PermitValueRule xsi:type="basic:ANY" />
              </AttributeRule>
      
              <AttributeRule attributeID="persistentId">
                  <PermitValueRule xsi:type="basic:ANY" />
              </AttributeRule>
      
          </AttributeFilterPolicy>
      

    Ez utóbbi módosításra azért van szükség, hogy a mindenki számára kiadható szabványos persistentID ne csapja felül ez Elsevier számára kiadandót.

    SimpleSAMLphp alatt

    vim [/path/to]/simplesaml/metadata/saml20-sp-remote.php
    

    Beállítjuk, hogy csak az elsevier SP-je esetén az attribútum előállítás és kiadás folyamatát toldja meg még egy lépéssel. Ehhez szükséges, hogy a fenti fájlba vegyük fel állandó elemként az Elsevire SP metadatájának kiegészítéseként az alábbi PHP tömböt. Fontos, hogy a tömb egyes elemei előtt szereplő számok magasabbak legyenek, mint az IdP általános feloldási szabályainál megadott számok, de alacsonyabbak, mint a jellemzően a folyamat végén beállított 'name2oid' mappelések.

    $metadata['https://sdauth.sciencedirect.com/']['authproc'] = array (
                   96 => array(
                            'class' => 'core:TargetedID'
                   ),
                   97 => array(
                           'class' => 'core:AttributeAlter',
                           'subject' => 'eduPersonTargetedID',
                           'pattern' => '/^.*$/',
                           'replacement' => '${0}@intezmenyiScope.hu',
                   ),
    );
    

    A fenti kódrészlet annyit teszi, hogy újragenerálja az alapértelmezett eduPersonTargetedID-t egyszerű formában (csak a stringet, a NameID-s xml struktúra nélkül), majd mögé teszi az intézményi scope-ot. Fontos, hogy a megoldás feltételezi azt, hogy az Elsevier SP metadatájának további részei betöltésre kerülnek pl. a metarefresh modul által.

    Tomcat55_to_Tomcat6

    Tomcat6 telepítés Debianra (Lenny)

    Debian testing tárolók beállítása

    Mivel az újabb fejlesztések nem kerülnek be debian stable ágába, és a backports ág sem tartalmaz mindent, ezért a testing ágból is be kell emelni néhány csomagot. Az alábbi beállításokkal elérjük, hogy a testing ágból csak külön kérésre települjenek csomagok (természetesen a függőségeikkel együtt).

    /etc/apt/sources.list.d/sqeeze.list:

    deb http://ftp.hu.debian.org/debian squeeze main
    

    /etc/apt/preferences:

    Package: *
    Pin: release a=stable
    Pin-Priority: 100
    
    Package: *
    Pin: release a=testing
    Pin-Priority: 50
    

    apt-get update

    Telepítés

    sudo aptitude -t testing install tomcat6
    

    Konfiguráció

    Kapcsoljuk ki a TOMCAT6_SECURITY opciót az init konfigurációban:

    sudo vim /etc/default/tomcat6
    

    Engedélyezzük az ajp konnektort (alapértelmezett konfigurációban ki van kommentezve):

    sudo vim /etc/tomcat6/server.xml
    
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
    

    Konfigurálás Shibboleth IdP-hez

    Alkalmazás descriptor

    sudo cp /etc/tomcat5.5/Catalina/localhost/idp.xml /etc/tomcat6/Catalina/localhost/
    

    Endorsed library-k

    cd /usr/share/tomcat6/
    sudo mkdir endorsed
    sudo cp -i ~/shibboleth-identityprovider-2.1.4-slo3/endorsed/* endorsed/
    

    Logok, metadata írása

    sudo chown -R tomcat6  /var/log/shibboleth-idp/
    sudo chown -R tomcat6  /var/run/shibboleth-idp/
    

    Terracotta

    sudo chown -R tomcat6 /var/log/terracotta/client/
    

    Tomcat 5.5 eltávolítása

    sudo aptitude remove tomcat5.5
    sudo update-rc.d -f tomcat5.5 remove
    sudo rm -r /etc/init.d/tomcat5.5 /etc/default/tomcat5.5 /etc/tomcat5.5/ /var/lib/tomcat5.5 /usr/share/tomcat5.5
    

    SP_Operational_Requirements

    Purpose of this document

    This document defines identity management and system operation requirements and recommendations for Service Providers joining the HREF Federation.

    Throughout this document the interpretation of terms MUST, MUST NOT, SHOULD, SHOULD NOT are defined as:

    Identity management

    1. The organisation running the Service Provider MUST have a Privacy Policy, and its location MUST be indicated in the Resource Registry.

    Service management

    1. The organisation MUST develop a role responsible for liaison with the Federation Operator.
    2. The organisation operating the Service Provider MUST provide end-user support about its service and have its users informed about the availability of the support.

    Operational issues

    1. Cryptographic keys of the Service Provider MUST be at least 1024 bits long.
      1. Private keys MUST be protected.
      2. In case of a key compromise, the Federation Operator MUST be notified within 24 hours.
      3. Use of self-signed certificates with a long expiration time is RECOMMENDED.
    2. Use of SAML:
      1. The Service Provider MUST comply with the Interoperable SAML 2.0 Web Browser SSO Deployment Profile (http://saml2int.org)
      2. It is RECOMMENDED to support SAML2 Single Logout Profile over HTTP Redirect and SOAP Bindings.
    3. All SAML endpoints of the Service Provider SHOULD be protected by HTTPS.
    4. All SAML endpoints of the Service Provider MUST be under a DNS domain which is either possessed by the operating organisation, or the organisation MUST be commissioned by the owner of the domain (according to WHOIS database) in written form for using its domain in eduID.

    AAI_szolgáltatási_IP

    eduID szolgáltatási IP-k

    193.224.92.0/24
    193.225.14.128/25
    2001:738:0:431::/64

    EduidFedStats

    Ezen az oldalon a föderációban résztvevő IdP-k történő becsatornázásáról lehet olvasni.

    Általában

    Egy IdP-nek naponta egyszer kell beküldenie az összesített, előző napra vonatkozó statisztikáit. A beküldendő fájl az alábbi módon épül fel:

    ENTITYID https://idp.niif.hu/idp/shibboleth
    APIKEY 0123.......
    DATE 2009-03-18
    
    STAT AUTH
    68 logins
    
    STAT USER_COUNT
    16 unique userids
    
    STAT SSO_TO_SERVICE
    1        | urn:geant:niif.hu:niifi:sp:register.ca.niif.hu
    12       | https://repo.niif.hu/shibboleth
    1        | https://sandbox.aai.niif.hu/shibboleth
    5        | https://sysmonitor.hbone.hu/shibboleth
    10       | https://www.ki.iif.hu/shibboleth
    1        | https://noc6.vh.hbone.hu/shibboleth
    21       | https://webadmin.iif.hu/shibboleth
    3        | https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth
    7        | https://ugyeletes.vh.hbone.hu/shibboleth
    2        | https://noc.grid.niif.hu/shibboleth
    1        | https://wiki.voip.niif.hu/shibboleth
    2        | https://netmonitor.hbone.hu/shibboleth
    2        | https://idp.sch.bme.hu:443/opensso/sp/test
    

    A fájl szerkezetileg két részre osztható. Az első három sorban kerül megadásra, hogy a statisztika miről szól (az idp entityID-ja, egy speciális 40 karakteres azonosítója és a dátum), a továbbiakban pedig az egyelőre három különböző statisztika típusra vonatkozó értékek.

    Teendők

    1. Kivonatoló python szkript letöltése. Jelenleg Shibboleth-hez és simpleSAMLphp-hez készítettük el.
    2. A beküldendő fájlt elkészítő szkript letöltése - ugyanaz Shibboleth-hez is és impleSAMLphp-hez is, lévén a forrás, melyből dolgoznak (a fenti szkript kimenete) ugyanaz.
    3. Az utóbbi szkript elején meg kell adni a beállításokat.
    PARSER_COMMAND="/opt/shibboleth-idp/bin/audit_r7.py" //Az első lépésben letöltött szkript elérési útvonala
    SOURCEDIR="/opt/shibboleth-idp/logs" //A statisztika alapját képző logok elérési útvonala
    TARGETDIR="/tmp" //Munkakönyvtár - itt hozza létre a beküldendő fájlokat a szkript, majd beküldés után törli is őket innen
    
    ENTITYID="idp-entity-id" //Az idp entityID-je
    APIKEY="aaa..." //A 40 karakteres egyedi azonosító. Ezt az első beküldés előtt meg kell kérni: aai@niif.hu
    LOCATION2PUT="ttp://eduid.hu/stats/import_stats" //Az eduID statisztikái ezen az url-en keresztül kerülnek fogadásra
    
    //Az alábbi két sorban az audit logokat tartalmazó fájlnév mintáját adjuk meg - ez idp-nként változhat, az alábbi példa egy Shibboleth IdP-re vonatkozik
    DATE=`date -d "yesterday" +"%Y-%m-%d"`
    SOURCEFILE="$SOURCEDIR/idp-audit-$DATE.log"
    

    Mindezek után az utóbbi szkriptet célszerű betenni egy cronjobba, mindennapi futtatással. Érdemes kora hajnali időpontot megadni, hisz ekkor már elérhetők az előző napi statisztikák, és az adott nap munkaidőben pedig már tudjuk nézegetni a beküldött adatokat :)

    Alternatív megoldás

    Shibboleth-hez választható cstamas python szkriptje is, amely által kihagyható a shell szkriptes ügyeskedés, és minden egy python configon keresztül adható meg.

    Használata:

    review
    ./Audit_shib_cstamas.py -lupe -d 2010-11-28 --config Audit_shib_cstamas.cfg /tmp/idp-audit-2010-11-28.log
    
    upload
    ./Audit_shib_cstamas.py -lupe -d 2010-11-28 --config Audit_shib_cstamas.cfg --up /tmp/idp-audit-2010-11-28.log
    

    Természetesen a megfelelő beállítások után ezt is napi rendszerességgel kell lefuttatni.

    Erre ime egy megoldas, ez cronjobbal vagy valami alternativ utemezovel indithato.

     #!/bin/sh
    
     set -e
    
     cd /ahol-a-script-van
     # vagy a scriptet berakod a pathba es teljes utvonallal hivatkozol a konfigra
    
     for i in /usr/local/shibboleth-idp-2.2.0-slo9/logs/idp-audit-201*log
     do
       d=$(echo $i | cut -b 53-62)
       # XXX a cut -nak a datumot kell kiszednie a fajlnevbol, igy valtoztatas szukseges
       ./Audit_shib_cstamas.py -lupe -d $d --config Audit_shib_cstamas.cfg --up $i
       gzip -v9 $i
       sleep 5
     done
    

    SessionCreationError

    Ha Session creation failure üzenetet kapunk, azt jelenti, hogy a Shibboleth SP-nek - ugyan a webszerver modul aktiválódik - nem sikerült létrehoznia megfelelő session-t. Ennek számos oka lehet, de első körben az SP naplóállományában (általában: /var/log/shibboleth/shibd.log) kell keresni a hiba okát.

    Lehetséges hibák:

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

    A felsorolás nem tartalmazza az összes előforduló hibát, kiegészítésre szorul!
    

    Lásd még:

    Föderáció

    Az Identitás Föderáció olyan intézmények halmaza, amelyek között lehetséges az identitás-információk átadása. Az intézmények - szabályozott keretek között - megbíznak a másik intézmény által kiállított identitás-információkban.

    A Föderáció a pont-pont bizalmi kapcsolati modell általánosítása. Ekkor nem szükséges egy intézménynek minden egyes társintézménnyel külön megállapodást kötnie, hanem a szövetséghez csatlakozással automatikusan létrejön közöttük a lehetőség az identitás-információk átadására. Általában lehetőség van arra, hogy egy intézmény több Föderációhoz is kapcsolódjon, ill. külön bilaterális megállapodásai legyenek.

    Célja

    A föderációk célja, hogy az identitás információk egyébként autonóm rendszerek között átjárhatók legyenek. Ez a következő előnyökkel járhat:

    Szerepek

    A legtöbb föderációs modell lehetővé teszi azt, hogy egy intézmény egyszerre több szereppel is részt vegyen egy föderációban.

    Identitás szolgáltatók (Identity Provider, IdP)

    A felhasználók adatait az identitás szolgáltató tárolja. Az identitás szolgáltató funkciói: Azonosítás

    Attribútumok kiadása

    Felhasználó menedzsment

    Tartalom / erőforrás szolgáltatók (Service Provider, SP)

    A tartalomszolgáltatók védett tartalmakat szolgáltatnak a felhasználók számára. Általában nincsenek közvetlenül a felhasználókhoz kapcsolatos adataik, ezért nem szükséges a felhasználókat adminisztrálniuk sem.

    A tartalomszolgáltató funkciói (a funkciók föderációs modelltől függően ezektől eltérhetnek):

    Metadata adminisztráció

    A szolgálatókhoz kötődő háttérinformációkat (pl. tanúsítvány, név, scope, stb.) sok esetben a föderációs szoftver számára is elérhetővé kell tenni, ez esetben Metadata használatáról beszélünk. Adminisztrációja általában központilag történik, és push vagy pull módszerrel jut el a föderációba bevont számítógépekhez.

    Speciális szolgáltatás a "Where Are You From?" (WAYF) szolgáltatás, amely a felhasználó számára lehetőséget ad, hogy az identitás szolgáltatóját kiválassza. Ez a szolgáltatás a föderációs metadata állomány(ok)ra épül.

    Föderációs alapelvek

    1. A föderáció célja, hogy a felhasználók úgy vehessenek igénybe szolgáltatásokat - amennyiben erre jogosultak -, hogy a saját intézményük azonosítja őket.
    2. Az IdP és az SP egyértelműen azonosítja magát, amikor üzenetet váltanak egymással.
    3. Az IdP csak valós személyeket azonosít (teszt felhasználókat csak meghatározott módon, korlátozásokkal szabad azonosítani)
    4. Az IdP csak abban az esetben azonosít egy felhasználót, ha az illető valamilyen - ismert - viszonyban van (volt) az intézménnyel.
    5. Az IdP és az SP nem ad meg magáról hamis, félrevezető információt.
    6. 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.
    7. 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.
    8. Az SP csak a működéséhez minimálisan szükséges adatmennyiséget igényli a felhasználóról.
    9. Az SP nem kérheti a felhasználót, hogy adja meg az IdP-nél érvényes jelszavát. Jelszó az SP-nek nem adható ki (kivéve speciális esetben egyszer használatos vagy rövid lejáratú jelszavak).
    10. Az SP az IdP-től származott információt harmadik félnek nem adja tovább.
    11. Felhasználói visszaélések esetén az IdP és az SP együttműködik egymással.
    12. Az IdP és az SP az informatikai rendszereit az elvárható gondossággal üzemelteti.

    Technológiák

    Szabályozás

    A lazán csatolt modellek (pl. az OpenID) nem igényelnek központi szabályozást, de a magasabb biztonság-igényű, nagy bizalmat igénylő modellek esetén szükséges az, hogy a föderációban résztvevő intézmények kidolgozzák (esetleg szerződésbe is foglalják) az együttműködés feltételeit.

    A megállapodás pl. az alábbi területeket érintheti

    SamlSign

    Parancssoros eszköz, melyhez debian alatt az opensaml2-tools csomagot kell telepíteni. A program kétféle üzemmódban képes működni: metaadat aláírása és metaadat ellenőrzése.

    Metaadat aláírása

    samlsign -s -k /path/to/mainkey.key -f /path/to/metadatatosign.xml
    

    Alapértelmezés szerint a samlsign az eredményeket az alapértelmezett kimenetre írja ki (STDOUT), így célszerű ezt egy új fájlba átirányítani:

    samlsign -s -k /path/to/mainkey.key -f /path/to/metadatatosign.xml > /path/to/metadatasigned.xml
    

    Metaadat ellenőrzése

    samlsign -c /path/to/maincert.crt -f /path/to/metadatatosign.xml
    

    Samlsign legfontosabb kapcsolói

    További fontos tudnivalók A samlsign nem szereti a metadatában szereplő Organization-nel kapcsolatos adatokat, mivel ilyen tag-ekben kötelezően megadandó xml:lang attribútumot lang-ra alakítja át, ami által viszont nem lesz érvényes (valid) maga a metaadat, így pl. a shibboleth sem fog tudni vele mit kezdeni. A megoldás (nem szép, de hasznos): az aláírás előtt álló metaadatokból ki kell szedni az Organization-nel kapcsolatos adatokat. Ezek után már gond nélkül aláírja és az eredmény is érvényes lesz.

    Apró trükk a privát kulcs kinyerésére jks-ből

    Tekintettel arra, hogy a keytool nem teszi lehetőve a privát kulcs kihalászását JavaKeystore-ból, így külső segítséget kell igénybe vennünk. A segédalkalmazás ExportPrivateKey névre hallgat, és innen letölthető egy darab zip fájl. Használata rendkívül egyszerű:

    java -jar ExportPrivateKey.zip {jks fájl elérhetősége} JKS {jks jelszó} {alias} {célfájl}
    

    Ezek után a létrehozott kulccsal már használhatjuk is a samlsign-t.

    FedReqDef

    HREFContract

    A HREF Föderáció nem jogi személy, így a szerződést formálisan a Föderációs Operátor és a Tag illetve a Partner kötik. A csatlakozáshoz szükséges egy egyoldalú szándéknyilatkozat aláírása is.

    A dokumentumok letölthetők eduid.hu/dokumentumok oldalról.

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


    Metadata

    Ahhoz, hogy a föderációban résztvevő entitások biztonságosan tudjanak kommunikálni egymással, szükség van egy metaadat állományra. Ez a metaadat állomány szinte mindig humán felügyelettel jön létre, mivel a szervezetek közötti bizalmi kapcsolat technikai leképzésének ez az elsődleges eleme. (Másodlagos leképzésnek nevezhetjük az attribútum policy IdP és SP oldali megvalósítását.)

    SAML 2.0 metaadatok

    Pontos szabvány: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

    A metadata állomány az alábbi fontosabb információkat tartalmazza

    Metadata érvényesége és hitelessége

    IdP

    AA

    SP

    Tanúsítványok

    Kontakt információk

    Példák

    Egy IdP-hez tartozó metadata

    A meglehetősen komplex eseteket leszámítva általában az Identity Provider és az Attribute Authority egyetlen entitásként kezelhető.

    <EntityDescriptor entityID="https://idp.niif.hu/shibboleth">
    
            <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
                    <Extensions>
                            <shibmd:Scope>niif.hu</shibmd:Scope>
                    </Extensions>
                    <KeyDescriptor use="signing">
                        <ds:KeyInfo>
                            <ds:X509Data>
                                    <ds:X509Certificate>
    MIIFAzCCA+ugAwIBAgICAl8wDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCSFUx
    DTALBgNVBAoTBE5JSUYxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVz
    MRUwEwYDVQQDEwxOSUlGIFJvb3QgQ0EwHhcNMDcwMzMwMTA0OTQ5WhcNMDgwMzI5
    MTA0OTQ5WjCB1zELMAkGA1UEBhMCSFUxEDAOBgNVBAoTB05JSUYgQ0ExEDAOBgNV
    BAgTB0h1bmdhcnkxETAPBgNVBAcTCEJ1ZGFwZXN0MUIwQAYDVQQKEzlOYXRpb25h
    bCBJbmZvcm1hdGlvbiBJbmZyYXN0cnVjdHVyZSBEZXZlbG9wbWVudCBJbnN0aXR1
    dGUxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMRQwEgYDVQQDEwtpZHAubmlpZi5o
    dTEeMBwGCSqGSIb3DQEJARYPcG9sYWtvdmlAaWlmLmh1MIGfMA0GCSqGSIb3DQEB
    AQUAA4GNADCBiQKBgQDFuOD6yq3NlMaQoR6qyRlET1WyGT+hllH+1qXIHHwag2gL
    KYByQpBXPva3uSsswn3Rjmv2G/9ifX8sUadflM/MDoCLRoq9umJkcwmOHEp1fMfa
    7Gx9isEeVNYO0taN9Lol5EQL6rdZMSmwAZ17DCTNs48tPdzm7ys5EOe+bHHA3wID
    AQABo4IB3DCCAdgwEQYJYIZIAYb4QgEBBAQDAgZAMA4GA1UdDwEB/wQEAwIE8DAa
    BgNVHREEEzARgQ9wb2xha292aUBpaWYuaHUwggFZBgNVHR8EggFQMIIBTDCBvKBb
    oFmkVzBVMQswCQYDVQQGEwJodTENMAsGA1UEChMETklJRjEgMB4GA1UECxMXQ2Vy
    dGlmaWNhdGUgQXV0aG9yaXRpZXMxFTATBgNVBAMTDE5JSUYgUm9vdCBDQYECAN6i
    WaRXMFUxCzAJBgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0
    aWZpY2F0ZSBBdXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMIGKoCmg
    J4YlaHR0cDovL3d3dy5jYS5uaWlmLmh1L25paWYtY2EtY3JsLmNybIECAN6iWaRX
    MFUxCzAJBgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZp
    Y2F0ZSBBdXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMB8GA1UdIwQY
    MBaAFIxuIeJxr6Aqp7Dk/rx+o/0PoOOIMBkGA1UdIAQSMBAwDgYMKwYBBAHdCgEB
    DAEAMA0GCSqGSIb3DQEBBQUAA4IBAQB262jS0aGJZrOg1Q6IVSodTnokgliojgWy
    1FAojS6ML0w7T0eA1PnqX42eSfQFB2Nh71dBUmw6i++iHdQ1gyxOHIelSDb4JFOB
    PoZ+3flwySXu42QgVjJZ46fEMsq2EM0PQV8p9pgBEjlG+6ifAEgJmKBnP+WCzQJ7
    3rugtu+q8KKQ0oxP0bWLYGllJ6tKLa4gJ1P/oLe6uX+GWP+P3bZfMpOq9Tu2MU+r
    l/gnG2rTSOBe7AEngRmeDfKKeFiSsg1cGxorxQJoEzBZksKUa0nlA9xtd30sUQFX
    OI2/Xo2ihYFcpzu551S6+mutZNHqKgOT7uID/TCHr5R0Q1h7CPCS
                                    </ds:X509Certificate>
                           </ds:X509Data>
                        </ds:KeyInfo>
                    </KeyDescriptor>
                    <ArtifactResolutionService index="1"
                            Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
                            Location="https://idp.niif.hu:8443/shibboleth-idp/Artifact"/>
                    <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
                    <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
                                         Location="https://idp.niif.hu/shibboleth-idp/SSO"/>
            </IDPSSODescriptor>
    
            <AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
                    <Extensions>
                            <!-- This is a Shibboleth extension to express attribute scope rules. -->
                            <shibmd:Scope>niif.hu</shibmd:Scope>
                    </Extensions>
                    <KeyDescriptor use="signing">
                        <ds:KeyInfo>
                            <ds:X509Data>
                                    <ds:X509Certificate>
    MIIFAzCCA+ugAwIBAgICAl8wDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCSFUx
    DTALBgNVBAoTBE5JSUYxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVz
    MRUwEwYDVQQDEwxOSUlGIFJvb3QgQ0EwHhcNMDcwMzMwMTA0OTQ5WhcNMDgwMzI5
    MTA0OTQ5WjCB1zELMAkGA1UEBhMCSFUxEDAOBgNVBAoTB05JSUYgQ0ExEDAOBgNV
    BAgTB0h1bmdhcnkxETAPBgNVBAcTCEJ1ZGFwZXN0MUIwQAYDVQQKEzlOYXRpb25h
    bCBJbmZvcm1hdGlvbiBJbmZyYXN0cnVjdHVyZSBEZXZlbG9wbWVudCBJbnN0aXR1
    dGUxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMRQwEgYDVQQDEwtpZHAubmlpZi5o
    dTEeMBwGCSqGSIb3DQEJARYPcG9sYWtvdmlAaWlmLmh1MIGfMA0GCSqGSIb3DQEB
    AQUAA4GNADCBiQKBgQDFuOD6yq3NlMaQoR6qyRlET1WyGT+hllH+1qXIHHwag2gL
    KYByQpBXPva3uSsswn3Rjmv2G/9ifX8sUadflM/MDoCLRoq9umJkcwmOHEp1fMfa
    7Gx9isEeVNYO0taN9Lol5EQL6rdZMSmwAZ17DCTNs48tPdzm7ys5EOe+bHHA3wID
    AQABo4IB3DCCAdgwEQYJYIZIAYb4QgEBBAQDAgZAMA4GA1UdDwEB/wQEAwIE8DAa
    BgNVHREEEzARgQ9wb2xha292aUBpaWYuaHUwggFZBgNVHR8EggFQMIIBTDCBvKBb
    oFmkVzBVMQswCQYDVQQGEwJodTENMAsGA1UEChMETklJRjEgMB4GA1UECxMXQ2Vy
    dGlmaWNhdGUgQXV0aG9yaXRpZXMxFTATBgNVBAMTDE5JSUYgUm9vdCBDQYECAN6i
    WaRXMFUxCzAJBgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0
    aWZpY2F0ZSBBdXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMIGKoCmg
    J4YlaHR0cDovL3d3dy5jYS5uaWlmLmh1L25paWYtY2EtY3JsLmNybIECAN6iWaRX
    MFUxCzAJBgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZp
    Y2F0ZSBBdXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMB8GA1UdIwQY
    MBaAFIxuIeJxr6Aqp7Dk/rx+o/0PoOOIMBkGA1UdIAQSMBAwDgYMKwYBBAHdCgEB
    DAEAMA0GCSqGSIb3DQEBBQUAA4IBAQB262jS0aGJZrOg1Q6IVSodTnokgliojgWy
    1FAojS6ML0w7T0eA1PnqX42eSfQFB2Nh71dBUmw6i++iHdQ1gyxOHIelSDb4JFOB
    PoZ+3flwySXu42QgVjJZ46fEMsq2EM0PQV8p9pgBEjlG+6ifAEgJmKBnP+WCzQJ7
    3rugtu+q8KKQ0oxP0bWLYGllJ6tKLa4gJ1P/oLe6uX+GWP+P3bZfMpOq9Tu2MU+r
    l/gnG2rTSOBe7AEngRmeDfKKeFiSsg1cGxorxQJoEzBZksKUa0nlA9xtd30sUQFX
    OI2/Xo2ihYFcpzu551S6+mutZNHqKgOT7uID/TCHr5R0Q1h7CPCS
                                    </ds:X509Certificate>
                            </ds:X509Data>
                        </ds:KeyInfo>
                    </KeyDescriptor>
                    <AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
                                      Location="https://idp.niif.hu:8443/shibboleth-idp/AA"/>
    
                    <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
            </AttributeAuthorityDescriptor>
    
    </EntityDescriptor>
    

    Egy SP-hez tartozó metadata

    <EntityDescriptor entityID="https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth">
            <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
                    <KeyDescriptor use="signing">
                        <ds:KeyInfo>
                            <ds:X509Data>
                                    <ds:X509Certificate>
    MIIEmjCCA4KgAwIBAgICArwwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCSFUx
    DTALBgNVBAoTBE5JSUYxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVz
    MRUwEwYDVQQDEwxOSUlGIFJvb3QgQ0EwHhcNMDcxMTMwMTMwNzE4WhcNMDgxMTI5
    MTMwNzE4WjBvMQswCQYDVQQGEwJIVTEQMA4GA1UEChMHTklJRiBDQTEOMAwGA1UE
    CxMFSEJPTkUxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMSUwIwYDVQQDExxycmQt
    bWEucGVyZnNvbmFyLnZoLmhib25lLmh1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
    iQKBgQC2x6Hpjr4yB6EDkXUHNMlHz250kqWBXf/UI6TziV5rvMjvS8pdFnsZcIt1
    coT03Fu4wzs6N8gtC5uW7f3JaBsG32sYZUorWcbecpgVy5ttcIqTM1RnxUsOktsM
    RuBz7qYAQ1/B9VvBH7P7DeREgIGm7Skel/Q3Qhl4oG9PtFe1wQIDAQABo4IB3DCC
    AdgwEQYJYIZIAYb4QgEBBAQDAgbAMA4GA1UdDwEB/wQEAwIE8DAaBgNVHREEEzAR
    gQ9wb2xha292aUBpaWYuaHUwggFZBgNVHR8EggFQMIIBTDCBvKBboFmkVzBVMQsw
    CQYDVQQGEwJodTENMAsGA1UEChMETklJRjEgMB4GA1UECxMXQ2VydGlmaWNhdGUg
    QXV0aG9yaXRpZXMxFTATBgNVBAMTDE5JSUYgUm9vdCBDQYECAN6iWaRXMFUxCzAJ
    BgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZpY2F0ZSBB
    dXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMIGKoCmgJ4YlaHR0cDov
    L3d3dy5jYS5uaWlmLmh1L25paWYtY2EtY3JsLmNybIECAN6iWaRXMFUxCzAJBgNV
    BAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZpY2F0ZSBBdXRo
    b3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMB8GA1UdIwQYMBaAFIxuIeJx
    r6Aqp7Dk/rx+o/0PoOOIMBkGA1UdIAQSMBAwDgYMKwYBBAHdCgEBCQEAMA0GCSqG
    SIb3DQEBBQUAA4IBAQAVuG4+KUxQZcYCedQmW6Ih83gqMS7inxfBFeadc4Ts1egY
    Wf6Y4CoEOrsdI7FmC7CCccarDaMC6PVJg1WlDV01LMGM2+6rcoMeMs/J5pCFTDhn
    c6MPz6KedRcMvVJajY+BZvJPG9CNpyxdiUf/aDa28yRryVM0Jbm6BOFH+UrVHlVw
    w2JxlmsHtk1fNmEU7gluzwo3FEZrx8nnLWkeTfMzz/iM+dudNm4sL99uGNEWGNFf
    tLi+R35McE7CfyNNfOvlskZX++dSX/Re8CERTo3wZrHmFKIoOnJzo6v48d2tEbw0
    a15Yl93MJCNlC5BUyvUMqKDLmHhTxmgO+HIaV7Kf
                                    </ds:X509Certificate>
                            </ds:X509Data>
                        </ds:KeyInfo>
                    </KeyDescriptor>
    
                    <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
    
                    <AssertionConsumerService index="1" isDefault="true"
                            Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
                            Location="https://rrd-ma.perfsonar.vh.hbone.hu/Shibboleth.sso/SAML/Artifact"/>
                    <AssertionConsumerService index="2"
                            Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
                            Location="https://rrd-ma.perfsonar.vh.hbone.hu/Shibboleth.sso/SAML/POST"/>
            </SPSSODescriptor>
    </EntityDescriptor>
    

    Shibboleth 1.3

    A Shibboleth (mind az SP, mind az IdP) a metaadatokat kizárólag a másik féllel kapcsolatban használja, tehát a saját konfigurációjával kapcsolatban figyelmen kívül hagyja.

    Az 1.3-as verzió kizárólag lokális állományokkal dolgozik (ez változni fog a 2.0-ban).

    Scope

    A Shibboleth 1.3 kiterjesztette a SAML2 metadata struktúrát egy saját, Scope mezővel. Ez a "scope" igazából egy postfix tagot definiál, melynek segítségével bizonyos attribútumok értelmezési helye jól meghatározható.

    Erre jó példa az eduPersonPrincipalName attribútum, mely a felhasználó egyedi azonosítóját adja meg. Ez az azonosító két részből áll:

    Ha a metadatában használjuk a Scope mezőt, akkor az SP ellenőrizni tudja, hogy az IdP jogosult-e ilyen scope-pal rendelkező attribútumot kiadni.

    Szintén gyakran használt scope-os attribútum az eduPersonScopedAffiliation.

    Metadata eszközök

    Több metadata állomány használata

    Mind az IdP, mind az SP képes arra, hogy több metadata állományt használjon. Így például különvehetjük az SP-ket az IdP-ktől, ill. több föderációban lehet benne a provider.

    A metadata állományok tartalma összeadódik.

    !!! danger "Figyelem"

    Ugyanaz az **`entityId`** (más néven [[providerId]]) nem szerepelhet többször! Az **`entityId`**-knek az összes használt metadata állományra nézve egyedinek kell lennie.
    

    Metadata állományok frissítése

    A metadata állományok központi helyről való letöltésére a Siterefresh és a Metadatatool eszközök valók.

    Az átszerkesztett/új metadata állományt mind az IdP, mind az SP automatikusan beolvassa, újraindítás nem szükséges.

    Nem SAML 2.0 metaadatokat használó alkalmazások

    simpleSAMLphp

    Az újabb verziók már támogatják az XML formátumú metaadatokat, de az SSP moduljai szeretik még mindig a flatfile formátumot használni. Van egy metarefresh nevű modul, ami képes webről leszedni a metaadatokat, ellenőrizni az aláírást, és flatfile formátumú metaadatokat generálni. Fontos momentum, hogy figyelembe veszi a *<RequestedAttribute>* elementet, ezáltal megoldható az IdP-k attribútum kiadási szabályzatának automatikus frissítése is.

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

    Switch WAYF

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

    HREFUseCaseStub

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

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

    AAIInterop-Shib2SimpleSAMLphp

    !!! bug "Elavult információ"

    **Figyelem**: ez a szakasz vagy szócikk elavult információkat tartalmazhat!
    

    Shibboleth2 IdP - SimpleSAMLphp SP Interoperabilitás

    SAML2.0 Single Sign on

    HTTP-Post

    <RelyingParty id="https://papigw.aai.niif.hu/simplesaml"
       provider="https://papigw.aai.niif.hu/idp/shibboleth"
       defaultSigningCredentialRef="IdPCredential">
       <ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
          encryptNameIds="never" includeAttributeStatement="true"/>
    </RelyingParty>
    

    HTTP-Artifact

    Attribute push

    Attribute pull

    NameIDFormat

    SAML2.0 Single Log out

    DrupalShibbolethReadmeDev

    Drupal shib_auth module enables Shibboleth authentication for Drupal CMS.

    Installation and bootstrapping

    !!! warning

    The following documentation assumes that
    
    * You [understand how Shibboleth works](https://wiki.shibboleth.net/confluence/display/SHIB2/FlowsAndConfig)
    * You have [successfully installed and configured Shibboleth SP](https://wiki.shibboleth.net/confluence/display/SHIB2/Installation) on your host running Drupal.
    

    Installing the module

    1. Download module source for your Drupal version from the project page.
    2. Uncompress archive to the modules/ directory
    3. Enable module at Administer -> Site building -> Modules

    Compatibility

    The module assumes that you use Shibboleth SP 2.x. It's possible to use the module with Shibboleth SP 1.3, but that version is not supported anymore.

    Upgrading the module

    !!! danger "Figyelem"

    If you upgrade from 3.x (or previous versions) to 4.x, **you must update the database**. After overwriting the files in the `modules/` directory, open up `YOUR_DRUPAL_INSTALLATION/update.php` in your browser and run update for the `shib_auth` module. **This is required to let your user info persist.**
    

    The upgrade script makes slight changes to the database. You only need to run this script once, however running it several times does no harm to your installation apart from showing some SQL errors.

    !!! note

    although the upgrade script was designed to be robust, please **back up your database** before upgrading.
    

    Moving from Drupal 6 to Drupal 7

    To migrate your working installation to D7, first you must update your module to the latest 4.x version. After that, you can perform the Drupal update.

    Get it running

    Configuring Shibboleth

    You should be familiar with protecting resources with Shibboleth before using this module. (See Shibboleth Wiki for comprehensive information) Please check that Shibboleth authentication is working for the location of your Drupal installation and all the necessary attributes are exported to the headers. You can enable DEBUG mode to dump the whole $_SERVER array. If you can see Shibboleth attributes there, you're fine.

    In Shibboleth there are two modes for protecting resources:

    !!! note

    after enabling "strict" sessions, you won't be able to login with admin user. [Read on further](#bkmrk-administering-drupal-with-strict-sessions) how to give your own user administrator rights.
    
    Example Shibboleth configuration

    !!! note

    this example uses lazy sessions.
    

    /etc/shibboleth/shibboleth2.xml snippet:

    <RequestMapper type="Native">
      <RequestMap applicationId="default">
        <Host name="your.host.name">
          <Path name="location_of">
            <Path name="your_Drupal">
              <Path name="installation" authType="shibboleth" requireSession="false" />
            </Path>
          </Path>
        </Host>
      </RequestMap>
    </RequestMapper>
    

    Apache config file snippet (ie. /etc/apache2/sites-enabled/your.host.name, or you can even use .htaccess without the <Location> tags):

    <Location /location_of/your_Drupal/installation>
      AuthType Shibboleth
      ShibRequireSession Off
      ShibUseHeaders On
      require shibboleth
    </Location>
    

    DEBUG mode

    If you enable DEBUG mode on the module configuration interface, you can dump the $_SERVER, $_SESSION arrays and additionally the $user object, if the user is logged in. This mode shows you all the available attributes and helps you diagnosing possible Shibboleth attribute problems.

    Debug path prefix

    Leave it empty, if you want to display debug information on every page. Enter the string user/ (mind the trailing slash!) for displaying DEBUG messages only on paths below user/*

    Adding a prefix is useful, if you want to enable debugging on an online drupal installation without littering all of the pages with the debugging information. You can set it to a non-existent node as well, in this case, the information will be displayed over the built-in 404 page.

    Setting Shibboleth parameters for the module

    Handler settings

    If you are using lazy sessions, you have to define the Shibboleth SessionInitiator to which the user should be directed when she clicks on "Login with Shibboleth". The SessionInitiator can be called on a special URL which depends on your Shibboleth configuration.

    If your /etc/shibboleth/shibboleth2.xml is something like this:

    <Sessions lifetime="28800" timeout="3600" checkAddress="false"
              handlerURL="/Shibboleth.sso" handlerSSL="false"
              exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
              idpHistory="false" idpHistoryDays"7">
      <SessionInitiator type="Chaining" Location"/Login" isDefault="true" id="Intranet"
                        relayState="cookie" entityID"https://idp.example.org/shibboleth">
        <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
        <SessionInitiator type="Shib1" defaultACSIndex="5"/>
      </SessionInitiator>
      <!-- other things -->
      <LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
        <LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
        <LogoutInitiator type="Local"/>
      </LogoutInitiator>
      <!-- other things -->
    </Sessions>
    

    Then your

    !!! note

    Most common errors are (please check Shibboleth documentation):
    
    * using *http* when your Shibboleth SP is configured for *https* only (either by Apache settings or the*handlerSSL* parameter)
    * you want to use another SessionInitiator (for example with Discovery Service), such as `/DS`
    
    Attribute settings

    Specify here the $_SERVER headers to look up the user's username and e-mail address. Please check DEBUG mode to look for the available headers. If you can not find the desired attribute, then something is wrong with your IdP-SP attribute release flow.

    Both fields can have the same value, if you wish.

    Redirecting authenticated users to HTTPS

    It's a common problem if Shibboleth SP is configured on HTTPS only (handlerSSL="true"), while the site also works on plain HTTP. By using Force HTTPS on login feature, you can redirect your users to HTTPS at login time. This way you can have your anonymous users view your site unencrypted (which saves some CPU cycles), but once they login, they get redirected to HTTPS (which is the only secure use of Shibboleth SP).

    !!! note

    If you don't see Shibboleth attributes in DEBUG although you have double checked that you have set `AuthType shibboleth`, `require shibboleth` in your `.htaccess` file, you most probably need to turn this feature on.
    

    Understanding features

    Automatic user creation

    Drupal CMS requires all users to be in its internal SQL database. If the module detects that no user exists in the database with the received Shibboleth user identifier, it creates a new (Drupal) user.

    Drupal needs 3 pieces of information to create a new user:

    The module by default uses the username and e-mail address taken from the $_SERVER headers, see [Attribute settings](#bkmrk-attribute settings) right above. On new user creation a random password is generated. This can be overwritten by the user unless you disallow it by the userprotect module.

    !!! note

    if the user overwrites the password, she can log in with her username and the new password.
    

    Using custom values

    You may want to let your users to define their own Drupal usernames and e-mail addresses other than what was received from the IdP. If either User-defined usernames or User-defined e-mail addresses option is set, new users are presented a form to enter data at the first logon.

    !!! info

    * The module ensures that neither values are in use by existing users.
    * If you enable and later disable the options, the two behave differently. On subsequent logons:
    	* the user-defined username is **preserved**
    	* e-mail address gets **rewritten** (or the user gets a fatal error if the IdP does not provide the data)
    * Even if you enable user-defined usernames, the **IdP must send a unique identifier** which must be in the server variable defined for username. This feature just enables you to use opaque identifiers such as `eduPersonTargetedId`
    * User-defined e-mail addresses are not verified, only well-formedness is checked
    

    Working with federated identifiers

    If you enable the option User-defined usernames in the module configuration, every new user is presented a form to specify a Drupal username. This way you can work with opaque (federated) identifiers such as eduPersonTargetedId, as long as it appears in the $_SERVER variable holding the username. The only limitation is that the federated identifier cannot be longer than 255 characters, however it can contain characters otherwise not allowed in Drupal account names (such as exclamation mark, etc).

    Disallowing password change

    If you don't want to let your users to change passwords and log in with it, you may want to disallow password change.

    1. Install Drupal User Protect module
    2. At Administer -> User management -> User Protect -> Protected roles tab check password for the authenticated user role.
    3. At Administer -> Permissions -> userprotect module: uncheck change own password for authenticated user
    4. Log in with a normal account, go to "My account" -> Edit. You shouldn't see the possibility for changing password; except for the case when the user has user administrator rights.

    Administering Drupal with strict sessions

    If you use strict sessions, you can not log in with a password. You need to grant your own user administrator rights to administer the CMS.

    1. Enable Shibboleth protection
    2. Login with your own user credentials, so that your Drupal user profile is created
    3. Disable Shibboleth protection
    4. Login as 'admin', grant your own user 'Administrator' rights.
    5. Enable Shibboleth protection
    6. Login with your own credentials, you should have 'Administrator' rights now.

    Pre-creating users

    Versions before 4.0 allowed pre-creating users without any tweaks; if the username matched, the user was logged in.

    Since 4.0 the module only logs in users who exist in {shib_authmap} and the update script only takes care of users tagged with 'shib_auth' in {authmap}. When there is no mapping in the {shib_authmap}, a new user is attempted to be created, which fails because of the mail being duplicated. So what was accidentally working with pre-created users, do not work anymore with 4.0.

    To pre-create users, you should first create the Drupal users in your preferred way (either by using the administration interface or by direct SQL query), and then you MUST manually run the following three queries:

    INSERT INTO shib_authmap (uid, targeted_id)
      SELECT uid, name
      FROM users
      WHERE uid > 1 AND (uid) NOT IN
        (SELECT uid
        FROM shib_authmap);
    
    INSERT INTO authmap (uid, authname)
      SELECT uid, targeted_id
      FROM shib_authmap
      WHERE (uid) NOT IN
        (SELECT uid
        FROM authmap);
    
    UPDATE authmap SET module = 'shib_auth'
    WHERE (uid) IN
      (SELECT uid
      FROM shib_authmap);
    

    !!! note

    These queries add all your existing users to `shib_authmap` with their usernames and make sure that your `authmap` table contains all of the user entries. You should optimize these queries if you have a large number of users.
    

    !!! danger "Figyelem"

    You should repeat these queries each time after you add pre-created users.
    

    Role assignment

    It's possible to assign roles to users based on their Shibboleth attributes.

    An assignment rule is made of three parameters:

    Dynamic rules (default)

    Dynamic rules add roles to the user, but do not save them to the user's profile. This means that

    Additional roles can be assigned statically to the user (as an individual) by the administrator as normally. Every logged in user gets the role Authenticated user automatically.

    Sticky rules

    On the other hand, sticky rules do save the roles to the user's profile. Thus

    User profile mapping

    From the 7.x-4.2 version (D6 is not supported) it is possible to define a mapping between Shibboleth attributes and Drupal Fields. You must have the Field UI and the Shibboleth profile fields modules enabled to use this functionality. Unlike other features of the module, this mapping is configured together with the field definition.

    Go to Administration » Configuration » People » Account settings » Manage fields (admin/config/people/accounts/fields) and create a new field or edit an existing one. The Shibboleth mapping is available on the Field Edit form and can be used in three ways:

    You can use the values of the server variables by referring to them with square brackets like [sn]. You can reference multiple server variables in one mapping. Anything that is not matched to a server variable will be treated as string and copied to the value of the field. The server variable match is case insensitive.

    As an example, consider the user's request containing the following server variables (regardless of being set by Shibboleth or by something else):

    [givenName] -> John
    [sn]        -> Doe
    [email]     -> jdoe@example.com
    

    The following mappings would produce the results as indicated:

    [sn], [givenName] <[email]> Doe, John jdoe@example.com [firstName] [sn] [firstname] Doe (note the mistaken header name)

    Account linking

    There might be cases when you have a number of existing users and you want them to (optionally) log in through the federation. If you enable account linking, a user can add her SSO login to her existing Drupal account. The process of adding an SSO login -> Drupal account association is the following (all steps are performed by the user):

    1. Login to Drupal (with username/password)
    2. Go to My account -> Edit
    3. Click on Link this account to Shibboleth!
    4. Authenticate with your IdP

    From this point the user can choose to login either with Shibboleth or with username/password. This feature can also be useful for users switching home organizations.

    !!! info

    * One Drupal account can be linked to more than one federated unique identifier, however
    * One federated identifier can only be linked to a single Drupal account
    * Nobody can link to *admin* or *Anonymous user*
    * If the administrator disables this feature, no new associations can be stored. Existing associations remain in effect.
    * On a new user logon, the one cannot choose the Drupal username of another user (when *user-defined usernames* is active). For account linking, the user must be already logged in.
    * Currently account linking link is not displayed if the user has been logged in using Shibboleth. If you want to support users with multiple federated identities, please file a feature request.
    

    !!! danger "Figyelem"

    Dynamic roles are roles based on server variables, not users. These may well be different on username/password logon and Shibboleth logon.
    

    Logging out

    Session expiry

    Enable the option "Destroy Drupal session when the Shibboleth session expires", if you want to force logout the users without a valid Shibboleth session. (This only applies to lazy sessions, otherwise it is the webserver what ensures that you have a valid session.)

    !!! info

    Keep in mind if you leave this option off:
    * if the Shibboleth session is lost, [assigned dynamic roles](#bkmrk-dynamic-rules-default) are lost, too
    * Shibboleth session might get lost if you use a clustered SP without a central session cache
    * **Never ever leave this option off if you want support Single Logout**. Otherwise the user will remain logged in to Drupal even after doing single (global) logout.
    

    URL to redirect to after logout

    Define an URL here, where you want the user to be navigated after logout. The URL can be absolute or relative to the server base url. The relative paths will be automatically extended with the site base URL.

    SAML2 Logout

    At the moment, Shibboleth2 SP supports SAML2 logout while the Shibboleth2 IdP does not. It has a consequence that (if you have a standard Shibboleth2 installation), you will get a Shibboleth error message on logout, like this:

    Global Logout
    Status of Global Logout: Identity provider does not support SAML 2 Single Logout protocol.
    

    You can avoid this message by commenting out SAML2 global logout initiator from /Logout handler in /etc/shibboleth/shibboleth2.xml:

    
     <!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
     <LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
       <!-- The following line should be commented out to make Drupal logout work,
            as long as your IdPs do not support SAML2 logout -->
       <!--LogoutInitiator type="SAML2" template="bindingTemplate.html"/-->
       <LogoutInitiator type="Local"/>
     </LogoutInitiator>
    

    In certain scenarios you are only allowed to store personal data if the user accepted some kind of legal agreement such as the Terms of Use or the Privacy Policy.

    When a new user arrives, she gets a screen with a link to the legal document and a checkbox. This page also contains the user's name and the e-mail address. Personal data required for login are stored only if the user accepts the agreement. If it's allowed by the administrator, the user might set custom values for those attributes.

    If the document changes, the administrator might increment the version. This case all users are forced to accept the new version of the agreement before logging in.

    !!! note

    Version matching is an exact match, so the user must accept exactly the same version what was specified by the administrator
    

    Personal data handled by the module

    Advanced SAML2 features

    SAML2 defines several properties of the authentication request message which may affect the authentication performed by the IdP.

    !!! warning

    **Be careful when using these options.**
    
    IdPs that do not support these features might signal an error instead of performing any kind of authentication of the user. Or might show errors *after* authenticating the user. Some kind of authentication handlers (ie. HTTP Basic Auth) will never work even if the IdP software is capable of handling these properties.
    

    isPassive

    If isPassive is set, then the user is redirected to the IdP or to the Discovery Service in advance, but neither of them are allowed to take over the control of the user interface (such as performing any visible authentication). If authentication (or IdP selection) can not be performed silently, an error is returned, which is then handled by the module.

    By using this option, you can auto-login users who are already logged in to the IdP even if you are using lazy sessions. If auto-login can not be performed, the user returns to Drupal unauthenticated without seeing any error message.

    !!! danger "Figyelem"

    You need to instruct Shibboleth to redirect errors back to Drupal to handle passive authentication failures. This is done by setting `redirectErrors` parameter in the RequestMap. See [Shibboleth wiki](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPContentSettings) for details.
    
    **IMPORTANT**: current implementation does not handle any errors except for NoPassive error. This means, that on every possible Shibboleth SP error you will get an unauthenticated Drupal page instead of a Shibboleth error page.
    

    !!! note

    this feature requires JavaScript.
    

    forceAuthn

    This feature requires reauthentication of the user at the IdP even if she is having an SSO session there. Just like isPassive, it's not generally supported by authentication handlers.

    In general, you should never mix isPassive and forceAuthn. The standard states that in this case, the IdP must reauthenticate the user without visibly taking control of the user interface. It's up to you, how you interpret it...

    Non-implemented features

    There are several other SAML features which are not yet implemented, because there seems to be very little practical interest for them. Please file a feature request if you really need them, but before doing so, please, spend a little time on thinking how things should really work.

    Change log

    Version 3.0 -> 3.1

    If you need documentation for 3.0, please use the previous version of the documentation

    Release notes

    Version 4.0

    Bug fixes

    New features

    Shib3IdpAuth

    Shibboleth 3 Identity Provider (IdP) hitelesítés

    Shibboleth 3 OpenLDAP címtárhoz kapcsolása

    Szerkesszük az {idp.home}/conf/ldap.properties állományt az alábbiak szerint

    ...
    ## Connection properties ##
    idp.authn.LDAP.ldapURL                          = ldap://ldap.intezmenyneve.hu:389
    idp.authn.LDAP.useStartTLS                      = false
    ...
    idp.authn.LDAP.bindDN                           = cn=pelda-admin-felhasznalo,dc=intezmenyneve,dc=hu
    idp.authn.LDAP.bindDNCredential                 = jelszo
    
    # Format DN resolution, used by directAuthenticator, adAuthenticator
    # for AD use idp.authn.LDAP.dnFormat=%s@domain.com
    idp.authn.LDAP.dnFormat                         =uid=%s,ou=people,dc=intezmenyneve,dc=hu
    ...
    

    !!! info

    A Shibboleth Identity Provider 2-es és 3-as verziója közötti egyik fontos különbség az LDAP hitelesítés átalakítása és natív könyvtárak használata a korábbi JAAS helyett.
    

    Dokumentáció: https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration

    Shib2IdpAttrib

    Az attribútum feloldást az IDP_HOME/conf könyvtárban található attribute-resolver.xml névre hallgató fájlban konfigurálhatjuk. A fájl szerkezetét tekintve négy részből áll.

    Attribute-resolver alapbeállítások

    Ezeket általában nem kell állítgatni, megfelelőek az alapbeállítások

    <AttributeResolver xmlns="urn:mace:shibboleth:2.0:resolver" xmlns:resolver="urn:mace:shibboleth:2.0:resolver"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pc="urn:mace:shibboleth:2.0:resolver:pc"
        xmlns:ad="urn:mace:shibboleth:2.0:resolver:ad" xmlns:dc="urn:mace:shibboleth:2.0:resolver:dc"
        xmlns:enc="urn:mace:shibboleth:2.0:attribute:encoder" xmlns:sec="urn:mace:shibboleth:2.0:security"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver classpath:/schema/shibboleth-2.0-attribute-resolver.xsd
                            urn:mace:shibboleth:2.0:resolver:pc classpath:/schema/shibboleth-2.0-attribute-resolver-pc.xsd
                            urn:mace:shibboleth:2.0:resolver:ad classpath:/schema/shibboleth-2.0-attribute-resolver-ad.xsd
                            urn:mace:shibboleth:2.0:resolver:dc classpath:/schema/shibboleth-2.0-attribute-resolver-dc.xsd
                            urn:mace:shibboleth:2.0:attribute:encoder classpath:/schema/shibboleth-2.0-attribute-encoder.xsd
                            urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd">
    
       <!-- ... -->
    </AttributeResolver>
    

    Attribútumok definiálása

    Az attribútum-definíciós szakasz igazából egyfajta egységesítése és előkészítése különböző forrásokból kinyerhető és később továbbítható adatoknak. Egy attribútum definiálásakor meg kell adni az alapként szolgáló <AttributeDefinition> elemet három attribútumával:

    <resolver:AttributeDefinition id="cn" xsi:type="simple:Simple"
            xmlns="urn:mace:shibboleth:2.0:resolver:ad">
    

    Az <AttributeDefinition> elemen belül meg kell adni az attribútum függőségét és az attribútum kódolási tulajdonságait

    Attribútumok függősége

    Egy attribútum függhet bármilyen más, az attribute-resolver.xml fájlban definiált elemtől, legyen az másik <AttributeDefinition>, vagy <DataConnector>. Egy attributum több más elemtől is függhet. Az egyetlen attribútuma a forrás elem azonosítója.

    <resolver:Dependency ref="ID_DEPENDENCY1" />

    Attribútumok kódolási tulajdonságai

    Egy attribútumhoz többféle kódolási mechanizmust megadhatunk, melyek meghatározzák, hogy az attribútum kiadásakor milyen formátum(ok)ban lesz elérhető az aktuális attribútum értéke. Ha nem adunk meg kódolási mechanizmust, alapértelmezetten SAML2String alapon kódol. Egy kódolás megadása az <AttributeEncoder> elem segítségével történik. A szükséges attribútumok

    Példa

    <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                               name="oid:1.3.6.1.4.1.5923.1.1.1.7"
                               friendlyName="commonName" />
    
    

    Kapcsolódások adattárakhoz

    Ahhoz, hogy megkaphassuk az egyes attribútumokhoz tartozó értéket, valamilyen adattárból (adatbázis, címtár) kell őket kinyernünk, hiszen ekkor még csak a sikeres azonosítás után tartunk, és csak a felhasználói nevet tudjuk, amivel az azonosítás megtörtént. Fontos, hogy az egyes kapcsolódások definiálásakor erre a felhasználói névre a $requestContext.principalName néven hivatkozhatunk, amely kiindulópontként szolgálhat lekérdezéseinkhez.

    Kapcsolódás címtárhoz

    1. Konnektor definiálása

    Új adatbáziskapcsolat létrehozásához definiálnunk kell a konnektort <DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"> az alábbi attribútumokkal

    Attribútumok, melyeket kötelező megadni

    <resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                            id="UNIQUE_ID"
                            ldapURL="LDAP_URL"
                            baseDN="BASE_DN"
                            principal="PRINCIPAL_NAME"
                            principalCredential="PRINCIPAL_CREDENTIAL">
    
         <!-- Ide kerülnek majd az további konfigurációs beállítások a következő lépések alapján -->
    
    </resolver:DataConnector>
    

    2. Az LDAP lekérdezés definiálása

    <resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                            id="UNIQUE_ID"
                            ldapURL="LDAP_URL"
                            baseDN="BASE_DN"
                            principal="PRINCIPAL_NAME"
                            principalCredential="PRINCIPAL_CREDENTIAL">
    
        <FilterTemplate>
            <![CDATA[
                (uid=${requestContext.principalName})
            ]]>
        </FilterTemplate>
    
         <!-- Ide kerülhet a lekérdezési eredmény mezőneveinek és értékeinek felüldefiniálása -->
    
    </resolver:DataConnector>
    

    Kapcsolódás relációs adatbázisokhoz

    1. Konnektor definiálása

    Új adatbáziskapcsolat létrehozásához definiálnunk kell a konnektort <DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"> az alábbi attribútumokkal

    Attribútumok, melyeket kötelező megadni

    Attribútumok, melyeket opcionálisan megadhatók

    <resolver:DataConnector xsi:typ="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                            id="UNIQUE_ID">
    
         <!-- Ide kerülnek majd az további konfigurációs beállítások a következő lépések alapján -->
    
    </resolver:DataConnector>
    

    2. Függőségek definiálása

    Opcionális

    3. Másodlagos adatkapcsolat definiálása

    Opcionális

    4/a. Idp által natívan vezérelt adatbáziskapcsolatok beállítása

    Az Idp alkalmazás által vezérelt kapcsolathoz definiálnunk kell egy <ApplicationManagedConnection> elemet az alábbi (mind kötelezően megadandó) attribútumokkal

    Példa MySQL adatbázis eléréséhez

    <resolver:DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                            id="UNIQUE_ID">
    
          <!-- Ide kerülhetnek a függőségek a másodlagos adatkapcsolatokkal kapcsolatos beállítások -->
    
         <ApplicationManagedConnection jdbcDriver="com.mysql.jdbc.Driver"
                                       jdbcURL="jdbc:mysql://localhost:3306/DATABASE_NAME?autoReconnect=true"
                                       jdbcUserName="DATABASE_USER"
                                       jdbcPassword="DATABASE_USER_PASSWORD" />
    
          <!-- Ide kerülnek majd az további konfigurációs beállítások a következő lépések alapján -->
    
    </resolver:DataConnector>
    

    4/b. Konténer által vezérelt adatbáziskapcsolatok beállítása

    5. SQL lekérdezés definiálása

    <resolver:DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                            id="UNIQUE_ID">
    
         <!-- Ide kerülhetnek a függőségek a másodlagos adatkapcsolatokkal kapcsolatos beállítások -->
    
         <ContainerManagedConnection resourceName="RESOURCE_NAME" />
    
         <QueryTemplate>
              <![CDATA[
                   SELECT * FROM PEOPLE WHERE userid='$requestContext.principalName'
              ]]>
         </QueryTemplate>
    
         <!-- Ide kerülhet a lekérdezési eredmény mezőneveinek és értékeinek felüldefiniálása -->
    
    </resolver:DataConnector>
    

    6. Lekérdezési eredmény mezőneveinek és értékeinek felüldefiniálása

    Opcionális

    Alapértelmezés szerint a lekérdezések eredményét mezőnevenként és a hozzákapcsolódó értékként egy-egy attribútumba szervezi a konnektor, melyet lehetőségünk van felüldefiniálni, ehhez a <Column> elemet használhatjuk az alábbi atttribútumokkal

    Kötelező megadni

    *columnName - az lekérdezés eredményének mezője, mellyel kapcsolatban módosításokat hajtanánk végre

    Az alábbiak közül minimum egyet kötelező megadni

    <resolver:DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                            id="UNIQUE_ID">
    
         <!-- Ide kerülhetnek a függőségek a másodlagos adatkapcsolatokkal kapcsolatos beállítások ill. a kapcsolatvezérló beállítások -->
    
    
         <QueryTemplate>
              <![CDATA[
                   SELECT * FROM people WHERE userid='$requestContext.principalName'
              ]]>
         </QueryTemplate>
    
         <Column columnName="firstname" attributeID="fname" />
         <Column columnName="personid" type="String" />
    
    </resolver:DataConnector>
    
    

    7. Összegzés

    Működő példa a fentieket összegezve

    <!-- ###### ###### ###### ###  -->
    <!-- Data Connectors -->
    <!-- ###### ###### ###### ###  -->
    
    <resolver:DataConnector id="vhoMySQLsurname" xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc">
    
            <ApplicationManagedConnection
                    jdbcDriver="com.mysql.jdbc.Driver"
                    jdbcURL="jdbc:mysql://localhost:3306/VHOtools?autoReconnect=true"
                    jdbcUserName="DATABASE_USER"
                    jdbcPassword="DATABASE_USER_PASSWORD" />
    
            <QueryTemplate>
                <![CDATA[
                         SELECT uniqueID FROM vho_Users WHERE username = '$requestContext.principalName'
                ]]>
            </QueryTemplate>
    
            <Column columnName="uniqueID" attributeID="uid" />
    
    </resolver:DataConnector>
    

    Principal Connectors

    Ezt sem kell babrálni :)

    <!-- ###### ###### ###### ###  -->
    <!-- Principal Connectors -->
    <!-- ###### ###### ###### ###  -->
    
    <resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="shibTransient"
                                 nameIDFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
    <resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="saml1Unspec"
                                 nameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
    <resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="saml2Transient"
                                 nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
    
    

    Attribútum

    HREF_metadata_specifikáció

    A föderációs metaadat célja, hogy a föderációban részt vevő intézmények illetve entitások technikai, bizalmi és adminisztratív adatait egy helyre gyűjtse. A metaadatok formátuma megfelel a SAML2 metaadat szabványnak.

    Biztonsági megfontolások

    Mivel a metadata tartalmazza a föderációban részt vevő tagok és komponensek technikai információit, ezért a benne tárolt információkkal kapcsolatban figyelembe kell venni a következő biztonsági megfontolásokat:

    Metaadatban tárolt információk

    Metaadat kiterjesztések használata

    Ezen kiegészítő adatok tárolására az internet2 szabványtervezetet készít, ennek a sémának a jelenlegi verziója megtalálható itt.

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

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

    Egy IdP példa

     <EntityDescriptor entityID="https://idp.niif.hu/shibboleth"
      xmlns:mdui="urn:oasis:names:tc:SAML:2.0:metadata:ui">
      <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
       <Extensions>
        <shibmd:Scope>niif.hu</shibmd:Scope>
        <mdui:DiscoHints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <mdui:GeolocationHint>47.518356,19.055437</mdui:GeolocationHint>
          <mdui:DomainHint>niif.hu</mdui:DomainHint>
          <mdui:DomainHint>iif.hu</mdui:DomainHint>
        </mdui:DiscoHints>
       </Extensions>
       <KeyDescriptor use="signing">
        <ds:KeyInfo>
         <ds:X509Data>
          <ds:X509Certificate>...</ds:X509Certificate>
         </ds:X509Data>
        </ds:KeyInfo>
       </KeyDescriptor>
       <!-- endpoints, nameidformats -->
       </IDPSSODescriptor>
      <ContactPerson contactType="technical">
       <SurName>NIIF AAI</SurName>
       <EmailAddress>aai@niif.hu</EmailAddress>
      </ContactPerson>
      <ContactPerson contactType="support">
       <SurName>NIIF AAI</SurName>
       <EmailAddress>aai@niif.hu</EmailAddress>
      </ContactPerson>
      <ContactPerson contactType="administrative">
       <SurName>NIIF AAI</SurName>
       <EmailAddress>aai@niif.hu</EmailAddress>
      </ContactPerson>
     </EntityDescriptor>
    

    Egy SP példa

     <EntityDescriptor entityID="https://rr.aai.niif.hu/shibboleth"
      xmlns:mdui="urn:oasis:names:tc:SAML:2.0:metadata:ui">
     <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol">
      <Extensions>
        <mdui:UIInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <mdui:PrivacyStatementURL>https://rr.aai.niif.hu/privacy-policy</mdui:PrivacyStatementURL>
          <mdui:InformationURL>https://rr.aai.niif.hu/about</mdui:InformationURL>
        </mdui:UIInfo>
      </Extensions>
      <KeyDescriptor use="signing">
       <ds:KeyInfo>
        <ds:X509Data>
         <ds:X509Certificate>...</ds:X509Certificate>
        </ds:X509Data>
       </ds:KeyInfo>
      </KeyDescriptor>
      <KeyDescriptor use="encryption">
       <ds:KeyInfo>
        <ds:X509Data>
         <ds:X509Certificate>...</ds:X509Certificate>
        </ds:X509Data>
       </ds:KeyInfo>
      </KeyDescriptor>
      <!-- endpoints -->
      <AttributeConsumingService index="1">
       <ServiceName xml:lang="hu">HREF Resource Registry</ServiceName>
       <ServiceName xml:lang="en">HREF Resource Registry</ServiceName>
       <ServiceDescription xml:lang="hu">Resource Registry - a föderáció adminisztrációs alkalmazása http://rr.aai.niif.hu/</ServiceDescription>
       <ServiceDescription xml:lang="en">Resource Registry - federation administration tool http://rr.aai.niif.hu/</ServiceDescription>
       <RequestedAttribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" isRequired="true"/>
       <RequestedAttribute FriendlyName="surname" Name="urn:oid:2.5.4.4" isRequired="true"/>
       <RequestedAttribute FriendlyName="givenName" Name="urn:oid:2.5.4.42" isRequired="true"/>
       <RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" isRequired="true"/>
       <RequestedAttribute FriendlyName="schacHomeOrganizationType" Name="urn:oid:1.3.6.1.4.1.25178.1.2.10" isRequired="true"/>
       <RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" isRequired="true"/>
      </AttributeConsumingService>
     </SPSSODescriptor>
     <Organization>
      <OrganizationName xml:lang="hu">NIIF - Nemzeti Információs Infrastruktúra Fejlesztési Intézet</OrganizationName>
      <OrganizationName xml:lang="en">NIIF Institute - National Information Infrastructure Development</OrganizationName>
      <OrganizationDisplayName xml:lang="hu">NIIF - Nemzeti Információs Infrastruktúra Fejlesztési Intézet</OrganizationDisplayName>
      <OrganizationDisplayName xml:lang="en">NIIF Institute - National Information Infrastructure Development</OrganizationDisplayName>
      <OrganizationURL xml:lang="hu">http://www.niif.hu</OrganizationURL>
      <OrganizationURL xml:lang="en">http://www.niif.hu/en</OrganizationURL>
     </Organization>
     <ContactPerson contactType="administrative">
      <SurName>NIIF AAI</SurName>
      <EmailAddress>aai@niif.hu</EmailAddress>
     </ContactPerson>
     <ContactPerson contactType="technical">
      <SurName>NIIF AAI</SurName>
      <EmailAddress>aai@niif.hu</EmailAddress>
     </ContactPerson>
     <ContactPerson contactType="support">
      <SurName>NIIF AAI</SurName>
      <EmailAddress>aai@niif.hu</EmailAddress>
     </ContactPerson>
     </EntityDescriptor>
    

    Metaadat aláírásának módja

    Aláíró kulcs és tanúsítványok

    HREF-2011

    HREF-2020

    Aláírási folyamat

    Az aláíratlan metaadat frissítése:

    1. Az aláíratlan metaadat a https://rr.eduid.hu oldalról ütemezetten, minden óra 15. és 45. percében letöltésre kerül.
    2. A letöltött metaadat XML séma ellenőrzése ellenőrzése.
    3. A metadat feltöltése az objektum tárolóba.

    Aláírás ellenőrzése explicit tanúsítvánnyal

    A föderáció entitásai a föderációs metaadat hitelességéről a digitális aláírás ellenőrzésével győződhetnek meg. Az explicit ellenőrzés esetén a [http://metadata.eduid.hu/current/](http://metadata.eduid.hu/current/) URL-ről kell letölteni a metadata fájlokat.

    Ajánlott a tanúsítvány lejárati idejét figyelmen kívül hagyni.

    HREF-2011

    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

    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

    Metaadat elérése

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

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

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

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

    MDX-alapú elérés

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

    A HREF föderációban teszt jelleggel működik és elérhető MDX-kiszolgáló: http://mdx.eduid.hu. A megfelelő beállításokhoz itt érhető el segédlet.

    Az MDX kiszolgáló eltérő kulcsot és tanúsítványt használ. Jelenleg az MDX elérés még csak teszt jelleggel működik, az élesüzemre váltáskor a HREF-2020 tanúsítvánnyal fog működni.

    A jelenlegi tanúsítvány innen tölthető le: http://metadata.eduid.hu/current/mdx-test-signer-2015.crt

    HREF-2015

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

    AAI_AzureADasAuthsource

    Amennyiben Azure AD-ban tároljuk a felhasználói adatokat, úgy lehetőség van azt azonosítási forrásként is használni. A SimpleSAMLphp oldalon leírt telepítés után az alábbiak elvégzésére van szükség:

    (ez csak egy példakonfiguráció, természetesen el lehet ettől térni)

    Teendők SimpleSAMLPHP (SSP) oldalon

    Keressük ki az Azure AD-ból a Tenant ID-t. A beállítás során erre TenantID-val fogunk hivatkozni, oda minden esetben ezt az azonosítót kell behelyettesíteni. Az azonosítót jelenleg a https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview oldalon keresztül lehet beszerezni (Forrás: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-to-find-tenant)

    A DOMAIN helyére a használni kívánt scope-ot szükséges behelyettesíteni (pl intezmeny.hu)

    config/authsources.php fájlba

        'default-sp' => [
            'saml:SP',
    
            // The entity ID of this SP.
            // Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
            'entityID' => null,
    
            // The entity ID of the IdP this SP should contact.
            // Can be NULL/unset, in which case the user will be shown a list of available IdPs.
            'idp' => 'https://sts.windows.net/_TenantID_/',
    
            // The URL to the discovery service.
            // Can be NULL/unset, in which case a builtin discovery service will be used.
            'discoURL' => null,
            'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
            'simplesaml.nameidattribute' => 'eduPersonTargetedID',
    
            /*
             * The attributes parameter must contain an array of desired attributes by the SP.
             * The attributes can be expressed as an array of names or as an associative array
             * in the form of 'friendlyName' => 'name'. This feature requires 'name' to be set.
             * The metadata will then be created as follows:
             * <md:RequestedAttribute FriendlyName="friendlyName" Name="name" />
             */
            /*
            'name' => [
                'en' => 'A service',
                'no' => 'En tjeneste',
            ],
    
            'attributes' => [
                'attrname' => 'urn:oid:x.x.x.x',
            ],
            'attributes.required' => [
                'urn:oid:x.x.x.x',
            ],
            */
        ],
    

    config/config-metarefresh.php fájlba

    $config = [
    
        'sets' => [
            'azure' => [
                'cron' => ['hourly'],
                'sources' => [
                    [
                        'src' => 'https://login.microsoftonline.com/_TenantID_/federationmetadata/2007-06/federationmetadata.xml',
                    ],
                ],
                'expireAfter' => 34560060, // Maximum 4 days cache time (3600*24*4)
                'outputDir' => 'metadata/metarefresh-azure',
                'outputFormat' => 'flatfile',
            ],
        ],
    ];
    

    metadata/saml20-idp-hosted.php

    A

        'authproc' => [
    
            10 => [
                  'class' => 'core:AttributeMap',
                  'azure2name'
            ],
    
            15 => [
                'class' => 'core:AttributeCopy',
                'eduPersonPrincipalName' => 'schacPersonalUniqueCode',
            ],
    
            16 => ['class' => 'core:PHP',            'code' => '                $attributes[= "urn:schac:personalUniqueCode:int:esi:_DOMAIN_:" . $attributes["schacPersonalUniqueCode"]("schacPersonalUniqueCode"][0])[0];
                ',
            ],
    
            18 => [
                'class' => 'core:AttributeAlter',
                'subject' => 'eduPersonPrincipalName',
                'pattern' => '/^.*$/',
                'replacement' => '${0}@_DOMAIN_',
                'target' => 'eduPersonPrincipalName'
            ],
    
            20 => [
                'class' => 'core:AttributeAdd',
                'eduPersonEntitlement' => array('urn:mace:dir:entitlement:common-lib-terms')
            ],
    
            22 => [
                'class' => 'core:AttributeAdd',
                'schacHomeOrganization' => array('_DOMAIN_')
            ],
    
            23 => [
                'class' => 'core:AttributeAdd',
                'schacHomeOrganizationType' => array('urn:schac:homeOrganizationType:eu:higherEducationalInstitution')
            ],
    
    // Azure AD-ban célszerű az affilation-t (intézményhez való viszonyt, pl hallgató, oktató, dolgozó) security group alapján meghatározni. Ezeknek az objektum azonosítóját át fogja adni az Azure AD, amit könnyen kicserélhetünk a kívánt affilation-re:
    
            31 => [
                'class' => 'core:AttributeAlter',
                'subject' => 'eduPersonAffiliation',
                'pattern' => '/^_eduID_Dolgozó_GroupID_$/', // _eduID_Dolgozó_GroupID_ értéket cseréljük a megfelelő Objektum ID-ra
                'replacement' => 'faculty',
            ],
    
            32 => [
                'class' => 'core:AttributeAlter',
                'subject' => 'eduPersonAffiliation',
                'pattern' => '/^_eduID_Hallgató_GroupID_$/', // _eduID_Hallgató_GroupID_ értéket cseréljük a megfelelő Objektum ID-ra
                'replacement' => 'student',
            ],
    
            33 => [
                'class' => 'core:AttributeAlter',
                'subject' => 'eduPersonAffiliation',
                'pattern' => '/^_eduID_Admin_GroupID_$/', // _eduID_Admin_GroupID_ értéket cseréljük a megfelelő Objektum ID-ra
                'replacement' => 'staff',
            ],
    
            34 => [
                'class' => 'core:AttributeAdd',
                'eduPersonAffiliation' => array('member'),
            ],
    
            35 => [
                'class' => 'core:AttributeCopy',
                'eduPersonAffiliation' => 'eduPersonScopedAffiliation'
            ],
    
            36 => [
                'class' => 'core:AttributeAlter',
                'subject' => 'eduPersonScopedAffiliation',
                'pattern' => '/^.*$/',
                'replacement' => '${0}@$_DOMAIN_',
            ],
    
            50 => [
                'class' => 'core:TargetedID',
                'identifyingAttribute' => 'eduPersonPrincipalName',
                'nameId' => TRUE,
            ],
    
            60 => [
                'class' => 'core:AttributeMap',
                'name2oid'
            ],
            75  => [
                'class' => 'entitycategories:EntityCategory',
                'default' => true,
                'strict' => false,
                'allowRequestedAttributes' => true,
                'http://eduid.hu/category/registered-by-eduidhu' => [],
                'http://www.geant.net/uri/dataprotection-code-of-conduct/v1' => [
                    'urn:oid:2.16.840.1.113730.3.1.241', # displayName
                    'urn:oid:2.5.4.4', # sn
                    'urn:oid:2.5.4.42', # givenName
                    'urn:oid:0.9.2342.19200300.100.1.3', # mail
                    'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', # eduPersonPrincipalName
                    'urn:oid:1.3.6.1.4.1.5923.1.1.1.9', # eduPersonScopedAffiliation
                    'urn:oid:1.3.6.1.4.1.5923.1.1.1.1', # eduPersonAffiliation
                ],
                'http://refeds.org/category/research-and-scholarship' => [
                    'urn:oid:2.16.840.1.113730.3.1.241', # displayName
                    'urn:oid:2.5.4.4', # sn
                    'urn:oid:2.5.4.42', # givenName
                    'urn:oid:0.9.2342.19200300.100.1.3', # mail
                    'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', # eduPersonPrincipalName
                    'urn:oid:1.3.6.1.4.1.5923.1.1.1.9', # eduPersonScopedAffiliation
                    'urn:oid:1.3.6.1.4.1.5923.1.1.1.1', # eduPersonAffiliation
                ],
            ],
    
            90 => 'core:AttributeLimit',
        ],
    
        'simplesaml.nameidattribute' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
    
        'attributeencodings' => array(
            'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw', /* eduPersonTargetedID with oid NameFormat. */
        ),
    
        'sign.logout' => true
    ];
    
    

    attributemap/azure2oid.php

    <?php
    $attributemap = [
        // displayName
        'http://schemas.microsoft.com/identity/claims/displayname' => 'urn:oid:2.16.840.1.113730.3.1.241',
        // eppn
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name' => 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6',
        // givenName
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname' => 'urn:oid:2.5.4.42',
        // cn
        '://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname' => 'urn:oid:2.5.4.3',
        // surname
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname' => 'urn:oid:2.5.4.4',
        // mail
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress' => 'urn:oid:0.9.2342.19200300.100.1.3',
        // o & organisation
        'http://schemas.microsoft.com/identity/claims/tenantid' => 'urn:oid:2.5.4.10',
    ];
    

    attributemap/azure2name.php

    <?php
    $attributemap = [
        // eppn
        'http://schemas.microsoft.com/identity/claims/objectidentifier' => 'eduPersonPrincipalName',
        // mail
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress' => 'mail',
        // displayName
        'http://schemas.microsoft.com/identity/claims/displayname' => 'displayName',
        // givenName
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname' => 'givenName',
        // cn
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname' => 'sn',
        // affiliation
        'http://schemas.microsoft.com/ws/2008/06/identity/claims/groups' => 'eduPersonAffiliation',
    ];
    

    Teendők Azure AD oldalon

    1. A https://portal.azure.com/ oldalon jelentkezzünk be egy adminisztrátori fiókkal
    2. Válasszuk az "App registrations"-t
    3. "New registration"
    4. "Redirect URI (optional)" -nál adjuk meg a telepített SSP default SP címét. Pl: https://idp.DOMAIN/simplesaml/module.php/saml/sp/metadata.php/default-sp
    5. "Token configuration" # > "Add optional claim"> "Token type"-nál válasszuk a "SAML"-t és jelöljük ki az összes attribútumot, majd, "Add"
    6. "Add groups claim", majd mentsük el bélyegkép
    7. Állítsuk be az API persmissions-t az alábbi alapján: bélyegkép

    Teszt

    Metadata_Specification

    Information about the entities of the Federation is maintained in a signed XML document, called the federation metadata.

    Metadata publishing rules

    The metadata file is available both at http://metadata.eduid.hu/current/href.xml and https://metadata.eduid.hu/current/href.xml, however the unencrypted method is preferred. The file is stored on a highly available file server.

    The metadata file is re-published every 4 hours or whenever the entity information changes (eg. entities are added or modified). Entities are expected to refresh metadata information regularly, although the cacheDuration attribute is currently not in use (for interoperability reasons).

    Trust in metadata

    The information inside the metadata file must not be trusted after the date specified in the validUntil field of the topmost EntitiesDescriptor is expired. The expiration time is is set to 7 days after the instant of the signature.

    Verification of the metadata file

    The contents of the metadata file must be trusted only if the signature of the Federation Operator can be validated.

    The Federation Operator uses a self-signed certificate for signing the metadata file, therefore the signing key must be explicitly trusted. Properties of the signing certificate:

    The certificate used for signing can be downloaded from https://metadata.eduid.hu/2011/href-metadata-signer-2011.crt , which link should lead to a page without certificate warnings with most browsers. It is recommended to request the signing certificate from the Federation Operator by using some other verifiable transport as well (such as PGP-signed email).

    Signing procedure

    Information about the entities is retrieved from the Resource Registry by using strong server authentication. If the contents of the metadata changes, it is saved to a version control system and the 'diff' is sent to a public mailing list (href-metadata-changes)

    The signing operation is done by a PIN-protected hardware token.

    Signing key change or revocation

    Changes of the signing key/certificate is always negotiated with the technical contacts of all federation entities.

    Authenticating peer entities

    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.

    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:

    Accordingly, all partner SP metadata management is performed by the Federation Operator, by the request of the Techical/Administrative Contact of the Partner.

    JoiningEduGAIN

    Metaadatok

    Az eduGAIN csatlakozáshoz a csatlakozó entitásnak - akár IdP, akár SP - ismernie kell az eduGAIN-ben résztvevő többi entitást. Ezt vagy a hagyományos módszerrel, az eduGAIN aláírt metaadatainak betöltésével lehet elérni, vagy az igény szerinti metaadat-kiszolgáló (MDX) használatával.

    Hagyományos XML állomány

    Töltse be és rendszeresen frissítse az általunk aláírt eduGAIN metadatát: http://metadata.eduid.hu/current/edugain.xml. Az aláírókulcs megegyezik a többi metadata setet aláíró kulccsal (https://metadata.eduid.hu/href-metadata-signer-2011.crt). Félreértések elkerülése végett a magyar entitások az újra aláírt eduGAIN metaadatok között nem szerepelnek, hogy ne legyen duplikáció.

    Ennél a módszernél fel kell készülni arra, hogy a metaadat-frissítés hosszadalmas, több percet igénylő folyamat lehet. Néhány jellemző probléma:

    Igény szerinti metaadat kiszolgálás

    Ebben az esetben a metaadatokat csak akkor töltjük le, ha éppen szükség van rájuk. Részletes leírás itt: MDX.

    Ennek a módszernek előnye, hogy sokkal kevesebb erőforrást igényel a szerveren. Az alapértelmezés szerinti gyorstárazási idő is jóval rövidebb, mint a hagyományos esetben, így a változások valamivel hamarabb érvényre jutnak.

    Egyidejű használat

    Mind a Shibboleth, mind a SimpleSAMLphp lehetővé teszi, hogy a hagyományos fájl-alapú és az MDX alapú metaadat forrásokat egyidőben használjuk. Például:

    Ilyen esetben az MDX metaadat-forrást célszerű utolsó helyre tenni a sorban. Ekkor az metaadat-kérés csak akkor hajtódik végre, ha az entitás egyik statikus forrásban sem található meg.

    HOWTO: SimpleSAMLphp metaadatforrások egyidejű használata.

    IdP csatlakozása az eduGAIN-hez

    Az IdP-nek értelmeznie kell SP-k attribútum-igényeit. Erre erősen ajánlott az EntityCategory alapú attribútum kiadást használni, kiegészítve a metadata-alapú (RequestedAttributes) attribútum kiadási mechanizmussal.

    A metaadatok, illetve az attribútum-kiadás megfelelő konfigurációja után az IdP csatlakozását az IdP technikai kapcsolattartója kezdeményezi a föderációs adminfelületen (https://rr.eduid.hu), ügyelve arra, hogy az entitáshoz beállított logó is https-en keresztüli url-en legyen elérhető, ill. rögzítésre kerüljenek a különböző leíró dokumentumok angol nyelvű változataira mutató url-ek is.

    SP csatlakozása az eduGAIN-hez

    A metaadatok megfelelő konfigurációja után az SP adminisztrátora a Resource Registry-ben állíthatja be, hogy az SP az eduGAIN-ben publikálásra kerüljön.

    A Discovery felület integrációjával kapcsolatban lásd az MDX leírás vonatkozó részét!

    Entitás kategóriák

    Amennyiben nemzetközi együttműködésben vesz részt az SP, az entitás kategóriák használatával megkönnyíthetjük, hogy az IdP-k az igényelt attribútumokat kiadják.

    Az entitás kategóriák beállítását az SP kapcsolattartója az info@eduid.hu címen kezdeményezheti.

    Research & Scholarship

    Amennyiben a szolgáltatás a kutatást vagy az oktatást támogatja, beállítható a Research & Scholarship entitás kategória. Részletes szabályok: https://refeds.org/category/research-and-scholarship

    GÉANT Data Protection Code of Conduct

    Az entitás kategória részletes szabályai itt találhatóak: https://wiki.edugain.org/Recipe_for_a_Service_Provider . Fontos kiemelni, hogy ez a kategória az entitás metaadatainak részletes kitöltését (https://rr.eduid.hu) igényli, valamint egy olyan angol nyelvű adatvédelmi szabályzat meglétét, amely hivatkozik a http://www.geant.net/uri/dataprotection-code-of-conduct/v1 dokumentumra.

    Shibenv-PHP-Lazy

    http://shib.kuleuven.be/download/sp/test_scripts/shibenv.php.txt alapján:

    <html>
    <head>
      <title>Shibboleth Attributes - <?php echo $_SERVER["SERVER_NAME"]; ?></title>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
      <META HTTP-EQUIV="Expires" CONTENT="-1">
    <script language"JavaScript" type="text/JavaScript">
    <!--
      function decodeAttributeResponse() {
            var textarea = document.getElementById("attributeResponseArea");
            var base64str = textarea.value;
            var decodedMessage = decode64(base64str);
            textarea.value = tidyXml(decodedMessage);
            textarea.rows = 15;
            document.getElementById("decodeButtonBlock").style.display='none';
      }
    
      function tidyXml(xmlMessage) {
            //put newline before closing tags of values inside xml blocks
            xmlMessage = xmlMessage.replace(/([^>])</g,"$1\n<");
            //put newline after every tag
            xmlMessage = xmlMessage.replace(/>/g,">\n");
            var xmlMessageArray = xmlMessage.split("\n");
            xmlMessage="";
            var nestedLevel=0;
            for (var n=0; n < xmlMessageArray.length; n++) {
                    if ( xmlMessageArray[n].search(/<\//) > -1 ) {
                            nestedLevel--;
                    }
                    for (i=0; i<nestedLevel; i++) {
                            xmlMessage+="  ";
                    }
                    xmlMessage+=xmlMessageArray[n]+"\n";
                    if ( xmlMessageArray[n].search(/\/>/) > -1 ) {
                            //level status the same
                    }
                    else if ( ( xmlMessageArray[n].search(/<\//) < 0 ) && (xmlMessageArray[n].search(/</) > -1) ) {
                            //only increment if this was a tag, not if it is a value
                            nestedLevel++;
                    }
            }
            return xmlMessage;
      }
    
      var base64Key = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
      function decode64(encodedString) {
        var decodedMessage = "";
        var char1, char2, char3;
        var enc1, enc2, enc3, enc4;
        var i = 0;
    
        //remove all characters that are not A-Z, a-z, 0-9, +, /, or =
        encodedString = encodedString.replace(/[^A-Za-z0-9\+\/\=]/g, "");
        do {
            enc1 = base64Key.indexOf(encodedString.charAt(i++));
            enc2 = base64Key.indexOf(encodedString.charAt(i++));
            enc3 = base64Key.indexOf(encodedString.charAt(i++));
            enc4 = base64Key.indexOf(encodedString.charAt(i++));
    
            char1 = (enc1 << 2) | (enc2 >> 4);
            char2 = ((enc2 & 15) << 4) | (enc3 >> 2);
            char3 = ((enc3 & 3) << 6) | enc4;
    
            decodedMessage = decodedMessage + String.fromCharCode(char1);
            if (enc3 != 64) {
                    decodedMessage = decodedMessage + String.fromCharCode(char2);
            }
            if (enc4 != 64) {
                    decodedMessage = decodedMessage + String.fromCharCode(char3);
            }
        } while (i < encodedString.length);
        return decodedMessage;
      }
    // -->
    </script>
    </head>
    
    
    <body>
    
    <!-- bk beszuras kovetkezik -->
    <?php
      $myServer = 'https://' . $_SERVER['HTTP_HOST'];
      $SessionInitiator = $myServer . "/Shibboleth.sso/WAYF/HREF";
      $myUrl = (isset($_SERVER['HTTPS']) ? 'https' : 'http') . '://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
      // $myUrl: ahova vissza kell majd juttatnia a Shibboleth-nek
    
      if (!$_SERVER['HTTP_SHIB_IDENTITY_PROVIDER'])
      // igy dontjuk el, hogy van-e session
      {
            echo "<p><b><a href=\"$SessionInitiator?target=$myUrl\">Kattints ide a Shibboleth-es belepeshez</a></b></p>";
      }
      else
      {
            $LogoutUrl = $myServer . "/Shibboleth.sso/Logout";
            echo "<p><b>Van Shib session, oh yeah. </b></p>";
            echo "<p><a href=\"$LogoutUrl?return=$myUrl\">Kattints ide</a>, ha <i>errol az SP-rol</i> ki akarsz jelentkezni</p>";
      }
      echo "<hr>";
    ?>
    <!-- bk beszuras vege -->
    
    <b>-all SHIB headers-</b> (<code>HTTP_SHIB_ATTRIBUTES</code> is not shown in this list)
    <?php
    echo '<table>';
    foreach ($_SERVER as $key => $value)
    {
            $fkey='_'.$key;
            if ( strpos($fkey,'SHIB')>1 && $key!="HTTP_SHIB_ATTRIBUTES")
    #       if ( strpos($fkey,'SHIB')>1 )
            {
                    echo '<tr>';
                    echo '<td>'.$key.'</td><td>'.$value.'</td>';
                    echo '</tr>';
            }
    }
    echo '<tr><td>(REMOTE_USER)</td><td>'.$_SERVER['REMOTE_USER'].'</td></tr>';
    echo '<tr><td>(HTTP_REMOTE_USER)</td><td>'.$_SERVER['HTTP_REMOTE_USER'].'</td></tr>';
    echo '<tr><td>HTTP_SHIB_LOGOUTURL</td><td>'.$_SERVER['HTTP_SHIB_LOGOUTURL']
    .'<a href="/Shibboleth.sso/Logout?return='.$_SERVER['HTTP_SHIB_LOGOUTURL']
    .'%3Freturn%3Dhttps%3A%2F%2Fshib.kuleuven.be%2Flogout.shtml">[logout]</a> </td></tr>';
    echo '</table>';
    ?>
    <br/>
    
    attribute response from the IdP (<code>HTTP_SHIB_ATTRIBUTES</code>):<br/>
    <textarea id="attributeResponseArea" onclick="select()" rows="1" cols="130">
    <?php echo $_SERVER["HTTP_SHIB_ATTRIBUTES"]; ?></textarea><br/>
    <span id="decodeButtonBlock"><input type="button" id="decodeButton"
    value="decode base64 encoded attribute response using JavaScript"
    onClick="decodeAttributeResponse();"><br/></span>
    
    <br/>
    
    <small>
    notes:<br/>
    The AAP throws away invalid values (eg an unscopedAffiliation of value "myBoss@&lt;yourdomain&gt;"
    or a value with an invalid scope which scope is checked)<br/>
    The raw attribute response (<code>HTTP_SHIB_ATTRIBUTES</code>) is NOT filtered by the AAP and should
    therefore be disabled for most applications (<code>exportAssertion=false</code>).<br/>
    </small>
    
    <br/>
    <hr/>
    <br/>
    
    
    <b>$_REQUEST</b>
    <?php
    echo '<table>';
    foreach ($_REQUEST as $key => $value)
    {
            echo '<tr>';
            echo '<td>'.$key.'</td><td>'.$value.'</td>';
            echo '</tr>';
    
    }
    echo '</table>';
    ?>
    
    
    
    <br/>
    <hr/>
    <br/>
    
    <b>$_SERVER</b>
    <?php
    echo '<table>';
    foreach ($_SERVER as $key => $value)
    {
            echo '<tr>';
            echo '<td>'.$key.'</td><td>'.$value.'</td>';
            echo '</tr>';
    
    }
    echo '</table>';
    ?>
    
    <br/>
    <hr/>
    <br/>
    
    <b>$_SESSION</b>
    <?php
    echo '<table>';
    foreach ($_SESSION as $key => $value)
    {
            echo '<tr>';
            echo '<td>'.$key.'</td><td>'.$value.'</td>';
            echo '</tr>';
    
    }
    echo '</table>';
    ?>
    
    <br/>
    <hr/>
    <br/>
    
    </body>
    </html>
    

    GoogleAuth

    Alapok

    A wikiben részletezett többi megoldáshoz képest ez a fejezet kilóg a sorból, hiszen ez a megoldás "a federáción" belül csak egy Identity Providert használ - a google központi kapuját. Ezt bárki használhatja a saját szolgáltatásában (SP) történő felhasználó-hitelesítésére, természetesen annyi megszorítás van, hogy az adott felhasználóknak rendelkezniük kell Google Accounttal (gmail-es e-mail címmel).

    A google ekkor 2.0-ás szabványú OpenID protokoll szerint működő OpenID IdP-ként viselkedik, emellett támogatja az OpenID Attribute Exchange 1.0 alapú attribútum kiadást, így ha a felhasználó az autentikáció során hozzájárul a felsorolt adatainak az SP részére történő kiadásához, akkor azt a google ki is adja. (A kiadható attribútumok köre korántsem teljes, lévén jelenleg egyedül az e-mail cím kiadatására van lehetősége az SP-nek)

    Beállítás

    Az autentikációhoz használt google-végpont a

    https://www.google.com/accounts/o8/id

    címen érhető el, a megfelelő paramétereket ide kell átadni.

    Rendelkezésre álló paraméterek

    openid.ns Kötelező - a használandó OpenID protokollt definiálja, ajánlott érték: "http://specs.openid.net/auth/2.0"
    openid.claimed_id Opcionális - a kérelem típusát azonosítja, ajánlott érték: "http://specs.openid.net/auth/2.0/identifier_select"
    openid.identity Opcionális, egy alternatív azonosítót definiál, ajánlott érték: "http://specs.openid.net/auth/2.0/identifier_select"
    openid.return_to Kötelező - azt az oldalt definiálja, amelyre a google visszairányít az autentikáció után. Támogatott http és https protokollú visszatérő oldal egyaránt.
    openid.realm Opcionális - azt a domaint definiálja, amelyre a felhasználót a google-el autentikáltatni szeretnénk. Alapértelmezés szerint az openid.return_to-nál megadott honlapra mutat. Amennyiben megadásra kerül, akkor a domainnek mindenképp egyeznie kell az openid.return_to domainnevével.
    openid.assoc_handle Opcionális - részletes ismetető: http://openid.net/specs/openid-authentication-2_0.html#associations
    openid.mode Kötelező - a kérés módját adja meg, a két lehetséges érték: "checkid_immediate" (szinkron kommunikáció) "checkid_setup" (aszinkron kommunkikáció)
    openid.ns.ext1 Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "http://openid.net/srv/ax/1.0"
    openid.ext1.mode Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "fetch_request"
    openid.ext1.type.email Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "http://axschema.org/contact/email"
    openid.ext1.required Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "email" (Jelenleg csak az email attribútum elérhető)

    Minta kérés

    Az alábbi kérés igényli az email-cím attribútum kiadását is

    https://www.google.com/accounts/o8/ud
    ?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
    &openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select
    &openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select
    &openid.return_to=http%3A%2F%2Fwww.example.com%2Fcheckauth
    &openid.realm=http%3A%2F%2Fwww.example.com%2F
    &openid.assoc_handle=ABSmpf6DNMw
    &openid.mode=checkid_setup
    &openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0
    &openid.ext1.mode=fetch_request
    &openid.ext1.type.email=http%3A%2F%2Faxschema.org%2Fcontact%2Femail
    &openid.ext1.required=email
    

    Minta válasz sikeres autentikáció esetén

    http://www.example.com:8080/checkauth
    ?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
    &openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fud
    &openid.response_nonce=2008-09-18T04%3A14%3A41Zt6shNlcz-MBdaw
    &openid.return_to=http%3A%2F%2Fwww.example.com%3A8080%2Fcheckauth
    &openid.assoc_handle=ABSmpf6DNMw
    &openid.signed=op_endpoint%2Cclaimed_id%2Cidentity%2Creturn_to%2Cresponse_nonce%2Cassoc_handle%2Cext1.mode%2Cext1.type.email%2Cext1.value.email
    &openid.sig=s%2FgfiWSVLBQcmkjvsKvbIShczH2NOisjzBLZOsfizkI%3D
    &openid.identity=https%3A%2F %2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%3DACyQatixLeLODscWvwqsCXWQ2sa3RRaBhaKTkcsvUElI6tNHIQ1_egX_wt1x3fAY983DpW4UQV_U
    &openid.claimed_id=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%3DACyQatixLeLODscWvwqsCXWQ2sa3RRaBhaKTkcsvUElI6tNHIQ1_egX_wt1x3fAY983DpW4UQV_U
    &openid.ns.ext1=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0
    &openid.ext1.mode=fetch_response
    &openid.ext1.type.email=http%3A%2F%2Faxschema.org%2Fcontact%2Femail
    &openid.ext1.value.email=fred.example%40gmail.com
    

    Minta választ sikertelen autentikáció esetén

    http://www.example.com/checkauth
    ?openid.mode=cancel
    &openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
    

    Válaszok feldolgozása

    A megfelelő kérés elküldése után a rendszer átirányít a google autentikációs oldalára, ahol a felhasználónak meg kell adnia google accounttal kapcsolatos adatait, majd sikeres bejelentkezés után jóvá kell hagynia, hogy a SP részére a google átadja az információt, hogy bejelentkezett ill. az egyéb attribútumokat, melyeket adott esetben az SP igényelt. Pozitív válasz esetén a google beállítva a megfelelő értékeket meghívja a visszatérő oldalt, ahol a megfelelő GET paraméterek feldolgozásával már SP-hatáskörben irányíthatók tovább a felhasználók.

    Külső hivatkozások

    Pont-pont_bizalmi_kapcsolati_modell

    Két intézmény egymással közvetlenül köt megállapodást az identitás-információk átadásáról. Ez lehet egy föderáción belüli megállapodás kiterjesztése, ill. teljesen új megállapodás. Mindkét intézmény működhet identitás szolgáltatóként és tartalomszolgáltatóként is.

    A pont-pont modell hátránya az adminisztrációs többletteher, mivel az együttműködő intézménnyel közvetlenül kell megállapodni. Leggyakrabban akkor használják, ha egy projektben szükség van 1-2 partnerrel külön megállapodást kötni (ekkor a partnereknek nem kell a föderációban részt venniük).

    Eszközök

    Log4whatever

    A Shibboleth korábban a log4cpp library 0.35-ös változatát használta, azonban ebben számos threading és egyéb hiba volt, ami miatt a shibd instabil lett. A Shibboleth fejlesztője kijavította a forrást, azonban az eredeti szoftverbe ez nem került vissza (valószínűleg átmenetileg szünetelt a fejlesztése).

    Később a log4cpp fejlesztése újrakezdődött, majd komolyabb változtatások után kijött az 1.0-ás verzió. Ez részben javította a Shibboleth fejlesztő által jelzett hibákat, azonban változott az API. A kezdeti instabilitások miatt Scott Cantor kiadta a 0.35-ös log4cpp forkjaként létrejött log4shib csomagot. Ez teljesen megegyezik a 0.35-össel, csak a Shibboleth használatához feltétlen szükséges hibajavításokat tartalmazza. A fejlesztő nem is tervezi a csomag további fejlesztését, álláspontja szerint a csomagra csak az Internet2 fejlesztésekben van szükség.

    A helyzet jelenleg (2008.04.28.) a következő:

    SLODemo

    !!! warning

    For more complete description please go and see [how Single Logout is implemented](https://help.edu.hu/books/aai/page/single-logout-in-shibboleth-idp) in Shibboleth IdP.
    

    To demonstrate the features we have prepared a demo application. The main purpose of the demo is to test the UI and various error conditions.

    Preparing

    !!! info

    This version is **still unreleased**.
    
    You can grab a snapshot from the web-basedGit repository by selecting the latest commit and clicking on the `snapshot` link
    

    Authentication

    There are 100 demo users from demo1..100, all users have the password 'demo'.

    !!! info

    It was necessary to use more than one demo account because IdP sessions mix if two testers (browsers) share the same userid.
    
    So if you face strange results (like trying to log out from SP's you were not logged in), please first try it with another demoXX account to sort out possible IdP session mixing problem.
    

    The IdP uses the UsernamePassword Login Handler. IdP logout is not possible with container-based authentication (like HTTP / X.509 / Kerberos).

    Service Providers

    SP1: (Not-so) Old Release

    SP software Shibboleth 2.2.1 (Debian backports)
    Front channel logout supported
    Back channel logout supported
    Notes This was a 2.1 SP which used to report partial logout on backchannel. Now it's working OK.

    SP2: Bright Shining Star

    SP software Shibboleth 2.2.1 (Debian SID)
    Front channel logout supported
    Back channel logout supported
    Notes Both front- and back-channel logout should work properly

    SP3: The Pretender

    SP software SimpleSAMLphp SAML2 SP
    Front channel logout supported
    Back channel logout not supported
    Notes SimpleSAMLphp does not support back-channel bindings, therefore the metadata does not contain it

    SP4: Use The Backdoor, Please!

    SP software Shibboleth 2.2.1 (Debian SID)
    Front channel logout not supported
    Back channel logout supported
    Notes The metadata of this SP does not contain front-channel bindings for logout

    SP5: Old Slowhand

    SP software Shibboleth 2.2.1 (Debian backports)
    Front channel logout not working (times out)
    Back channel logout not working (times out)
    Notes Metadata points to a fake logout service that is not answering in time. Actually this is a PHP script that returns a 500 Internal Server Error after 20 seconds of delay, similarly to an overloaded webserver. Actually there is a big difference: usually an overloaded server can not complete TCP connection establishment in time. This test only delays the sending of responses

    SP6: Shibboleth Neanderthalensis

    SP software Shib 1.3 (IRL: Shibboleth 2.2.1 Debian backports)
    Front channel logout not supported
    Back channel logout not supported
    Notes The metadata of this SP does not contain any logout services, just like a normal Shib1.3 SP

    SP7: Good Guy Speaking Ancient Greek

    SP software Shibboleth 2.2.1 (Debian SID)
    Front channel logout supported
    Back channel logout supported
    Notes This is a 2.x SP but it uses Shibboleth 1.3 SSO protocol. I'd expected a logout failure because of the Shibboleth-specific NameID format, however it turned out to be working.

    SP8: Blitzkrieg

    SP software Shibboleth 2.2.1 (Debian SID)
    Front channel logout not working (if timed out)
    Back channel logout not working (if timed out)
    Notes This is a special SP that has a very short session lifetime (30 sec). If you hit the logout button within 30 sec, it should work but it should fail afterwards, because the principal is no longer known to the SP.

    SP9: Knight Without Armour

    SP software Shibboleth 2.2.1 (Debian SID)
    Front channel logout supported
    Back channel logout supported
    Notes This SP only supports HTTP for both SSO and SLO. Presumably, it would not work if the SSO was using HTTPS (not checked).

    How this demo works

    The SLO Demo runs in a separate machine from all the SPs and IdP. So it has no information if the login is succeeded or not, it just hopes, everything goes as expected.

    Below is a very brief description of the logout demo.

    Selecting SPs

    At first the user selects the SPs he/she wants to log in. The order of the login is currently sequential (not sure if it makes any difference).

    Redirecting to SPs

    1. all SP sessions are initiated by using 302 Redirects to the SPs SessionInitiator by specifying only the IdP entityID (https://sandbox.slotest.aai.niif.hu/idp/shibboleth).
      • the simpleSAMLphp login URL is somewhat similar but not the same
    2. the SP initiates the session (the first one gets the user logged into the IdP)
    3. the SP redirects to the homeURL
    4. homeURL redirects back to the redirection point of the demo interface (by some trivial PHP script)
    5. the demo interface starts over with the next SP or displays summary page

    Summary page

    The (supposedly) logged in SPs are displayed along with their logout urls. Logout opens up in a new window.

    Logging out

    User clicks on one of the logout URLs.

    Start over

    On page refresh you can start it over. If you are not asked for password by the IdP, it means that your IdP session was not cleared properly, therefore the logout is failed.

    How to get your SP involved

    1. Configure the SP as you wish
      • Don't forget to set signing="true" or signing="false", as described in the SLO documentation
    2. Configure the target application (or the page which is served on homeURL) to redirect to [https://www.aai.niif.hu/SLODemo/sloDemoLoginRedirect.php](https://www.aai.niif.hu/SLODemo/sloDemoLoginRedirect.php).
    3. Send SP details to aai at niif dot hu
      • Metadata
      • SessionInitiator URL
      • Optionally:
      • Front-channel logout initiator (if there's any)
      • Back-channel logout initiator (if there's any)
      • SP software & version
      • Session handler (attribute viewer) URL
      • Short description of what to test
      • A funny name, of course ;)
    4. Configure your SP to trust slotest metadata (this will contain your SP metadata as well).
    5. Please inform us when your test SP is no longer functioning

    Setting up a back-channel only LogoutInitiator

    See this Jira entry for background. If you have a pre-2.2.1 SP, you should use:

    <LogoutInitiator type="Chaining" Location="/BackChannelLogout" relayState="cookie">
      <LogoutInitiator type="SAML2" outgoingBindings=" " />
      <LogoutInitiator type="Local"/>
    </LogoutInitiator>
    

    Expected results

    SAML2

    Single Logout profile is for SAML2 only. Therefore SP6 (Neanderthalensis) will always fail. Note that SP7 (Ancient Greek) actually speaks SAML2 although it initiates SSO with Shibboleth protocol. Therefore you cannot initiate SLO from SP7 but you can participate in SLO.

    SP5 (Old Slowhand) will always fail unless the Logout request is initiated by it.

    Front-channel, back-channel

    The IdP can fallback to back-channel, if the logout is front-channel and the SP software does support only back-channel bindings. Not the other way, because front-channel bindings need the information held in browser cookies. Therefore front-channel SLO will work with SP4 (Backdoor) if initiated by some other SP's, but SP4 can only initiate back-channel SLO (which is not supported by many of the SP's above.)

    Unexpected results

    TODO

    Support NoScript

    !!! warning "TODO"

    NoScript support has been added recently to front-channel logout, thorough testing is still necessary.
    
    The user interface is a bit clumsy, because the daisy-chain of redirects is a no-go and some browser not even support frames. Ideas, tips are welcome for making it better.
    
    The main rationale behind supporting noscript is to make it even possible to use logout with other clients than web browsers. Bach-channel is much more convenient for them, though.
    

    Test with Application Notification

    !!! warning "TODO"

    Contribution is welcome!
    

    Try it with various browsers

    !!! warning "TODO"

    Contribution is welcome!
    

    Misc

    Shibboleth2_IdP

    Telepítési leírások

    Konfigurációs leírások

    Kiegészítő programok konfigurációs leírásai

    Shibboleth fejlesztések(angolul) / Shibboleth IdP development (in English)

    MDX

    Az MDX, azaz MetaDataeXchange protokolt erőforrás optimalizálás céljából találták ki, hogy ne kelljen egyes IdP-knek és SP-knek indokolatlanul nagy XML fájlokat feldolgozniuk és tárolniuk, mikor a felhasználóiknak jó eséllyel a fájlokban tárolt entitások töredékére van csak szükségük. Ezért az egyes entitásokat be lehet úgy állítani, hogy csak akkor töltsék le az adott entitás metaadatát, mikor arra szükség van (az első letöltés után természetesen helyben tároldóik a metaadat a cacheDuration-ben megadott ideig). Az MDX kiszolgáló az alábbi szabvány szerint tudja visszaadni egy-egy entitás metaadatát: https://mdx.eduid.hu/entities/{urlencoded}$entityID, pl: https://mdx.eduid.hu/entities/https%3A%2F%2Fdev.aai.niif.hu%2Fshibboleth

    Dinamikus metadata kiszolgálás a HREF-ben

    Az MDX kiszolgáló a https://mdx.eduid.hu alatt szolgáltat, és a href és az edugain metadata halmazokat tartalmazza.

    Mindkét kiszolgáló ugyanazzal a kulccsal írja alá a lekért metaadat-állományt.

    Fontos tudnivaló Discovery Service használattal kapcsolatban

    Lévén az MDX-et használó SP-knél nem áll rendelkezésre folyamatosan az összes potenciális IdP listája, így a beépített Discovery Service-ek nem működnek. Ha MDX-et használunk, akkor valamilyen külső Discvery Service-t kell használnunk. A HREF-ben a https://discovery.eduid.hu a központi Discovery Service.

    Emellett maga az MDX kiszolgáló is biztosít Discovery Service felületet, ehhez akár Shibboleth SP-nél, akár simpleSAMLphp SP-nél a konfigurációban az alábbi URL-t kell megadni, mint Discovery Service: https://mdx.eduid.hu/role/idp.ds . Ez a Discovery Service tartalmazza a hazai eduID-ben, valamint az eduGAIN-ben levő összes IdP-t. (És, ellentétben a hagyományos https://discovery.eduid.hu/edugain szolgáltatással, ez tartlamazza a magyar VHO-t is VHO IdP néven.)

    MDX használata kliens oldalon

    SimpleSAMLphp

    Az 1.14-es kiadástól kezdve a SimpleSAMLphp tartalmazza az dinamikus metadata lekérdezés funkciót, amely mind IdP, mind SP szerepben egységes módon használható. A config/config.php állományban metadata.sources szekcióban kell elhelyezni az alábbi blokkot:

    'metadata.sources' => array(
         array('type' => 'flatfile'), // ez a *-hosted metadata konfiguráció betöltése miatt szükséges
         array(
             'type' => 'mdx',
             'server' => 'https://mdx.eduid.hu',
             'cachedir' => '/var/simplesamlphp/mdx-cache', //opcionális, de ajánlott
             'cachelength' => 86400, //opcionális,
             'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61' //opcionális
          ),
    ),
    

    A dinamikus és a statikus metadataforrások egyidejű használatára egy példa: SimpleSAMLMixedMetadata

    Shibboleth SP

    <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

    <MetadataProvider
         xmlns="urn:mace:shibboleth:2.0:metadata"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd"
         id="dynamicMDQ" xsi:type="DynamicHTTPMetadataProvider">
    
    
         <!--
           Require a validUntil XML attribute on the EntityDescriptor element
           and make sure its value is no more than 14 days into the future
         -->
         <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P14D" />
    
    
          <!-- Verify the signature on the metadata file -->
         <MetadataFilter xsi:type="SignatureValidation" requireSignedMetadata="true"
             certificateFile="${idp.home}/credentials/href-metadata-signer-2020.crt" />
    
         <!-- The MetadataQueryProtocol element specifies the base URL for the query protocol. -->
         <MetadataQueryProtocol>https://mdx.eduid.hu/</MetadataQueryProtocol>
    </MetadataProvider>
    

    Alkalmazások_samlizálást_segítő_teszt_IdP_simplesamlPHP_segítségével

    1. Telepítünk egy SSP egyedet valamelyik szerverünkre.

    2. Engedélyezzük a userpass auth forrás modult.

       touch modules/exampleauth/enable
      
    3. Elrendezzük a metadatákat.

    4. Az authsources.php file-t valahogy így alakítjuk ki:

    <?php
    
    $config = array(
    
           // This is a authentication source which handles admin authentication.
           'admin' => array(
                   // The default is to use core:AdminPassword, but it can be replaced with
                   // any authentication source.
    
                   'core:AdminPassword',
           ),
    
           'multi' => array(
               'multiauth:MultiAuth',
    
               /*
                * The available authentication sources.
                * They must be defined in this authsources.php file.
                */
               'sources' => array('projekt1', 'projekt2'),
           ),
           'projekt1' => array(
                   'exampleauth:UserPass',
                   'tesztuser1:tesztuser1' => array(
                           'eduPersonPrincipalName' => array('tesztuser1@example.com'),
                           'uid' => array('tesztuser1'),
                           'cn' => "Nemecsek Ernő",
                           'sn' => "Nemecsek",
                           'givenName' => "Ernő",
                           'mail' => "devnull@example.com",
                           'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
                           'schacDateOfBirth' => "19751221",
                           'schacPlaceOfBirth' => "Budapest",
                           'niifPersonMothersName' => "Törőcsik Mari",
                           'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
                   ),
                   'tesztuser2:tesztuser2' => array(
                           'eduPersonPrincipalName' => array('tesztuser2@example.com'),
                           'uid' => array('tesztuser2'),
                           'cn' => "Nemecsek Ernő 2",
                           'sn' => "Nemecsek",
                           'givenName' => "Ernő",
                           'mail' => "devnull@example.com",
                           'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
                           'schacDateOfBirth' => "19751221",
                           'schacPlaceOfBirth' => "Budapest",
                           'niifPersonMothersName' => "Törőcsik Mari",
                           'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
                   ),
           ),
          'projekt2' => array(
                   'exampleauth:UserPass',
                   'tesztuser1:tesztuser1' => array(
                           'eduPersonPrincipalName' => array('tesztuser1@example.com'),
                           'uid' => array('tesztuser1'),
                           'cn' => "Nemecsek Ernő",
                           'sn' => "Nemecsek",
                           'givenName' => "Ernő",
                           'mail' => "devnull@example.com",
                           'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
                           'schacDateOfBirth' => "19751221",
                           'schacPlaceOfBirth' => "Budapest",
                           'niifPersonMothersName' => "Törőcsik Mari",
                           'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
                   ),
                   'tesztuser2:tesztuser2' => array(
                           'eduPersonPrincipalName' => array('tesztuser2@example.com'),
                           'uid' => array('tesztuser2'),
                           'cn' => "Nemecsek Ernő 2",
                           'sn' => "Nemecsek",
                           'givenName' => "Ernő",
                           'mail' => "devnull@example.com",
                           'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
                           'schacDateOfBirth' => "19751221",
                           'schacPlaceOfBirth' => "Budapest",
                           'niifPersonMothersName' => "Törőcsik Mari",
                           'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
                   ),
           ),
    );
    

    Shibenv-JSP

    Eredeti forrás: http://shib.kuleuven.be/download/sp/test_scripts/shibenv.jsp.txt

    <html>
    <head>
      <title>Shibboleth Attributes - <% out.println( request.getHeader("host") ); %></title>
      <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
      <META HTTP-EQUIV="Expires" CONTENT="-1">
    <script language="JavaScript" type="text/JavaScript">
    <!--
      function decodeAttributeResponse() {
            var textarea = document.getElementById("attributeResponseArea");
            var base64str = textarea.value;
            var decodedMessage = decode64(base64str);
            textarea.value = tidyXml(decodedMessage);
            textarea.rows = 15;
            document.getElementById("decodeButtonBlock").style.display='none';
      }
    
      function tidyXml(xmlMessage) {
            //put newline before closing tags of values inside xml blocks
            xmlMessage = xmlMessage.replace(/([^>])</g,"$1\n<");
            //put newline after every tag
            xmlMessage = xmlMessage.replace(/>/g,">\n");
            var xmlMessageArray = xmlMessage.split("\n");
            xmlMessage="";
            var nestedLevel=0;
            for (var n=0; n < xmlMessageArray.length; n++) {
                    if ( xmlMessageArray[n].search(/<\//) > -1 ) {
                            nestedLevel--;
                    }
                    for (i=0; i<nestedLevel; i++) {
                            xmlMessage+="  ";
                    }
                    xmlMessage+=xmlMessageArray[n]+"\n";
                    if ( xmlMessageArray[n].search(/\/>/) > -1 ) {
                            //level status the same
                    }
                    else if ( ( xmlMessageArray[< 0 ) && (xmlMessageArray[n](n].search(/<\//)).search(/</) > -1) ) {
                            //only increment if this was a tag, not if it is a value
                            nestedLevel++;
                    }
            }
            return xmlMessage;
      }
    
      var base64Key = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
      function decode64(encodedString) {
        var decodedMessage = "";
        var char1, char2, char3;
        var enc1, enc2, enc3, enc4;
        var i = 0;
    
        //remove all characters that are not A-Z, a-z, 0-9, +, /, or =
        encodedString = encodedString.replace(/[^A-Za-z0-9\+\/\=]/g, "");
        do {
            enc1 = base64Key.indexOf(encodedString.charAt(i++));
            enc2 = base64Key.indexOf(encodedString.charAt(i++));
            enc3 = base64Key.indexOf(encodedString.charAt(i++));
            enc4 = base64Key.indexOf(encodedString.charAt(i++));
    
            char1 = (enc1 << 2) | (enc2 >> 4);
            char2 = ((enc2 & 15) << 4) | (enc3 >> 2);
            char3 = ((enc3 & 3) << 6) | enc4;
    
            decodedMessage = decodedMessage + String.fromCharCode(char1);
            if (enc3 != 64) {
                    decodedMessage = decodedMessage + String.fromCharCode(char2);
            }
            if (enc4 != 64) {
                    decodedMessage = decodedMessage + String.fromCharCode(char3);
            }
        } while (i < encodedString.length);
        return decodedMessage;
      }
    // -->
    </script>
    </head>
    
    
    <body>
    
    
    <u><b>-all SHIB headers-</b></u> (`HTTP_SHIB_ATTRIBUTES` and `Shib-Attributes` are not shown in this list)<br/>
    <table>
    <%
    java.util.Enumeration eHeaders = request.getHeaderNames();
    while(eHeaders.hasMoreElements()) {
         String name = (String) eHeaders.nextElement();
         if (  ( name.matches(".*Shib.*") || name.matches(".*shib.*")  ) && !name.equals("HTTP_SHIB_ATTRIBUTES") && !name.equals("Shib-Attributes")) {
                 Object object = request.getHeader(name);
                 String value = object.toString();
                 out.println("<tr><td>" + name + "</td><td>" + value+"</td></tr>");
         }
    }
    %>
    </table>
    
    <br/>
    
    attribute response from the IdP (`Shib-Attributes` or `HTTP_SHIB_ATTRIBUTES`):<br/>
    <textarea id="attributeResponseArea" onclick="select()" rows="1" cols="130"><%
            String attributesString=null;
            if ( request.getHeader("Shib-Attributes")!=null ) attributesString=request.getHeader("Shib-Attributes");
            else if ( request.getHeader("HTTP_SHIB_ATTRIBUTES")!=null ) attributesString=request.getHeader("HTTP_SHIB_ATTRIBUTES");
            out.println( attributesString );
    %></textarea><br/>
    <span id="decodeButtonBlock">
    <input type="button" id="decodeButton" value="decode base64 encoded attribute response using JavaScript"
    onClick="decodeAttributeResponse();"><br/></span>
    
    <br/>
    <hr/>
    <br/>
    
    
    <%
            out.print("request.getRemoteUser: "+request.getRemoteUser()+"<br/>");
            out.print("REMOTE_USER: "+request.getHeader("REMOTE_USER")+"<br/>" );
            out.print("HTTP_REMOTE_USER: "+request.getHeader("HTTP_REMOTE_USER")+"<br/>" );
    %>
    
    
    <br/>
    <hr/>
    <br/>
    
    
    <u>REQUEST PARAMETERS (GET/POST)</u><br/>
    <table>
    <%
    java.util.Enumeration eParameters = request.getParameterNames();
    while(eParameters.hasMoreElements()) {
         String name = (String) eParameters.nextElement();
         Object object = request.getParameter(name);
         String value = object.toString();
         out.println("<tr><td>" + name + "</td><td>" + value+"</td></tr>");
    }
    %>
    </table>
    
    
    <br/>
    <hr/>
    <br/>
    
    
    <u>ALL HEADERS</u><br/>
    <table>
    <%
    // already initiated at top of script
    // java.util.Enumeration eHeaders = request.getHeaderNames();
    // reset to beginning of Enumeration
    eHeaders = request.getHeaderNames();
    while( eHeaders.hasMoreElements() ) {
         String name = (String) eHeaders.nextElement();
         Object object = request.getHeader(name);
         String value = object.toString();
         out.println("<tr><td>" + name + "</td><td>" + value+"</td></tr>");
    }
    %>
    </table>
    
    
    
    <br/>
    <hr/>
    <br/>
    
    
    
    <u>SESSION</u><br/>
    <table>
    <%
    out.println("SESSION_ID: "+session.getId()+"<br/>");
    
    java.util.Enumeration eSession = session.getAttributeNames() ;
    while(eSession.hasMoreElements()) {
         String name = (String) eSession.nextElement();
         Object object = session.getAttribute(name);
         String value = object.toString();
         out.println("<tr><td>" + name + "</td><td>" + value+"</td></tr>");
    }
    %>
    </table>
    
    
    <br/>
    <hr/>
    <br/>
    
    
    </body>
    </html>
    

    MetadataTrust

    Ez a szócikk a Metadata bizalmi kérdéseivel foglalkozik. A föderációk üzemeltetéhez hozzátartozik a föderációs metadata állomány karbantartása is. A föderációban való bizalom technikai értelemben megegyezik a metadatába vetett bizalommal, így ezen bizalom fenntartása rendkívül fontos.

    További információkkal szolgál a Trust Management oldal a Shibboleth wikin.

    Központi metadata bizalmi modellek

    Alapvetően kétféle módon lehet biztosítani a metadata hitelességét:

    Előbbi módszer esetén a szállítási protokoll biztonsága nem szükséges (tehát a metadata nem hiteles helyről is beszerezhető - pl. http, email, ...), a digitális aláírás ellenőrzésével a hitelesség megállapítható.

    A lejárati idő - validUntil ebben az esetben kulcsfontosságú, hiszen egy lejárati idő nélküli metadatát nem lehetséges visszavonni (egy rosszindulatú támadó egy régi metadata példányt később bármikor felhasználhat), így az esetleg kompromittált entitások az egész föderáció biztonságát veszélyeztethetik.

    Utóbbi módszer használata esetén a föderációs entitások kötelesek a metadatát egy központi helyről, biztonságos csatornán (pl. https megfelelő tanúsítvány-ellenőrzéssel) adott időközönként letölteni. Ezt a frissítési időközt határozza meg a gyorstárazási idő, a cacheDuration.

    Metadata bizalom a HREF Föderációban

    A HREF Föderációban a metadata biztonságát digitális aláírás és 72 órás lejárati idő együttes alkalmazása biztosítja. A metadata óránként generálódik a Resource_Registry-ben, és aláírásra kerül a metadata aláíró kulccsal.

    Aláírás ellenőrzése az aláíró kulcs tanúsítványának segítségével

    Az aláírás ellenőrizhető a metadata aláíró kulcs tanúsítványányának segítségével, mely elérhető a https://metadata.eduid.hu/href-metadata-signer-2011.crt címről.

    Shibboleth IdP illetve SP használata esetén a metadata állomány ellenőrzésére az ún. MetadataFilter használatos, mely az aláírást ellenőrzi a tanúsítvány segítségével.

    Shibboleth 2 IdP esetén

    Metadata provider beállítása:

     <MetadataProvider id="href" xsi:type="FileBackedHTTPMetadataProvider"
      xmlns="urn:mace:shibboleth:2.0:metadata"
      metadataURL="http://rr.aai.niif.hu/metadata/href-metadata.xml"
      backingFile="/path/to/metadata/href-metadata.xml" >
      <MetadataFilter xsi:type="ChainingFilter">
       <MetadataFilter xsi:type="RequiredValidUntil"
         maxValidityInterval="604800" />
       <MetadataFilter xsi:type="SignatureValidation"
         trustEngineRef="shibboleth.MetadataTrustEngine"
         requireSignedMetadata="true" />
      </MetadataFilter>
     </MetadataProvider>
    

    Illetve a hozzá tartozó TrustEngine konfiguráció:

     <!-- Trust engine used to evaluate the signature on loaded metadata. -->
     <security:TrustEngine id="shibboleth.MetadataTrustEngine"
       xsi:type="security:StaticExplicitKeySignature">
       <security:Credential id="MyFederation1Credentials" xsi:type="security:X509Filesystem">
         <security:Certificate>/path/to/href-metadata-signer-2011.crt</security:Certificate>
       </security:Credential>
     </security:TrustEngine>
    

    Shibboleth 2 SP esetén

     <MetadataProvider type="XML"
       url="http://metadata.eduid.hu/current/href.xmll"
       backingFilePath="href.xml">
      <MetadataFilter type="RequireValidUntil" maxValidityInterval="604800"/>
      <MetadataFilter type="Signature" certificate="href-metadata-signer-2011.crt"/>
    </MetadataProvider>
    

    SimpleSAMLphp esetén

    SimpleSAMLphp használata esetén a metarefresh modul használható a metadata időzített letöltésére és ellenőrzésére. Ezzel kapcsolatban további információkat tartalmaz a SimpleSAMLphp HREF integráció fejezet.

    Az aláíró kulcs visszavonása

    A fent leírt modell egyetlen problémája az aláíró kulcs kezelésében rejlik. Az aláíró kulcs visszavonása ugyanis csak a rendszeren kívül történhet, egy új kulcs bevezetéséhez az összes partner rendszerében meg kell változtatni az ellenőrzést. Sőt, az átmeneti időben mindkét kulcs használata szükséges lehet (két különböző metadatán).

    Amennyiben az aláíró kulcs kompromittálódik, az azonnali visszavonása és egy új kulcs használata esetén azok a rendszerek, melyek még a régi tanúsítványt használták, a metadata lejárati idő letelte után működésképtelenné válnak.

    CA használata

    Ezen problémák kiküszöbölhetőek egy CA használatával. Ekkor ugyanis az aláíró kulcs tanúsítványát a CA aláírhatja, a partnerek pedig magát a CA tanúsítványt jelölhetik megbízhatónak.

    A metadata aláírásakor ebben az esetben nem elég csak az aláíró tanúsítványt beágyazni (Signature/KeyInfo/X509Certificate elembe), hanem a CA tanúsítványát is el kell helyezni az aláírt metadatába.

    Tanúsítvány visszavonása

    CA használata esetén a tanúsítvány visszavonási listák (CRL) illetve on-line ellenőrzés (OCSP) is alkalmazható az aláíró tanúsítvány érvényességének megállapítására. Ezen kívül - mivel magát a tanúsítványt nem kell külön csatornán eljuttatni a partnerekhez -, alkalmazhatóak rövidebb lejáratú (pár hónap, maximum egy év) tanúsítványok is.

    Hitelesség ellenőrzése

    A metadata aláírásának ellenőrzése ebben az esetben a beágyazott tanúsítvánnyal történik, az aláírás hitelesítése után pedig megtörténik a megfelelő, megbízhatónak jelölt CA-ra történő PKI ellenőrzés.

    Shibboleth IdP esetén

    A fenti IdP konfigurációs példában a TrustEngine konfigurációt kell megváltoztatni, hogy PKIX validációt végezzen. Fontos, hogy a CRL fájl folyamatosan frissítésre kerüljön, ugyanis a Shibboleth nem ad lehetőséget ezen fájl távoli elérésére.

    <security:TrustEngine xsi:type="security:StaticPKIXSignature"
      id="shibboleth.MetadataTrustEngine">
     <ValidationInfo xsi:type="PKIXFilesystem" xmlns="urn:mace:shibboleth:2.0:security"
       id="HREFCA" VerifyDepth="1" >
      <Certificate>/path/to/trusted/ca-cert.pem</Certificate>
      <CRL>/path/to/trusted/ca-crl.pem</CRL>
     </ValidationInfo>
    </security:TrustEngine>
    

    !!! danger "Figyelem"

    A fenti konfigurációs kódrészlet nem alkalmazható a CRL rendszeres, időzített letöltése és előzetes tesztelés nélkül!
    

    Shibboleth SP esetén

    A fenti Shibboleth SP példában a SignatureMetadataFilter-t kell módosítani az alábbiak szerint

    <SignatureMetadataFilter verifyName="false">
     <TrustEngine type="StaticPKIX">
      <CredentialResolver type="File">
       <Certificate>
        <Path>ca-cert.pem</Path>
       </Certificate>
       <CRL>
        <Path>ca-crl.pem</Path>
       </CRL>
      </CredentialResolver>
     </TrustEngine>
    </SignatureMetadataFilter>
    

    Az újabb Shibboleth SP verziókban lehetőség van a CRL URL-ről történő letöltésére is, ezzel kapcsolatban további információk.

    !!! danger "Figyelem"

    A fenti konfigurációs kódrészlet nem alkalmazható előzetes tesztelés nélkül!
    

    SimpleSAMLphp esetén

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

    Külön eszközzel

    Az NIIF által fejlesztett metadata aláíró/ellenőrző eszköz támogatja a CA tanúsítványok használatát és a PKI validációt (MDSigner forrás).

    Shib2IdpCluster

    Shibboleth 2.1 IdP klaszterezése

    Klaszter terminológia

    Node

    Klaszter

    Szerver

    Failover

    High availability

    Load balancing

    Terracotta

    A Shibboleth2 IdP a Terracotta szoftvert támogatja a klaszter építéséhez. A Terracotta képes arra, hogy a különböző nodeokon futó Shibboleth IdP-k között a session és egyéb információkat (például artifact map, authnrequest replay map, stb.) szinkronban tartsa.

    A Terracotta kliens-szerver architektúrában működik. A kliensek a JVM-ben futó instrumentált osztályokból, osztálybetöltőből és zármenedzserből állnak, a szerverek pedig biztosítják a klaszterezett adatok perzisztens tárolását és a csomópont-független elérést. Amennyiben egy JVM-ben szükség van egy távoli JVM-ben létrehozott klaszterezett objektumra, akkor ezt az első elérésnél a Terracotta kliens elkéri a távoli szervertől. Emiatt teljesítmény okokból érdemes az azonos felhasználóhoz tartozó kéréseket mindig ugyanahhoz a csomóponthoz küldeni. A HTTP-Artifact profil használata esetén ez nem garantálható, ezért ajánlott a HTTP-Post profil használata.

    Shibboleth IdP és Terracotta

    A Shibboleth IdP-ben a következő adatok klaszterezését kell megvalósítani: artifact, session, replay, transientId, loginContext. Ezeket az adatokat a Shibboleth StorageService tárolja.

    A Terracotta telepítéséhez és beállításához ez a wikioldal nyújt segítséget.

    1. Terracotta letöltése, kicsomagolása
    2. tűzfalbeállítások (TCP/9510 kliens->szerver és TCP/9530 szerver->szerver portok engedélyezése)
    3. minden csomóponton azonos JVM verziót használjunk a Terracotta szerverben és kliensben is
    4. tim-vector integrációs modul telepítése
    5. Shibboleth IdP-hez Terracotta konfiguráció szerkesztése [[Shib2IdpTerracottaConfiguration]] alapján
      • csomópontok definiálása (szervernév, hosztnév, logok helye)
    6. terracotta szerver futtatása
    7. boot jar készítése (Terracotta kliens)
    8. boot jar használata a webkonténer JVM-nél
    9. FONTOS: JVM frissítés után újra kell generálni a boot jart!

    JVM beállítások:

     JAVA_OPTS="-Dtc.install-root=$TC_INSTALL_DIR \
               -Dtc.config=$SHIB_IDP_HOME/conf/tc-config.xml \
               -Xbootclasspath/p:$TC_INSTALL_DIR/lib/dso-boot/dso-boot-hotspot_$jvm_spec_ver.jar"
    

    2.1.2 -es IdP verzióhoz a következő konfigurációs rész is szükséges az instrumented-classes szekcióba:

     <include>
       <class-expression>org.opensaml.xml.util.LazyList</class-expression>
       <honor-transient>true</honor-transient>
     </include>
    

    A Terracotta log- és adatfájljainak /var alatti tárolását a következőképpen végezhetjük el:

    Könyvtárak létrehozása megfelelő jogosultságokkal

    mkdir /var/{lib,log}/terracotta/{client,server}
    chown tomcat55.nogroup /var/{lib,log}/terracotta/client
    chown nobody.nogroup /var/{lib,log}/terracotta/server
    

    Terracotta tc-config.xml -ben a data,stats,logs opciók átírása értelem szerint.

    Magas rendelkezésre állás beálítása

    A következő konfigurációs részt a tc-config.xml elején kell elhelyezni. Ez engedélyezi a kliens-szerver és szerver-szerver újrakapcsolódást, ezzel kivédve az apró hálózati kimaradások okozta problémákat. Sajnos mindkét beállítás megnöveli a failover idejét.

     <tc-properties>
      <!-- server-to-server reconnect -->
      <property name="l2.nha.tcgroupcomm.reconnect.enabled" value="true" />
      <property name="l2.nha.tcgroupcomm.reconnect.timeout" value="15000" />
      <!-- client-to-server reconnect -->
      <property name="l2.l1reconnect.enabled" value="true" />
      <property name="l2.l1reconnect.timeout.millis" value="15000" />
     </tc-properties>
    

    Debian initszkript a Terracotta szerver indításához

    #!/bin/sh
    TC_USER=nobody
    TC_GROUP=nogroup
    PIDFILE=/var/run/terracotta.pid
    
    if [`id -u` -ne 0 ](); then
            echo "You need root privileges to run this script"
            exit 1
    fi
    
    if [-f /etc/default/terracotta ](); then
        . /etc/default/terracotta
    fi
    
    if [-z "$TC_INSTALL_DIR" -o ! -d "$TC_INSTALL_DIR" ](); then
        echo "No TC_INSTALL_DIR specified or invalid TC_INSTALL_DIR"
        exit 1
    fi
    if [-z "$TC_CONFIG_PATH" -o ! -f "$TC_CONFIG_PATH" ](); then
        echo "No TC_CONFIG_PATH specified or invalid TC_CONFIG_PATH"
        exit 1
    fi
    if [-z "$NODENAME" ](); then
        echo "No NODENAME specified"
        exit 1
    fi
    
    export JAVA_HOME
    
    JAVA_OPTS="-server -Xms512m -Xmx512m -XX:+HeapDumpOnOutOfMemoryError $JAVA_OPTS"
    TC_START_OPTS="$JAVA_OPTS \
       -Dcom.sun.management.jmxremote \
       -Dtc.install-root=$TC_INSTALL_DIR \
       -cp $TC_INSTALL_DIR/lib/tc.jar \
       com.tc.server.TCServerMain -n $NODENAME -f $TC_CONFIG_PATH"
    TC_STOP_OPTS="-Dtc.install-root=$TC_INSTALL_DIR \
      -cp $TC_INSTALL_DIR/lib/tc.jar \
      com.tc.admin.TCStop -n $NODENAME"
    
    . /lib/lsb/init-functions
    . /etc/default/rcS
    
    check_stopped () {
        return `/sbin/start-stop-daemon --test --start --pidfile "$PIDFILE" \
            --user $TC_USER --startas "$JAVA_HOME/bin/java" \
            >/dev/null`
    }
    start () {
        log_daemon_msg "Starting Terracotta server node ($NODENAME)..."
    
        if check_stopped; then
    
            /sbin/start-stop-daemon -S -v --make-pid --pidfile "$PIDFILE" \
                --chuid $TC_USER:$TC_GROUP --background \
                --exec $JAVA_HOME/bin/java -- $TC_START_OPTS
    
        else
            log_progress_msg "(already running)"
        fi
        log_end_msg 0
    }
    stop () {
        log_daemon_msg "Stopping Terracotta server node ($NODENAME)..."
        if $JAVA_HOME/bin/java $TC_STOP_OPTS; then
            log_progress_msg "(shutdown command sent)"
        else
            log_progress_msg "(could not send shutdown command)"
        fi
        sleep 5
        if check_stopped; then
            log_progress_msg "(cleaning persistent store)"
            rm -r /var/lib/terracotta/server/*
            log_end_msg 0
        else
            log_progress_msg "(stopping in progress)"
        fi
    }
    force_stop () {
        log_daemon_msg "Killing Terracotta server node ($NODENAME)..."
        /sbin/start-stop-daemon -K --pidfile $PIDFILE -x $JAVA_HOME/bin/java
    }
    
    case "$1" in
      start)
          start
          ;;
      stop)
          stop
          ;;
      force-stop)
          force_stop
          ;;
      restart)
          stop
          sleep 10
          start
          ;;
      *)
        echo "Usage terracotta start|stop|force-stop|restart"
        exit 1;;
    esac
    
    exit $?
    
    NODENAME=terracotta-node-name
    TC_CONFIG_PATH=/path/to/shibboleth-idp/conf/tc-config.xml
    JAVA_HOME=/path/to/jvm
    TC_INSTALL_DIR=/path/to/terracotta
    

    Monitoring (JMX, Munin, Nagios)

    Fontosabb Terracotta MBean attribútumok

    Server

    * Active (bool)
    * PassiveStandby (bool)
    * PassiveUninitialized (bool)
    * HealthStatus (String)
    * State (string)
    * StartTime (timestamp)
    * Shutdownable (bool)
    

    Nagios Terracotta szerver check

    #!/bin/sh
    
    TERRACOTTA_SERVER_NODES="papigw.aai.niif.hu sandbox.aai.niif.hu"
    TERRACOTTA_CLIENT_COUNT=2
    TERRACOTTA_SERVER_COUNT=2
    JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
    TC_HOME=/usr/local/terracotta-2.7.2
    TC_MONITORING=/home/hege/terracotta/terracotta-monitoring/terracotta_monitoring.jar
    
    ACTIVE_NODES=""
    STANDBY_NODES=""
    CLUSTER_STATUS=""
    
    function check_health() {
        TC_HEALTH=`echo "$1" | awk "/$2.health/{print "'$2}'`
        if [ "x$TC_HEALTH" = "xOK" ]; then
            return 0
        else
            echo TERRACOTTA CRITICAL - node $2 down
            exit 2
        fi
    }
    function check_active_count() {
        ACTIVE_NODES=`echo "$1" | awk '/ACTIVE-COORDINATOR/{print $1}' | sed 's/\.state://'
        ACTIVE_COUNT=`echo "$1" | awk 'BEGIN {cnt=0} /ACTIVE-COORDINATOR/{cnt++} END {print cnt}'`
        CLUSTER_STATUS="$CLUSTER_STATUS, active nodes: $ACTIVE_NODES"
    
        if [ "0$ACTIVE_COUNT" -eq 1 ]; then
            return 0
        else if [ "0$ACTIVE_COUNT" -gt 1 ]; then
                echo TERRACOTTA CRITICAL - multiple ACTIVE nodes $CLUSTER_STATUS
            else
                echo TERRACOTTA_CRITICAL - no ACTIVE nodes $CLUSTER_STATUS
            fi
            exit 2
        fi
    }
    
    function check_standby_count() {
        STANDBY_NODES=`echo "$1" | awk '/PASSIVE-STANDBY/{print $1}' | sed 's/\.state://'`
        STANDBY_COUNT=`echo "$1" | awk 'BEGIN {cnt=0} /PASSIVE-STANDBY/{cnt++} END {print cnt}'`
        CLUSTER_STATUS="$CLUSTER_STATUS, standby nodes: $STANDBY_NODES"
    
        if [ "0$STANDBY_COUNT" -eq $(($TERRACOTTA_SERVER_COUNT-1)) ]; then
            return 0
        else
            echo TERRACOTTA CRITICAL - not enough STANDBY node $CLUSTER_STATUS
            exit 2
        fi
    }
    
    function check_client_count() {
        CLIENTCOUNT=`echo "$1" | awk '/clientcount/{print $2}'`
        CLIENT_NODES=`echo "$1" | awk '/client.*address/{print $2}'`
        CLUSTER_STATUS="$CLUSTER_STATUS, client nodes: $CLIENT_NODES"
        if [ "0$CLIENTCOUNT" -eq $TERRACOTTA_CLIENT_COUNT ]; then
            return 0
        else
            echo TERRACOTTA WARNING - client count is $CLIENTCOUNT $CLUSTER_STATUS
            exit 1
        fi
    }
    
    OUTPUT=`$JAVA_HOME/bin/java -jar $TC_MONITORING $TERRACOTTA_SERVER_NODES 2>/dev/null`
    
    check_active_count "$OUTPUT"
    for i in $TERRACOTTA_SERVER_NODES; do
        check_health "$OUTPUT" "$i"
    done
    check_standby_count "$OUTPUT"
    check_client_count "$OUTPUT"
    
    echo TERRACOTTA OK - cluster is running $CLUSTER_STATUS
    
    if [ "0$1" == "0--verbose" -o "0$1" == "0-v" ]; then
            echo -e "\n\n$OUTPUT"
    fi
    

    Munin plugin a terracotta szerver memóriahasználatának méréséhez

    A check_jmx csomagban található jmx_ munin plugin mellé másoljuk oda a jmxremote_optional csomagot (sun.com-ról letölthető), majd végezzük el a következő módosítást:

    JMXQUERY="java -cp $RDIR/jmxquery.jar:$RDIR/jmxremote_optional-1.0.1_04-b58.jar \
     org.munin.JMXQuery $SERVICE $RDIR/$CONFIGNAME"
    

    Ezután a következő konfigurációt hozzuk létre terracotta_objectcount.conf néven:

    graph_title Terracotta clustered object count
    graph_category Terracotta
    graph_order terracotta_objectcount
    
    terracotta_objectcount.label cluster object count
    terracotta_objectcount.jmxObjectName org.terracotta:type=Terracotta Server,name=DSO
    terracotta_objectcount.jmxAttributeName LiveObjectCount
    

    Majd symlinkeljük be a jmx_ szkriptet a munin pluginok közé jmx_terracotta_objectcount néven, és adjuk meg a munin-node.conf -ban a jmx hozzáférési paramétereket:

    [jmx_*]
    env.jmxurl service:jmx:jmxmp://localhost:9520
    

    Tomcat monitorozása muninnal

    A Tomcat JVM JMX elérésének engedélyezéséhez az /etc/default/tomcat5.5 fájlban a következő plusz kapcsolókat kell megadni:

    CATALINA_OPTS="${CATALINA_OPTS} \
     -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=8083 \
     -Dcom.sun.management.jmxremote.ssl=false \
     -Dcom.sun.management.jmxremote.authenticate=false"
    

    Ezután a 8083 -as porton jmxrmi protokollon keresztül lehet elérni a menedzsment ágenst. A check_jmx pluginhoz a következő környezeti beállítást kell hozzárendelni az /etc/munin/plugin-conf.d/munin-node fájlban:

    [jmx_catalina_*]
    env.jmxurl service:jmx:rmi:///jndi/rmi://localhost:8083/jmxrmi
    

    Terracotta 2.7.3 ismert hibák

    Log file flood

    Az L2 újracsatlakozás engedélyezése esetén egy elvesztett kapcsolat után hiába áll helyre a helyes működés, a szerver szemetel a logba:

    2009-06-24 14:48:38,304 [ConnectionEstablisher] WARN com.tc.net.protocol.transport.ClientMessageTransport -
    ConnectionID(0.0e84473d1e744f4db1d539db88633a30): Timeout of 10000 milliseconds occured
    2009-06-24 14:48:39,305 [ConnectionEstablisher] INFO com.tc.net.protocol.transport.ClientMessageTransport -
    ConnectionID(0.0e84473d1e744f4db1d539db88633a30): Attaching new connection: [...]
    

    Ez egy ismert probléma: http://jira.terracotta.org/jira/browse/CDV-1252 a javítás elkészült, azonban a 2.7.3 -ba még nem került be.

    Workaround-ként ki lehet kapcsolni az l2 újracsatlakozást a konfigurációban. Ilyenkor azonban rövid hálózati megszakadás is teljes node újraindítást fog okozni.

    Terracotta 3.2.1 ismert hibák

    Még nincs :)

    Troubleshooting

    Kliens library

    Szerver processz

    Nagios riasztások és megoldásuk

    Adminisztrációs feladatok

    JVM frissítése

    A következő leírás meglehetősen az NIIF Intézet saját infrastruktúrájára specifikus, de talán más környezetekben is felhasználható.

    Lépések összefoglalása

    1. Terheléselosztóból a frissítendő node-ot kivenni
    2. Tomcat, Terracotta leállítása a frissítendő node-on
    3. JVM beállítások (/etc/java-6-openjdk/security, ill. esetleg /usr/lib/jvm/java-6-openjdk/jre/lib/security) elmentése. Ez fontos azért, mert bizonyos JVM upgrade-ek (legalábbis a múltban) felülírták a tanúsítvány tárat, és ez nehezen javítható hibához vezetett (pl. az LDAP-hoz nem tudott kapcsolódni az IdP)
    4. JVM frissítés
    5. Boot jar generálás
    6. (Ha megváltozott a jar): Tomcat konfigban a boot jar átírása az újra
    7. Ellenőrzés, hogy megváltozott-e a cacerts ($JAVA_HOME/lib/security/cacerts). Ha igen, akkor írjuk felül az elmentett változattal
    8. Terracotta, majd utána Tomcat indítás
    9. (Az LVS magától visszateszi a megjavuló klaszter node-ot, de erről nem árt meggyőződni)

    Shell parancsok

    ldir2:~# ipvsadm -d -t idp.niif.hu:8443 -r idp1.aai.niif.hu:8443
    ldir2:~# ipvsadm -d -t idp.niif.hu:https -r idp1.aai.niif.hu:https
    ldir2:~# watch "ipvsadm -L -t idp.niif.hu:https  && ipvsadm -L -t idp.niif.hu:8443"
    
    idp1:~$ sudo /etc/init.d/tomcat6 stop
    idp1:~$ sudo /etc/init.d/terracotta stop
    idp1:~$ tar czf security.tgz /etc/java-6-openjdk/security
    idp1:~$ sudo aptitude safe-upgrade
    
    idp1:~$ sudo env JAVA_HOME=/usr/lib/jvm/java-6-openjdk /usr/local/terracotta/platform/bin/make-boot-jar.sh \
    -f /etc/shibboleth-idp/tc-config.xml
    idp1:~$ sudo vim /etc/default/tomcat6
    
    idp1:~$ sudo /etc/init.d/terracotta start
    idp1:~$ sudo /etc/init.d/tomcat6 start
    

    Shib2IdpTerracottaConfiguration

    Shibboleth 2 Terracotta konfiguráció

    Shibboleth 2.1.2 IdP -hez

    <?xml version="1.0" encoding="UTF-8"?>
    
    <tc:tc-config xmlns:tc="http://www.terracotta.org/config"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.terracotta.org/config http://www.terracotta.org/schema/terracotta-4.xsd">
    
        <!--
            Terracotta configuration file for Shibboleth.
    
            Complete documentation on the contents of this file may be found here:
            http://terracotta.org/web/display/docs/Configuration+Guide+and+Reference
        -->
    
        <tc-properties>
            <!-- server-to-server reconnect -->
            <property name="l2.nha.tcgroupcomm.reconnect.enabled" value="true" />
            <property name="l2.nha.tcgroupcomm.reconnect.timeout" value="15000" />
    
            <!-- client-to-server reconnect -->
            <property name="l2.l1reconnect.enabled" value="true"/>
            <property name="l2.l1reconnect.timeout.millis" value="15000" />
        </tc-properties>
    
        <servers>
            <!-- START Terracotta server definitions -->
                <server name="idp1" host="idp1.aai.niif.hu">
                        <dso>
                                <persistence>
                                        <mode>permanent-store</mode>
                                </persistence>
                        </dso>
    
                        <logs>/var/log/terracotta/server/logs</logs>
                        <data>/var/lib/terracotta/server/data</data>
                        <statistics>/var/lib/terracotta/server/stats</statistics>
                </server>
    
                <server name="idp2" host="idp2.aai.niif.hu">
                        <dso>
                                <persistence>
                                        <mode>permanent-store</mode>
                                </persistence>
                        </dso>
    
                        <logs>/var/log/terracotta/server/logs</logs>
                        <data>/var/lib/terracotta/server/data</data>
                        <statistics>/var/lib/terracotta/server/stats</statistics>
                </server>
    
            <!-- END Terracotta server definitions -->
    
            <ha>
                <mode>networked-active-passive</mode>
                <networked-active-passive>
                    <election-time></election-time>
                </networked-active-passive>
            </ha>
        </servers>
    
        <system>
            <configuration-model>production</configuration-model>
        </system>
    
        <clients>
            <logs>/var/log/terracotta/client/logs-%i</logs>
            <statistics>/var/lib/terracotta/client/stats-%i</statistics>
            <modules>
                <module name="tim-vector" version="2.3.1" group-id="org.terracotta.modules"/>
            </modules>
        </clients>
        <application>
            <dso>
                <additional-boot-jar-classes>
                    <include>javax.security.auth.Subject</include>
                    <include>javax.security.auth.Subject$SecureSet</include>
                    <include>javax.security.auth.x500.X500Principal</include>
                    <include>javax.security.auth.kerberos.KerberosPrincipal</include>
                </additional-boot-jar-classes>
                <roots>
                    <root>
                        <root-name>storageService</root-name>
                        <field-name>edu.internet2.middleware.shibboleth.common.util.EventingMapBasedStorageService.store</field-name>
                    </root>
                </roots>
                <instrumented-classes>
                    <include>
                        <class-expression>edu.vt.middleware.ldap.jaas.LdapPrincipal</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.authn.UsernamePrincipal</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.vt.middleware.ldap.jaas.LdapCredential</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.authn.AuthenticationException</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>org.opensaml.util.storage.AbstractExpiringObject</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.TransientIdEntry</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.authn.LoginContextEntry</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.authn.LoginContext</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.authn.ShibbolethSSOLoginContext</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.authn.Saml2LoginContext</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.session.impl.AuthenticationMethodInformationImpl</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>org.opensaml.util.storage.ReplayCacheEntry</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.session.impl.SessionManagerEntry</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.common.session.impl.AbstractSession</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.session.impl.SessionImpl</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>edu.internet2.middleware.shibboleth.idp.session.impl.ServiceInformationImpl</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                        <class-expression>org.opensaml.common.binding.artifact.BasicSAMLArtifactMapEntry</class-expression>
                        <honor-transient>true</honor-transient>
                    </include>
                    <include>
                       <class-expression>org.opensaml.xml.util.LazyList</class-expression>
                       <honor-transient>true</honor-transient>
                   </include>
                </instrumented-classes>
                <locks>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.vt.middleware.ldap.jaas.LdapPrincipal.*(..)</method-expression>
                        <lock-level>write</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.authn.LoginContext.set*(..)</method-expression>
                        <lock-level>write</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.authn.LoginContext.get*(..)</method-expression>
                        <lock-level>read</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.authn.ShibbolethSSOLoginContext.set*(..)</method-expression>
                        <lock-level>write</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.authn.ShibbolethSSOLoginContext.get*(..)</method-expression>
                        <lock-level>read</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.authn.Saml2LoginContext.set*(..)</method-expression>
                        <lock-level>write</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.authn.Saml2LoginContext.get*(..)</method-expression>
                        <lock-level>read</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.common.session.impl.AbstractSession.set*(..)</method-expression>
                        <lock-level>write</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.common.session.impl.AbstractSession.get*(..)</method-expression>
                        <lock-level>read</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.SessionImpl.set*(..)</method-expression>
                        <lock-level>write</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.SessionImpl.get*(..)</method-expression>
                        <lock-level>read</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.AuthenticationMethodInformationImpl.set*(..)</method-expression>
                        <lock-level>write</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.AuthenticationMethodInformationImpl.get*(..)</method-expression>
                        <lock-level>read</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.ServiceInformationImpl.set*(..)</method-expression>
                        <lock-level>write</lock-level>
                    </autolock>
                    <autolock auto-synchronized="false">
                        <method-expression>* edu.internet2.middleware.shibboleth.idp.session.impl.ServiceInformationImpl.get*(..)</method-expression>
                        <lock-level>read</lock-level>
                    </autolock>
                </locks>
            </dso>
        </application>
    </tc:tc-config>
    

    Shib2IdpARP

    Az attribútumok kiadását az IDP_HOME/conf könyvtárban található attribute-filter.xml névre hallgató fájlban konfigurálhatjuk.

    Attribute-filter alapbeállítások

    Ezeket általában nem kell állítgatni, megfelelőek az alapbeállítások

    <AttributeFilterPolicyGroup id="ShibbolethFilterPolicy" xmlns="urn:mace:shibboleth:2.0:afp"
        xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic" xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:afp classpath:/schema/shibboleth-2.0-afp.xsd
                            urn:mace:shibboleth:2.0:afp:mf:basic classpath:/schema/shibboleth-2.0-afp-mf-basic.xsd
                            urn:mace:shibboleth:2.0:afp:mf:saml classpath:/schema/shibboleth-2.0-afp-mf-saml.xsd">
    
       <!-- ... -->
    
    </AttributeFilterPolicyGroup>
    

    Kiadási szabálycsoportok megadása

    Egy kiadási szabálycsoportot a <AttributeFilterPolicy> elemmel definiálhatunk, melynek kötelező aleleme egy <PolicyRequirementRule xsi:type="MATCHING_RULE_TYPE"> elem, amely meghatározza, hogy a szabály mely attribútumok esetén aktivizálódjon. A működése kifejezetten egyszerű, a kiadási szabály akkor lesz aktív, mikor a PolicyRequirementRule elem attribútumában meghatározott egyezési feltétel igaz értéket ad.

    Egy kiadási szabálycsoport (attribute filters) meghatározhatja egy sor attribútum számára, hogy mikor, milyen feltételek teljesülése mellett adhatók ki értékeik.

    Egy kiadási szabály megadása

    Egy attribútumra vonatkozó szabályt a <AttributeRule> elemmel határozunk meg, melynek kötelező attrubútuma annak az attribútumnak az azonosítója, melyre a szabályokat vonatkoztatni szeretnénk, és egy elem, amely meghatározza, hogy milyen illeszkedés esetében aktív a szabály.

    Példa I.

    <AttributeRule attributeID="transientId">
        <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
    
    

    Egy attribútumra vonatkozó szabályban természetesen további finomításokat megadhatunk.

    Példa II.

        <AttributeRule attributeID="eduPersonAffiliation">
            <PermitValueRule xsi:type="basic:OR">
                <Rule xsi:type="basic:AttributeValueString" value="faculty" ignoreCase="true"/>
                <Rule xsi:type="basic:AttributeValueString" value="student" ignoreCase="true"/>
                <Rule xsi:type="basic:AttributeValueString" value="staff" ignoreCase="true"/>
                <Rule xsi:type="basic:AttributeValueString" value="alum" ignoreCase="true"/>
                <Rule xsi:type="basic:AttributeValueString" value="member" ignoreCase="true"/>
                <Rule xsi:type="basic:AttributeValueString" value="affiliate" ignoreCase="true"/>
                <Rule xsi:type="basic:AttributeValueString" value="employee" ignoreCase="true"/>
                <Rule xsi:type="basic:AttributeValueString" value="library-walk-in" ignoreCase="true"/>
            </PermitValueRule>
        </AttributeRule>
    
    

    Magyarázat: a kiadási szabály, akkor adja ki az eduPersonAffiliation attribútumot, amennyiben annak értéke egyezik a felsoroltak valamelyikével (OR szabály - tehát elég, hogy egyikkel egyezzen).

    Az alábbi listában található egyezési szabályok alkalmazhatók egy-egy <PermitValueRule> megadásakor:

    ShibIdpSLO

    1. ÁTIRÁNYÍTÁS Single Logout in Shibboleth IdP

    FedDev

    Föderáció létrehozásával kapcsolatos lap.

    EduPersonAffiliation

    img

    A kép az eduPersonAffiliation értékeinek egy lehetséges ábrázolása. A pontos meghatározás az intézmények feladata, erre a föderációnak nincsenek szigorúbb megkötései

    Attribute_Conversion_for_simpleSAMLphp

    This page describes the features of Attribute Conversion and Filtering library for simpleSAMLphp

    Introduction

    eduGAIN uses Bridging Elements for interconnecting federations. To provide attribute translation and filtering services, an attribute 'mangling' library was developed for the Java-based bridging elements. As simpleSAMLphp can also be used as an eduGAIN bridging element, the conversion and filtering library was ported to PHP.

    Beyond eduGAIN, you can use this module for every IdP or SP operating mode (shib13 SP/IdP, saml2 SP/IdP) of simpleSAMLphp in order to provide more powerful attribute conversion and filtering capabilities.

    Download and support

    You can download the module from here. The module is in beta stage, it needs broader community review. It is not yet recommended for production environments.

    If you have any questions regarding the module, please write to 'aai aT niif _dOt hu.

    For changelogs please visit the project repository.

    Compatibility

    eduGAIN

    This library is intended to be configuration-compatible with the eduGAIN Attribute_Conversion_for_eduGAIN Java library. The module can read the eduGAIN converter and filter engine XML configuration files and should operate the same way as the Java one.

    Configuration files

    The eduGAIN attribute converter and filter module defines its own XML schema for attribute conversion and attribute filtering purposes. See the Attribute_Conversion_for_eduGAIN page for more information on attribute rules.

    Using the module

    This module has a working name edugain. As this module only addresses the attribute translation part of the 'eduGAIN-problem', it might be renamed later.

    Enabling the simpleSAMLphp module

    This module depends on the xsl php extensions (more specifically, the XSLTProcessor class), so make sure it is properly configured.

    The module can be enabled by creating an empty file named modules/edugain/default-enable.

    simpleSAMLphp module configuration

    EduGAIN is available for simpleSAMLphp as an authentication processing filter: edugain:Attributes. The Attributes processing filter takes the following configuration properties:

     'authproc' => array(
       50 => array(
        'class' => 'edugain:Attributes',
        'mode' => 'idp',
        'converterconfig' => '/path/to/AttributeConverter.xml',
        'filterconfig' => '/path/to/AttributeFilter.xml',
        'cache' => true
       )
     )
    

    Configuration parameters for the module

    !!! info

    If either `converterconfig` or `filterconfig` is omitted, than the relevant part of the module (conversion or filtering respectively) is disabled. Note that **disabling filter means you let all the attributes through**.
    

    Operating modes

    EduGAIN module can operate in two modes, idp or sp. This mode affects two behaviors: the conversion-filtering order, and the provider matching.

    Configuration file

    The simpleSAMLphp eduGAIN module reads the eduGAIN XML configuration format and transforms it into php arrays using XSL transformation. The submodules (edugain:SplitMerge and edugain:Filter) are configured automatically by the edugain:Attributes class.

    PHP configuration interface for these filters are not supported at the moment and may be subject to change, so please use the XML configuration.

    Configuration cache

    The XML reading is very time-consuming but conversion and filtering rules should be evaluated on every request. Because of that, the eduGAIN module can cache the XML configuration into a serialized PHP array, which is stored locally in a directory named cache. If the XML file is not updated since the last cache file generation then the cache is used and the XML parsing part is skipped. Cache file name is computed according to the following:

    md5(full_configuration_file_path).cache.php
    

    !!! info

    Enabling the cache is strongly recommended in production environments.
    

    Differences between the Java and the PHP implementations

    HREF_alapelvek_és_alapvető_szabályok

    Föderációs alapelvek

    1. A föderáció célja, hogy a felhasználók úgy vehessenek igénybe szolgáltatásokat - amennyiben erre jogosultak -, hogy a saját intézményük azonosítja őket.
    2. Az IdP csak abban az esetben azonosít egy felhasználót, ha az illető valamilyen - ismert - viszonyban van az intézménnyel.
    3. Az IdP és az SP nem ad meg magáról hamis, félrevezető információt.
    4. Az IdP minden tőle telhetőt megtesz annak érdekében, hogy a kiadott információ a lehető legpontosabb legyen. Az SP tisztában van vele, hogy bizonyos információkat a felhasználók maguk is szerkeszthetnek.
    5. Az IdP gondoskodik róla, hogy a felhasználót azonosító információk (pl. jelszó) védett módon legyenek tárolva, ill. a felhasználók ezt biztonságosan adhassák meg.
    6. Az SP csak a működéséhez minimálisan szükséges adatmennyiséget (attribútumokat) igényli a felhasználóról.
    7. Az SP nem kérheti a felhasználót, hogy adja meg az IdP-nél érvényes jelszavát.
    8. Az SP-nél történő adatkezelés a törvényi előírások szerint működik.
    9. Felhasználói visszaélések vizsgálatában az IdP és az SP együttműködik egymással.
    10. Az IdP és az SP az informatikai rendszereit az elvárható gondossággal üzemelteti.

    Szabályok

    Adatvédelmi szabályok

    1. A Tag és a Partner biztosítja, hogy a HREF Föderáció működése során közöttük a személyes adatok kezelése a vonatkozó jogszabályoknak megfelelő módon történik. Így a személyes adatok kezelése csak törvényi felhatalmazáson vagy felhasználói önkéntes, határozott és tájékozott hozzájárulásán alapul, amellyel beleegyezését fejezi ki az őt érintő személyes adatok kezelésébe.
    2. Mind a Tag, mind a Partner rendelkezik a személyes adatok kezelését megfelelően rendező adatkezelési szabályzattal, amely rendelkezik különösen:
      • a kezelt személyes adatok köréről;
      • az adatkezelés céljáról;
      • az adatkezelés időtartamáról;
      • az adatalanyokat érintő tiltakozási jog lehetőségéről.
    3. Mind a Tag, mind a Partner a mindenkor hatályos adatkezelési szabályzatukat elérhetővé teszik.

    Üzemeltetési szabályok

    1. Az üzemeltetéssel kapcsolatos szabályokat, valamint a megkövetelt és ajánlott eljárásokat külön dokumentumok részletezik: en_US IdP üzemeltetési szabályok, SP üzemeltetési szabályok
    2. A Föderációs Operátor jogosult ellenőrizni a vonatkozó szabályok betartását.
    3. A Tag és a Partner gondoskodik arról, hogy a metaadatok kezelése a metadata specifikációnak megfelelően történjen, így:
      • a Tag a Resource Registry használatával gondoskodik arról, hogy az őt érintő föderációs metaadatok naprakészek legyenek,
      • a metaadatokat a specifikációnak megfelelő gyakorisággal frissítik és ellenőrzik.
    4. A felhasználói attribútumok átadása során az IdP és a SP az attribútum specifikáció előírásait betartják.

    Adatkezeléssel kapcsolatos szabályok

    1. Az Azonosító Szervezet biztosítja, hogy a felhasználó regisztrációs folyamatai dokumentáltak legyenek.
    2. Csak olyan felhasználó azonosítható, akinek az intézményhez való viszonya egyértelműen megállapítható.
    3. Adatminőség
      • A személyes adat tárolási módjának alkalmasnak kell lennie arra, hogy az érintett felhasználót csak a tárolás céljához szükséges ideig lehessen azonosítani.
      • Az adatminőség biztosítása érdekében az IdP AAI Kapu számára hozzáférhetővé tett felhasználói adatokat célszerű autoritatív adatbázisban rögzített adatok alapján létrehozni, így a rendszeres frissítéssel azok időszerűsége, pontossága nem vitatott.
      • Amennyiben az IdP AAI Kapu adatbázisa nem autoritatív adatbázis alapján működik, a Tagnak meg kell tennie a szükséges lépéseket az adatminőség biztosítása érdekében.
    4. Az Azonosító Szervezet törekszik arra, hogy a HREF Föderáció szolgáltatásai minden jogosult felhasználója számára elérhetővé váljon.
    5. Az Azonosító Szervezet biztosítja, hogy az IdP AAI Kapu az attribútum specifikációban megkövetelt attribútumokat megvalósítsa.

    Tagsággal kapcsolatos szabályok

    A HREF Föderáció infrastruktúrájának üzemeltetője az országos kutatói hálózatot működtető Föderációs Operátor. A HREF Föderáció további résztvevői egy már megkötött csatlakozási szerződés alapján a Tagok és a Partnerek.

    1. A föderáció Tagjai az alábbi intézmények lehetnek:
      • felsőoktatási intézmények;
      • akadémiai intézmények, kutatással foglalkozó intézmények;
      • oktatással foglalkozó intézmények;
      • közgyűjtemények.
    2. A föderáció Partnere tetszőleges szervezet lehet
    3. A föderáció Tagjai és Partnerei jogosultak a föderációban szolgáltatásokat üzemeltetni
    4. A Partner a Tagok Tanácsa ülésein megfigyelőként részt vehet, azonban szavazati joggal nem rendelkezik.
    5. Csak Tagok jogosultak:
      • felhasználói adatokat szolgáltatni;
      • a Tagok Tanácsába szavazati joggal rendelkező képviselőt küldeni.

    Shib2SPConfig

    Az Shibboleth 2 SP-t a shibboleth.xml állományon keresztül konfigurálhatjuk. Ebben a leírásban feltételezzük, hogy az SP konfigurációja a /etc/shibboleth könyvtárban van.

    Alapszerkezet

    Mindenekelőtt megmutatjuk a shibboleth.xml fájl alapszerkezetét, majd alább az egyes szerkezeti elemeket részletesen is tárgyaljuk, majd a fejezet végén egy teljes, működő konfigurációt mutatunk be.

    <SPConfig xmlns="urn:mace:shibboleth:sp:config:2.0"
    	xmlns:conf="urn:mace:shibboleth:sp:config:2.0"
    	xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    	logger="shibboleth/syslog.logger" clockSkew="180">
    
        <Extensions/>
    
        <OutOfProcess logger="shibboleth/shibd.logger"/>
    
        <InProcess logger="shibboleth/native.logger"/>
    
        <Listener/>
    
        <StorageService/>
        <SessionCache/>
        <ReplayCache/>
        <ArtifactMap/>
    
        <RequestMapper/>
    
        <ApplicationDefaults id="default" policyId="default"
            entityID="https://sp.example.org/shibboleth"
            homeURL="https://sp.example.org/index.html"/>
    
        <SecurityPolicies/>
    
    </SPConfig>
    

    Látható, hogy a szerkezet keretét egy <SPConfig> elem adja, ez fogja közre a különböző összetevők részletes konfigurációit. Az <SPConfig> opcionális attribútumai

    Összetevők

    <Extensions>

    <OutOfProcess>

    <InProcess>

    <Listener>

    <StorageService>

    <SessionCache>

    <ReplayCache>

    <ArtifactMap>

    <RequestMapper>

    A RequestMap megadja azokat a címeket (Host és Path), amelyeket a Shibboleth SP kezelni fog. Szerkezete:

    <RequestMap applicationId="default">
        <Host name="www.example.org">
            <Path name="secure" authType="shibboleth" requireSession="true"/>
        </Host>
        <Host name="admin.example.org" applicationId="admin" authType="shibboleth" requireSession="true">
            <AccessControl>
                <Rule require="affiliation">faculty@osu.edu student@osu.edu</Rule>
            </AccessControl>
        </Host>
    </RequestMap>
    

    A RequestMap több Host elemet is tartalmazhat, a Host elem 0 vagy több Path elemet tartalmazhat.

    !!! danger "Figyelem"

    Ha 1-nél nagyobb mélységű könyvtárat (pl. a `/shibtest/shibreq` nevűt) szeretnénk védeni, akkor **nem** adhatjuk meg a *name* paraméterben a "shibtest/shibreq" értéket, hanem egymásba ágyazott Path elemeket kell használni. A *name* paraméter nem tartalmazhat '/' karaktert.
    

    Az egyes elemeknél paraméterekkel szabályozhatjuk, hogy az SP milyen módon kezelje a hostot vagy az útvonalat. A paraméterek felüldefiniálhatók. A legfontosabb paraméterek az alábbiak (ezek ugyanúgy használhatók Host-nál mint Path-nál):

    <ApplicationDefaults>

    IsPassive

    Az isPassive SAML2-ben bevezetett lehetőség, mellyel azt szabhatjuk meg, hogy az azonosításnak úgy kell megtörténnie, hogy közben semmiféle látható felhasználói interakciónak nem szabad történnie. Ha az azonosítás így nem hajtható végre, akkor hibát kell visszaadni az SP-nek.

    Miért jó?

    Az isPassive használatával elérhetjük, hogy Lazy Session-nel védett oldalunkra a felhasználó bejelentkezése automatikusan - azaz "Bejelentkezés" gombra kattintás nélkül - megtörténjen. Ehhez három feltétel együttes teljesülése szükséges:

    Amennyiben ezen feltételek közül valamelyik nem teljesül, úgy az SP hibát fog dobni. Ezt redirectErrors attribútum segítségével átirányíthatjuk a saját alkalmazásunkra.

    Hátrányok

    Lehetséges olyan helyzet, hogy a hiba nem jut vissza az SP-hez:

    Ebben az esetben a felhasználó olyan üzenetet kap, amit valószínűleg nem tud értelmezni. Pl.:

    Ezért isPassive-ot csak abban az esetben szabad használni, ha garantálni tudjuk, hogy az IdP-k mind támogatják a passzív autentikációt!

    Működése a gyakorlatban

    Kód

    <!-- START: isPassive script-->
    <script type="text/javascript" language="javascript">
    <!--
    // Written by Lukas Haemmerle <lukas.haemmerle@switch.ch>, SWITCH
    
    // Check for session cookie that contains the initial location
    if(document.cookie && document.cookie.search(/_check_is_passive=/) >= 0){
    	// If we have the opensaml::FatalProfileException GET arguments
    	// redirect to initial location because isPassive failed
    	if (
    		window.location.search.search(/errorType/) >= 0
    		&& window.location.search.search(/RelayState/) >= 0
    		&& window.location.search.search(/requestURL/) >= 0
    	) {
    		var startpos = (document.cookie.indexOf('_check_is_passive=')+18);
    		var endpos = document.cookie.indexOf(';', startpos);
    		window.location = document.cookie.substring(startpos,endpos);
    	}
    } else {
    	// Mark browser as being isPassive checked
    	document.cookie = "_check_is_passive=" + window.location;
    
    	// Redirect to Shibboleth handler
    	window.location = "/Shibboleth.sso/DS?isPassive=true&target=" + encodeURIComponent(window.location);
    }
    
    </script>
    <!-- END: isPassive script-->
    

    AttributePushPull

    Egy IdP és egy SP között az attribútumok átadása push és pull modell szerint történhet.

    Attribute Pull

    Attribute Pull esetén a folyamat az alábbi:

    1. IdP azonosítja a felhasználót (ill. feldolgozza az autentikációs kérést)
    2. IdP autentikációs igazolást állít ki és elküldi az SP-nek
    3. SP attribútum kérést (AttributeRequest) küld az IdP-nek
    4. IdP attribútum igazolást állít ki, mely a felhasználó attribútumait tartalmazza, majd ezt visszaküldi az SP-nek

    Attribute Push

    Attribute Push használata esetén az IdP által küldött első válaszba beágyazva szerepelnek az attribútumok, ezért az SP részéről nincs szükség további kérésekre, a folyamat tehát a következő módon zajlik:

    1. IdP azonosítja a felhasználót (ill. feldolgozza az autentikációs kérést)
    2. IdP autentikációs és attribútum igazolást állít ki és ezeket egyetlen válaszként elküldi az SP-nek

    Alkalmazási terület

    Shibboleth esetén Browser/POST profil használata esetén a pull modell, míg Browser/Artifact profil esetén a push modell az alapértelmezett, ám ez felülbírálható.

    Bizonyos föderációs megvalósítások (pl. a SimpleSAMLphp) csak a push modellt támogatják, mivel ennek implementációja egyszerűbb.

    !!! info

    Nagyméretű attribútumok használata esetén a válasz mérete is elég nagy lehet, ezért ez [POST]() profil esetén esetleg kényelmetlenséget (lassú működést) okozhat.
    

    Alkalmazások_illesztése

    Shib2IdPMobileLogin

    A Shibboleth autentikációs képernyője tetszőlegesen testre szabható. A fájl a war/idp.war-ban található. Módosításhoz ki kell csomagolni, módosítani a login.jsp-t majd visszacsomagolni.

    Lévén egyre többen használunk webes szolgáltatásokat mobilon keresztül, jó szolgálatot tehet, ha a Shibboleth belépő oldala is optimalizált a kis kijelzőkre és nem kell a nagy fehérségben matatnunk, hogy rámutassunk a felhasználónév mezőre...

    Az alábbi, Shibboleth 2.3-hoz készült, módosított login.jsp a jQuery mobile környezetét használja a megjelenítéshez, így a legtöbb mobilon ugyanúgy kell megjelennie. A kód természetesen tovább szabható, formálható. Fontos, hogy javascript nélkül is működik, csak nem lesz szép.

    <%@ taglib uri="urn:mace:shibboleth:2.0:idp:ui" prefix="idpui" %>
    <%
    
    String ua=request.getHeader("User-Agent").toLowerCase();
    if(ua.matches(".*(android|avantgo|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\\/|plucker|pocket|psp|symbian|treo|up\\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino).*")||ua.substring(0,4).matches("1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\\-(n|u)|c55\\/|capi|ccwa|cdm\\-|cell|chtm|cldc|cmd\\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\\-s|devi|dica|dmob|do(c|p)o|ds(12|\\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\\-|_)|g1 u|g560|gene|gf\\-5|g\\-mo|go(\\.w|od)|gr(ad|un)|haie|hcit|hd\\-(m|p|t)|hei\\-|hi(pt|ta)|hp( i|ip)|hs\\-c|ht(c(\\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\\-(20|go|ma)|i230|iac( |\\-|\\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\\/)|klon|kpt |kwc\\-|kyo(c|k)|le(no|xi)|lg( g|\\/(k|l|u)|50|54|e\\-|e\\/|\\-[a-w])|libw|lynx|m1\\-w|m3ga|m50\\/|ma(te|ui|xo)|mc(01|21|ca)|m\\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\\-2|po(ck|rt|se)|prox|psio|pt\\-g|qa\\-a|qc(07|12|21|32|60|\\-[2-7]|i\\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\\-|oo|p\\-)|sdk\\/|se(c(\\-|0|1)|47|mc|nd|ri)|sgh\\-|shar|sie(\\-|m)|sk\\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\\-|v\\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\\-|tdg\\-|tel(i|m)|tim\\-|t\\-mo|to(pl|sh)|ts(70|m\\-|m3|m5)|tx\\-9|up(\\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|xda(\\-|2|g)|yas\\-|your|zeto|zte\\-")) {
    %>
    
    <!DOCTYPE html>
    <html>
        <head>
            <meta charset="utf-8">
            <meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1">
            <title>mobil login page</title>
            <link rel="stylesheet"  href="http://code.jquery.com/mobile/1.0a4.1/jquery.mobile-1.0a4.1.min.css" />
            <script type="text/javascript" src="http://code.jquery.com/jquery-1.5.min.js"></script>
            <script type="text/javascript" src="http://code.jquery.com/mobile/1.0a4.1/jquery.mobile-1.0a4.1.min.js"></script>
            <style>
                .errMsg {text-align: center; color: red;}
            </style>
        </head>
        <body>
            <div data-role="page" data-theme="b" id="editor">
                <div data-role="header" data-position="inline">
                    <h1>NIIF IdP - mobile login</h1>
                </div>
                <div data-role="content">
    
                            <% if ("true".equals(request.getAttribute("loginFailed"))) { %>
                                <div data-role="fieldcontain">
                                    <p class="errMsg">Authentication Failed</p>
                                </div>
                            <% } %>
    
                            <% if(request.getAttribute("actionUrl") != null){ %>
                                <form action="<%=request.getAttribute("actionUrl")%>" method="post" data-ajax="false">
                            <% }else{ %>
                                <form action="j_security_check" method="post">
                            <% } %>
                                <div data-role="fieldcontain">
                                    <label for="j_username">Username:</label>
                                    <input type="text" name="j_username" id="j_username" value="" />
                                </div>
                                <div data-role="fieldcontain">
                                    <label for="j_password">Password:</label>
                                    <input type="password" name="j_password" id="j_password" value="" />
                                </div>
                                <div data-role="fieldcontain" style="text-align:center">
                                    <input type="submit" value="Login" data-role="button" data-inline="true" data-theme="b" />
                                </div>
                            </form>
                    </div>
                    </div>
            </body>
    
    </html>
    
    <%
    } else {
    
    %>
    
    <!DOCTYPE html>
    <html>
      <link rel="stylesheet" type="text/css" href="<%= request.getContextPath()%>/login.css"/>
      <head>
        <title>Shibboleth Identity Provider - Example Login Page</title>
      </head>
    
      <body id="homepage">
        <img src="<%= request.getContextPath()%>/images/logo.jpg" alt="Shibboleth Logo"/>
        <h1>Example Login Page</h1>
        <p>This login page is an example and should be customized.  Refer to the
           <a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPassLoginPage" target="_blank"> documentation</a>.
        </p>
    
        <div class="loginbox">
           <div class="leftpane">
             <div class="content">
               <p>The web site described to the right has asked you to log in and you have chosen &lt;FILL IN YOUR SITE&gt; as your home institution.</p>
               <% if ("true".equals(request.getAttribute("loginFailed"))) { %>
                  <p><font color="red"> Credentials not recognized. </font> </p>
               <% } %>
               <% if(request.getAttribute("actionUrl") != null){ %>
                 <form action="<%=request.getAttribute("actionUrl")%>" method="post">
               <% }else{ %>
                 <form action="j_security_check" method="post">
               <% } %>
               <table>
                 <tr><td width="40%"><label for="username">Username:</label></td><td><input name="j_username" type="text" /></td></tr>
                 <tr><td><label for="password">Password:</label></td><td><input name="j_password" type="password" /></td></tr>
                 <tr><td></td><td><button type="submit" value="Login" >Continue</button></td></tr>
               </table></form>
             </div>
           </div>
           <div class="rightpane">
             <div class="content">
               <div id="spName"><idpui:serviceName/></div>
               <!-- pick the logo.  If its between 64 & max width/height display it
                    If its too high but OK wide clip by height
                    If its too wide clip by width.
                    We should not clip by height and width since that skews the image.  Too high an image will just show the top.
                -->
               <idpui:serviceLogo  minWidth="64" minHeight="64" maxWidth="350" maxHeight="147" cssId="splogo">
                  <idpui:serviceLogo  minWidth="64" minHeight="64" maxWidth="350" cssId="clippedsplogoY">
                      <idpui:serviceLogo  minWidth="64" minHeight="64" cssId="clippedsplogoX"/>
                  </idpui:serviceLogo>
               </idpui:serviceLogo>
               <div id="spDescription">
                 <idpui:serviceDescription>You have asked to login to <idpui:serviceName/></idpui:serviceDescription>
               </div>
             </div>
          </div>
        </div>
      </body>
    </html>
    <% } %>
    

    Shib3IdpARP

    Shibboleth 3 IdP attribútum szűrés beállítása

    Vonatkozó állományok:

    Az {idp.home}/conf/attribute-filter.xml állomány már tartalmaz néhány egyszerű példa beállítást. Az alábbi módosítások lehetővé teszik, hogy az attribútum feloldó által feloldott sn és givenName attribútumok az SP-k számára elérhetők legyenek. Bővítsük az állományt az alábbiak szerint.

    <afp:AttributeFilterPolicyGroup id="ShibbolethFilterPolicy"
            xmlns:afp="urn:mace:shibboleth:2.0:afp"
            xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
            xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:mace:shibboleth:2.0:afp http://shibboleth.net/schema/idp/shibboleth-afp.xsd
                                urn:mace:shibboleth:2.0:afp:mf:basic http://shibboleth.net/schema/idp/shibboleth-afp-mf-basic.xsd
                                urn:mace:shibboleth:2.0:afp:mf:saml http://shibboleth.net/schema/idp/shibboleth-afp-mf-saml.xsd">
    
    <!-- ... további tartalom ... -->
    
        <!-- ezeket az attribútumokat minden SP megkapja -->
        <afp:AttributeFilterPolicy id="mindensp">
            <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
    
            <afp:AttributeRule attributeID="sn">
                <afp:PermitValueRule xsi:type="basic:ANY" />
            </afp:AttributeRule>
            <afp:AttributeRule attributeID="givenName">
                <afp:PermitValueRule xsi:type="basic:ANY" />
            </afp:AttributeRule>
        </afp:AttributeFilterPolicy>
    
        <!-- ezeket az attribútumokat csak a megadott SP kapja meg -->
        <afp:AttributeFilterPolicy id="intezmenysp1">
            <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://sp1.intezmenyneve.hu/shibboleth"/>
    
            <afp:AttributeRule attributeID="description">
                <afp:PermitValueRule xsi:type="basic:ANY"/>
            </afp:AttributeRule>
        </afp:AttributeFilterPolicy>
    
    </afp:AttributeFilterPolicyGroup>
    

    Dokumentáció:

    OpenSSO

    OpenSSO telepítése

    Az OpenSSO szerver letölthető a projekt oldaláról. Telepítéshez servlet-api támogató alkalmazásszerver szükséges. (Tomcat-et nem ajánlják a futtatásra, inkább érdemes nagyobb alkalmazásszervereken futtatni, pl. Glassfish vagy Oracle AS)

    Az alkalmazásszerver konfigurációjában a Heap size-ot 1G méretűre kell állítani (-Xmx1G), különben a telepítés hibát dob. Valamint érdemes a JVM hotspotot -server módban futtatni. (/path/to/glassfish/domains/domain/config/domain.xml)

    Glassfish V2UR1 alatt így zajlik a telepítés:

    $ /path/to/asadmin deploy --name opensso --contextroot opensso /path/to/opensso.war
    

    Ezután webes felületen történik a konfigurálás: meg kell adni az admin felhasználó nevét, jelszavát, a konfigurációs címtár paramétereit (érdemes a beágyazott címtárat használni), a felhasználókat tároló címtár paramétereit (host, port, admin bind paraméterek és DIT gyökér).

    Sikeres telepítés esetén a webes felületen állíthatjuk be ízlésünk szerint a kért szolgáltatásokat.

    Realm-ek

    Az OpenSSO egyszerre képes több szervezetet kiszolgálni, ezeknek a konfigurációját külön-külön 'realm'-ekben kezeli. Minden realmhez megadhatóak az authentikációs modulok, a felhasználói adatokat tartalmazó címtár elérésének paraméterei, egyedileg szerkeszthetők a hozzáférési szabályok, és a federációs konfiguráció is teljesen külön van minden szervezetnél.

    Hosztolt IDP beállítása

    Legegyszerűbben a nyitóoldalon elhelyezett gyorslinkekkel hozhatunk létre új IDP-t ('Create hosted Identity Provider'). Ekkor meg kell adni a realm-et, és hogy melyik Circle-of-trust részévé kívánjuk tenni az IDP-t. Ha még nem hoztunk létre COT-ot, akkor azt megtehetjük itt.

    Ezután a 'Federation' fül alatt találjuk az összes beállítási paramétert. A hosztolt IDP minden beállítását elvégezhetjük adminfelületről: aláíró és titkosító kulcsok (ezeket keystore-ból veszi, amit a keytool parancssal menedzselhetünk parancssorból), támogatott NameID formátumok, attríbutum mappelés akár saját osztállyal, és persze a támogatott SAML2 bindingok - Redirect, POST, Artifact - paraméterei.

    A beállított metaadatok XML formátumban a http://host:port/opensso/saml2/jsp/exportmetadata.jsp URL-en lesznek elérhetőek. (az exportmetadata.jsp a következő paramétereket tudja fogadni: realm, entityID)

    Amennyiben digitálisan aláírt metaadatra van szükségünk, azt az adminkonzolból tudjuk csak exportálni, illetve ezen patch segítségével az exportmetadata.jsp -ből is a signMetadata=true paraméter megadásával (https://opensso.dev.java.net/issues/show_bug.cgi?id=2680)

    Új SP hozzáadása

    Szintén a taszkok között található link új távoli SP hozzáadására ('Register remote Service Provider'). Itt a SAML2 metaadat URL-jét kell megadni, vagy feltölteni azt. Ezen kívül egy listában megadható, hogy milyen attribútum-leképzést igényel az SP. Természetesen az SP-t is hozzá kell adni egy COT-hoz.

    Miután felvettük az SP-t, néhány attribútumot a Federation fülön átállíthatunk utólag is.

    Interoperabilitás

    Problémák

    Hibás metaadat hozzáadása (vannak hibák, amiket az import parancs nem vesz észre) után a hozzáadott entity-t nem lehet törölni sem, ilyenkor a teljes federation fül működésképtelenné válik. Megoldás: újraindítás és a famadm delete-entity parancs használata. Ha ez sem megy, akkor a konfigurációs címtárból ki kell törölni az entity-t.

    Az SP metaadatának tartalmazni kell a NameID attribútumot, az IDP anélkül nem képes a federációra. Ezt a ManageNameIDService után, és az AssertionConsumerService elé kell beírni, pl. így

    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    

    HREFJoin

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

    1. A csatlakozni kívánó tag/partner jelzi csatlakozási szándékát a Föderációs Operátor felé.
    2. Mind jogilag, mind technikailag előkészül a csatlakozáshoz: Föderáció alapelvek, Műszaki előírások IdP-k számára, Műszaki előírások SP-k számára.
    3. Egyeztetés után elküldi az aláírt szerződést, ill. nyilatkozatot, és ezzel párhuzamosan elérhetővé teszi a csatlakozás előtti ellenőrzéskor átnézendő dokumentumokat. Különösen fontos, hogy megadja az azonosítható felhasználók számát és elérhetővé tegye az adatkezelési szabályzatát.
    4. A Föderációs Operátor elkészíti a Tag számára a szükséges HEXAA jogosultságokat
    5. A Föderációs Operátor elvégzi az előzetes ellenőrzést (a különálló és benyújtandó dokumentumokat és a Resource Registry-be felvitt adatokat), majd ennek eredményértől tájékoztatja a Tagok Tanácsát
    6. Tagok Tanácsa dönt a csatlakozni kívánó tag/partner kérelméről
    7. A Föderációs Operátor - pozitív TT döntés esetén - aláírva visszaküldi a szerződést, és beteszi a föderációs éles metaadatba az új entitást. Negatív válasz esetén a hiányosságok ismertetése mellett lehetőséget biztosít azok a pótlására, javítására.

    Azonosító szervezet (IdP) felvétele a föderációba

    1. A Föderációs Operátor az intézményi adminisztrátorral egyeztetve rögzíti a Resource Registry-be az IdP adatait. Egyúttal a Föderációs Operátor az IdP-t hozzáadja a föderációs tesztmetaadathoz, ezáltal az intézményi adminisztrátor, amennyiben helyesen konfigurálta az IdP-t, be fog tudni lépni a Resource Registrybe.
    2. A Tagok Tanácsa dönt az IdP felvételi kérelméről. Pozitív döntés esetén a Föderációs Operátor hozzáadja az éles föderációs metaadathoz az IdP-t.

    Intézményi (tagi) szolgáltatás (SP) felvétele a föderációba

    1. Egy intézményi adminisztrátor (akinek a HEXAA-ban megfelelő, a Resource Registryhez szükséges intézményi admin joggköre van) a Resource Registry-ben rögzíti az SP minden szükséges adatát.
    2. Az SP a föderációs metaadatba a Föderációs Operátor számára történt jelézés után kerülhet. Technikailag a Föderációs Operátor engedélyezi a föderációs metaadatba történő megjelenést.

    Külső (partner) szolgáltatás (SP) felvétele a föderációba

    1. A Föderációs Operátor a Resource Registry-ben rögzíti az SP minden szükséges adatát.
    2. A Tagok Tanácsa pozitív döntése után a Föderációs Operátor engedélyezi az új SP föderációs metaadatba történő megjelenését.
    3. Az SP-n a későbbiekben szükségessé váló módosításokat a Föderációs Operátor végzi el.

    Sirtfi

    Security Incident Response Trust Framework for Federated Identity (SIRTFI)

    A SIRTFI kezdeményezést a REFEDS (the Research and Education FEDerations group) koordinálja, célja, hogy a föderációs és különösen a föderációközi együttműködéshez kapcsolódó incidenskezelés számára kereteket szabjon, a föderációban résztvevő felek számára egy magasabb biztonsági szintet adjon azáltal, hogy a SIRTFI-nak megfelelő entitások kapcsán biztosak lehetnek az alábbiakban:

    Fontos, hogy a SIRTFI-képesség metadatában való jelzése önbevallás útján történik, tehát föderációs szinten nem kerül vizsgálatra, hogy az intézmény az állításának megfelelően ténylegesen bír-e a fenti listában jelzett kompetenciákkal. Az eduID entitások kapcsán a Resource Registry-ben állítható be a SIRTFI-képesség.

    Attribute_Specification

    Purpose of this document

    In a federation, information about the user is represented in SAML attributes transferred from the Identity Provider to the Service Provider. It is important for both parties to interpret the data in the same way.

    Exact definitions of the attributes are maintained in their defining schemas. Within this specification, we use the following schemas:

    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

    Levels of implementation

    Attribute Requirements of the SP

    SPs can indicate attribute requirements among the information provided to Resource Registry. This information also shows up in the federation metadata. From the point of view of the SP, an attribute can be:

    Attributes

    Summary

    Mandatory attributes

    eduPersonTargetedID
    eduPersonScopedAffiliation
    schacHomeOrganizationType
    mail
    eduPersonEntitlement

    Optional attributes

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

    Persistent user identifiers

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

    Persistent identifiers can be:

    Identifiers can hold the following properties:

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

    List of attributes

    In this specification, only mandatory and recommended attributes are specified. The Hungarian version of the Attribute Specification contains descriptions of the optional attributes as well. If you have any questions regarding the optional attributes, please contact the Federation Operator.

    eduPersonTargetedID

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

    eduPersonPrincipalName

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

    displayName

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

    mail

    mail
    Elnevezés URI: urn:mace:dir:attribute-def:mail OID: 0.9.2342.19200300.100.1.3
    Rövid leírás Mail address of the person
    Implementáció ajánlott
    Részletes leírás Notification email address of the person. The institution asserts that
  • either the address is provided by the institution to the person
  • 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).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>
  • <affiliation>: the following values are permitted
    • student: the person is a student at the institution
    • faculty: the person is a member of the teaching or researching staff
    • staff: the person is a member of the non-teaching staff (ie. IT personnel, etc)
    • employee: the person is employed in the institution (not recommended for use between institutions)
    • member: users who get basic set of privileges. In general, users having student, faculty or staff affiliations, should also be given this value.
    • affiliate: the user is recognised by the institution, but no basic privileges should be given.
    • alum: alumni
    • library-walk-in: affiliated to the library only
  • <scope>: local security domain. It must have a format as a DNS domain, and ends with a resolvable domain name, which is possessed by the identity provider institution.(Note: the scope as a whole may not be resolved from DNS.)\n\nSee also: http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation
  • Values One of the following: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, followed by the scope
    # of values multi
    Availability -
    Syntax Directory String
    Examples
  • Learners: student@example.org;member@example.org
  • Teachers: faculty@example.org;member@example.org
  • Notes -
    Use in federation -

    eduPersonEntitlement

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

    schacHomeOrganizationType

    schacHomeOrganizationType
    OID 1.3.6.1.4.1.25178.1.2.10
    Description Type of the Home Organisation
    Semantics
  • university: universities and colleges
  • nren: National research and educational network
  • library: Libraries
  • vho: Virtual home organisation
  • school: Primary and secondary education
  • business: Industrial or commercial companies
  • other: Other
  • 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 -

    SSP2

    Az alábbi lapon megkíséreljük összefoglalni a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő SimpleSAMLphp (SSP) alkalmazást állítsunk üzembe.

    Telepítés

    Először is nagyvonalakban leírásra kerülnek az előkészületek ezt követően pedig maga a szoftver telepítése és beállítása.

    Előkészületek

    Ahhoz, hogy problémamentesen telepíthessük SSP alkalmazásunkat, az alábbi szoftverkomponenseknek kell működniük szerverünkön.

    Composer

    A composer PHP csomagkezelőt is telepíteni kell (akár forrásból, akár csomagból), hogy telepíteni lehessen a SimpleSAMLphp futásához szükséges PHP library-ket.

    Telepítés

    Elvégezhető composerrel például a /var/ mappában:

    composer create-project simplesamlphp/simplesamlphp:2.1.3

    Mappaszerkezet módosítása:

    mv simplesamlphp simplesamlphp-prod #Tetszőleges átnevezés
    mkdir -p simplesamlphp-prod/cert
    mkdir -p /var/simplesamlphp-prod/log/stats/
    mkdir -p /var/simplesamlphp-prod/mdx-cache/
    chown -R www-data:www-data /var/simplesamlphp-prod/mdx-cache/
    chown -R www-data:www-data /var/simplesamlphp-prod/log/
    chown -R www-data:www-data /var/simplesamlphp-prod/metadata/
    

    Composerrel a szükséges modulok telepítése (például LDAP, REDIS, vagy consent):

    composer require simplesamlphp/simplesamlphp-module-ldap:v2.3.2
    composer require predis/predis:2.2.2
    composer require simplesamlphp/simplesamlphp-module-consent:1.3.2
    

    Ezzel a telepítés, és a szükséges kiegészítők telepítése megtörtént.

    Apache konfigurálás

    A webről csak a /var/simplesamlphp-prod/public könyvtárat kell elérni. Tilos a teljes simplesamlphp könyvtárat a DocumentRoot alá tenni!

    Alias /simplesaml /var/simplesamlphp-prod/public
    <Directory /var/simplesamlphp-prod/public>
      Require all granted
    </Directory>
    

    Simplesamlphp Alapbeállítások

    Konfigurációs fájlok

    Amennyiben korábbi verziókat használtunk,

    jó megközelítés lehet diff segítségével ellenőrizni a különbségeket a korábbi config.php fileunk és a config.php.dist között.

    Ha ilyennel nem rendelkezünk akkor lehet rögtön alapul venni a config.php.dist-et és hasonlóképp a metadata-templates mappát.

    Konfigurációs fájlok szerkesztése

    Baseurlpath beállítása

    'baseurlpath' => 'https://your.canonical.host.name/simplesaml/',

    Adminisztrációs adatok beállítása

    Az alapadatok megadása után mentsük és zárjuk be a config.php-t.

    Naplózás beállítása

    Alapértelmezetten a SimpleSAMLphp a syslog-ba irányítja a naplózást.

    Ha fájlba akarunk naplózni, akkor a megfelelő könyvtárhoz biztosítsunk írás jogot a webszerver felhasználónak, és ne felejtsünk el gondoskodni a naplófájlok rotálásáról!

    A "SimpleSAML\Logger::DEBUG" a legrészletesebb naplózási beállítás, éles rendszernél nem ajánlott csak hiba keresés esetén.

    Modulok engedélyezése
    'module.enable' => [
     'exampleauth' => true,
     'saml' => false, //
     'core' => null, // Alapértelmezett érték
     'ldap' => true, // 2.x verzióban külön telepíteni és engedélyezni kell az ldap modult.
     'admin' => true, // Ezt szükséges engedélyezni hogy elérhessük az adminisztrációs felületet
    ],
    
    Tanúsítvány készítése

    Nem ajánlott a SimpleSAMLphp-hoz és webszerverhez ugyanazt a tanúsítvány használni!

    A fingerprint az alábbi módon kérdezhető le a legegyszerűbben

    openssl x509 -fingerprint -noout -in cert/saml-example-org.crt
    

    Telepítés kész

    Amennyiben elkészültünk a fenti lépésekkel, úgy a https://service.example.org/simplesaml/admin címen elérjük a telepített SSP-nk webes adminfelületét.

    Identity Provider (IdP) beállítás

    Alapbeállítások

    IdP engedélyezése: a config/config.php fájlban kell a saml20 idp-t "true"-re állítani.

    'enable.saml20-idp' => true,
    

    Metaadat alapok

    A beállítandó IdP alapvető paraméterei a metadata/saml20-idp-hosted.php fájlban állíthatók. Az alábbi kódrészlet egy minimális, de már működő példát mutat.

     <?php
     $metadata['https://example.org/saml-idp'] = [
        /*
         * The hostname for this IdP. This makes it possible to run multiple
         * IdPs from the same configuration. '__DEFAULT__' means that this one
         * should be used by default.
         */
        'host' => '__DEFAULT__',
        /*
         * The private key and certificate to use when signing responses.
         * These can be stored as files in the cert-directory or retrieved
         * from a database.
         */
        'privatekey' => 'example.org.pem',
        'certificate' => 'example.org.crt',
        /*
         * The authentication source which should be used to authenticate the
         * user. This must match one of the entries in config/authsources.php.
         */
        'auth' => 'example-ldap',
     ];
    

    A fentebb hivatkozott certeket korábban létrehoztuk, de az example-ldap auth forrást még nem:

    LDAP autentikáció

    Javasolt az LDAP-ban egy olyan bejegyzést létrehozni az IdP számára, amely olvasni tudja a felhasználóknak a föderációban használt attribútumait. Az azonosítás alapértelmezett módon a felhasználó nevében történő újra bind-olással történik, így a jelszóhoz nem kell hozzáférést adni.

    Ahhoz, hogy megadhassuk az LDAP-hoz tartozó beállításokat, a config/authsources.php fájlt kell szerkesztenünk. Az alábbi kódrészletet elegendő beszúrni, és az egyes változóknak a helyi LDAP-nak megfelelő adatokat értékül adni.

    'example-ldap' => [
            'ldap:Ldap',
    
            /**
             * The connection string for the LDAP-server.
             * You can add multiple by separating them with a space.
             */
            'connection_string' => 'ldap.example.org',
    
            /**
             * Whether SSL/TLS should be used when contacting the LDAP server.
             * Possible values are 'ssl', 'tls' or 'none'
             */
            'encryption' => 'ssl',
    
            /**
             * The LDAP version to use when interfacing the LDAP-server.
             * Defaults to 3
             */
            'version' => 3,
    
            /**
             * Set to TRUE to enable LDAP debug level. Passed to the LDAP connector class.
             *
             * Default: FALSE
             * Required: No
             */
            'debug' => false,
    
            /**
             * The LDAP-options to pass when setting up a connection
             * See [Symfony documentation]
             */
            'options' => [
                /**
                 * Set whether to follow referrals.
                 * AD Controllers may require 0x00 to function.
                 * Possible values are 0x00 (NEVER), 0x01 (SEARCHING),
                 *   0x02 (FINDING) or 0x03 (ALWAYS).
                 */
                'referrals' => 0x00,
    
                'network_timeout' => 3,
            ],
    
            /**
             * The connector to use.
             * Defaults to '\SimpleSAML\Module\ldap\Connector\Ldap', but can be set
             * to '\SimpleSAML\Module\ldap\Connector\ActiveDirectory' when
             * authenticating against Microsoft Active Directory. This will
             * provide you with more specific error messages.
             */
            'connector' => '\SimpleSAML\Module\ldap\Connector\Ldap',
    
            /**
             * Which attributes should be retrieved from the LDAP server.
             * This can be an array of attribute names, or NULL, in which case
             * all attributes are fetched.
             */
            'attributes' => null,
    
            /**
             * Which attributes should be base64 encoded after retrieval from
             * the LDAP server.
             */
            'attributes.binary' => [
                'jpegPhoto',
                'objectGUID',
                'objectSid',
                'mS-DS-ConsistencyGuid'
            ],
    
            /**
             * The pattern which should be used to create the user's DN given
             * the username. %username% in this pattern will be replaced with
             * the user's username.
             *
             * This option is not used if the search.enable option is set to TRUE.
             */
            'dnpattern' => 'uid=%username%,ou=people,dc=example,dc=org',
    
            /**
             * As an alternative to specifying a pattern for the users DN, it is
             * possible to search for the username in a set of attributes. This is
             * enabled by this option.
             */
            'search.enable' => false,
    
            /**
             * An array on DNs which will be used as a base for the search. In
             * case of multiple strings, they will be searched in the order given.
             */
            'search.base' => [
                'ou=people,dc=example,dc=org',
            ],
    
            /**
             * The scope of the search. Valid values are 'sub' and 'one' and
             * 'base', first one being the default if no value is set.
             */
            'search.scope' => 'sub',
    
            /**
             * The attribute(s) the username should match against.
             *
             * This is an array with one or more attribute names. Any of the
             * attributes in the array may match the value the username.
             */
            'search.attributes' => ['uid', 'mail'],
    
            /**
             * Additional filters that must match for the entire LDAP search to
             * be true.
             *
             * This should be a single string conforming to [RFC 1960]
             * and [RFC 2544]. The string is appended to the search attributes
             */
            'search.filter' => '(&(objectClass=Person)(|(sn=Doe)(cn=John *)))',
    
            /**
             * The username & password where SimpleSAMLphp should bind to before
             * searching. If this is left NULL, no bind will be performed before
             * searching.
             */
            'search.username' => null,
            'search.password' => null,
        ],
    

    Megfelelő beállítások után a dinamikusan generált metadata a /saml2/idp/metadata.php útvonalon érhető el.

    Tesztelés

    A usereknek már nincs adminisztrációs felület azonban adminként még be lehet lépni amennyiben a core modulok között engedélyeztük az admin felületet: https://service.example.org/simplesaml/admin/

    A belépést követően a teszt fülre kattintva tesztelhetjük az authentikációs forrásokat:

    https://idp.niif.hu/simplesaml/module.php/admin/test

    Kézi metadata csere, élesített SP-vel

    Az IdP metadata valamint metadata eszközök megtalálhatók a következő oldalon (admin fiók szükséges): https://idp.example/simplesaml/module.php/admin/federation

    Amennyiben az SP is simplesamlphp használhatjuk a fentihez hasonló elérési úton található SimplesSAMLphp SP Metadatát, ez php formátumban van, ellenkező esetben pl shibboleth sp meg kell keresnünk a metaadat XML-t majd a fentebb említett federation oldalon található XML →simplesamlphp metadata konvertert használni.

    Az így kapott php formátumú metaadatokat pedig be kell illeszteni az IdP-n a metadata/saml20-sp-remote.php fileba a következő példához hasonlóképp:

    <?php
    
    $metadata['https://sp.example.org/simplesaml/module.php/saml/sp/metadata.php/default-sp'] = [
        'AssertionConsumerService' => 'https://sp.example.org/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
        'SingleLogoutService' => 'https://sp.example.org/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp',
    ];
    

    A másik (SP) oldalon amennyiben szintén simplesamlphp van, az idp metaadatokat hasonlóképp hasonlóképp érjük el majd illesszük be a metadata/saml20-idp-remote.php fileba.

    <?php
    $metadata['https://example.org/saml-idp'] = [
        'SingleSignOnService'  => 'https://example.org/simplesaml/saml2/idp/SSOService.php',
        'SingleLogoutService'  => 'https://example.org/simplesaml/saml2/idp/SingleLogoutService.php',
        'certificate'          => 'example.pem',
    ];
    
    

    A certet a config php-ban beállított certdir-ben keresi (alapértelmezetten /cert) Amennyiben más SP-t használunk az idp XML metadatájára lesz szükség amely szintén föderáció fül alatt érhető el (https://idp.example/simplesaml/module.php/admin/federation), és az SPn-nek releváns dokumentációt kell követni.

    Service Provider (SP) beállítás

    Alapbeállítások

    A telepített alkalmazásunk által kezelt SP-ket a config/authsources.php fájlban tudjuk beállítani. A SimpleSAMLphp a tanúsítvány fájlokat a korábban létrehozott cert mappában fogja keresni, a fájlokat elég relatív elérési úttal megadni.

    <?php
    $config = [
    
        /* This is the name of this authentication source, and will be used to access it later. */
        'default-sp' => [
            'saml:SP',
            'entityID' => 'https://myapp.example.org/',
            'privatekey' => 'saml.pem',
            'certificate' => 'saml.crt',
            'idp' => 'https://example.org/saml-idp', //Alapértelmezett IdP beállítása
        ],
    
    ];
    
    

    Tesztelés

    A fent elvégzett alapbeállítások után már tudjuk tesztelni a, hogy a felépített IdP - SP kapcsolat működik-e.

    SP oldalon nyissuk meg a admin teszt felületet:

    https://idp.niif.hu/simplesaml/module.php/admin/test

    Itt kattintsunk a default SP-re

    HREF-integráció

    Metadata beállítása (IdP és SP is)

    Javasolt dinamikus metaadatforrást (MDX) használni, opcionálisan kiegészítve statikus állományokkal. Részletes leírás itt: SimpleSAMLMixedMetadata()

    IdP

    Amennyiben van SSP alapú IdP-nk, melyet szeretnénk a föderáció részévé tenni, úgy a teendők a következők.

    Attribútumok kezelése

    Beállított IdP-nk alapértelmezés szerint azokat az attribútumokat adja ki, melyeket a metaadat alapján az SP kért (Lásd a metadatában a RequestedAttribute elemeket), és egyúttal alapból meg tudta szerezni a felhasználói adatbázisból, esetünkben az LDAP-ból. Mivel néhány attribútum nem szerepel az LDAP-ban, hanem az IdP-ben kell előállítani, így pár helyen módosítanunk kell az alapértelmezett konfiguráción.

    A metadata/saml20-idp-hosted.php fájlba szerkesszük be az alábbi kódrészlet értelemszerűen módosított változatát. Az 'auth' => 'example-ldap', sor alatt kezdjük. Fontos, hogy egyúttal a config.php authproc.idp részét kikommentezzük, nehogy az ottani sorszámokkal megadott default feladatok bekavarjanak.

     'AttributeNameFormat' => 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri',
     'userid.attribute' => 'uid', // Itt adjuk meg, hogy mely, az LDAPból származó attribútum alapján fogja az IdP kiszámítani az eduPersonTargetedID-t
     'authproc' => array(
                    10 => array(
                            'class' => 'core:AttributeMap',
                            'uid' => 'eduPersonPrincipalName'
                    //Itt az 'uid' az az attribútum az LDAP-ban, amely a felhasználó azonosítóját tartalmazza, mert ebből képezzük az eduPersonPrincipalName-t.
                    ),
                    # 20 => array(
                    #         'class' => 'core:AttributeAdd',
                    #         'schacHomeOrganizationType' => array('urn:schac:homeOrganizationType:hu:university')
                    # //Kötelező statikus attribútum az [[HREFAttributeSpec#schacHomeOrganizationType|intézmény jellegének]] megfelelően
                    # ),
                    30 => array(
                            'class' => 'core:AttributeAlter',
                            'subject' => 'eduPersonPrincipalName',
                            'pattern' => '/^.*$/',
                            'replacement' => '${0}@intezmenydomain.hu',
                    // Itt adjuk hozzá az intézményi scope-ot az eduPersonPrincipalName már meglévő értékéhez
                    ),
                    40 => array(
                            'class' => 'core:AttributeAlter',
                            'subject' => 'eduPersonAffiliation',
                            'pattern' => '/^.*$/',
                            'replacement' => '${0}@intezmenydomain.hu',
                    // Itt adjuk hozzá az intézményi scope-ot az eduPersonAffiliation már meglévő értékéhez
                    ),
                    50 => array(
                            'class' => 'core:AttributeMap',
                            'eduPersonAffiliation' => 'eduPersonScopedAffiliation'
                    // Az LDAP-ból eduPersonAffiliation-ként érkező attribútumból föderációs elvárásoknak megfelelően eduPersonScopedAffiliationt készítünk
                    ),
                    60 => array(
                            'class' => 'core:AttributeAdd',
                            'eduPersonScopedAffiliation' => array('member@intezmenydomain.hu')
                    // Az eduPersonScopedAffiliation-ben tesztelés céljából kiadhatjuk member értéket,
                    // így ha LDAP-ból nem jön érték, akkor is láthatjuk, hogy működik az attribútum kiadás
                    ),
                    61 => array(
                            'class' => 'core:TargetedID',
                            'nameId' => TRUE,
                    ),
                   // Itt állítjuk be, hogy az IdP előállítson és kiadhasson állandóazonosítóként eduPersonTargetedID-t, ha kérik
                    70 => array('class' => 'core:AttributeMap',
                            'name2oid'
                    // Az LDAP-os attribútum nevekből itt kreálunk szabványos urn:oid formátumúakat
                    ),
                    80 => 'core:AttributeLimit',
                  ), // .authproc
           'simplesaml.nameidattribute' => 'eduPersonPrincipalName',
           'attributeencodings' => array(
                   'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw',
            ),
            'sign.logout' => true
    

    SP

    Amennyiben IdP-t is beállítottunk, és be is tudunk lépni a Resource Registry-be, úgy nincs más dolgunk, mint az RR-ben új SP-t hozzáadni a föderációhoz, amely a megfelelő átfutási idő után a föderáció minden tagjánál látható is lesz.

    Ellenkező esetben (nincs IdP, és nem is tervezünk beállítani), akkor az IdP hozzáadásánál részletezett pontokon kell végig menni a metaadat betöltéséig, s a továbbiakat az említett e-mail címen megbeszélni.

    Attribútum scopeok használata

    A HREF föderáció IdP-i ún. scopeolt attribútumokat is használnak. Ez a scopeolás azt jelenti, hogy minden egyes IdP csak a saját scopejában ad ki attribútumokat, és a Shibboleth SP-k ezt ellenőrzik is. A scope és az attribútum valódi értéke egy '@' karakterrel kerül elválasztásra (ilyen attribútumok jelenleg: eduPersonScopedAffiliation illetve eduPersonPrincipalName).

    A SimpleSAMLphp alapértelmezett telepítése nem szűri a hibásan scopeolt értékeket. Kiegészítő modulként szűrésre használható az NIIF által fejlesztett attributescope modul, ami reményeink szerint rövid távon a hivatalos SimpleSAMLphp kiadás része lehet.

    A telepítésről és konfigurációról bővebben itt lehet olvasni: https://github.com/NIIF/simplesamlphp-module-attributescope

     authproc.sp =  array(
                          ...
                         // 49 => array('class' => 'core:AttributeMap', 'oid2name'),
                         50 => array(             'class' => 'attributescope:FilterAttributes'
                         ),
                         ...
                    ),
    

    Figyeljünk arra, hogy mire a modulhoz ér a vezérlés, az attribútumok nevei friendlyName alakúak legyenek (ne pedig oid-ok). A példában erre utal a 49-es sor.

    DrupalShibboleth

    Elgondolás

    A Drupal saját maga szereti kezelni a felhasználóit - adatbázisban -, de az azonosítás moduláris. A felhasználó beállításai a Drupal saját adatbázisában vannak, a Shibboleth modul csak a felhasználó azonosítóját adja meg.

    Felhasználó létrehozása

    Az IdP-nek azonosítania kell tudnia a felhasználót, tehát valamilyen központi adatbázisban léteznie kell.

    Ha egy olyan felhasználó jelentkezik be a Drupalba, aki még korábban nem jelentkezett be (pontosabban ha a Shibboleth-en keresztül megkapott azonosító még nem létezik), akkor a modul létrehoz egy új Drupal felhasználót. A felhasználó jelszava egy olyan véletlenszerűen generált megfelelően hosszú karakter sorozat, amely egyaránt tartalmazhat kis- és nagybetűket, valamint számokat. Alapesetben a felhasználó számára a jelszó változtatása tiltott, így a hagyományos úton (felhasználó név/ jelszó párossal) nem tud. A későbbiekben a jelszó változtatásának joga azonban egyénileg, vagy csortosan kiosztható ezzel engedélyezve a két authentikáció párhuzamos használatát. Néhány felhasználói beállítás kezdeti értéke származhat a Shibboleth-től kapott attribútumokból:

    (Ez utóbb funkciót az implementáció nem tartalmazza, ugyanis a különböző Shibboleth beállításoknak megfelelően rendszerenként más információk állnak rendelkezésre. Ennek kezelése a modul jövőbeli fejlesztései közé tartozik.)

    A felhasználói attribútumok változtatása az IdP-ben nem terjed át a Drupalra (leszámítva természetesen a felhasználói azonosítót), az Drupalban található attribútumok megváltoztathatók, ha ezt az oldal konfigurációja megengedi.

    Az újonnan létrejött felhasználó alap jogosultságokkal rendelkezik, ezután az adminisztrátor további jogokat biztosíthat számára.

    Felhasználó törlése

    A felhasználót a központi adatbázisból kell törölni, ezáltal megszűnik a hozzáférése a Drupalhoz. A Drupal azonosítója és beállításai azonban megmaradnak, ami az alábbi következményekkel jár (Vigyázat! Ha korábban egedélyeztük számára a jelszavas belépést, akkor azt külön le kell tiltani!):

    A fenti problémákat csak úgy lehet megoldani, ha egy alkalmazás a törölt felhasználók státuszát inaktiválja a Drupalban (és a hasonló elven felépülő többi rendszerben is).

    Shibboleth konfiguráció

    Be kell állítani a RequestMap-et az adott virtuális szerver adott könyvtárára, majd az Apache-nak a megfelelelő Directory vagy Location blokkjában be kell kapcsolni a Shibboleth azonosítást.

    !!! info

    [Lazy sessiont](https://help.edu.hu/books/aai/page/lazy-session) kell beállítani akkor, ha azt szeretnénk, hogy
    * anonymous módon hozzáférhető legyen a Drupal (pl. csak olvasásra)
    * az adminisztrátor be tudjon jelentkezni jelszóval.
    

    Bővebben lásd: Required Session

    Drupal Shibboleth modul

    Amennyiben lehetővé szeretnéd tenni, hogy a rendszered felhasználói Shibboleth-en keresztül is azonosíthassák magukat, nem kell mást tenned, mint hogy a meglévő Drupal rendszeredhöz hozzáadjad a Drupal Shibboleth modul-t (shib_auth).

    A Drupal Shibboleth modul angol nyelvű dokumentációja itt található

    !!! warning "Figyelem"

    A szócikk további része lehetséges, hogy elavult, az [angol nyelvű dokumentáció](https://help.edu.hu/books/aai/page/drupal-shibboleth-module) az érvényes!
    

    Telepítés

    1. Telepítsd a userprotect modult
      1. Töltsd le a rendszerünknek megfelelő verzióhoz tartozó userprotect modult a project honlapjáról!
      2. Kövesd a modullal együtt érkező README.txt utasításait a telepítéshez!
    2. Telepítsd a shib_auth modult
      1. Töltsd le a rendszerünknek megfelelő verzióhoz tartozó shib_auth modult a project honlapjáról!
      2. Másold be a tömörítve érkező fájlokat a rendszered modules/shib_auth könyvtárába. (Ez elsősorban a <drupal telepítési könyvtára>/modules/shib_auth útvonalon érhető el, azonban néha - főként multisite alkalmazások esetén - ettől eltérő is lehet.)
      3. A portál adminisztrációs felületén keresztül (Administer/Site Building/Modules) engedélyezd a shib_auth modult! Amennyiben ezt a rendszer nem egedélyezné, bizonyosodj meg róla, hogy a Drupal verziójához tartozó modult töltötted-e le, valamint hogy a függőségként szereplő modulok be vannak-e már kapcsolva!

    Konfiguráció

    A modul telepítője elvégezi a szükséges beállítások és módosítások többségét, így neked már nincs sok tennivalód. Az egyetlen elengedhetetlen beállítás a modul (Administer/User management/Shibboleth authentication module settings útvonalon elérhető) adminisztrációs oldalán található, ahol megadható a a WAYF localhost-ra mutató útvonala. (például: /Shibboleth.sso/WAYF/NIIF-WAYF)

    Ajánlott a settings.php-ben (pl.: <drupal telepítési könyvtára>/sites/default/settings.php) a cookie-k élettartamát 0-ra csökkenteni. ini_set('session.cookie_lifetime', 0);

    Használat

    A modul működése automatikus. A felhasználók a modul által létrehozott block-ban található url-re kattintva (lazy-session) vagy automatikusabn, az oldal betöltése közben (required session) authentikálják magukat a hozzájuk tartozó, a szerver által megbízhatónak tartott IdP-nél. A rendszer a apache modul által kapott információk alapján, az első bejelentkezés során létrehoz egy, a felhasználóhoz tartozó Drupal accountot, amihez egy véletlenszerű jelszót társít. Mivel a felhasználó ezt nem ismeri, így ezzel nem, kizárólag Shibboleth-es azonosítás segítségével tud belépni.

    !!! info

    Amennyiben engedélyezni szeretnéd egy felhasználónak vagy csoportnak a Shibboleth-es belépésen túl a jelszavas azonosítást **IS** nincs más dolgod, mint
    
    * a felhasználónak, vagy csoportnak a jogosultságokat kezelő oldalon engedélyezni a jelszavának átállítását
    * majd ezt követően:
    	* beállítani neki egy jelszót és ezt közölni vele, vagy
    	* rávenni, hogy egy Shibboleth-es belépést követően adjon meg magának egy jelszót.
    

    Admin felhasználó bejelentkezése

    Érdemes egy, a Shibboleth-től elkülönítve kezelt adminisztrátort is létrehoznod (például a telepítés során), hogy a rendszer az IdP-től függetlenül is használható maradjon, vagy hogy például szükség esetén magát a shib_auth modult is el lehessen távolítani.

    Mivel a modul kikapcsolja a főoldalon megjelenő user login blokkot, így azon keresztül nem lehetséges a username/password alapú belépés. (Ez a blokk opcionálisan visszakapcsolható.) Ahhoz hogy mégis be tudj lépni töltsd be a <Drupal CMS elérhetősége>/?q=user oldalt anélkül, hogy Shibboleth-en keresztül authentikáltad volna magad.

    Required session

    Lehetőség van arra is, hogy a felhasználók Shibboleth-en keresztüli authentikációját kötelezően megköveteld az oldal valamennyi megtekintése előtt. Ebben az esetben azonban nem lehetséges a nem shib_auth-on keresztüli belépés, így amíg ez a kényszer fenn áll, nem megoldható, hogy adminisztrátorként lépj be.

    Publikációk

    Federation_Policy

    About eduID

    Hungarian Research and Educational Federation (HREF) is a SAML2-based Identity Federation of Hungarian higher education and research institutions, public collections and other content providers. For the end-users, the federation aims to be transparent, therefore the login procedure is communicated as eduID login.

    Contacts

    The Federation is operated by NIIF Institute as a Federation Operator. Questions, concerns or any kind of requests about the Federation should be directed to any of the following addresses:

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

    Policy and principles of interoperation

    Basic principles

    1. The aim of the Federation is to allow the use of services of its Members and Partners, where authorisation is based on the user information originating from the users' Home Institutions.
    2. Home Institutions must only authenticate users having a known affiliation to them.
    3. IdPs and SPs must not give false or misleading information about themselves.
    4. User information provided by IdPs should be as accurate as possible. SPs must take into account that parts of the received information may be at the discretion of the user.
    5. User credentials (i.e. passwords) stored by IdPs must be protected and verified only through secure procedures.
    6. SPs must request only the user attributes which are absolutely necessary for their operation.
    7. SPs must not ask users for their federation passwords.
    8. SPs must handle personal data according to the local privacy laws.
    9. IdPs and SPs must cooperate in the investigation of possible abuse/fraud.
    10. IT systems running IdPs and SPs must be operated with due diligence.

    Data protection

    Rules of membership

    The Federation is operated by the Federation Operator, that also operates the national research network. Further participants are Members and Partners that must have a signed contract with the Operator.

    1. The following institutions may be Members of the federation:
      • Institutions of the higher education;
      • Institutions of the Hungarian Research Academy and other research institutions;
      • Institutions of secondary education;
      • Public collections.
    2. Any organisation might join as a Partner.
    3. All Members and Partners of the Federation might provide services.
    4. A Partner might participate in the meeting of the Members' Board as an observer, without having rights to vote.
    5. Only Members are entitled to
      • supply user identity information to the federation
      • send representatives into the Members' Board with a right to vote.

    Governance

    The governance body of the federation is the Members' Board (MB). Every Federation Member may send one representative person to the Members' Board, who has one vote.

    The working language of the MB is Hungarian. The Board publishes its decisions and guidelines at http://eduid.hu/dokumentumok in Hungarian, although whenever the topic is of interest of any international Partner, it shall be translated to English and the administrative contacts shall be notified.

    MB is authorised to

    Partners may also send representatives for MB meetings, without voting rights.

    The Federation itself is not a legal entity, Members and Partners establish a legal connection to the Federation Operator. Any legal claims between Members and/or Partners shall be directed to the organisation operating the Identity Provider or the Service Provider.

    Shibboleth_Service_Provider__SP__és_Docker

    Az alábbi lapon összefoglaljuk a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő Shibboleth SP-t állítsunk üzembe, Docker konténerben. Fontos, hogy rengeteg olyan igény lehet, amely további speciális beállítások meglétét teszik szükségessé, ezeket ezen a lapon nem részletezzük, ilyen irányú tájékozódáshoz legbiztosabb források:

    Apache 2.4

    Az alábbi példákban az SP és az alkalmazás konténer SSL termination proxy mögött helyezkedik el. Természetesen a VirtualHost átalakítható úgy, hogy SSL-t is ki tudjon szolgálni, ha erre van igény.

    Proxy

    Ebben az esetben, a Shibboleth SP-vel védeni kívánt alkalmazást proxy-zuk egy másik futó konténerből.

     <VirtualHost *:80>
         ServerName https://domain:443
         ServerAdmin admin@domain.com
         UseCanonicalName On
         ErrorLog /dev/stderr
         CustomLog /dev/stdout combined
         ProxyVia On
         ProxyRequests Off
         ProxyPreserveHost On
         ProxyPass /Shibboleth.sso !
         ProxyPass / http://cel_kontener:8080/ retry=0 timeout=30
         ProxyPassReverse / http://cel_kontener:8080/
         <Location "/socket.io">
             RewriteEngine On
             RewriteCond %{QUERY_STRING} transport=websocket [NC]
             RewriteRule /(.*) ws://cel_kontener:8080/socket.io/$1 [P,L]
             ProxyPass http://cel_kontener:8080/socket.io retry=0 timeout=30
             ProxyPassReverse http://cel_kontener:8080/socket.io
         </Location>
         <Proxy "*">
             AuthType shibboleth
             ShibRequestSetting requireSession 1
             Require valid-user
         </Proxy>
     </VirtualHost>
    

    Lazy session

    Az előző példához hasonlóan, a Shibboleth SP-vel védeni kívánt alkalmazást proxy-zuk egy másik futó konténerből, de csak a https://domain.com/secure útvonalat védjük.

     <VirtualHost *:80>
         ServerName https://domain:443
         ServerAdmin admin@domain.com
         UseCanonicalName On
         ErrorLog /dev/stderr
         CustomLog /dev/stdout combined
         ProxyVia On
         ProxyRequests Off
         ProxyPreserveHost On
         ProxyPass /Shibboleth.sso !
         ProxyPass / http://cel_kontener:8080/ retry=0 timeout=30
         ProxyPassReverse / http://cel_kontener:8080/
         <Location "/secure">
             AuthType Shibboleth
             ShibRequestSetting requireSession true
             ShibUseHeaders On
             Require shibboleth
             ProxyPass http://cel_kontener:8080/secure retry=0 timeout=30
             ProxyPassReverse http://cel_kontener:8080/secure
         </Location>
         <Proxy "*">
             AuthType shibboleth
             ShibRequestSetting requireSession false
             Require shibboleth
         </Proxy>
     </VirtualHost>
    

    Shibboleth

    Load balance

    Terheléselosztó mögött a shibboleth2.xml-ben, a <Session> beállításnál érdemes a consistentAddress="false" értéket beállítani, ha tudjuk, hogy változó (LAN!) címekről érkeznek a felhasználók.

    EduIDTest

    hosts file használata

    A hosts file meglehetősen egyszerűen használható eszköz arra, hogy élesben működő szolgáltatás átalakítása során tudjunk. Mivel az eduID-ban elterjedten használt SAML profilokban az üzenetváltás a legtöbb esetben a böngészőn keresztül zajlik, ezért elegendő a böngészőt arra rávenni, hogy a tesztelni kívánt SP-t vagy IdP-t ne a világ által látott helyen, hanem a tesztelni kívánt ponton keresse. Ez a módszer mind SP, mind IdP tesztelésre használható.

    Néhány tipp:

    SP tesztelés

    A szolgáltatásunk SAML integrációjának tesztelésére remekül használható eszköz a https://samlidp.io, amellyel pár kattintással készíthetünk magunknak teszt célokra IdP-t, amelynek megadható - akár a föderációban még nem regisztrált - SP metaadata is, így különböző felhasználói profilokkal próbálkozhatunk.

    Drupal_telepítés

    A Drupal aktuális verzióját az alábbi link segítségével lehet letölteni: https://ftp.drupal.org/files/projects/drupal-8.7.7.tar.gz

    A letöltött tar.gz állományt tömörítsük ki a saját gépünkön. Miután a kitömörítettük, a mappa tartalmát feltölthetjük a tárhelyünkre.

    A PWS-en található tárhelyünkhöz a SFTP segítségével tudunk kapcsolódni.

    Windows operációs rendszer esetén pl. :WinSCP - https://winscp.net/eng/download.php

    Szükséges adatok:

    SFTP host: ftp.pws.niif.hu

    SFTP user: < felhasználói név >

    SFTP password: < jelszó >

    WinSCP - Munkamenet

    A csatlakozás során fogadjuk el, a kiszolgáló kulcsának hozzáadását a gyorsítótárhoz.

    Amennyiben sikeresen csatlakoztunk az alábbi mappa szerkezetet láthatjuk:

    Könyvtárszerkezet

    A korábban letöltött és kicsomagolt Drupal fájlokat másoljuk fel a www könyvtárba.

    Miután feltöltésre kerültek a fájlok a domain név beírása után az alábbi oldalnak kell megjelennie: Drupal - Kezdőlap

    Válasszuk ki az English opciót majd kattintsunk a Save and continue opcióra.

    Drupal - Profil választás

    Válasszuk ki a Standard opciót.

    Megjegyzés: Ha a követelmények ellenőrzése során azt a hibát kapjuk vissza, hogy a settings.php nem létezik.

    A settings.php nem létezik

    Az alábbi fájlt nevezzük át:/protected/www/sites/default/default.settings.php -> settings.php-ra. (Az átnevezés előtt ajánlott egy másolat készítése a default.setting.php fájlról) default.settings.php átnevezése

    A folytatáshoz görgessünk le az oldal aljára és kattintsunk a try again szövegre. A hibajelzés eltűnt, maradt egy Waring-ra felhívó szöveg. Ezt figyelmen kívül hagyhatjuk, görgessünk le ismét az oldal aljára és kattintsunk a continue anyway szövegre.

    A következő lépésnél az adatbázis beállítása következik Drupal - adatbázis beállítás

    A Database type-nál válasszuk ki a MySQL, MariaDB, Percona Server, or equivalent lehetőséget. Töltsük ki az adatok. Az adatbázis szerver az elérését az Advanced options-ra kattintva tudjuk megtenni. További beállítások elvégzésére is lehetőségünk van.

    A table name prefixet nem muszáj kitölteni.

    Ha ezekkel meg vagyunk kattintsunk a Save and continue gombra. Elkezdődik a Drupal telepítése.

    Drupal - telepítés

    Utolsó lépésként jön az oldal beállítása. Itt tudjuk megadni az oldalunk nevét, email címet, adminisztrátor név jelszó, régió beállítás.

    Drupal - Oldalbeállítás - 1 Drupal - Oldalbeállítás 2

    Ha megvagyunk akkor Save and continue gombra kattintunk. Egy kis várakozás után az oldalunk telepítése elkészül.

    Telepítés után:

    Állapot jelentésnél az alábbi hibákkal találkozhatunk: http://sajtdomain/admin/reports/status

    Drupal hiba

    a) A settings.php olvasható/írható

    Megoldás:

    A /protected/www/sites/default/settings.php jogosultságát módosítsuk 0444-re, settings.php jogosultság

    A default mappa jogosultságát módosítsuk 0555-re. Drupal default mappa

    b) A trusted_host_patterns beállítás nincs még megadva a settings.php fájlban (Ez a hiba az oldal működését nem befolyásolja, csak állandó hibaként jelenik meg a státusznál)

    Megoldás:

    A /protected/www/sites/default/settings.php fájlban megkeressük a trusted_host pattern részt (kb. 721. sor) majd az ide vonatkozó részt kijelöljük és átmásoljuk a fájl végére. Drupal - settings.php (trusted_host_patterns)

    Ha ezzel végeztünk akkor kikommentezzük és a példában szereplő adatokat kicseréljük a mi domain címünkre, majd az egészet másoljuk a fájl végére. Drupal - settings.php (trusted_host_patterns)

    FederationStats

    Federation usage statistics

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

    I am a stub, please fix me!
    

    Federation visualization project - discountinued.

    Running the sample project

    Statistic types

    Currently we have the following types of statistics:

    Log statistics format

    The following simple format is used to convey statistics from IdPs to the central module - the white spaces (new lines) are important:

    ENTITYID #ENTITYID#
    APIKEY #API_KEY#
    DATE yyyy-mm-dd
    
    STAT #STAT_ID#
    xxxx
    
    STAT #STAT_ID#
    yyyy
    
    STAT #STAT_ID#
    ww | #PEER_ENTITY_1#
    zz | #PEER_ENTITY_2#
    

    The following sample might help understanding the format:

    ENTITYID https://idp.niif.hu/idp/shibboleth
    APIKEY 0123.......
    DATE 2009-03-18
    
    STAT AUTH
    68 logins
    
    STAT USER_COUNT
    16 unique userids
    
    STAT SSO_TO_SERVICE
    1        | urn:geant:niif.hu:niifi:sp:register.ca.niif.hu
    12       | https://repo.niif.hu/shibboleth
    1        | https://sandbox.aai.niif.hu/shibboleth
    5        | https://sysmonitor.hbone.hu/shibboleth
    10       | https://www.ki.iif.hu/shibboleth
    1        | https://noc6.vh.hbone.hu/shibboleth
    21       | https://webadmin.iif.hu/shibboleth
    3        | https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth
    7        | https://ugyeletes.vh.hbone.hu/shibboleth
    2        | https://noc.grid.niif.hu/shibboleth
    1        | https://wiki.voip.niif.hu/shibboleth
    2        | https://netmonitor.hbone.hu/shibboleth
    2        | https://idp.sch.bme.hu:443/opensso/sp/test
    

    Running the log statistics collector

    This following script can be used the collect statistics from the idp audit logs of Shibboleth 2 IdP generated on the day before running. It is based on Peter Schober's audit_r7.py, and good for run from daily cronjob:

    #!/bin/bash
    
    #Config section
    PARSER_COMMAND="/opt/shibboleth-idp/bin/audit_r7.py"
    SOURCEDIR="/opt/shibboleth-idp/logs"
    TARGETDIR="/tmp"
    
    ENTITYID="idp-entity-id"
    APIKEY="aaa..."
    LOCATION2PUT="https://fedstats.example.org/import_stats"
    
    DATE=`date -d "yesterday" +"%Y-%m-%d"`
    SOURCEFILE="$SOURCEDIR/idp-audit-$DATE.log"
    
    #Should not edit below this
    
    if [-f $SOURCEFILE ]()
    then
        LOGINS=`$PARSER_COMMAND -l $SOURCEFILE`
        UNIQUE_LOGINS=`$PARSER_COMMAND -u $SOURCEFILE`
        SERVICES=`$PARSER_COMMAND -p $SOURCEFILE | sed '/^[0-9]/p' -n`
    
        TARGETFILE="stat-$DATE.log"
    
    echo "ENTITYID $ENTITYID
    APIKEY $APIKEY
    DATE $DATE
    
    STAT AUTH
    $LOGINS
    
    STAT USER_COUNT
    $UNIQUE_LOGINS
    
    STAT SSO_TO_SERVICE
    $SERVICES
    " > $TARGETDIR/$TARGETFILE
    
        wget -q --no-check-certificate --post-file=$TARGETDIR/$TARGETFILE $LOCATION2PUT -O /dev/null
        rm $TARGETDIR/$TARGETFILE
    fi
    
    

    The script below can be used the collect statistics from all the idp audit logs placed in a folder.

    #!/bin/bash
    
    #Config section
    PARSER_COMMAND="/opt/shibboleth-idp/bin/audit_r7.py"
    SOURCEDIR="/opt/shibboleth-idp/logs"
    TARGETDIR="/tmp"
    
    ENTITYID="idp-entity-id"
    APIKEY="aaa..."
    LOCATION2PUT="https://fedstats.example.org/import_stats"
    
    FILES="idp-audit-*.log"
    
    #Should not edit below this
    cd $SOURCEDIR
    for f in $FILES
    do
      if [-f $f ]()
      then
        echo "Processing $f file..."
        DATE=${f:10:10}
        LOGINS=`$PARSER_COMMAND -l $f`
        UNIQUE_LOGINS=`$PARSER_COMMAND -u $f`
        SERVICES=`$PARSER_COMMAND -p $f | sed '/^[0-9]/p' -n`
    
        TARGETFILE="stat-$DATE.log"
    
        echo "ENTITYID $ENTITYID
    APIKEY $APIKEY
    DATE $DATE
    
    STAT AUTH
    $LOGINS
    
    STAT USER_COUNT
    $UNIQUE_LOGINS
    
    STAT SSO_TO_SERVICE
    $SERVICES
    " > $TARGETDIR/$TARGETFILE
    
        wget -q --no-check-certificate --post-file=$TARGETDIR/$TARGETFILE $LOCATION2PUT -O /dev/null
        rm $TARGETDIR/$TARGETFILE
      fi
    done
    

    Feeding the database with the statistics

    The federation statistics rails project contains the script/stat_parser/file.rb command which can process the statistics format and load the data to the database. Note that this script currently contains an absolute path for the script/runner script, so you must fix this before use.

    Using HTTP-Post to feed the database

    When deployed, the rails project provides a /import_stats URL to which one could POST the generated statistics file.

    Creating IdPs

    Use the rails console to create new idps:

    $ RAILS_ENV=production script/console
    
    >> Entity.create :name => 'foo', :entity_type => 'idp'
    
    => #<Entity id: 1, name: "foo", entity_type: "idp", created_at: "2010-11-29 14:55:40", updated_at: "2010-11-29 14:55:40", api_key: "da9l233a45698fa5c4a252e301e3da2sf5ece24e">
    

    HREFGlossary

    Föderáció

    Olyan bizalmi szövetség, melynek résztvevői elfogadják egymás felhasználóit azonosítottnak.

    HREF Föderáció

    (Hungarian Research and Education Federation, Magyar Kutatási és Felsőoktatási Föderáció), magyar felsőoktatási, kutatási intézmények és közgyűjtemények föderációja.

    Föderációs Operátor

    A Föderációs Operátor a Tagokkal és Partnerekkel megkötött csatlakozási szerződés alapján a HREF föderáció központi szolgáltatásainak működtetője. Elsődleges szerepe az, hogy a tagok közötti bizalmi viszonyt kialakítsa és fenntartsa.

    Gyakorlati feladatai közé tartozik a központi szolgáltatások működtetése (Discovery Service, Resource Registry), a Metadata állomány karbantartása és rendszeres aláírása, valamint a tagokkal ill. partnerekkel való szerződéses viszony kialakítása. A Föderációs Operátor vállalt feladatait és ezek szolgáltatási szint paramétereit az SLA megállapodás tartalmazza.

    Felhasználó

    Egy Tag alkalmazottja, oktatási tevékenységet végző munkatársa ill. hallgatója, akik igénybevehetik a Tartalomszolgáltatók szolgáltatásait.

    Tag

    A HREF Föderációhoz a Föderációs Operátorral megkötött csatlakozási szerződés alapján csatlakozó intézmény. Ilyen módon csak magyar felsőoktatási, kutatási, ill. oktatási és közgyűjteményi tevékenységet folytató jogi személyek csatlakozhatnak.

    A Tag azonosított felhasználói igénybe vehenek más tagok ill. Partnerek által biztosított szolgáltatásokat.

    Partner

    A HREF Föderációhoz a Föderációs Operátorral megkötött csatlakozási szerződés alapján csatlakozó partner intézmény.

    Partner intézmény szolgáltatásokat biztosíthat Tagok által azonosított felhasználók számára.

    Tagok Tanácsa

    A Föderáció működését szabályozó dokumentumokat a Föderációs Operátor a Tagok Tanácsa jóváhagyásával módosíthatja.

    IdP

    Identity Provider. Szövegkörnyezettől függően jelentheti az Azonosító Szervezetet, ill. az IdP AAI Kaput.

    Azonosító Szervezet

    A felhasználók azonosítását elvégző intézmény ("saját intézmény"). Az azonosító szervezet - az adatvédelmi szabályok betartása mellett - a felhasználóról Attribútumokat adhat át a Tartalomszolgáltatónak

    Attribútum

    A felhasználóhoz kapcsolódó személyes adat, illetve a felhasználó intézményhez való viszonyát leíró adat. A felhasználó attribútumait az Azonosító Szervezet tartja karban. Az attribútumok egy jól meghatározott halmazát az azonosítási folyamat részeként az IdP AAI Kapu átadja a Tartalomszolgáltatónak.

    IdP AAI Kapu

    Az a szoftver, amely elvégzi a felhasználók azonosítását és lehetőséget biztosít az azonosítással kapcsolatos információk, valamint felhasználói adatok (Attribútumok) kiadására.

    SP

    Service Provider. Szövegkörnyezettől függően jelentheti a Tartalomszolgáltatót, ill. az SP AAI Kaput.

    Tartalomszolgáltató

    A Tartalomszolgáltató az Azonosító Szervezet azonosítása alapján, az arra jogosult felhasználók számára webes szolgáltatásokat nyújtó szervezet. A HREF Föderációban Tartalomszolgáltatóként részt vehet mind a Tag, mind a Partner.

    SP AAI Kapu

    Az a szoftver, amely értelmezi az Azonosító Szervezettől kapott adatokat, ellenőrzi a kapott üzenet az érvényességét és sértetlenségét, majd jogosultságellenőrzést végez.

    Entitás

    Az SP AAI Kapu és az IdP AAI Kapu összefoglaló neve.

    Saját SP

    Tag által üzemeltett webes szolgáltatás, amely kizárólag intézményen belül elérhető. Saját SP-k regisztrálhatók a Resource Registry segítségével, azonban a föderációs metadatában nem jelennek meg.

    Resource Registry

    A Resource Registry az HREF Föderáció működtetéséhez szükséges olyan nyilvántartás, amely az Azonosító Szervezetekre és a Tartalomszolgáltatókra vonatkozó információkat kezeli. A Resource Registry segítségével előállítható és szerkeszthető a föderációs Metadata, valamint az Azonosító Szervezetek által a Tartalomszolgáltatók részére átadandó információkra vonatkozó szabályok.

    Discovery Service

    A Föderációs Operátor által üzemeltetett Keresőszolgáltatás (Discovery Service) egy olyan webes felület, ahol a felhasználók kiválaszthatják az őket azonosítani tudó Azonosító Szervezetet.

    Keresőszolgáltatást Tartalomszolgáltató és Azonosító Szervezet is üzemeltethet.

    Metaadatok

    (Metadata) Az HREF Föderációban résztvevő intézményeket leíró adatállomány. Az állomány tartalmaz:

    Virtuális Azonosító Szervezet

    (VHO, Virtual Home Organization) A Föderációs Operátor által üzemeltetett szolgáltatás, mely azonosítási szolgáltatást nyújt a Föderációban Tagként nem szereplő intézmények felhasználói számára, illetve lehetőséget biztosít a Tagok vendég felhasználói adminisztrálására is.

    Shibboleth_IdP_telepítés__Debian_

    !!! bug "Elavult információ"

    **Figyelem**: a Shibboleth szoftver ezen változata már nem támogatott. Az új verziókhoz a leírások itt találhatók:
    
    * [Shibboleth2_IdP](https://help.edu.hu/books/aai/page/shibboleth2-idp)
    * [Shibboleth2_SP](https://help.edu.hu/books/aai/page/shibboleth2-sp)
    

    Előkészületek

    Tanúsítvány

    Kell készíteni egy megfelelő SSL szerver tanúsítványt. Ha más nem szól ellene, érdemes ugyanazt a tanúsítványt használni a felhasználók felé, mint az SP-k felé.

    Tűzfal

    Be kell engedni a 443-as és a 8443-as portokat. Ha nagyon szigorúan vesszük, akkor a 8443-as portot elegendő csak a szóbajöhető SP-kről beengedni, de ezzel általában nem vagyunk tisztában, ezért célszerű a "nagyvilágból" beengedni. Biztonsági szempontból nem sok különbség van a 443-as és a 8443-as porton elérhető alkalmazások között.

    Tomcat

    JDK telepítés

    Sajnos Etch alatt a sun-java5-jdk csomag függ egy csomó X-es csomagtól, melyeket nem biztos, hogy szeretnénk telepíteni egy szerveren, érdemes lehet

    Ez igazából egy nagy hack, ugyanis ahhoz, hogy a tomcat-et csomagból telepíteni tudjuk, kell a java2-runtime csomag, amelyet biztosít a JRE is, viszont a Tomcat-nek JDK kell, hogy JSP-t tudjon futtatni.

    * <small>**Megj.:** Minden JSP-t első futtatáskor a konténer (Tomcat) lefordít Java kóddá, aztán byte-kóddá, ezért tart jó sokáig az - újraindítás utáni - első request. Ezután az eredményt elcache-eli, így csak akkor kell újrafordítania, ha a JSP megváltozik.</small>
    

    A JDK telepítés elég egyszerű, letöltjük a java.sun.com oldalról a nekünk tetsző verziót, aztán kicsomagoljuk, mondjuk a /usr/lib alá, aztán csinálunk egy szimbolikus linket, hogy a /usr/jdk mindig a "jó" JDK-ra mutasson.

    Tomcat telepítés

    Ha minden rendben meg, akkor elegendő egy

    apt-get install tomcat5.5
    

    Ez felpakolja a tomcat különböző függőségeit is.

    Ahhoz, hogy a Tomcat rendben elinduljon, szükséges neki megmondani, hogy hol találja a JDK-t. Ezért tegyük a /etc/default/tomcat5.5 fájlba a következőt:

    JAVA_HOME=/usr/jdk
    

    Ne felejtsük el, hogy a Tomcat szerver "tomcat55" user nevében fog futni! Mivel a Shibboleth servletnek szüksége van arra, hogy hozzáférjen a filerendszerhez, a Java Security Manager-t ki kell kapcsolni a /etc/default/tomcat5.5 fájlban:

    TOMCAT5_SECURITY=no
    

    Tomcat konfiguráció

    A 8009-es porton figyelő Connector elem konfigurációjához hozzá kell adni, hogy a tomcatAuthentication értéke "false" legyen, ezen kívül a hozzáférést korlátozhatjuk a localhost-ra is (hiszen a Connector-t csak a helyben futó Apache mod_jk konnektora érheti el).

    <Connector port="8009" address="127.0.0.1" tomcatAuthentication="false"
                   enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
    

    Apache

    IdP-t telepíthetünk "standalone" Tomcat környezetre is, ekkor nincs szükségünk Apache-ra. A leírást ide kérjük :)

    Az IdP telepítéséhez szükségünk lesz az alap apache szerverre (Etch-ben 2.2-es verziójú) és néhány modulra:

    A konfiguráció lépései:

    mod_ssl

    /etc/apache2/ports.conf

    Listen 443
    Listen 8443
    

    Engedélyezzük az SSL modult.

    a2enmod ssl
    

    mod_jk

    A mod_jk telepítés után alapértelmezetten engedélyezve van, ha mégsem lenne, az a2enmod jk paranccsal engedélyezhetjük.

    A /etc/libapache2-mod-jk/workers.properties file-ban állítsuk be a workers.tomcat_home és a workers.java_home paramétereket a Tomcat ill. a JDK telepítésénél használt értékekre. (tomcat_home=/usr/share/tomcat5.5 az alapértelmezett telepítésnél.)

    Már csak az van hátra, hogy bizonyos URI-kra érkező kéréseket a modul átküldje a Tomcat-nek. Ehhez az alábbi konfigurációs direktívákat kell megadnunk valahol a szerver konfigurációban (pl. /etc/apache2/apache2.conf)

    <IfModule mod_jk.c>
       JkWorkersFile /etc/libapache2-mod-jk/workers.properties
       JkLogFile /var/log/apache2/mod_jk.log
       JkLogLevel info
       JkMount /shibboleth-idp/* ajp13_worker
    </IfModule>
    

    A fenti példában a shibboleth-idp az IdP servlet telepítése során (később) megadott URI. Ez azt jelenti, hogy a /shibboleth-idp URI alá jövő összes kérést a Tomcat fogja megkapni.

    VirtualHost

    Nem feltétlenül szükséges külön VirtualHost-ban futtatni az IdP-t, de sok szempontból "tisztább" konfigurációt eredményez. Egy működő konfig:

    <VirtualHost 193.224.163.21:443 [2001:738:0:600:216:3eff:fe00:18]:443>
      ServerName      papigw.aai.niif.hu
      ServerAdmin     root@niif.hu
      DocumentRoot    /var/www/papigw.aai.niif.hu/htdocs
      CustomLog       /var/log/apache2/papigw.aai.niif.hu.ssl_access.log combined
      ErrorLog        /var/log/apache2/papigw.aai.niif.hu.ssl_error.log
      SSLEngine       On
      SSLCertificateFile      /etc/apache2/ssl/papigw.aai.niif.hu.crt
      SSLCertificateKeyFile   /etc/apache2/ssl/papigw.aai.niif.hu.key
    
      <Location /shibboleth-idp/SSO>
            AuthType Basic
            AuthBasicProvider ldap
            AuthName "Login to PAPIGW Identity Provider"
            AuthLDAPURL ldaps://directory.iif.hu:636/ou=users,o=niifi,o=niif,c=hu?uid?one
            AuthLDAPBindDN uid=papigw.aai.niif.hu,ou=https,ou=applications,o=niifi,o=niif,c=hu
            AuthLDAPBindPassword ******
            AuthzLDAPAuthoritative off
            require valid-user
      </Location>
     </VirtualHost>
    
     <VirtualHost 193.224.163.21:8443 [2001:738:0:600:216:3eff:fe00:18]:8443>
      ServerName      papigw.aai.niif.hu
      ServerAdmin     root@niif.hu
      DocumentRoot    /var/www/papigw.aai.niif.hu/htdocs
      CustomLog       /var/log/apache2/papigw.aai.niif.hu.ssl_access.log combined
      ErrorLog        /var/log/apache2/papigw.aai.niif.hu.ssl_error.log
      SSLEngine       On
      SSLCertificateFile      /etc/apache2/ssl/papigw.aai.niif.hu.crt
      SSLCertificateKeyFile   /etc/apache2/ssl/papigw.aai.niif.hu.key
      SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
      SSLVerifyClient optional_no_ca
      SSLVerifyDepth 10
      SSLOptions +StdEnvVars +ExportCertData
     </VirtualHost>
    

    Autentikáció

    SSO URI

    Ez az az URI, amelyre az SP átirányítja a felhasználót, általában a szabványos https porton érhető el. A példában LDAP-ból azonosítjuk a felhasználót, majd az azonosított felhasználónevet a REMOTE_USER változóban adjuk át a Shibboleth IdP servletnek.

    A <Location ...> blokkban bármilyen azonosítást beállíthatunk (MySql, plain file, stb).

    AA URI

    Az Attribute Authority általában a 8443-as porton érhető el.

    Ezen az URI-n az SP-k kapcsolódnak hozzánk, hogy a felhasználóról adatokat kérjenek. Az SP-ket mindig tanúsítvánnyal azonosítjuk. "Természetesen" a request-et utána továbbítani kell a Tomcatben futó IdP servletnek. (Ezt a mod_jk fejezetben mutatott példában a JkMount /shibboleth-idp/* megadásával értük el.)

    IdP servlet telepítése

    Az IdP innen tölthető le: http://shibboleth.internet2.edu/latest.html

    A tar.gz állományt csomagoljuk ki, majd lépjünk be a létrejövő könyvtárba.

    Endorsed jar állományok

    Sajnos - legalábbis a cikk írásakor - a "kincstári" Sun-os Tomcat (Java?) JAXP parser egy ismert memóriaszivárgást tartalmaz, ezért a disztribúcióban az endorsed/ könyvtárban található .jar file-okat kézzel be kell másolni a Tomcat endorsed/ könyvtárába.

    Installer

    export JAVA_HOME=/usr/jdk
    ./ant
    

    A telepítés során az alábbi paramétereket kell megadnunk:

    Könyvtárak

    A telepítő minden file-t (binárisok, konfiguráció, logok, stb) egyetlen könyvtár alatti struktúrába tenne, de valószínűleg jobban járunk, ha az alkalmazásunk konfigurációja a /etc, a logok pedig a /var/log alatt találhatók.

    Például:

    export IDP_HOME=/usr/local/shibboleth-idp
    mv $IDP_HOME/etc /etc/`basename $IDP_HOME`
    ln -s /etc/`basename $IDP_HOME` $IDP_HOME/etc
    mv $IDP_HOME/logs /var/log/`basename $IDP_HOME`
    ln -s /var/log/`basename $IDP_HOME` $IDP_HOME/logs
    

    Mivel a Debianon a Tomcat "tomcat55" user nevében fut, a szükséges állományokhoz hozzá kell tudnia férni

    chown tomcat55 /var/log/`basename $IDP_HOME`
    chmod 755 $IDP_HOME/bin/*
    

    Ezek után már csak újra kell indítani a Tomcat-et, és az IdP-nek működnie kell. Ellenőrizni pl. úgy tudjuk, hogy meghívjuk a https://hostnev/shibboleth-idp/Status URI-t, amelynek az "AVAILABLE" stringet kell visszaadni.

    Forrás

    SimpleSAMLphp_NIIF_ldap_séma_mapping

    A simpleSAMLphp különböző attribútum mappinget használ az attribúmnevek átfordításaihoz. A href ldap sémához még nincs, ezt a két file tartalmazza az oid - name oda-vissza mapping-et. Az attributemap könyvtárban van a helyük. A config.php authproc szabályai között kell felvenni őket, amikor szükség van rá.

    config/config.php

    ...
            'authproc.sp' => array(
    ...
                   11 => array(
                           'class' => 'core:AttributeMap', 'oid-href'
                   ),
    ...
       ),
    ...
    

    attributemap/href-oid.php

    <?php
    
    /**
    *  Hungarian Research and Education Federation AttributeSchema representation
    *  source: [https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif](https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif)
    *  @author: Szabó Gyula, aai.sztaki.hu  <gyufi@sztaki.hu>
    *
    */
    
    $attributemap = array(
            'niifPersonCityOfBirth' => 'urn:oid:1.3.6.1.4.1.11914.0.1.155',
            'niifPersonDateOfBirth' => 'urn:oid:1.3.6.1.4.1.11914.0.1.152',
            'niifPersonActivityStatus' => 'urn:oid:1.3.6.1.4.1.11914.0.1.153',
            'niifPersonJoinDate'  => 'urn:oid:1.3.6.1.4.1.11914.0.1.169',
            'niifPersonOrgID' => 'urn:oid:1.3.6.1.4.1.11914.0.1.154',
            'niifCertificateSubjectDN' => 'urn:oid:1.3.6.1.4.1.11914.0.1.151',
            'niifEduPersonFacultyDN' => 'urn:oid:1.3.6.1.4.1.11914.0.1.161',
            'niifPersonPosition' => 'urn:oid:1.3.6.1.4.1.11914.0.1.167',
            'niifStatus' => 'urn:oid:1.3.6.1.4.1.11914.0.1.1',
            'niifPersonIdentityNumber' => 'urn:oid:1.3.6.1.4.1.11914.0.1.158',
            'niifTitle' => 'urn:oid:1.3.6.1.4.1.11914.0.1.2',
            'niifCertificateSHA1Fingerprint' => 'urn:oid:1.3.6.1.4.1.11914.0.1.173',
            'niifEduPersonAttendedCourse' => 'urn:oid:1.3.6.1.4.1.11914.0.1.164',
            'niifEduPersonArchiveCourse' => 'urn:oid:1.3.6.1.4.1.11914.0.1.171',
            'niifEduPersonHeldCourse' => 'urn:oid:1.3.6.1.4.1.11914.0.1.172',
            'niifPrefix' => 'urn:oid:1.3.6.1.4.1.11914.0.1.0',
            'niifPersonDegree' => 'urn:oid:1.3.6.1.4.1.11914.0.1.166',
            'niifEduPersonFaculty' => 'urn:oid:1.3.6.1.4.1.11914.0.1.160',
            'niifEduPersonMajor' => 'urn:oid:1.3.6.1.4.1.11914.0.1.162',
            'niifPersonQuitDate' => 'urn:oid:1.3.6.1.4.1.11914.0.1.170',
            'niifPersonMothersName' => 'urn:oid:1.3.6.1.4.1.11914.0.1.157',
            'niifEduPersonAcademicYear' => 'urn:oid:1.3.6.1.4.1.11914.0.1.163',
            'niifPersonCountyOfBirth' => 'urn:oid:1.3.6.1.4.1.11914.0.1.156',
            'niifUniqueId' => 'urn:oid:1.3.6.1.4.1.11914.0.1.3',
            'niifPersonPrefix' => 'urn:oid:1.3.6.1.4.1.11914.0.1.165',
            'niifActiveMemberOf' => 'urn:oid:1.3.6.1.4.1.11914.0.1.168',
            'niifPersonResidentalAddress' => 'urn:oid:1.3.6.1.4.1.11914.0.1.159',
            'niifIDPrefix' => 'urn:oid:1.3.6.1.4.1.11914.0.1.100',
    );
    ?>
    

    /attributemap/oid-href.php

    <?php
    
    /**
    *  Hungarian Research and Education Federation AttributeSchema representation
    *  source: [https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif](https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif)
    *  @author: Szabó Gyula, aai.sztaki.hu  <gyufi@sztaki.hu>
    *
    */
    
    $attributemap = array(
            'urn:oid:1.3.6.1.4.1.11914.0.1.155' => 'niifPersonCityOfBirth',
            'urn:oid:1.3.6.1.4.1.11914.0.1.152' => 'niifPersonDateOfBirth',
            'urn:oid:1.3.6.1.4.1.11914.0.1.153' => 'niifPersonActivityStatus',
            'urn:oid:1.3.6.1.4.1.11914.0.1.169' => 'niifPersonJoinDate' ,
            'urn:oid:1.3.6.1.4.1.11914.0.1.154' => 'niifPersonOrgID',
            'urn:oid:1.3.6.1.4.1.11914.0.1.151' => 'niifCertificateSubjectDN',
            'urn:oid:1.3.6.1.4.1.11914.0.1.161' => 'niifEduPersonFacultyDN',
            'urn:oid:1.3.6.1.4.1.11914.0.1.167' => 'niifPersonPosition' ,
            'urn:oid:1.3.6.1.4.1.11914.0.1.1' => 'niifStatus',
            'urn:oid:1.3.6.1.4.1.11914.0.1.158' => 'niifPersonIdentityNumber',
            'urn:oid:1.3.6.1.4.1.11914.0.1.2' => 'niifTitle',
            'urn:oid:1.3.6.1.4.1.11914.0.1.173' => 'niifCertificateSHA1Fingerprint',
            'urn:oid:1.3.6.1.4.1.11914.0.1.164' => 'niifEduPersonAttendedCourse',
            'urn:oid:1.3.6.1.4.1.11914.0.1.171' => 'niifEduPersonArchiveCourse',
            'urn:oid:1.3.6.1.4.1.11914.0.1.172' => 'niifEduPersonHeldCourse',
            'urn:oid:1.3.6.1.4.1.11914.0.1.0' => 'niifPrefix',
            'urn:oid:1.3.6.1.4.1.11914.0.1.166' => 'niifPersonDegree' ,
            'urn:oid:1.3.6.1.4.1.11914.0.1.160' => 'niifEduPersonFaculty',
            'urn:oid:1.3.6.1.4.1.11914.0.1.162' => 'niifEduPersonMajor',
            'urn:oid:1.3.6.1.4.1.11914.0.1.170' => 'niifPersonQuitDate' ,
            'urn:oid:1.3.6.1.4.1.11914.0.1.157' => 'niifPersonMothersName',
            'urn:oid:1.3.6.1.4.1.11914.0.1.163' => 'niifEduPersonAcademicYear',
            'urn:oid:1.3.6.1.4.1.11914.0.1.156' => 'niifPersonCountyOfBirth',
            'urn:oid:1.3.6.1.4.1.11914.0.1.3' => 'niifUniqueId',
            'urn:oid:1.3.6.1.4.1.11914.0.1.165' => 'niifPersonPrefix' ,
            'urn:oid:1.3.6.1.4.1.11914.0.1.168' => 'niifActiveMemberOf' ,
            'urn:oid:1.3.6.1.4.1.11914.0.1.159' => 'niifPersonResidentalAddress',
            'urn:oid:1.3.6.1.4.1.11914.0.1.100' => 'niifIDPrefix',
    );
    ?>
    

    Shibboleth3_IdP

    Telepítési leírások

    Konfigurációs leírások

    Interoperabilitás_mátrix

    Interoperabilitás mátrix

    Tesztelt szoftverek

    Tesztelt protokollok és bindingok

    SAML2.0 Interoperabilitás mátrix

    Jelmagyarázat:

    A zöld-del jelölt funkciók tökéletesen működnek, a narancssárgák nem triviálisan, de működésre bírhatók (ilyenkor mindig van megjegyzés is hozzájuk), a pirossal jelölt funkciók nem működtek. Az áthúzott funkciókat nem implementálja az adott szoftverpáros.

    Sure, here's the HTML conversion of the provided MediaWiki table:

    Shibboleth2 SP OpenSSO SP simpleSAMLphp SP
    Shibboleth2 IdP
    Shib2-Shib2
    Single Sign on
    HTTP-POST
    HTTP-Artifact
    Attribute query
    Signing / encryption
    Metadata management
    Shib2-OpenSSO
    Single Sign on
    HTTP-POST
    HTTP-Artifact
    Attribute query
    Signing / encryption
    Metadata management
    Shib2-SimpleSAMLphp
    Single Sign on
    HTTP-POST
    HTTP-Artifact
    Attribute query
    Signing / encryption
    Metadata management
    OpenSSO IdP
    OpenSSO-Shib2
    Single Sign on
    HTTP-POST
    HTTP-Artifact
    Attribute query
    Signing / encryption
    Metadata management
    OpenSSO-OpenSSO
    Single Sign on
    HTTP-POST
    HTTP-Artifact
    Attribute query
    Signing / encryption
    Metadata management
    OpenSSO-simpleSAML
    Single Sign on
    HTTP-POST
    HTTP-Artifact
    Attribute query
    Signing / encryption
    Metadata management
    simpleSAMLphp IdP
    simpleSAML-Shib2
    Single Sign on
    HTTP-POST
    HTTP-Artifact
    Attribute query
    Signing / encryption
    Metadata management
    simpleSAML-OpenSSO
    Single Sign on
    HTTP-POST
    HTTP-Artifact
    Attribute query
    Signing / encryption
    Metadata management
    simpleSAML-simpleSAML
    Single Sign on
    HTTP-POST
    HTTP-Artifact
    Attribute query
    Signing / encryption
    Metadata management

    HREF

    Magyarországi felsőoktatási és kutatói föderáció (Hungarian Research & Education Federation)

    A föderáció jelenleg technikai pilot státuszban van, azaz elsősorban a technikai együttműködésre, ill. a hosszú távú szabályozás előkészítésére koncentrálunk.

    Tagjai

    Szolgáltatások

    URN

    Támogatott szabványok

    A föderáció a SAML2 szabvány protokolljait használja. Minden résztvevő támogatja a SAML2 SSO Profile-t HTTP POST bindingon keresztül, néhányan Artifact bindingon keresztül is. A legtöbb résztvevő támogatja a SAML2 Single Logout profile-t.

    WebmailShibboleth

    Shibboleth, Webmail, IMAP Proof-of-concept

    In English

    Requirements

    Solution concepts

    Shibboleth IdP plugin

    IMAP configuration

    Webmail softwares

    Magyarul

    Koncepció

    A webmail és a levelezőszerver (IMAP/POP3) együttes működését szeretnénk Shibbolizálni. A fő probléma abból áll, hogy a webmail az IMAP szerver felé felhasználónévvel és jelszóval autentikál. Az címtárban tárolt jelszót azonban nem adhatjuk ki az alkalmazásoknak, ráadásul legtöbb esetben ez egy hashelt jelszó.

    A következő kritériumoknak kell teljesülniük:

    A fenti kritériumokat az 'egyszer használatos', rövid lejáratú jelszó használata ('service token') kielégíti. Ebben az esetben az IdP minden egyes webmail bejelentkezéshez generál egy véletlen jelszót, és ezt elmenti egy adatbázisban, (beállítva a jelszóhoz egy rövid lejárati időt) valamint elküldi a webmail SP-nek. A webmail ezen rövid lejáratú jelszó használatával autentikál az IMAP szerver felé.

    A leírt gondolatmenet megvalósításához három komponens együttműködése szükséges:

    Adatbázis struktúra

    MySQL használata esetén a következő adatbázisstruktúra használható:

    CREATE TABLE `service_tokens` (
      `uid` varchar(255) NOT NULL,
      `password` varchar(255) NOT NULL,
      `expiration` datetime NOT NULL,
      PRIMARY KEY  (`uid`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1
    

    IdP plugin

    Az IdP plugin aktuális verziója a következő URL-ről tölthető le: http://software.niif.hu/maven2/hu/niif/shibboleth-servicetoken/1.0. A shibboleth-servicetoken-1.0.jar -t illetve a megfelelő adatbázis drivert (MySQL esetén mysql-connector.jar) be kell másolni az idp.war WEB-INF/lib könyvtárába.

    Az attribute-resolver.xml -ben a következő változtatásokat kell megtenni:

     <!--xml semak megfelelo beallitasa -->
     <AttributeResolver
       ....
       xmlns:niifconnector="urn:geant:niif.hu:dataconnector"
       xsi:schemaLocation="
           ....
           urn:geant:niif.hu:dataconnector classpath:/schema/servicetokendataconnector.xsd">
    
      <!-- onetimepassword definicio -->
      <resolver:AttributeDefinition id="serviceToken" xsi:type="Simple"
        xmlns="urn:mace:shibboleth:2.0:resolver:ad"
        sourceAttributeID="serviceToken">
    
        <resolver:Dependency ref="serviceTokenConnector" />
    
        <resolver:AttributeEncoder xsi:type="SAML2String"
            xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:geant:niif.hu:servicetoken" friendlyName="serviceToken" />
      </resolver:AttributeDefinition>
    
      <!-- uid definicio -->
      <resolver:AttributeDefinition id="uid" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
         sourceAttributeID="uid">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:mace:dir:attribute-def:uid" />
        <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" />
      </resolver:AttributeDefinition>
    
      <!-- service token generalasa -->
      <resolver:DataConnector xsi:type="niifconnector:ServiceToken"
        id="serviceTokenConnector"
        sourceAttributeID="uid"
        generatedAttributeID="serviceToken"
        tableName="service_tokens"
        principalColumn="uid"
        passwordColumn="password"
        expirationColumn="expiration"
        passwordLifetime="XXXXXX"
        spEntityID="https://webmail.example.org/shibboleth" >
    
        <resolver:Dependency ref="myLDAP" />
    
        <dc:ApplicationManagedConnection
            jdbcDriver="com.mysql.jdbc.Driver"
            jdbcURL="jdbc:mysql://localhost:3306/shib_idp"
            jdbcUserName="*****"
            jdbcPassword="*****" />
      </resolver:DataConnector>
    

    Fontos, hogy a DataConnector (másodpercekben értelmezett) passwordLifetime attribútumát jól állítsuk be, azaz hosszabb legyen, mint a webmail oldali SP session, de javasolt 24 óránál rövidebbre venni.

    Az attribute-filter.xml -ben pedig ki kell engedni az uid és serviceToken attribútumokat a webmail sp-nek:

     <AttributeFilterPolicy id="sendServiceTokenToWebmail">
      <PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
       value="https://webmail.example.org/shibboleth" />
    
      <AttributeRule attributeID="uid">
        <PermitValueRule xsi:type="basic:ANY" />
      </AttributeRule>
      <AttributeRule attributeID="serviceToken">
        <PermitValueRule xsi:type="basic:ANY" />
      </AttributeRule>
     </AttributeFilterPolicy>
    

    IMAP konfiguráció (Cyrus imapd)

    Imapd saját autentikáció

    A Cyrus imapd-ben be kell állítani az SQL autentikációt. Ehhez a libsasl2-modules-sql debian csomagra is szükségünk lesz. A konfigurációt az imapd.conf-ban tehetjük meg:

    sasl_mech_list: PLAIN
    sasl_pwcheck_method: auxprop
    
    sasl_auxprop_plugin: sql
    sasl_sql_engine: mysql
    sasl_sql_hostnames: localhost
    sasl_sql_user: *****
    sasl_sql_passwd: *****
    sasl_sql_database: shib_idp
    sasl_sql_select: SELECT password AS userPassword FROM service_tokens WHERE uid = '%u' AND expiration > now()
    

    Amennyiben az IMAP szervert nem TLS/SSL felett használjuk, ezek a beállítások nem biztonságosak!

    Használat PAM-mal

    PAM használata esetén távolítsuk el a libsasl2-modules-sql csomagot, mert felesleges logüzeneteket gyárt. Ezen kívül szükség van a saslauthd-re is, amit debian alatt a sasl2-bin csomagban találhatunk.

    Az imapd.conf-ot a következőképp kell beállítani:

    sasl_mech_list: PLAIN
    sasl_pwcheck_method: saslauthd
    

    A saslauthd-t az /etc/default/saslauthd fájlban kell engedélyeznünk:

    START=yes
    MECHANISMS="pam"
    

    Az /etc/pam.d/imap fájlban kell az imap pam beállításokat megtenni. Adatbázis használatához a libpam-mysql csomag is szükséges. Ha az adatbázisos felhasználókhoz nincs lokális account, akkor a PAM 'account' metódusát permit-re kell állítani.

    auth       sufficient   pam_ldap.so
    auth       sufficient   pam_mysql.so use_first_pass user=****** passwd=****** \
      host=/var/run/mysqld/mysqld.sock db=shib_idp table=service_tokens usercolumn=uid passwdcolumn=password \
      crypt=plain [where=expiration>now()]
    auth       required     pam_deny.so
    @include common-account
    

    SP konfiguráció

    A webmailt futtató webszerver Shibboleth konfigurációjában el kell fogadni a felhasználónevet és a jelszót az IdP-től. Az attribute-map.xml -hez a következő bejegyezéseket kell hozzáadni:

      <Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="PHP_AUTH_USER"/>
      <Attribute name="urn:geant:niif.hu:servicetoken" id="PHP_AUTH_PW"/>
    

    Figyeljünk arra, hogy az attribute-policy.xml -ben ezeket az attribútumokat beengedjük! (Az alapértelmezett telepítés egy catch-all engedélyező szabályt tartalmaz, tehát az attribútum rendben meg fog jelenni.)

    Webmail szoftverek konfigurációja

    Squirrelmail

    A Squirrelmailhez a Squirrelmail HTTP Authentication Plugin letöltésével és telepítésével elvégezhető az IdP által kiadott és az SP által láthatóvá tett felhasználónév és jelszó alapú bejelentkezés.

    Roundcube

    A HTTP Authentication Plugin telepítése után a plugin-ból el kell távolítani a következő sort:

    public $task = 'login';
    

    Shibboleth_IdP_konfigurációja

    !!! bug "Elavult információ"

    **Figyelem**: a Shibboleth szoftver ezen változata már nem támogatott. Az új verziókhoz a leírások itt találhatók:
    
    * [Shibboleth2_IdP](https://help.edu.hu/books/aai/page/shibboleth2-idp)
    * [Shibboleth2_SP](https://help.edu.hu/books/aai/page/shibboleth2-sp)
    

    Az IdP alkalmazást az idp.xml állományon keresztül konfigurálhatjuk. Ebben a leírásban feltételezzük, hogy az IdP alkalmazás konfigurációs állományai a /etc/shibboleth-idp könyvtárban vannak.

    Működő példa konfiguráció

    <?xml version="1.0" encoding="ISO-8859-1"?>
    <IdPConfig
            xmlns="urn:mace:shibboleth:idp:config:1.0"
            xmlns:cred="urn:mace:shibboleth:credentials:1.0"
            xmlns:name="urn:mace:shibboleth:namemapper:1.0"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:mace:shibboleth:idp:config:1.0 ../schemas/shibboleth-idpconfig-1.0.xsd"
            AAUrl="https://idp.niif.hu:8443/shibboleth-idp/AA"
            resolverConfig="file:/etc/shibboleth-idp/resolver.ldap.xml"
            defaultRelyingParty="urn:niif.hu:aai:HREF"
            defaultAuthMethod="urn:oasis:names:tc:SAML:1.0:am:password"
            providerId="https://idp.niif.hu/shibboleth">
    
            <RelyingParty name="urn:niif.hu:aai:HREF" signingCredential="href_cred">
                    <NameID nameMapping="shm"/>
            </RelyingParty>
            <RelyingParty name="urn:geant:niif.hu:niifi:sp:register.ca.niif.hu"
                          signingCredential="href_cred"
                          forceAttributePush="true">
                    <NameID nameMapping="shm"/>
            </RelyingParty>
    
            <ReleasePolicyEngine>
                    <ArpRepository implementation="edu.internet2.middleware.shibboleth.aa.arp.provider.FileSystemArpRepository">
                            <Path>file:/etc/shibboleth-idp/arps/</Path>
                    </ArpRepository>
            </ReleasePolicyEngine>
    
            <Logging>
                    <ErrorLog level="DEBUG" location="file:/var/log/shibboleth-idp/shib-error.log" />
                    <TransactionLog level="INFO" location="file:/var/log/shibboleth-idp/shib-access.log" />
            </Logging>
    
            <NameMapping
                    xmlns="urn:mace:shibboleth:namemapper:1.0"
                    id="shm"
                    format="urn:mace:shibboleth:1.0:nameIdentifier"
                    type="SharedMemoryShibHandle"
                    handleTTL="28800"/>
    
            <ArtifactMapper implementation="edu.internet2.middleware.shibboleth.artifact.provider.MemoryArtifactMapper" />
    
            <Credentials xmlns="urn:mace:shibboleth:credentials:1.0">
                    <FileResolver Id="href_cred">
                            <Key>
                                    <Path>file:/etc/httpd/conf/ssl.key/idp.niif.hu.key</Path>
                            </Key>
                            <Certificate>
                                    <Path>file:/etc/httpd/conf/ssl.crt/idp.niif.hu.crt</Path>
                            </Certificate>
                    </FileResolver>
            </Credentials>
    
            <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.ShibbolethV1SSOHandler">
                    <Location>https?://[^:/]+(:(443|80))?/shibboleth-idp/SSO</Location> <!-- regex works when using default protocol ports -->
            </ProtocolHandler>
            <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.SAMLv1_AttributeQueryHandler">
                    <Location>.+:8443/shibboleth-idp/AA</Location>
            </ProtocolHandler>
            <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.SAMLv1_1ArtifactQueryHandler">
                    <Location>.+:8443/shibboleth-idp/Artifact</Location>
            </ProtocolHandler>
            <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.Shibboleth_StatusHandler">
                    <Location>https://[^:/]+(:443)?/shibboleth-idp/Status</Location>
            </ProtocolHandler>
    
            <MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata"
                    uri="file:/etc/shibboleth-idp/href-metadata.xml"/>
    </IdPConfig>
    

    XML elemek magyarázata

    IdPConfig

    Az IdPConfig elem attribútumai közül az xmlns: és xsi: attribútumokat nem szabad megváltoztatni, de van néhány, amit kötelező:

    Általában nem szükséges megadni:

    Az IdP konfigurációban a többi XML Element az IdPConfig gyereke.

    RelyingParty

    Egy IdP tetszőleges mennyiségű RelyingParty-t kezelhet.

    A legfelső szintű alapértelmezett beállításokon kívül minden egyes RelyingParty-ra beállíthatjuk az alábbi értékeket:

    A RelyingParty element NameID gyermeke segítségével állítható be a használt NameID kezelés.

    ReleasePolicyEngine

    Itt adhatjuk meg az attribútum kiadás implementációját (ezt általában nem kell változtatni) és az ARP állományok elérhetőségét.

    Logging

    A Logging element szabályozza a naplózási szintet, ill. a naplófile-ok helyét. Részletesebb beállításokra a Log4J-t is használhatjuk. (Lásd még: Értelmes naplóüzenetek (IdP))

    NameMapping

    Ebben az elemben adható meg a NameMapper implementációja, illetve az assertionökben használt azonosító (Subject Identifier) formátuma.

    Attribútumok:

    ArtifactMapper

    Itt adható meg az ArtifactMapper implementációja. HAShib használata esetén át kell állítani.

    Credentials

    Ebben az elemben adhatók meg a használt titkos kulcsok és tanúsítványok. Több is megadható, az id attribútum értékével hivatkozhatunk rájuk, pl a RelayingParty konfigurációban.

    ProtocolHandler

    Itt adhatók meg az egyes handler servletek elérhetőségei. Általában nem szükséges felülírni!

    Forrás

    ** Shibboleth Wiki**

    Single_Logout_in_Shibboleth_IdP

    Important notes on third party cookies

    In some browsers, the IFrame-driven front-channel logout doesn't work due to the browser blocking third party cookies.

    Additional links:

    "Although any third-party cookie restrictions are not a sufficient method to prevent cross-domain user tracking, they prove to be rather efficient in disrupting or impacting the security of some legitimate web site features, most notably certain web gadgets and authentication mechanisms."

    Why service providers might need the session cookie

    Most of the services do not need the session cookie itself, they only need the NameIdentifier, which is carried by the logout request, so back-channel logout requests are enough for them. But there might be service providers which do not implement back-channel bindings (eg. SimpleSAMLphp), or need front-channel application notification.

    Why not fully back-channel?

    SAML profiles specification (section 4.4.3.1) clearly states that front-channel should be preferred when sending the logoutrequest to the session authority (IdP). If the user interface is generated by the IdP, it could inform the user about the whole logout process, and each SP response. If the SP would use back-channel logoutrequest, the IdP's response would only contain minimal information (ie. success or failure), and this is not desirable. Also, the IdP would need to execute back-channel requests in parallel and synchronize them with the originating request, so this would make the processing code much more complex.

    Technical solution

    Our proposal is to prefer back-channel endpoints at the service provider side, unless your application needs to be notified via front-channel. For example,

    By these mutually exclusive endpoint sets, the SP can clearly advise the IdP which binding it should use when contanting this SP. Thus on the IdP side, both implementations need to be available.

    Non-technical solution

    Another option would be to add a new requirement for your end users. You can claim that banning third-party cookies is unsupported (because it breaks SLO), just like disabling all cookies (which breaks SSO). Convincing your users (and the Shibboleth developers to accept this solution) might be dubious, though.

    Features

    UI customization

    The UI is located in two JSP files:

    How it works

    SLOServlet

    The heart of the logout process is the SLOServlet. This servlet is responsible for these actions:

    With javascript

    The controller renders a page where an iframe is placed for every active session participant. This iframe calls the SLOServlet?action&entityID=... URL where the logout request is issued for the given session participant. If the request is front-channel, the iframe will make a front-channel SAML message exchange with the peer (using HTTP-Redirect or POST bindings).

    The status of the single logout process is queried via asynchronous requests. The status response from SLOServlet is a JSON array. This JSON array contains one object with the entityID and logoutStatus properties for each session participant.

    The logout status can be one of the followings:

    Status queries are issued using exponential backoff timing, until the timeout is reached. Please see the sloController.jsp for the exact timing used.

    Without javascript

    Controller renders an HTML page with <noscript> tags. There is one link for each session participant opening up in new window/tab, which can initiate the logout process for that particular SP. Depending on the current logout status, several other controls are enabled on the page:

    IdP-initiated Logout (available since v2.1.3-slo2)

    The user can initiate their logout process from the IdP (the URL is /idp/Logout). IdP-initiated logout has a clear advantage over SP-initiated logout, because the URL and the UI is fully independent from the current SP software used, thereby providing a unique logout URL for all users of the given IdP.

    Non-trivial settings

    Security

    SAML Single Logout Profile requires the logout requests and responses to be signed or otherwise authenticated. Without this, a user session could be DOS-ed knowing the NameID.

    You have two choices

    Signing messages

    Signing can be turned on by setting the signing property to front (for front-channel only) or true in the ApplicationDefaults or ApplicationOverride element in shibboleth2.xml.

    !!! note

    Signing messages is normally unnecessary for back-channel, as the transport is usually authenticated with the certificates in the metadata. However, for back-channel logout it is the IdP who initiates the HTTP connection to the SP, and it is the **webserver**, who answers the request. Because of the different needs, the webserver almost always uses a different certificate (a server certificate signed by a well-known CA) than the SP (possibly self-signed, client certificate). Therefore the SP must sign back-channel messages as well to authenticate itself to the IdP. Unfortunately, you can only enable signing all (otherwise transport protected) messages, and this may affect performance.
    

    Not requiring peer authentication

    Message issuer authentication can be turned off by changing the security policy of processing Single Logout messages. You can do this by commenting out the following line from the block SAML2SLOSecurityPolicy at relying-party.xml:

    <security:Rule xsi:type="security:MandatoryMessageAuthentication" />
    

    Session lifetime

    IdP session lifetime must be longer than any SP session lifetime. Otherwise, if an SP session outlives the IdP session and the user reauthenticates for a new session for other SPs, logout would not terminate session at the first SP.

    The IdP can limit the maximum lifetime of the SP session by using the (optional) SessionNotOnOrAfter property in the SAML2 authentication statement. SAML1.1 does not have this feature, so you cannot limit the session lifetime for SPs using Shibboleth SSO protocol.

    This can be set in the relying-party.xml by specifying the number of milliseconds in the maximumSPSessionLifetime attribute of the SAML2SSOProfile configuration.

    Required changes in the IdP

    Name identifier caching in IdP session

    In the LogoutRequest the IdP must reference the current user's name identifier. This name identifier is issued as part of the SSO process. In order to efficiently retrieve this information, the IdP should cache the name identifier in the IdP session information object.

    Associated ticket: SIDP-336

    Session indexing

    On receiving a LogoutRequest from a session participant, the IdP must be able to retrieve the IdP session associated with the principal. Session participants use the issued name identifier to identify the principal. The IdP session object can be indexed (and then retrieved of course) by any arbitrary unique key, so we use the name identifier value to index the session.

    Associated ticket: SIDP-338

    IdP Session invalidation

    Currently there is a bug in the IdP implementation which causes the IdP sessions to outlive the session removal.

    Associated ticket: SIDP-333

    How to use

    How to build

    Released versions

    v2.2.0-slo10

    v2.2.0-slo9

    v2.1.5-slo7

    v2.1.5-slo6

    v2.1.5-slo5

    v2.1.5-slo4

    v2.1.4-slo4

    v2.1.3-slo3

    v2.1.3-slo2

    v2.1.3-slo1

    Hints

    Missing features

    Shib2IdpTomcat6

    Ezt a lapot össze kellene vonni ezzel, és az elavult infókat frissíteni

    JVM beállítások

    A Tomcat6 jelenleg nem működik együtt tökéletesen 6-os JVM-mel (egész pontosan a commons-dbcp csomag a JDBC API pici megváltozása miatt), ezért egyelőre ajánlott 5-ös JVM-mel futtatni - FIXME.

    A Shibboleth2 IdP nem hajlandó elindulni a JVM-mel szállított Sun-féle Xerces implementációval, ezért az IdP csomaggal szállított Xerces és Xalan implementációkat be kell másolni a $JAVA_HOME/lib/endorsed könyvtárba, vagy a következő kapcsolóval kell indítani a Tomcat-et:

    java -Djava.endorsed.dirs=/path/to/xerces-libs
    

    Shibboleth IdP telepítése

    A kitömörített bináris disztribúció könyvtárában adjuk ki a

    sh ant.sh
    

    parancsot, ami megkérdezi a telepítési könyvtárat (${SHIB_HOME}) és a hostnevet, majd elkészíti azt, legenerálja a teszt-céllal használható kulcsokat és tanúsítványokat (ezeket a credentials könyvtárba teszi idp.key, idp.crt néven).

    Ezután a tomcat-et futtató felhasználónak (nálam: tomcat) írási jogot kell adni a log könyvtárra, majd telepíthetjük az idp webalkalmazást a tomcat webapps root alá (nálam: a /var/lib/tomcat-6/webapps/ROOT)

    chown tomcat:tomcat ${SHIB_HOME}/logs
    cp ${SHIB_HOME}/war/idp.war /var/lib/tomcat-6/webapps/ROOT
    

    Új SAML SP felvétele

    Egy új SP felvételéhez csak az SP metaadatára van szükségünk SAMLv2 szabványos XML formában. A metaadatot vagy fizikailag el kell helyezni a ${SHIB_HOME}/metadata könyvtárban, vagy egy URL-en elérhetővé kell tenni a Shibboleth IdP számára.

    Metaadat-források megadása a ${SHIB_HOME}/conf/relying-party.xml -ben

    <!-- több provider megadása láncolással -->
    <MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata">
       <!-- Fájlrendszerből olvasott metaadat -->
       <!-- Fill in metadataFile attribute with deployment specific information -->
       <MetadataProvider id="sp1" xsi:type="FilesystemMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
          metadataFile="${SHIB_HOME}/metadata/sp1-meta.xml" maintainExpiredMetadata="true">
        <!--Metaadat aláírás ellenőrzése -->
        <!--MetadataFilter xsi:type="SignatureValidation" trustEngineRef="shibboleth.MetadataTrustEngine" /-->
       </MetadataProvider>
    </MetadataProvider>
    

    SAMLv2 Profilok beállítása

    A ${SHIB_HOME}/conf/relying-party.xml -ben kell a következő módosításokat eszközölni:

    Először a SAMLv2 SSO Profil alapbeállításai

    <!-- a saját IDP entityID-je, amivel minden SP-hez egyszerre beállíthatjuk mint provider -->
    <DefaultRelyingParty
      provider="https://idp.example.com/idp/shibboleth"
      defaultSigningCredentialRef="IdPCredential">
    
     <!--
       5 perces assertion érvényesség (óraszinkronizálás IdP - SP között fontos!)
       A válaszok kötelező digitális aláírása
       Attribútum push
     -->
     <ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
        includeAttributeStatement="true"
        assertionLifetime="300000"
        assertionProxyCount="0"
        signResponses="always"
        signAssertions="never"
        encryptAssertions="conditional"
        encryptNameIds="conditional" />
    </DefaultRelyingParty>
    

    SP esetén az alapértelmezett beállítások felülírása:

    <RelyingParty
        id="https://sp1.example.com/shibboleth"
        provider="https://idp.example.com/idp/shibboleth"
        defaultSigningCredentialRef="IdPCredential">
       <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never"/>
    </RelyingParty>
    

    Attribútum kiadása (címtárból)

    Egy attribútum kiadásához két dolgot kell beállítani: a resolver-t és a filter-t. Előbbi felelős az attribútum megszerzéséért és a session kontextusba helyezésért, utóbbi az SP felé történő kiadást szabályozza.

    Új attribútum beolvasása címtárból (${SHIB_HOME}/conf/attribute-resolver.xml) és SAMLv1 illetve SAMLv2 AttributeStatement -be kódolása:

    <resolver:AttributeDefinition id="email" xsi:type="Simple"
      xmlns="urn:mace:shibboleth:2.0:resolver:ad"
      sourceAttributeID="mail">
      <resolver:Dependency ref="myLDAP" />
      <resolver:AttributeEncoder xsi:type="SAML1String"
        xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        name="urn:mace:dir:attribute-def:mail" />
      <resolver:AttributeEncoder xsi:type="SAML2String"
        xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />
    </resolver:AttributeDefinition>
    

    A resolver:Dependency adja meg azt a forrást, amiből az attribútum feloldásra kerül. Ez esetünkben a myLDAP:

    <resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory"
       xmlns="urn:mace:shibboleth:2.0:resolver:dc"
       ldapURL="ldap://ldap.example.com" baseDN="ou=people,dc=example,dc=com"
       principal="userid=shibboleth,ou=systems,dc=example,dc=com"
       principalCredential="password">
         <FilterTemplate>
               <![CDATA[
                   (uid=$requestContext.principalName)
               ]]>
         </FilterTemplate>
    </resolver:DataConnector>
    

    NameIdentifier leképzés

    Szintén az attribute-resolver.xml -ben kell beállítani az Assertion Subject NameID -t, ami az IdP-SP közötti azonosítóért felel. Példaképp egy SAMLv2 Tranziens azonosítót a következőképp állíthatunk be:

    <resolver:AttributeDefinition id="transientId" xsi:type="TransientId" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
      <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
        xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
    </resolver:AttributeDefinition>
    <resolver:PrincipalConnector xsi:type="Transient"
      xmlns="urn:mace:shibboleth:2.0:resolver:pc"
      id="saml2Transient"
      nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />