# AAI

Auto-generated book for AAI

# NIIFI_IdP

<table id="bkmrk-tulajdons%C3%A1g-%C3%89rt%C3%A9k-in"><thead><tr><th>Tulajdonság</th><th>Érték</th></tr></thead><tbody><tr><td>Intézmény (IdP) neve</td><td>**NIIF Intézet**</td></tr><tr><td>IdP szoftver</td><td>Shibboleth IdP 2.1</td></tr><tr><td>Technikai kapcsolattartó</td><td>Bajnok Kristóf, aai *KuKaC* niif *PoNT* hu</td></tr><tr><td>Azonosítható felhasználók száma</td><td>70</td></tr><tr><td>Hallgatók száma</td><td>0</td></tr><tr><td>Alkalmazottak száma</td><td>63</td></tr><tr><td>Külsősök száma</td><td>3</td></tr><tr><td>Nem felhasználóhoz köthető bejegyzések száma</td><td>4</td></tr><tr><td>Hallgatók felvételének folyamata</td><td>Nem alkalmazható</td></tr><tr><td>Alkalmazottak felvételének folyamata</td><td>Ú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.</td></tr><tr><td>Külsősök felvételének folyamata</td><td>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.</td></tr><tr><td>Hallgatók törlésének folyamata</td><td>Nem alkalmazható</td></tr><tr><td>Alkalmazottak törlésének folyamata</td><td>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</td></tr><tr><td>Külsősök törlésének folyamata</td><td>Nem meghatározott, mivel a felvétel is különleges eljárás szerint történik</td></tr><tr><td>Felhasználó intézményhez való kapcsolatát leíró attribútum/érték</td><td>1. **Alkalmazott**: `edupersonAffiliation: employee`
2. **Külsős munkatársak**: nincs `edupersonAffiliation` attribútum vagy `edupersonAffiliation: affiliate`
</td></tr><tr><td>Egyes attribútumok származás helye ill. módosításra jogosultak</td><td>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.</td></tr><tr><td>Jelszavak formai követelményei</td><td>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.</td></tr><tr><td>Naplóállományok rendelkezésre állási ideje</td><td>min. 6 hónap</td></tr><tr><td>Autentikációs backend</td><td>LDAP</td></tr><tr><td>Autentikációs mód</td><td>Username/password</td></tr><tr><td>Vállalt rendelkezésre állás</td><td>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).</td></tr></tbody></table>

# Döntési_táblázat

## Döntési módok

- Aktív többségi döntés: Tagok Tanácsának 50% + 1 döntése
- Gyorsított döntés 
    - cél: gyorsított eljárás
    - olyan esetekre, ahol a tagok beleegyezése feltételezhető
    - a döntés körülményeit a Föderációs Operátor már alaposan megvizsgálta
    - 3 munkanapon belül ha nincs tiltakozó tag, jóváhagyásnak minősül
    - ha van tiltakozó tag, aktív többségi döntés, vagy a Föderációs Operátor visszavonja az indítványt

## Regisztrációs folyamat

<table id="bkmrk-d%C3%B6nt%C3%A9si-folyamat-k%C3%A9r"><thead><tr><th>Döntési folyamat</th><th>Kérelem forma</th><th>Csatolt dokumentáció</th><th>Döntés módja</th><th>Döntés eredménye</th></tr></thead><tbody><tr><td>*Új Tag felvétele*</td><td>Szerződés, szándéknyilatkozat</td><td></td><td>Aktív többségi döntés</td><td>Szerződés aláírása Felvétel T.T. -ba</td></tr><tr><td>Tag (új) IdP</td><td>RR</td><td>Adatkezelési folyamatok dokumentálása Adatkezelési nyilatkozat</td><td>Gyorsított eljárás</td><td>Jóváhagyás az RR-ben</td></tr><tr><td>Tag (új) SP</td><td>RR</td><td>Adatkezelési nyilatkozat</td><td>Gyorsított eljárás</td><td>Jóváhagyás az RR-ben</td></tr><tr><td>*Új Partner felvétele*</td><td>Szerződés, szándéknyilatkozat</td><td></td><td>Aktív többségi döntés</td><td>Szerződés aláírása Jóváhagyás az RR-ben</td></tr><tr><td>Partner új SP</td><td>RR</td><td>Adatkezelési nyilatkozat</td><td>Gyorsított eljárás</td><td>Jóváhagyás az RR-ben</td></tr></tbody></table>

## Döntési jogok

<table id="bkmrk-d%C3%B6nt%C3%A9si-jog-int%C3%A9zm%C3%A9n"><thead><tr><th>Döntési jog</th><th>Intézményi döntés, Tagok tájékoztatása</th><th>Föderációs operátor döntése, Tagok tájékoztatása</th><th>Föderációs operátor mint szolgáltató döntése</th><th>Gyorsított eljárás</th><th>Tagok Tanácsának döntése</th></tr></thead><tbody><tr><td>**Műszaki dokumentumok megváltoztatása**2. [Attribútum specifikáció](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
3. [Metadata specifikáció](https://help.edu.hu/books/aai/page/href-metadata-specifikacio)
4. [Műszaki követelmények és ajánlások](https://help.edu.hu/books/aai/page/href-muszaki-eloirasok)
</td><td></td><td></td><td></td><td><center>**X**</center></td><td></td></tr><tr><td>**Policy dokumentumok bármilyen megváltoztatása**2. [Szószedet](https://help.edu.hu/books/aai/page/hrefglossary)
3. [Alapelvek](https://help.edu.hu/books/aai/page/href-alapelvek-es-alapveto-szabalyok)
</td><td></td><td></td><td></td><td></td><td><center>**X**</center></td></tr><tr><td>**Csatlakozás nemzetközi szervezetekhez és együttműködésekhez**</td><td></td><td></td><td></td><td></td><td><center>**X**</center></td></tr><tr><td>**Azonosítási szolgáltatás (Identity Management) kiszervezése**</td><td><center>**X**</center></td><td></td><td></td><td></td><td></td></tr><tr><td>**Metadata módosítása**</td><td></td><td><center>**X** (*jóváhagyás*)</center></td><td></td><td></td><td></td></tr><tr><td>**Szolgáltatási díj bevezetése / megváltoztatása**</td><td></td><td></td><td></td><td></td><td><center>**X** (*Tagok új szerződést kötnek*)</center></td></tr><tr><td>**Egyedi díjkedvezmények megállapításának joga**</td><td></td><td></td><td><center>**X**</center></td><td></td><td></td></tr><tr><td>**Bevételek felhasználása**</td><td></td><td><center>**X**</center></td><td></td><td></td><td></td></tr><tr><td>**Szerződés rendes felmondása**</td><td><center>**X**</center></td><td><center>**X**</center></td><td></td><td></td><td></td></tr><tr><td>**Súlyos szerződésszegés miatti rendkívüli felmondás**</td><td><center>**X**</center></td><td><center>**X**</center></td><td></td><td></td><td></td></tr><tr><td>**Föderáció megszüntetése**</td><td></td><td></td><td></td><td></td><td><center>**X**</center></td></tr><tr><td>**Tagok Tanácsak saját eljárási szabályainak elfogadása, módosítása**</td><td></td><td></td><td></td><td></td><td><center>**X**</center></td></tr></tbody></table>

# 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](https://wiki.shibboleth.net/confluence/display/SHIB2/DSConfiguration)

## Az IdP Discovery menete

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

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

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

## A Discover Service metaadatok konfigurálása

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

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

## Discovery Service pluginek

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

# AAIInterop-OpenSSOShib2

!!! bug "Elavult információ"

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

```

# OpenSSO IdP - Shibboleth2 SP Interoperabilitás

- IdP: [maszat-opensso-idp.xml](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/maszat-opensso-idp.xml)
- SP: [papigw-shibboleth2-sp.xml](../static/papigw-shibboleth2-sp.xml){.download="papigw-shibboleth2-sp.xml"}

## SAML2.0 Single Sign on

- SP oldali SAML2 bindingot támogató AttributeConsumerService-ek: 
    - 1: /SAML2/POST urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
    - 2: /SAML2/POST-SimpleSign urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
    - 3: /SAML2/Artifact urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact
    - 4: /SAML2/ECP urn:oasis:names:tc:SAML:2.0:bindings:PAOS

### HTTP-Post

- Működik
- [https://papigw.aai.niif.hu/saml2interop/opensso-post/](https://papigw.aai.niif.hu/saml2interop/opensso-post/)
- SP oldalon

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

```

### HTTP-Artifact

- Az OpenSSO nem figyel arra hogy az SP milyen AttributeConsumerService-t kér, így az IDP oldalon kell konfigurálni az SP tulajdonságait úgy, hogy az alapbeállítás ne a POST legyen.
- TODO - Trust management a back-channel kommunikációnál a tanusítványt ismernie kell az SP-nek.
- JVM beállítása a kliens tanúsítvány használatához - [https://opensso.dev.java.net/issues/show\_bug.cgi?id=1409](https://opensso.dev.java.net/issues/show_bug.cgi?id=1409)

### Attribute push

- Gyári buildekkel nem működik, ugyanis az OpenSSO urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified formátumban küldi az attribútumokat, amiket a Shibboleth2 SP nem fogad el.
- Saját patch használata esetén bekonfigurálható az uri típusú NameFormat is, azzal működik probléma nélkül. 
    - [https://opensso.dev.java.net/issues/show\_bug.cgi?id=2775](https://opensso.dev.java.net/issues/show_bug.cgi?id=2775)

### Attribute pull

- Az OpenSSO-ban nem lehet kikapcsolni az attribute push-t. FIXME

### NameIDFormat

- A Shibboleth2 SP által generált metaadatba kézzel be kell illeszteni a NameIDFormat node-ot
- Az OpenSSO támogatja a perzisztens és a tranziens SAML2 azonosítót is.

## SAML2.0 Single Log out

- A shibboleth2 nem támogatja (még) a Single Log-out protokollt, lásd: [https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues](https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues)

## Metaadat problémák

- A Shibboleth2 SP metaadatból el kell távolítani az `<md:Extensions>` node-ot az összes gyerekelemével együtt. 
    - Erre nagyon figyelni kell, mert összeomlik tőle az OpenSSO, és csak címtár-módosítással ('hibás' metaadat törlése) állítható helyre.
    - Sajnos nem triviális javítani ezt a viselkedést...
- A metaadatba ágyazott certificate esetén csak a `<ds:X509Certificate>` node szerepelhet, semmi más 
    - Ehhez írtam patch-et ami ezt javítja.
    - [https://opensso.dev.java.net/issues/show\_bug.cgi?id=2985](https://opensso.dev.java.net/issues/show_bug.cgi?id=2985)

# Shibboleth2_SP

**Telepítési leírások**

- [Shibboleth 2 SP telepítése forrásból](https://help.edu.hu/books/aai/page/shib2spsourceinstall)

**Konfigurációs leírások**

- [Shibboleth 2 SP konfigurálása](https://help.edu.hu/books/aai/page/shib2sp)

# Shib3IdpMetadata

Shibboleth 3 IdP metaadat beállítása

**Vonatkozó állományok:**

- `{idp.home}/conf/metadata-providers.xml`

## Nem föderációs SP metaadat

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

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

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

```bash
$ 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.

```xml
<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/](https://metadata.eduid.hu/) helyen érhető el.

## Tovább a föderációba

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

## Dokumentáció

- [https://wiki.shibboleth.net/confluence/display/IDP30/MetadataConfiguration](https://wiki.shibboleth.net/confluence/display/IDP30/MetadataConfiguration)
- [https://wiki.shibboleth.net/confluence/display/IDP30/HTTPMetadataProviders](https://wiki.shibboleth.net/confluence/display/IDP30/HTTPMetadataProviders)

# RelyingParty

A Shibboleth terminológiában a **RelyingParty** kifejezés jelenti a "másik fele(ke)t". Egy RelyingParty vonatkozhat egyetlen SP-re vagy IdP-re, illetve egy teljes [föderációra](https://help.edu.hu/books/aai/page/foderacio) 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](https://help.edu.hu/books/aai/page/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](https://help.edu.hu/books/aai/page/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 IdP konfiguráció](https://help.edu.hu/books/aai/page/shibboleth-idp-konfiguracioja)
- [IdPRelyingConfig](https://spaces.internet2.edu/display/SHIB/IdPRelyingConfig) (Shibbleth Wiki)
- \[\[Shibboleth\_SP\_konfigurációja\]\]
- [SPRelyingConfig](https://spaces.internet2.edu/display/SHIB/SPRelyingConfig) (Shibbleth Wiki)

# Shibboleth_Service_Provider__SP_

Az alábbi lapon megkíséreljük összefoglalni a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő Shibboleth SP-t állítsunk üzembe. Fontos, hogy rengeteg olyan igény lehet, amely további speciális beállítások meglétét teszik szükségessé, ezeket ezen a lapon nem részletezzük, ilyen irányú tájékozódáshoz legbiztosabb forrás a [http://wiki.shibboleth.net](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](https://wiki.shibboleth.net/confluence/display/SP3) címről. Célszerű valamilyen előre csomagolt változattal dolgozni, melyet az adott rendszer csomagkezelőjén keresztül egy mozdulattal feltelepíthetünk minden függőségével együtt.

- Az alábbi parancs a Shibboleth webszerver modul függőségeit is telepíti. Előfordulhat, hogy a telepítés engedélyezni kell a modult és újraindítani az Apache webszervert.

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

```
sudo apt install apache2 libapache2-mod-shib2

```

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

```
sudo apt-get install apache2 libapache2-mod-shib2

```

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

<span style="color:red">**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!**</span>

A [Debian Shibboleth](http://wiki.debian.org/Teams/DebianShibboleth) csapat által készített új verziók időről időre bekerülnek [backports.org](http://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/](http://download.opensuse.org/repositories/security://shibboleth/) oldalra, majd a pontos verzió kiválasztása után a security:shibboleth.repo fájl tartalmát másoljuk be a /etc/yum/ `/etc/yum.repos.d/CentOS-Base.repo` fájl aljára, majd

```
yum install shibboleth

```

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

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

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

```

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

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

```

## Alapbeállítások

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

### `shibboleth2.xml`

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

- Választanunk kell egy entityID-t. Ez általában a védendő szolgáltatást futtató hosztnévből származik: `https://hosztnev/shibboleth`, ezt az azonosítót beírni az `ApplicationDefaults` részbe az alábbi módon (az entityID és a homeURL értékein kívül, ahová a hosztnév írandó be, alapértelmezés szerint mást nem szükséges változtatni):
    
    ```xml
    <ApplicationDefaults entityID="https://hosztnév/shibboleth"
                        homeURL="https://hosztnév/shib-error.html"
                        signing="false" encryption="false"
                        id="default" policyId="default"
                        REMOTE_USER="eppn persistent-id targeted-id">
    
    ```
- Meg kell adni, hogy egy Discovery Service-n keresztül kérjük meg a felhasználót, hogy adja meg, mely IdP-től érkezik, avagy csak IdP-t engedélyezünk számukra. Az első eset nyilvános szolgáltatások esetében indokolt, a második belső, pl. csak intézményi oldalak védésénél szükséges.
    
    
    - Discovery Service beállítása
        
        ```xml
        <SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.eduid.hu">
        SAML2 SAML1
        </SSO>
        
        ```
    - Fix IdP beállítása
        
        ```xml
        <SSO entityID="https://idp.example.org/idp/shibboleth">
        SAML2 SAML1
        </SSO>
        
        ```
- Meg kell adnunk, hogy milyen metadata forrásból dolgozzon az SP, az alábbi példában az eduID-ban használatos beállítás látható (a hivatkozott href-metadata-signer-2011.crt fájl a [http://metadata.eduid.hu](http://metadata.eduid.hu) címről töltendő le a shibboleth konfigurációs könyvtárába) :
    
    ```xml
    <MetadataProvider type="XML" uri="http://metadata.eduid.hu/current/href.xml"
        backingFilePath="href.xml" reloadInterval="7200">
        <MetadataFilter type="Signature" certificate="href-metadata-signer-2011.crt"/>
    </MetadataProvider>
    
    ```
- Meg kell adni, hogy az SP mely kulcsot és tanúsítványt használja. Ehhez egy self-signed tanúsítványra lesz szükség, amely pl. az alábbi paranccsal generálható:
    
    ```
      openssl req -new -newkey rsa:2048 -x509 -days 3652 -nodes -out sp.example.org.crt -keyout sp.example.org.key
    
    ```
    
    Az xml-ben módosítandó részlet pedig:
    
    ```
      <CredentialResolver type="File" key="sp.example.org.key" certificate="sp.example.org.crt"/>
    
    ```
- Végül ugorjunk vissza a fájl első felére, szedjük ki a kommentjeleket a `RequestMapper` rész körül, adjuk meg a kezelendő hosztokat és path-okat. Egy Shibboleth SP példány több, az adott webszerver által kezelt hosztot is kezelni tud, és egy-egy hoszton belül több útvonalat is, ezeket itt meg kell adni. Alább egy példa:
    
    ```xml
    <RequestMapper type="Native">
        <RequestMap applicationId="default">
            <Host name="hosztnév" authType="shibboleth" requireSession="false">
                    <Path name="secure" authType="shibboleth" requireSession="true" />
            </Host>
        </RequestMap>
    </RequestMapper>
    
    ```

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

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

```

További részletek az authorizációval kapcsolatban: [https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPhtaccess](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](https://help.edu.hu/books/aai/page/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](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.

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

- [Shibboleth 2 SP telepítése FastCGI alapú webszerver környezetben](https://help.edu.hu/books/aai/page/fastcgi)

# ProviderId

A [föderációban](https://help.edu.hu/books/aai/page/foderacio) résztvevő entitásokat (Identity Provider, Service Provider) **providerId** azonosítja a föderáción belül. Ennek a formája tetszőleges lehet, az egyetlen követelmény, hogy egyértelműen azonosítsa az entitást.

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

- **URL**: [https://idp.niif.hu/shibboleth](https://idp.niif.hu/shibboleth) formában
- **URN**: valamilyen URN hierarchiában, pl. `urn:geant:niif.hu:href:idp:niifi`

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

# 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

<table id="bkmrk-elnevez%C3%A9s-metaadat-a"><thead><tr><th>Elnevezés</th><th>Metaadat aláíró tanúsítvány</th><th>Kivezetés tervezett időpontja</th></tr></thead><tbody><tr><td>HREF-2011</td><td>[href-metadata-signer-2011.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2011.crt)</td><td>2022.01.01.</td></tr><tr><td>HREF-2015</td><td>[mdx-test-signer-2015.crt](https://metadata.eduid.hu/certs/mdx-test-signer-2020.crt)</td><td>2022.01.01.</td></tr><tr><td>HREF-2020</td><td>[href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt)</td><td>2025.06.14.</td></tr></tbody></table>

### SHA1 fingerprints

<table id="bkmrk-elnevez%C3%A9s-sha1-finge"><thead><tr><th>Elnevezés</th><th>SHA1 fingerprint</th></tr></thead><tbody><tr><td>HREF-2011</td><td>`FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66`</td></tr><tr><td>HREF-2015</td><td>`91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43`</td></tr><tr><td>HREF-2020</td><td>`C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61`</td></tr></tbody></table>

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

<table id="bkmrk-domain-technikai-dom"><thead><tr><th>Domain</th><th>Technikai domain</th><th>Kulcs</th><th>Állapot</th></tr></thead><tbody><tr><td>metadata.eduid.hu</td><td>`metadata.eduid.hu/2011/href.xml`</td><td>HREF-2011</td><td>Prod</td></tr><tr><td>metadata.eduid.hu</td><td>`metadata.eduid.hu/2020/href.xml`</td><td>HREF-2020</td><td>Prod</td></tr><tr><td>mdx.eduid.hu</td><td>`mdx-2015.eduid.hu`</td><td>HREF-2015</td><td>Prod</td></tr><tr><td>mdx.eduid.hu</td><td>`mdx-2020.eduid.hu`</td><td>HREF-2020</td><td>Prod</td></tr></tbody></table>

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

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

### XML

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

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

```

### MDX

#### Shibboleth 3.X

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

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

```

#### Shibboleth 2.X

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

```

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

### XML

#### Shibboleth 4.X

[https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider](https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider)

```xml
<MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
                  backingFile="%{idp.home}/metadata/href-2020.xml"
                  metadataURL="https://metadata.eduid.hu/2020/href.xml">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>

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

    <MetadataFilter xsi:type="EntityRoleWhiteList">
        <RetainedRole>md:SPSSODescriptor</RetainedRole>
    </MetadataFilter>

</MetadataProvider>

```

#### Shibboleth 3.X

[https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider](https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider)

```xml
<MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
                  backingFile="%{idp.home}/metadata/href-2020.xml"
                  metadataURL="https://metadata.eduid.hu/2020/href.xml">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>

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

    <MetadataFilter xsi:type="EntityRoleWhiteList">
        <RetainedRole>md:SPSSODescriptor</RetainedRole>
    </MetadataFilter>

</MetadataProvider>

```

### MDX

#### Shibboleth 4.X

[https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider](https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider)

```xml
<MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
                  connectionRequestTimeout="PT2S"
                  connectionTimeout="PT2S"
                  socketTimeout="PT4S">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>

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

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

</MetadataProvider>

```

#### Shibboleth 3.X

[https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider](https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider)

```xml
<MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
                  connectionRequestTimeout="PT2S"
                  connectionTimeout="PT2S"
                  socketTimeout="PT4S">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>

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

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

</MetadataProvider>

```

## SimpleSAMLphp

### MDX

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

```

### metarefresh

[https://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section\_3](https://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_3)

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

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

```

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

```

## FAQ /GYIK

Bővítés alatt!

- Miért cserél KIFÜ kulcsot?
- IdP-t érinti?
- Mi a helyzet az eduGAIN-t használó IdP-kkel?
- Mi a helyzet az eduGAIN-t használó SP-kkel?
- Hogyan tudom ellenőrízni, hogy jó kulcsot használok?

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

```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](http://free.tagish.net/jaas/doc-1.0.3/index.htmlJAAS/JDBC) kódbázisán alapuló) modul beállítását mutatjuk be:

- JAAS/JDBC modul megfelelő verziójának [letöltése](http://software.niif.hu/maven2/hu/niif/jaas-jdbc/)
- jaas-jdbc-VERSION.jar és adatbázis driver jar bemásolása az idp webalkalmazás (idp.war) WEB-INF/lib könyvtárába 
    - a MySQL Connector/J letölthető a [MySQL oldalról](http://dev.mysql.com/downloads/connector/j/)
    - MySQL esetén a mysql-connector-java-{verzio}-bin.jar fájlra van szükségünk
- handler.xml -ben UsernamePassword login handler engedélyezése és RemoteUser login handler tiltása
- login.config ShibUserPassAuth-ban a JDBCLoginModul engedélyezése (a többi JAAS modul legyen kikommentezve!)
- adatbázis kapcsolattal összefüggő beállítások: 
    - "hagyományos" megoldás 
        - **dbDriver**: JDBC Driver osztály neve
        - **dbURL, dbUser, dbPassword**: adatbázis elérési paraméterek
    - JNDI használata esetén 
        - **jndiResourceName**: DataSource API-t támogató JNDI név (bővebben lásd: [Connection pool leírás](https://help.edu.hu/books/aai/page/shib2idpconnectionpool))
- egyéb beállítások 
    - **usersPreparedStatement**: egy olyan lekérdezés, ami a tárolt elhashelt jelszót kérdezi le egy felhasználónévhez (a felhasználónév helyén a ? karakter kell álljon, a lekérdezés egy vagy nulla sort kell visszaadjon!)
    - **passwordHashMethod**: a hasheléshez alkalmazott metódus (a használható metódusakat a [Java Cryptography Architecture dokumentáció](http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html#AppA) írja le).

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

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

```

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

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

- a konténernek támogatnia kell a kliens-tanúsítványokat, azonban a CA ellenőrzés nem követelmény, a felhasználók self-signed tanúsítvánnyal is igénybe vehetik az autentikációs szolgáltatást
- az IdP-nek a kérésből el kell érnie a klienstanúsítványt
- a tanúsítványban szerepelnie kell a felhasználónévnek (mégpedig az `UID` mezőben)

A modul dokumentációja a [ezen az oldalon](https://help.edu.hu/books/aai/page/shibidpx509ldapauthentication) é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:

```xml
   <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ó](https://help.edu.hu/books/aai/page/foderacio)
- [Pont-pont bizalmi kapcsolati modell](https://help.edu.hu/books/aai/page/pont-pont-bizalmi-kapcsolati-modell)
- [Metadata](https://help.edu.hu/books/aai/page/metadata)
- [Föderációs modellek](https://help.edu.hu/books/aai/page/foderacios-modellek)
- [Home Location Service](https://help.edu.hu/books/aai/page/wayf)
- [Shibboleth](https://help.edu.hu/books/aai/page/shibboleth)
- [Hogy kezdjem?](https://help.edu.hu/books/aai/page/aaigettingstarted)

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

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

- Shibboleth IdP: [Telepítés, beállítás](https://help.edu.hu/books/aai/page/shib3idpinstall), [Egyéb leírások](https://help.edu.hu/books/aai/page/shibboleth3-idp), [Shibboleth 2 IdP leírások](https://help.edu.hu/books/aai/page/shibboleth2-idp)
- Shibboleth SP: [Kezdőlépések](https://help.edu.hu/books/aai/page/shibboleth-service-provider-sp), [Egyéb leírások](https://help.edu.hu/books/aai/page/shibboleth2-sp)
- simpleSAMLphp IdP és SP: [Kezdőlépések](https://help.edu.hu/books/aai/page/simplesamlphp), [SimpleSAMLphp 2](https://help.edu.hu/books/aai/page/ssp2)
- [Microsoft Azure AD hitelesítési forrás simpleSAMLphp-ben](https://help.edu.hu/books/aai/page/aai-azureadasauthsource)
- [Melyik IdP-t válasszam?](https://help.edu.hu/books/aai/page/idp-whichone)

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

- [HREF Key Rollover 2020](https://help.edu.hu/books/aai/page/href-key-rollover-2020): Új metaadat aláírókulcs a HREF föderációban
- [HREF Key Rollover 2020 English](https://help.edu.hu/books/aai/page/href-key-rollover-2020-english): New metadata signing certificate
- [HREFContract](https://help.edu.hu/books/aai/page/hrefcontract): A föderációhoz kapcsolódó dokumentációk gyűjtőlapja
- [HREF\_attribútum\_specifikáció](https://help.edu.hu/books/aai/page/href-attributum-specifikacio): A föderációban használható attribútumok specifikációja
- [HREF\_metadata\_specifikáció](https://help.edu.hu/books/aai/page/href-metadata-specifikacio): A föderációban használt metadata specifikációja
- [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry): A föderáció adminisztrációs felületének leírása
- [JoiningEduGAIN](https://help.edu.hu/books/aai/page/joiningedugain): Tudnivalók az eduGAIN csatlakozással kapcsolatban
- [MDX](https://help.edu.hu/books/aai/page/mdx): Igény szerinti metaadat-kiszolgálás
- [Sirtfi](https://help.edu.hu/books/aai/page/sirtfi): Föderációs és föderációközi együttműködéshez kapcsolódó incidenskezelés keretei
- [URN](https://help.edu.hu/books/aai/page/urn): Magyar NREN-nél használt speciális azonosítók tára
- [URN\_SCHAC](https://help.edu.hu/books/aai/page/urn-schac): eduID.hu föderációban használt speciális azonosítók tára

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

- [DiscoveryService](https://help.edu.hu/books/aai/page/shibboleth2-discoveryservice): Shibboleth 2.0 SAML-kompatibilis Discovery Service
- [OpenSSO](https://help.edu.hu/books/aai/page/opensso): Nehézsúlyú Java hozzáférés-szabályozást és federációt megvalósító rendszer
- [OpenID](https://help.edu.hu/books/aai/page/openid): Széles körben támogatott, de nem SAML-alapú federációt megvalósító rendszer
- [GoogleAuth](https://help.edu.hu/books/aai/page/googleauth): Google, mint [OpenID](https://help.edu.hu/books/aai/page/openid) szabványú IdP
- [mod\_mellon](#bkmrk-szolg%C3%A1ltat%C3%A1si-ip-tar): SP megoldás apache modulban. A SAML2 motort a [Lasso](http://lasso.entrouvert.org) valósítja meg. [1](http://docs.feide.no/fs-0050)
- [oiosaml.java](#bkmrk-szolg%C3%A1ltat%C3%A1si-ip-tar): Java SP megoldás, amit a Dán állam is használ. [2](http://www.softwareborsen.dk/projekter/softwarecenter/brugerstyring/oio-saml-java)
- [UApprove](https://help.edu.hu/books/aai/page/uapprove): Shibboleth 2.1.x IdP-hez illeszthető "consent-modul" beállításának leírása
- [Shibboleth troubleshooting](https://help.edu.hu/books/aai/page/shibboleth-troubleshooting): Shibboleth hibaelhárítás
- [Shibboleth Service Provider (SP) és Docker](https://help.edu.hu/books/aai/page/shibboleth-service-provider-sp-es-docker): Shibboleth és Docker összehangolása

## Kiegészítő tudnivalók

- [Szolgáltatási IP tartományok](https://help.edu.hu/books/aai/page/aai-szolgaltatasi-ip)
- [Alkalmazások illesztése](https://help.edu.hu/books/aai/page/alkalmazasok-illesztese): Néhány alkalmazás Shibboleth-illesztésének leírása
- [Interoperabilitás mátrix](https://help.edu.hu/books/aai/page/interoperabilitas-matrix): Shibboleth, OpenSSO, simpleSAMLphp együttműködési mátrix
- [Eszközök](https://help.edu.hu/books/aai/page/eszkozok): Hasznos eszközök föderációk üzemeltetéséhez, használatához
- [Intézmény átnevezés](https://help.edu.hu/books/aai/page/intezmeny-atnevezes): megfontolandó szempontok
- [Tanúsítványok a föderációban](https://help.edu.hu/books/aai/page/tanusitvanyok-a-foderacioban)
- [Test HEXAA (or any SAML AA) from command line](https://help.edu.hu/books/aai/page/aa-testing)
- [Hogyan teszteljünk eduID IdP-t vagy SP-t?](https://help.edu.hu/books/aai/page/eduidtest)
- [Erasmus+ és ESI információk](https://help.edu.hu/books/aai/page/erasmusplus-esi)
- [Publikációk](https://help.edu.hu/books/aai/page/publikaciok)
- [Azure AD használata azonosítási forrásként](https://help.edu.hu/books/aai/page/aai-azureadasauthsource)

# 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](http://weblabor.hu/cikkek/phpfastcgimodban)

## 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 <a href="http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz">http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz</a>
tar -xf <a href="http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz">http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz</a>
```

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

```

wget <a href="http://redmine.lighttpd.net/attachments/download/91/fastcgi-authorizer-fixes.diff">http://redmine.lighttpd.net/attachments/download/91/fastcgi-authorizer-fixes.diff</a>
```

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.

```c
                            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](http://redmine.lighttpd.net/projects/lighttpd/wiki/InstallFromSource))

```
./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 <a href="http://ftp.de.debian.org/debian/pool/main/s/shibboleth-sp2/shibboleth-sp2_2.0.dfsg1-4.dsc">http://ftp.de.debian.org/debian/pool/main/s/shibboleth-sp2/shibboleth-sp2_2.0.dfsg1-4.dsc</a>
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](https://help.edu.hu/books/aai/page/shib2sp) beállítás után - a rendszernek további beállítások nélkül működnie kellene. Ám **kizárólag statikus tartalmat tud rendeltetésszerűen kiszolgálni, dinamikusat nem**.

### A HIBAJELENSÉG

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

# Lazy_Session

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

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

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

- az alkalmazásnak tudnia kell, hogy mikor van érvényes Shibboleth session
- az alkalmazás felhasználói interfészén el kell helyezni egy olyan elemet (linket), melynek segítségével a session létrehozható
- magyarul: *csak Shibboleth-et "beszélő" alkalmazások védhetők lazy session-nel*.

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

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

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

### Session létrehozás

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

- metódus: `http://` vagy `https://`
- hostnév
- Shibboleth SP modul elérhetősége (általában: `/Shibboleth.sso`)
- [SessionInitiator](#bkmrk-a-_server-t%C3%B6mb-eleme) "location"-je, pl. `/WAYF/HREF`
    - <small>Milyen jó is lenne, ha a default session initiator akkor is menne, ha nem adunk meg location-t. De sajnos jelenleg nem ez a helyzet.</small>
- `?target=` + az az URL, amelyre a Shibboleth session létrehozás után szeretnénk, hogy a felhasználónk kerüljön. Általában az éppen aktuális Request URI-t szoktuk használni.

Példa URL:

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

```

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

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

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

- a Shibbleth webszerver modul (mod\_shib) be van töltve ÉS
- az adott Directoryra vagy Location-re be van konfigurálva, hogy hallgasson

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

# Föderációs_modellek

- [SAML](https://help.edu.hu/books/aai/page/saml)
- [Liberty Alliance](#bkmrk-saml-liberty-allianc)
- [WS-Federation](#bkmrk-saml-liberty-allianc)
- [OpenID](#bkmrk-saml-liberty-allianc)
- [Ügyfélkapu](#bkmrk-saml-liberty-allianc)
- [.NET Passport](#bkmrk-saml-liberty-allianc)
- [Moira](#bkmrk-saml-liberty-allianc)
- [PAPI](#bkmrk-saml-liberty-allianc)
- [EduGAIN](#bkmrk-saml-liberty-allianc)
- [EduROAM](#bkmrk-saml-liberty-allianc)

# ShibAndEdugain

## Loading metadata

Metadata downloaded from [https://mds.edugain.org](https://mds.edugain.org)

**Strange things**

- Metadata is not signed by a third party
- Line breaks and indentation is quite by chance, however running through `xml_pp` of course invalidates the signature of the individual `<EntityDescriptor>`s
- Metadata cannot be validated to the schema (see later)

### Problems loading metadata to Shibboleth SP

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

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

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

```

Explanation follows:

#### Unable to connect

For some reason, Shibboleth 2.0 cannot connect to [https://mds.edugain.org](https://mds.edugain.org). It seems to be a `libcurl` issue, which is not easy to circumvent. ([See this shib-users thread](http://groups.google.com/group/shibboleth-users/browse_thread/thread/db6993fbaa3bd6ec#)) 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](https://help.edu.hu/books/aai/page/attributum-feloldas)

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

```sql
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:

```xml
<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](https://help.edu.hu/books/aai/page/shib2idpconnectionpool) hasznos lehet.

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

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

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

- [OpenOffice formátum](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/Hbone2007_shib.odp)
- [PDF formátum](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/Hbone2007_shib.pdf)

# ArpFilterProposal

## ArpFilter before the profile servlet - support for other authentication modules

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

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

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

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

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

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

The code logic is the following:

- Ensure that the request is made to the profile servlet.
- Try to get LoginContext from session. 
    - If LoginContext is found in the session, transfer it back to the request scope and remove it from the session.
- Try to get LoginContext from request scope. 
    - If no LoginContext found, proceed to the profile servlet and exit.
    - Else process the request as usual, and find username in the IdP session.
- In the case when ArpFilter decides to hand over the control to the ArpViewer application, save the LoginContext back to Session.

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

# Shib3IdpInstall

Az alábbiakban a [Shibboleth 3 Identity Provider](http://shibboleth.net/products/identity-provider.html) 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](http://www.eclipse.org/jetty/) alkalmazáskonténerbe.

## Előkészületek

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

- `entityID` (URI) 
    - z entityID az a SAML azonosító, mely egyedi névvel látja el az IdP-t. Az első lépések egyike telepítéskor a megfelelő és gondos kiválasztása. Föderáción belül és világszinten egyedi kell legyen az ütközések elkerülése érdekében.
    - avasolt forma: **`https://idp.intezmenyneve.hu/idp/shibboleth`**.
    - gépnév rész legyen bejegyzett DNS név.
    - e tartalmazzon portszámot, lekérdezést, részazonosítót.
- `DNS`
    - Az entityID megtalálása után szükséges az IdP nevének DNS-be jegyzése.
    - avasolt forma: **`idp.intezmenyneve.hu`**.

!!! warning

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

```

- `Tűzfal`
    - Szükséges nyitott portok a *TCP/443* és *TCP/8443*.
- `Operációs rendszer és Java futtató-környezet`
    - A jelen telepítési leírás Debian 8 (Jessie) rendszerhez készült.
    - Java telepítése
    - `apt-get install default-jdk`

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

Letöltés: [http://download.eclipse.org/jetty/](http://download.eclipse.org/jetty/)

Telepítés menete.

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

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

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

```xml
<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/](http://shibboleth.net/downloads/identity-provider/latest/)

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

```bash
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](https://idp.intezmenyneve.hu:8443/idp) URL-en rövid tájékoztatást kell kapnunk *No services are available at this location.* szöveggel.

# HREFChecklist

# Előzetes ellenőrzés

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

- Adatkezelés
    
    
    - Van-e adatkezelési szabályzat?
    - A felhasználókról szóló, intézmény által ismert adatok forrása, karbantartásának módja dokumentált-e? (**TAG**)
    - Elérhetők-e a fenti dokumentumok? A hivatkozásnak a metadata állományban kell szerepelnie.
    - Ezek megfelelnek-e a [Föderációs alapelvek](https://help.edu.hu/books/aai/page/href-alapelvek-es-alapveto-szabalyok)-ben foglaltaknak?
- Műszaki követelmények
    
    
    - Az intézmény teljesíti-e a Műszaki előírásokat leírtakat? ( [Műszaki előírások IdP-k számára](https://docs.google.com/document/d/1XkFqQx9npWVgftAU1b0cRoqiTNrhj9oqEWpMWaIJO6o/edit?hl=en_US), [Műszaki előírások SP-k számára](https://docs.google.com/document/d/1QZWwFqHm4VNyIn6GdKnOzyA0Xdg2uYgwlAkJA1ffpM8/edit?hl=en_US))
    - Van-e kijelölt ember, aki a föderációs ügyekért felelős, technikailag be tud avatkozni (be tud-e lépni a Resource Registry-be és a saját IdP-jét adminisztrálni is tudja)?
    - Van-e jól beállított naplózási mechanizmus?
    - Megfelelőek-e az entitás által használt kulcsok?
    - Megfelelőek-e az entitás által támogatott SAML-profilok?
    - Az attribútumspecifikációnak megfelelő-e az attribútumok használata?
    - Ajánlásoktól eltéréseket dokumentálni
- Egyéb
    
    
    - Hány felhasználót tud az IdP azonosítani?
    - Elvárt, hogy az entitás technikai kapcsolattartója iratkozzon fel a [href-tech](https://listserv.niif.hu/mailman/listinfo/href-tech) levelezőlistára, az entitás adminisztratív kapcsolattartója pedig a [href-admin](https://listserv.niif.hu/mailman/listinfo/href-admin) levelezőlistára.

# Shibenv

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

- [PHP implementáció](https://help.edu.hu/books/aai/page/shibenv-php)
- [JSP (Java Server Pages) implementáció](https://help.edu.hu/books/aai/page/shibenv-jsp)
- [Lazy Session-t használó PHP implementáció](https://help.edu.hu/books/aai/page/shibenv-php-lazy) (saját kiterjesztés)

# SimpleSAMLphp

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

## Telepítés

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

### Előkészületek

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

- PHP futtatására alkalmas webszerver
- PHP környezet (&gt;=5.4)
- A következő PHP kiterjesztéseket engedélyezni kell 
    - `date`, `dom`, `hash`, `libxml`, `openssl`, `pcre`, `SPL`, `zlib`
    - LDAP-ból történő autentikáció esetén: `ldap`
    - Adatbázisból történő autentikáció esetén a megfelelő adatbázis-csatolót `mysql`, `pgsql`
    - RADIUS szerveren keresztül történő autentikáció esetén: `radius`
    - Assertion-ök titkosítása esetén: `mcrypt`
    - Memcache használata esetén: `memcache`
    - HEXAA integrációhoz (SP): `soap`

#### Debian 9 / Ubuntu 16.04 LTS csomagok

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

```

#### RHEL / CentOS 7 csomagok

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

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

```

#### Composer

A **[composer](https://getcomposer.org)** 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](https://simplesamlphp.org/download) oldalról tudhatjuk meg.

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

```

### Apache konfigurálás

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

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

```

### Alapbeállítások

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

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

- **config.php** másolása a **config-templates** mappából cp config-templates/config.php config/
- **authsources.php** másolása a **config-templates** mappából cp config-templates/authsources.php config/

<span style="color:green">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](https://example.org/simplesaml) oldalon.</span>

#### Konfigurációs fájlok szerkesztése

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

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

- **Az "admin" felhasználó jelszavát, mellyel webes felületen keresztül be tud lépni a települő SSP-be.**
    
    'auth.adminpassword' =&gt; 'ujjelszotirdide',
- **Titkosítási feladatokhoz szükséges "salt", azaz véletlenszerűen összeálló karaktersorozat**
    
    ```
      'secretsalt' => 'randombytesinsertedhere',
    
    ```
    
    A karaktersorozat előállításában segíthet az alábbi parancs:
    
    ```
      tr -c -d '0123456789abcdefghijklmnopqrstuvwxyz' </dev/urandom | dd bs=32 count=1 2>/dev/null;echo
    
    ```
- **Elérhetőségeket, amely adatok bekerülnek majd a generált metaadatba**
    
    ```
      'technicalcontact_name'     => 'Gipsz Jakab',
      'technicalcontact_email'    => 'jakab.gipsz@example.org',
    
    ```
- **Nyelv és időzóna adatok**
    
    ```
      'language.default'      => 'hu',
      'timezone' => 'Europe/Budapest',
    
    ```

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

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

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

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

- **log** mappa létrehozása és jogosultság beállítása
    
    ```
      sudo mkdir log; sudo chown www-data:adm log; sudo chmod 755 log
    
    ```
- Naplózási szint beállítása a **config/config.php**-ban
    
    ```
      'debug' => array(
          'saml' => true,
          'backtraces' => true,
          'validatexml' => false,
      ),
      'logging.level' => SimpleSAML\Logger::DEBUG,
      'logging.handler' => 'file',
    
    ```

<span style="color:red">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.</span>

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

<span style="color:red">Nem ajánlott a SimpleSAMLphp-hoz és webszerverhez ugyanazt a tanúsítvány használni!</span>

- A SimpleSAMLphp alapértelmezetten a tanúsítványt a **cert** mappában keresi.
    
    ```
      mkdir cert
    
    ```
- Az alábbi paranccsal egy 10 éves [self-signed tanúsítvány](https://help.edu.hu/books/aai/page/tanusitvanyok-a-foderacioban) generálunk a SimpleSMALphp számára.
    
    ```
      openssl req -new -newkey rsa:2048 -x509 -days 3652 -nodes -out cert/saml-example-org.crt -keyout cert/saml-example-org.key
    
    ```

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

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

```

### Telepítés kész

Amennyiben elkészültünk a fenti lépésekkel, úgy a [https://service.example.org/simplesaml/](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.

```php
'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.

```php

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

```php

 'default-sp' => array(
        'saml:SP',

        // The entity ID of this SP.
        // Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
        'entityID' => NULL,

        // The entity ID of the IdP this should SP should contact.
        // Can be NULL/unset, in which case the user will be shown a list of available IdPs.
        'idp' => NULL,

        // The URL to the discovery service.
        // Can be NULL/unset, in which case a builtin discovery service will be used.
        'discoURL' => NULL,

        'privatekey' => 'saml-example-org.key',
        'certificate' => 'saml-example-org.crt',

 ),

```

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

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

#### Metadata

#### Metadata fájlok

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

- **SP** oldalon lennie kell egy **metadata/saml20-idp-remote.php** fájlnak. Ez a fájl tartalmazza az IdP eléréséhez szükséges adatokat.
    
    ```
      cp metadata-templates/saml20-idp-remote.php metadata
    
    ```
- **IdP** oldalon lennie kell egy **metadata/saml20-sp-remote.php** fájlnak. Ez a fájl tartalmazza az SP eléréséhez szükséges adatokat.
    
    ```
      cp metadata-templates/saml20-sp-remote.php metadata
    
    ```

#### Metadata letöltés

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

#### SP metadata beállítás IdP oldalon

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

- Magyar nyelv esetén: "Föderáció" fül / "SAML 2.0 SP Metaadatok" pont alatt a "Mutasd a metaadatokat" linkre kattintva juthatunk el a fenti menüponthoz.
- Angol nyelv esetén: "Federation" fül / "SAML 2.0 SP Metadata" pont alatt a "Show metadata" linkre kattintva juthatunk el a fenti menüponthoz.

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

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

```

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

#### IdP metadata beállítás SP oldalon

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

- Magyar nyelv esetén: "Föderáció" fül / "SAML 2.0 IdP Metaadatok" pont alatt a "Mutasd a metaadatokat" linkre kattintva juthatunk el a fenti menüponthoz.
- Angol nyelv esetén: "Federation" fül / "SAML 2.0 IdP Metadata" pont alatt a "Show metadata" linkre kattintva juthatunk el a fenti menüponthoz.

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

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

```

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

### Tesztelés

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

SP oldalon nyissuk meg a **simplesaml** kezdőlapot:

- Magyar nyelv esetén: "Azonosítás (autentikáció)" fül / "Azonosítási (autentikációs) beállítások tesztelése" link / "default-sp" link-re kattintva tudjuk tesztelni az IdP - SP kapcsolatot.
- Angol nyelv esetén: "Authentication" fül / "Test configured authentication sources" link / "default-sp" link-re kattintva tudjuk tesztelni az IdP - SP kapcsolatot.

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

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

## HREF-integráció

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

Javasolt [dinamikus metaadatforrást (MDX)](https://help.edu.hu/books/aai/page/mdx) használni, opcionálisan kiegészítve statikus állományokkal. Részletes leírás itt: [SimpleSAMLMixedMetadata](https://help.edu.hu/books/aai/page/simplesamlmixedmetadata)

### IdP

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

- (Az adminisztratív teendőktől itt most eltekintünk, a csatlakozás folyamata [itt van leírva](https://help.edu.hu/books/aai/page/hrefjoin))
- Kell küldeni egy levelet a info@eduid.hu címre, benne néhány mondat mellett az IdP metaadatának URL-jével ([https://example.org/simplesamlphp/saml2/idp/metadata.php](https://example.org/simplesamlphp/saml2/idp/metadata.php))
- Ha minden rendben megy, akkor az IdP bekerül a [Resource\_Registry](https://help.edu.hu/books/aai/page/resource-registry)-be, ezáltal a föderációs metaadatba is.
- Az előző pontban leírt módon be kell állítani a központi metadata feldolgozását.
- Amennyiben a föderációs metaadatban már szerepel a mi IdP-nk is, úgy a föderáció valamelyik, tesztelési célokat szolgáló SP-jénél ki is próbálhatjuk a bejelentkezést.
- **Fontos**, hogy a föderációs Discovery Service óránként generálja újra az IdP-k listáját, így ennyi idő mindenképp szükséges, hogy az új IdP megjelenjen itt, az egyes SP-k pedig két óránként töltik újra a metaadatot, így előfordulhat, hogy azonnal nem fog minden működni, de néhány óra alatt várhatóan beindul. :)
- Tesztelésre használható oldal: [https://attributes.eduid.hu](https://attributes.eduid.hu)
- Ahhoz, hogy a Resource Registry-be is be tudjunk lépni és az IdP további, a föderációra vonatkozó beállításait meg tudjuk ejteni, ehhez az IdP-nek ki kell adnia az alábbi attribútumokat:
    
    
    - [mail](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) - ez belépés után, manuálisan is beállítható
    - [eduPersonPrincipalName](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
    - <del>[schacHomeOrganizationType](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)</del> (az attribútumot hamarosan kivezetjük a kötelező attribútumok közül)
    - [eduPersonScopedAffiliation](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)

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

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

```

- További tudnivalók a [Resource Registry-ről](https://help.edu.hu/books/aai/page/resource-registry), ill. a [Föderációs attribútum specifikációról](https://help.edu.hu/books/aai/page/href-attributum-specifikacio).
- Ha minden rendben ment, akkor a Resource Registry-ben regisztrált IdP-hez tartozó adminisztrációs jogok átkerülnek az IdP technikai gazdájához, s ezzel a folyamat kész is.

### SP

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

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

#### Attribútum scopeok használata

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

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](https://github.com/NIIF/simplesamlphp-module-attributescope), 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](https://github.com/NIIF/simplesamlphp-module-attributescope)

- Az `attributescope` modul használata esetén a következőképp kell módosítani a `config/config.php` fájlt:

```php

 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](http://www.eduid.hu)

Date of last change: 20110907

## Common Practices

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

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

## Practices on Identity Provider Registration

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

- a completed membership service agreement signed by official representative(s) of the newly participating institution
- elements and attributes to be registered must use a domain name of that institution

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

## Practices on Service Provider Registration

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

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

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

## Additional Rules for Federation Partner Service Providers

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

## Practices regarding metadata modifications

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

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

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

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

---

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

# Shib2SPSourceInstall

## Függőségek

## Fordítás

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

### log4shib vs. log4cpp

!!! danger "Figyelem"

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

```

### XML-Security C

Ez a csomag igazából része általában a disztribúcióknak, de a Shibboleth 2-nek (és az OpenSAML-nak) &gt;=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.

```bash
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](https://help.edu.hu/books/aai/page/xmltooling-log4cpp-patch).

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

```

### opensaml

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

```

### Shibboleth SP

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

```

# ShibIdPX509LdapAuthentication

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

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

## In English

### Motivations

- The use of hardware tokens as authentication source. However, X.509 certificate authentication is not generally considered secure by nature, hardware tokens are designed to be safer than passwords. Local policy can decide whether they accept software tokens or not.
- Give the choice to our SPs. Some SPs can decide if they wanted to force the X.509 authentication (or force password authentication).

### PKIful versus PKIless

- If one has built their full-fledged PKI infrastructure, one could use it for client certificate authentication.
- But it is hard to do PKI right, CRLs and/or OCSP are crucial in PKI.
- If only authentication is needed, storing the (self-signed) certificate is enough.

### Shibboleth X.509 authentication

- With PKI, you would use simple RemoteUser authentication with container support.
- Without PKI, the container can not authenticate the user, it can only check if the user has the corresponding private key.
- You will also need some custom workflow to validate the presented client certificates. Eg. checking them against the directory attribute 'userCertificate'. This is step is a must to have control over certificate revocation.

### X.509 + LDAP certificate authentication (implementation details)

- The web container does client certificate checking, but does not validate. Instead, it handles the certificate to the Shibboleth authentication module which will validate it.
- Shibboleth is configured with RemoteUser login handler pointing to our X.509 authentication servlet.
- The certificate must contain some identification data (eg the X.500 'UID' RDN). Our authentication servlet takes the presented certificate and compares it to the stored certificate(s) for the user. If a matching certificate is found in the directory, then the user is authenticated.
- The certificate authentication is implemented as a standard JAAS module, and can be reused elsewhere.

### Combining X.509 and username/password authentication

- When SP does not specifically request authentication methods, the user should have the choice between supported authentication modes. Otherwise, the IdP must conform with the authentication context class the SP sent. The IdP must refuse to authenticate the user with authentication methods unacceptable to the SP. There is a support ticket named SIDP-258 about this flaw in Shibboleth IdP.
- We want to support two authentication methods: username/password (PasswordProtectedTransport) and X.509 authentication.
- Unfortunately this is not enough, we need a default authentication method which offers the choice of these two methods to our users. This can be done by placing a link to the X.509 authentication servlet in login.jsp. However when the SP requests PasswordProtectedTransport, this link must not be visible, so we decided to configure a new UserPassword login handler which maps to the unspecified authentication class and uses this tweaked login.jsp.
- We also want to send the actual authentication method to the SP (instead of saying 'unspecified'), so both login handlers must set their corresponding authentication class in the Shibboleth request. As the internal UsernamePassword login servlet does not do this, we subclassed it.
- Playing with Shibboleth login handlers and authentication contexts revealed that Shibboleth IdP can not properly support default authentication methods, and our hybrid handler with its 'unspecified' authentication method is invoked on every authentication request (because both actual methods it uses override this unspecified method in the request and IdP can not decide whether the unspecified class is requested by the SP or it is simply the default method configured in relying-party.xml). Fixing SIDP-265 with our proposed patch corrected this behavior.

## Követelmények

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

- a felhasználók saját maguk által aláírt tanúsítványokat is használhassanak autentikációra
- ne kelljen PKI infrastruktúrát üzemeltetni a klienstanúsítványok használatához
- a tanúsítványok központilag menedzseltek, egyszerűen visszavonhatók legyenek

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

!!! info

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

```

## Telepítés

Az autentikációs modul letölthető a [http://software.niif.hu](http://software.niif.hu) oldalról. A Shibboleth2 IdP autentikációs motorjának konfigurációját részetesen a [Shibboleth2 User Authentication](https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUserAuthn) 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:

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

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

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

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

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

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

```xml
...
<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](https://help.edu.hu/books/aai/page/shib2idpinstall), ezen az oldalon az OpenSUSE alatt történő azon beállításokat részletezzük, amelyek eltérnek a Debianban megszokottól.

## Szükséges csomagok

- apache2
- tomcat6
- java-1\_6\_0-sun

## Apache beállítása

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

```

További információk: [Shib2IdpInstall#apache-beállítás](https://help.edu.hu/books/aai/page/shib2idpinstall)

## 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](https://help.edu.hu/books/aai/page/shib2idpinstall)

# MediaWikiShibboleth

- Shibboleth Authentication Extension: [http://www.mediawiki.org/wiki/Extension:Shibboleth\_Authentication](http://www.mediawiki.org/wiki/Extension:Shibboleth_Authentication)
- Shibboleth Authentication Plus Extension: [http://www.mediawiki.org/wiki/Extension:Shibboleth\_Authentication\_Plus](http://www.mediawiki.org/wiki/Extension:Shibboleth_Authentication_Plus)

# Attribútum_feloldás

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

Fontos megjegyezni, hogy az attribútumok csak akkor adódnak át az SP-knek, ha ez az [Attribute Release Policy](https://help.edu.hu/books/aai/page/attributum-kiadas)-ban engedélyezve van. Természetesen fel nem oldott attribútumokat nem lehet átadni.

Az attribútum feloldást az [IdP konfiguráció](https://help.edu.hu/books/aai/page/shibboleth-idp-konfiguracioja) `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ó

```xml
<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](#bkmrk-https%3A%2F%2Fspaces.inter) 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:

```xml
<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](https://spaces.internet2.edu/display/SHIB/JNDIDataConnector)!)**

- *`Search@filter`*: az az LDAP filter, amely alapján a REMOTE\_USER értékéből megkereshető a felhasználó LDAP entry-je. Ha összetett szűrő szabályt kell mondani, akkor a **&amp;** jelet **&amp;amp;**-vel kell eszképelni.
- *`Search/Controls@searchScope`*: az LDAP lekérdezés scope-ja. Lehetséges értékek: 
    - ONELEVEL\_SCOPE
    - OBJECT\_SCOPE (base)
    - SUBTREE\_SCOPE
- *`java.naming.provider.url` property*: LDAP URL, amely a search base DN-jét is tartalmazza
- *`java.naming.provider.protocol` property*: itt lehet megadni, hogy SSL-t használjon-e az LDAP kapcsolat kiépítésekor. Ha nem akarunk SSL-t használni, akkor ezt a property-t ne adjuk meg! Lásd még: [LDAP kliens SSL](https://help.edu.hu/books/ldap-l5f/page/ldap-kliens-ssl)
- *`java.naming.security.principal` property*: az a DN, amellyel a Shibboleth alkalmazás bind-ol az LDAP szerverhez.
- *`java.naming.security.credentials` property*: az előző DN-hez tartozó jelszó

### JDBCDataConnector

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

```xml
<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](https://spaces.internet2.edu/display/SHIB/JDBCDataConnector)!

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

```xml
<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](https://spaces.internet2.edu/display/SHIB/StaticDataConnector)!

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

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

- **DataConnectorDependency**: az attribútum értéke egy már definiált adatforrásból származik.
- **AttributeDependency**: az attribútum értéke egy másik (feloldott) attribútum értékéből származik

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

### SimpleAttributeDefinition

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

- *id*: ezzel lehet rá függőségekben hivatkozni, ill. az attribútum forrásának megállapításához is felhasználható. Az [Assertion](#bkmrk-https%3A%2F%2Fspaces.inter)-ben ennek az értéke szerepel attribútum névként.
- *sourceName*: ezzel lehet explicit módon meghatározni a forrás nevét
- *smartScope*: ha az érték nem scope-olt (azaz nem `valami@valahol` formátumú), akkor az attribútum scope-ja a `smartScope` lesz, ellenkező esetben a scope értéke a "@ utáni rész" lesz (pl.: `valahol`). 
    - <small>(Leegyszerűsítve) egy [Assertion](#bkmrk-https%3A%2F%2Fspaces.inter)-ben egy attribútum így adható meg: attribútum név + scope + érték(ek)</small>
- *allowEmpty*: ez a boolean paraméter adja meg, hogy az üres érték elfogadható-e. Alapértelmezett értéke `false`, azaz ha nincs érték, akkor az [Assertion](#bkmrk-https%3A%2F%2Fspaces.inter)-be nem kerül bele az attribútum. Ha `true`, akkor érték nélkül kerül bele.

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

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.

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

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

```xml
<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](https://spaces.internet2.edu/display/SHIB/SimpleAttributeDefinition)!

### CompositeAttributeDefinition

**TODO**, lásd: [https://spaces.internet2.edu/display/SHIB/CompositeAttributeDefinition](https://spaces.internet2.edu/display/SHIB/CompositeAttributeDefinition)

### RegExpAttributeDefinition

**TODO**, lásd: [https://spaces.internet2.edu/display/SHIB/RegExpAttributeDefinition](https://spaces.internet2.edu/display/SHIB/RegExpAttributeDefinition)

### ScriptletAttributeDefinition

**TODO**, lásd: [https://spaces.internet2.edu/display/SHIB/ScriptletAttributeDefinition](https://spaces.internet2.edu/display/SHIB/ScriptletAttributeDefinition)

### SAML2PersistentID

**TODO**, lásd: [https://spaces.internet2.edu/display/SHIB/SAML2PersistentIDAttributeDefinition](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`

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

<Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           AttributeName="urn:mace:dir:attribute-def:uid"
           AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
    <AttributeValue>bajnokk</AttributeValue>
</Attribute>

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

```

## Forrás

- [https://spaces.internet2.edu/display/SHIB/NewIdPAttribute](https://spaces.internet2.edu/display/SHIB/NewIdPAttribute)
- [https://spaces.internet2.edu/display/SHIB/IdPAttributeConfig](https://spaces.internet2.edu/display/SHIB/IdPAttributeConfig)

# SimpleSAMLphp_proxy_vidyo_portálhoz

# Vidyo Portal Authentication Proxy

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

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

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

## simpleSAMLphp telepítése

A simplesamlphp telepítését elvégezzük a [dokumentáció](https://simplesamlphp.org/docs/stable/simplesamlphp-install) szerint.

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

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

*config/config.php*

```
'enable.saml20-idp' => true,

```

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

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

```

*metadata/saml20-idp-hosted.php*

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

```

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

```
metadata/vidyo-sp.xml

```

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

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

```

### Vidyo admin portál

A portálon be kell állítani,

- hogy az azonosítás SAML alapú legyen, *Authentication Type*
- fel kell tölteni az IdP metaadatát, ezt az ssp telepítés *saml2/idp/metadata.php* oldaláról tölthetjük le. *Identity Provider (IdP) Metadata XML*
- be kell állítani az auto provisioninget, *SAML provision type*

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

![VidyoAdmin1.png](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/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](https://github.com/simplesamlphp/simplesamlphp/blob/master/attributemap/name2oid.php)

![VidyoAdmin2.png](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/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](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:

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

```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 -&gt; Import Entity parancsával tudjuk importálni a megfelelő Realm-be. Importálás után a Circle of Trust konfigurációhoz is hozzá kell adni a SimpleSAMLphp SP-t.

## Problémák

Nincsenek :)

# Shib2IdpInstall

## Előkészületek

### entityID

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

### Tűzfal

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

## JDK

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

```
aptitude install sun-java6-jdk

```

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

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

```

!!! danger "Figyelem"

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

```

### Shibboleth security provider

!!! info

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

```

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

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

```

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

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

- **Megj.:** a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!

### Bouncy Castle JCE

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

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

```

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

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

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

```

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

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

- **Megj.:** a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!

## Tomcat 6

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

A Tomcat6-ra való frissítésről további - vázlatos - információkkal ez az [oldal szolgál](https://help.edu.hu/books/aai/page/tomcat55-to-tomcat6).

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

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

```xml
<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](#bkmrk-shibboleth-2x-idp-servlet-telep%C3%ADt%C3%A9s) 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](https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare)

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

```apache
 <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ó.

```

```apache
 <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](http://shibboleth.internet2.edu/downloads/shibboleth/idp/latest/)

Alternatívaként az NIIF által patchelt, ezáltal SLO képes IdP kiadást ajánljuk, ami a [NIIF AAI oldalról](http://software.niif.hu) érhető el. A Single Logout-képes IdP-ről további [információ itt](https://help.edu.hu/books/aai/page/single-logout-in-shibboleth-idp).

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

- <small>A Debian alatti tomcat6 csomag használatakor a `/usr/share/tomcat6/common/endorsed` könyvtárba kell tenni a jar file-okat (ezt a könyvtárt létre is kell hozni).</small>
    
    mkdir /usr/share/tomcat6/endorsed cp endorsed/\*.jar /usr/share/tomcat6/endorsed/

### Installer

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

```

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

> Is this a new installation? Answering yes will overwrite your current configurat ion. \[yes|no\] <font color="#DF0000">yes</font>

Új telepítés, vagy sem.

> Where should the Shibboleth Identity Provider software be installed? [/ opt/shibboleth-idp-2.0.0](default:)<font color="#DF0000">/usr/local/shobboleth-idp</font>

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

> What is the hostname of the Shibboleth Identity Provider server? [idp.example.org](default:)<font color="#DF0000">idp.example.org</font>

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. <font color="#DF0000">changeme</font>

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:

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

```

### Naplófájlok rotálása

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

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

```xml
 <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](http://jira.qos.ch/browse/LBCORE-147), 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](https://help.edu.hu/books/aai/page/shib2idpattrib) és [kiadását](https://help.edu.hu/books/aai/page/shib2idparp).

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

- `/var/log/shibboleth/idp-error.log`
- `/var/log/shibboleth/idp-process.log`

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

## Shibboleth 2.0 IdP beállítás

### Metadata beállítása

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

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

```xml
	<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](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:

- [http://metadata.eduid.hu/current/href.xml](http://metadata.eduid.hu/current/href.xml)

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

```xml
	<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](https://help.edu.hu/books/aai/page/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](https://help.edu.hu/books/aai/page/resource-registry)

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

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

```xml
	<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](https://help.edu.hu/books/aai/page/eduidfedstats)**

### [Autentikáció beállítása](https://help.edu.hu/books/aai/page/shib2idpauth)

### [Attribútum feloldás beállítása](https://help.edu.hu/books/aai/page/shib2idpattrib)

### [Attribútum kiadás beállítása](https://help.edu.hu/books/aai/page/shib2idparp)

# HREFServices

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

### Tagi Szolgáltatások

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

- **Azonosító Szolgáltatás (Identity Provider, [IdP](https://help.edu.hu/books/aai/page/hrefglossary))**: a tag felhasználóinak azonosítását végző szolgáltatás. Az Azonosító Szolgáltatás szabványos protokollon elérhető a Tartalomszolgáltatások számára.
- **Tartalomszolgáltatás (Service Provider, [SP](https://help.edu.hu/books/aai/page/hrefglossary))**: a Föderáció Tagjainak felhasználói számára nyújtott szolgáltatások vagy elérhetővé tett erőforrások.
- **Attribútum Szolgáltatás (Attribute Authority, AA)**: bizonyos felhasználói adatok Tartalomszolgáltatók általi lekérdezését speciális esetekben (pl. virtuális szervezet, VO) lehetővé tevő szolgáltatás.

### Partner Szolgáltatások

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

- **Tartalomszolgáltatás (Service Provider, [SP](https://help.edu.hu/books/aai/page/hrefglossary))**: a Föderáció Tagjainak felhasználói számára nyújtott szolgáltatások vagy elérhetővé tett erőforrások.

# Attribute_Conversion_for_eduGAIN

JRA5 Attribute Conversion allows a Bridging Element administrator to define rules to transform attributes being released or received. The same logic can work in both Home and Remote Bridging Elements.

## Introduction

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

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

Attribute Conversion only adds attributes (or values) to the attribute set; use [Attribute Filtering](https://help.edu.hu/books/aai/page/attribute-conversion-for-edugain) for filtering out unnecessary attributes. It also means that if no rules match an attribute, then it will go to the filter unmodified - so conversion works with a **default by-pass policy**.

## Attribute conversion rule concepts

Most of the rules are based on standard [regular expressions](http://en.wikipedia.org/wiki/Regular_expression) and [Unified Expression Language](http://en.wikipedia.org/wiki/Unified_Expression_Language).

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

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

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

- local federation peer's identifier (LocalProviderMatch)
- remote federation peer's identifier (RemoteProviderMatch)
- attribute values (AttributeMatch)

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

## Attribute conversion rule types

### BasicRule

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

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

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

```

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

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

```

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

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

```

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

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

```

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

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

```

You can also use regular expressions, as with **BasicRule**.

### SplitRule

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

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

```

### CustomRule

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

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

```

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

### Negating matches

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

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

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

```

## Using attribute name mapper

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

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

### Attribute name mapper concepts

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

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

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

### Configuration of the attribute name mapper

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

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

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

```

### Using logical attribute names

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

### Using SAML1.1 Namespaces

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

## Attribute Filtering

### Concepts

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

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

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

### Allowing and denying attributes

Three main rules of the filtering:

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

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

!!! 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
<?xml version="1.0" encoding="UTF-8"?>
<AttributeFilter  xmlns='urn:geant:edugain:attribute-mangling:1.0'
   xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
   xsi:schemaLocation='urn:geant:edugain:attribute-mangling:1.0 AttributeMangling.xsd'>

   <FilterRule>
       <Description>Unconditional allowing and denying. The main rule is to deny ALL attributes.</Description>
       <AllowAttribute attributeName="mail" />
       <AllowAttribute attributeName="cn" />
       <AllowAttribute attributeName="eppn" />
       <DenyAttribute attributeName="userPassword" />
       <DenyAttribute attributeName="uid" />
       <DenyAttribute attributeName="homeOrganization" />
       <AllowAttribute attributeName="schacHomeOrganization" />
   </FilterRule>

   <FilterRule>
       <Description>Use conditions - allow only specific attribute values</Description>
       <Condition>
           <LocalProviderMatch>^urn:.*\.hu$</LocalProviderMatch>
       </Condition>
       <AllowAttribute attributeName="eduPersonEntitlement">
           <AttributeValue>^.*@.*\.hu$</AttributeValue>
       </AllowAttribute>
   </FilterRule>

   <FilterRule>
       <Description>Use conditions - reference any attribute</Description>
       <Condition>
           <AttributeMatch attributeName="homeOrganization">niif.hu</AttributeMatch>
       </Condition>
       <AllowAttribute attributeName="eduPersonEntitlement">
           <AttributeValue>^.*@niif\.hu$</AttributeValue>
       </AllowAttribute>
   </FilterRule>

</AttributeFilter>

```

## Integration

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

### Initialization time

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

```java
  // get a reference to the AttributeConverterFactory singleton object
  AttributeConverterFactory factory = AttributeConverterFactory.getInstance();
  // set the configuration file paths (which paths can be set in web.xml for example)
  factory.setAttributeConverterFilePath("path-to-converter.xml");
  factory.setAttributeFilterFilePath("path-to-filter.xml");
  factory.setAttributeNameMapperFilePath("path-to-namemapper.xml");

  // create converter and filter objects
  try {
    AttributeConverter converter = factory.createAttributeConverter();
    AttributeFilter filter = factory.createAttributeFilter();
  } catch (ConfigurationException ex) {
    // handle configuration errors (missing files, not valid xmls and more issues)
    log.error(ex);
  }

```

### Runtime

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

!!! danger "Figyelem"

```
If you do not pass `local` or `remote` then rules containing `LocalProviderMatch` or `RemoteProviderMatch` will **NOT** be executed.

```

```java
  String remote = "remote-federation-peer-identifier";
  String local = "local-federation-peer-identifier";

  // get Attributes from the assertion
  List<AttributeValues> input = ...;

  // Call converter and filter in order.
  // Home BE should call converter first, remote BE should call filter first.
  if (isHomeBE) {
    List<AttributeValues> output = converter.process(input, remote, local);
    output = filter.process(output, remote, local);
  } else {
    List<AttributeValues> output = filter.process(input, remote, local);
    output = converter.process(output, remote, local);
  }

  // process output here, create new assertion, etc.

```

## Testing

### XMLTest.sh

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

```
$ ./XMLTest.sh

Attribute Converter Test usage

java AttributeConverterTest
  [-debug]
  [AttributeConverter.xml](-converterconfig)
  [AttributeFilter.xml](-filteringconfig)
  [AttributeNameMapping.xml](-attributenameconfig)
  [output.xml](-output)
  input.xml

```

#### Example test configuration

The `xmltest/` directory contains the following examples

**`AttributeNameMapper.xml`** converter name mapper configuration

```xml
<?xml version="1.0" encoding="UTF-8"?>
<AttributeMapper
   xmlns='urn:geant:edugain:attribute-mapper:1.0'>

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

    <AttributeDefinition
    Id="edupersonAffiliation"
    AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation" />

    <AttributeDefinition
    Id="homeOrganization"
    AttributeName="urn:mace:dir:attribute-def:homeOrganization" />

    <AttributeDefinition
    Id="cn"
    AttributeName="urn:mace:dir:attribute-def:cn">
        <Attribute AttributeName="urn:oid:2.5.4.3"/>
    </AttributeDefinition>
</AttributeMapper>

```

**`AttributeConverter.xml`** converter configuration

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

```

**`AttributeTest.xml`** test input xml

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

```

#### Output of the example

```
$ ./XMLTest.sh \
  -converterconfig xmltest/AttributeConverter.xml \
  -attributenameconfig xmltest/AttributeNameMapper.xml \
  xmltest/AttributeTest.xml

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

```

### Real-life examples

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

```cpp
--- xmltooling/soap/impl/SOAPClient.cpp.orig    2008-03-14 23:50:29.000000000 +0100
+++ xmltooling/soap/impl/SOAPClient.cpp 2008-04-25 13:14:29.000000000 +0200
@@ -89,8 +89,11 @@
     XercesJanitor<DOMDocument> janitor(doc);

     Category& log = Category::getInstance(XMLTOOLING_LOGCAT".SOAPClient");
-    if (log.isDebugEnabled())
-        log.debugStream() << "received XML:\n" << *(doc->getDocumentElement()) << logging::eol;
+    if (log.isDebugEnabled()) {
+        string serializedXml;
+        XMLHelper::serialize (doc->getDocumentElement(),serializedXml,false);
+        log.debugStream() << "received XML:\n" << serializedXml << logging::eol;
+    }

     auto_ptr<XMLObject> xmlObject(XMLObjectBuilder::buildOneFromElement(doc->getDocumentElement(), true));
     janitor.release();

```

# IdP_Operational_Requirements

## Purpose of this document

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

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

- **MUST** (or **SHALL**, **REQUIRED**): the definition is an absolute requirement of the specification in order to build and keep trust in the federation.
- **MUST NOT**: the definition is an absolute prohibition of the specification
- **SHOULD** (or **RECOMMENDED**): there may be valid reasons for ignoring the definition, however, the divergence from the specification **MUST** be documented
- **SHOULD NOT** (or **NOT RECOMMENDED**): there may be valid reasons for the particular behaviour to be acceptable, however, the divergence from the specification **MUST** be documented

## Identity management

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](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](https://open.eduid.hu)) az eduID egy olyan azonosító szervezete, amelybe bárki regisztrálhat, majd a regisztrált azonosító birtokában különböző szolgáltatásokat vehet igénybe.

## Felhasználóknak

- Ahhoz, hogy regisztrálni tudjon, nincs más teendője, mint az [openIdP](https://open.eduid.hu) oldalán a Regisztráció menüpontra kattintani, majd megadni egy érvényes e-mail címet, melyre a rendszer elküldhet egy ellenőrző levelet. A levél elolvasása után az abban szereplő hivatkozásra kattintva nyílik mód a regisztráció befejezésére, a további adatok (vezetéknév, keresztnév) megadására.
- Ha elfelejtette jelszavát, és szeretne újat beállítani, úgy adja meg regisztrációkor használt e-mail címét, melyre a rendszer küld egy levelet, benne egy hivatkozással, amelyre ha rákattint, lehetősége lesz új jelszót megadnia.
- Ha regisztrált adatain szeretne módosítani, lépjen be az [openIdP](https://open.eduid.hu) oldalán, majd az 'Adatok megváltoztatása' menüpont alatt vezesse át a változtatásokat
- Ha törölni szeretné az openIdP-ből azonosítóját, úgy belépés után válassza az 'Azonosító törlése a rendszerből' menüpontot, s adatai azonnal törlésre kerül.

## Háttér

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

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

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

## Szolgáltatások üzemeltetőinek

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

1. A fent említett, adatok ellenőrizetlenségéből adódó kockázatok megértése
2. Az [openIdP metaadatának](https://metadata.eduid.hu/current/openidp.xml) betöltése a szolgáltatás előtt dolgozó SP-be.

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

- [eduPersonPrincipalName](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) (scope: @open.eduid.hu)
- [eduPersonTargetedID](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
- [mail](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
- [surname](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
- [givenName](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)

**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](#bkmrk-switchaai-wayf-%28http) szabvány ezt a szolgáltatást **Discovery Service**-nek nevezi.

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

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

\*\* Szoftverek:\*\*

- SWITCHaai WAYF ([http://www.switch.ch/aai/support/tools/wayf.html](http://www.switch.ch/aai/support/tools/wayf.html))
- A Shibboleth 1.3 IdP tartalmaz WAYF alkalmazást

# HREF_Key_Rollover_2020_English

## Introduction

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

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

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

## Key Rollover

### Code names

<table id="bkmrk-code-name-metadata-s"><thead><tr><th>Code name</th><th>Metadata signing certificate</th><th>Date of expiration</th></tr></thead><tbody><tr><td>HREF-2011</td><td>[href-metadata-signer-2011.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2011.crt)</td><td>2022.01.01.</td></tr><tr><td>HREF-2015</td><td>[mdx-test-signer-2015.crt](https://metadata.eduid.hu/certs/mdx-test-signer-2020.crt)</td><td>2022.01.01.</td></tr><tr><td>HREF-2020</td><td>[href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt)</td><td>2025.06.14.</td></tr></tbody></table>

### SHA1 fingerprints

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

### Domain names

<table id="bkmrk-domain-url-key-statu"><thead><tr><th>Domain</th><th>URL</th><th>Key</th><th>Status</th></tr></thead><tbody><tr><td>metadata.eduid.hu</td><td>`metadata.eduid.hu/2011/href.xml`</td><td>HREF-2011</td><td>Prod</td></tr><tr><td>metadata.eduid.hu</td><td>`metadata.eduid.hu/2020/href.xml`</td><td>HREF-2020</td><td>Prod</td></tr><tr><td>mdx.eduid.hu</td><td>`mdx-2015.eduid.hu`</td><td>HREF-2015</td><td>Prod</td></tr><tr><td>mdx.eduid.hu</td><td>`mdx-2020.eduid.hu`</td><td>HREF-2020</td><td>Prod</td></tr></tbody></table>

## Shibboleth Service Provider Configurations

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

### XML

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

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

```

### MDX

#### Shibboleth 3.X

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

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

```

#### Shibboleth 2.X

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

```

## Shibboleth Identity Provider Configurations

### XML

#### Shibboleth 4.X

[https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider](https://wiki.shibboleth.net/confluence/display/IDP4/FileBackedHTTPMetadataProvider)

```xml
<MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
                  backingFile="%{idp.home}/metadata/href-2020.xml"
                  metadataURL="https://metadata.eduid.hu/2020/href.xml">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>

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

    <MetadataFilter xsi:type="EntityRoleWhiteList">
        <RetainedRole>md:SPSSODescriptor</RetainedRole>
    </MetadataFilter>

</MetadataProvider>

```

#### Shibboleth 3.X

[https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider](https://wiki.shibboleth.net/confluence/display/IDP30/FileBackedHTTPMetadataProvider)

```xml
<MetadataProvider id="RemoteMetadataAggregate" xsi:type="FileBackedHTTPMetadataProvider"
                  backingFile="%{idp.home}/metadata/href-2020.xml"
                  metadataURL="https://metadata.eduid.hu/2020/href.xml">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/conf/metadata/href-metadata-signer-2020.crt"/>

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

    <MetadataFilter xsi:type="EntityRoleWhiteList">
        <RetainedRole>md:SPSSODescriptor</RetainedRole>
    </MetadataFilter>

</MetadataProvider>

```

### MDX

#### Shibboleth 4.X

[https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider](https://wiki.shibboleth.net/confluence/display/IDP4/DynamicHTTPMetadataProvider)

```xml
<MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
                  connectionRequestTimeout="PT2S"
                  connectionTimeout="PT2S"
                  socketTimeout="PT4S">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>

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

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

</MetadataProvider>

```

#### Shibboleth 3.X

[https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider](https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider)

```xml
<MetadataProvider id="DynamicEntityMetadata" xsi:type="DynamicHTTPMetadataProvider"
                  connectionRequestTimeout="PT2S"
                  connectionTimeout="PT2S"
                  socketTimeout="PT4S">

    <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
        certificateFile="%{idp.home}/credentials/href-metadata-signer-2020.crt"/>

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

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

</MetadataProvider>

```

## SimpleSAMLphp Configurations

### MDX

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

```

### metarefresh

[https://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section\_3](https://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_3)

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

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

```

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

```

# Shib2IdpConnectionPool

# Mi is az a connection pooling?

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

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

- egy adatbáziskapcsolat, szinkronizációval. Ebben az esetben az alkalmazásunk tulajdonképpen egyszálúvá válik.
- feldolgozó szálanként külön adatbáziskapcsolat, így nem kell a szinkronizációval foglalkozni. Így azonban a kapcsolatok jelentős része kihasználatlan, szélsőséges esetben az adatbázis által engedélyezett kapcsolatok száma telítődhet is. Ez a megoldást tehát jelentős overheadet okoz.
- az adatbázis kapcsolatok dinamikus kiosztása a feldolgozó szálak között.

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

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

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

- minimális és maximális kapcsolatszám meghatározása
- inaktivitás esetén lezárás
- adatbázis oldali lezárás megakadályozása folyamatos "pingeléssel"
- halott kapcsolatok transzparens eltávolítása

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

["Hivatalos", Sun-féle leírás](http://java.sun.com/developer/onlineTraining/Programming/JDCBook/conpool.html)

## Connection pool használata Tomcat6 alatt

A Tomcat jelenleg a [dbcp](http://commons.apache.org/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:

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

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

```java
 // 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](https://help.edu.hu/books/aai/page/shib2persistentid)) használ relációs adatbázist, ezért példaként álljon itt egy DataConnector konfiguráció:

```xml
  <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](https://help.edu.hu/books/aai/page/shib2idpauth)

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

```xml
<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 --&gt; fájlok bemásolása --&gt; visszacsomagolás a követendő út):

- [aopalliance-1.0.jar](https://lipton.aai.niif.hu/downloads/aopalliance-1.0.jar)
- [spring-aop-3.0.6.RELEASE.jar](https://lipton.aai.niif.hu/downloads/spring-aop-3.0.6.RELEASE.jar)

# Shib3IdpAttrib

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

**Vonatkozó állományok:**

- `{idp.home}/conf/attribute-resolver.xml`
- `{idp.home}/conf/idp.properties`

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

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

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

```xml
    <!-- ========================================== -->
    <!--      Attribute Definitions                 -->
    <!-- ========================================== -->

    <!-- ... további tartalom ... -->

    <!--
    In the rest of the world, the email address is the standard identifier,
    despite the problems with that practice. Consider making the EPPN value
    the same as your official email addresses whenever possible.
    -->

    <resolver:AttributeDefinition id="mail" xsi:type="ad:Simple" sourceAttributeID="mail">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
    </resolver:AttributeDefinition>

    <resolver:AttributeDefinition id="sn" xsi:type="ad:Simple" sourceAttributeID="sn">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:sn" encodeType="false" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.4" friendlyName="sn" encodeType="false" />
    </resolver:AttributeDefinition>

    <resolver:AttributeDefinition id="givenName" xsi:type="ad:Simple" sourceAttributeID="givenName">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:givenName" encodeType="false" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:2.5.4.42" friendlyName="givenName" encodeType="false" />
    </resolver:AttributeDefinition>

    <!-- ========================================== -->
    <!--      Data Connectors                       -->
    <!-- ========================================== -->

    <!-- ... további tartalom ... -->

```

- A **18, 24.** sorban adjuk meg az attribútum nevét, valamint, hogy egyszerű attribútumról van szó, nem szükséges átalakítani.
- A **19, 25.** sor hivatkozik a használandó LDAP kapcsolatra.
- A **21, 27.** sorbeli SAML2String előállításához szükséges oid megegyezik az attribútum LDAP sémabeli oid-jával.

**Dokumentáció:**

- [https://wiki.shibboleth.net/confluence/display/IDP30/AttributeResolverConfiguration](https://wiki.shibboleth.net/confluence/display/IDP30/AttributeResolverConfiguration)

# 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](https://learning-agreement.eu/user/login) (OLA) és az Erasmus+ mobilalkalmazást. A digitalizálás alapvető része a hallgatók azonosítása, amely az [eduGAIN](https://edugain.org)-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](https://wiki.geant.org/display/SM/MyAcademicID+Identity+and+Access+Management+Service) 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](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](mailto:info@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](https://help.edu.hu/books/aai/page/metadata) ).

### Attributumok

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

<table id="bkmrk-attributumok-le%C3%ADr%C3%A1s-"><thead><tr><th>Attributumok</th><th>Leírás</th><th>Példa</th></tr></thead><tbody><tr><td>eduPersonPrincipalName</td><td>Állandó, nem célzott, nem újra kiosztható globálisan egyedi azonosító</td><td>`username@foobar.hu`</td></tr><tr><td>eduPersonTargetedID</td><td>Nem átlátszó, célzott (minden szolgáltatónál más) azonosító, amely nem osztható ki újra</td><td>`https://idp.foobar.hu/idp/shibboleth!https://sp.example.com/shibboleth!a1b2c3d4-789a-4ca7-8ff9-43216789bd`</td></tr><tr><td>displayName</td><td>A felhasználó megjelenítendő neve. **Szükséges, ha nincsen cn, vagy givenName+sn.**</td><td></td></tr><tr><td>cn</td><td>A felhasználó teljes neve. **Szükséges, ha nincsen displayName vagy givenName+sn.**</td><td>`Gipsz Jakab Aladár`</td></tr><tr><td>givenName</td><td>Felhasználó keresztneve. **Szükséges, ha nincsen displayName vagy cn.**</td><td>`Jakab`</td></tr><tr><td>sn</td><td>Felhasználó családi neve. **Szükséges, ha nincsen displayName vagy cn.**</td><td>`Gipsz`</td></tr><tr><td>eduPersonAffiliation</td><td>Felhasználó és intézmény közti viszony leírása.</td><td>`[student](member,)`</td></tr><tr><td>eduPersonScopedAffiliation</td><td>Felhasználó és intézmény közti viszony leírása. scope-al</td><td>`[student@foobar.hu](member@foobar.hu,)`</td></tr><tr><td>schacPersonalUniqueCode</td><td>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.</td><td>`<nowiki>urn:schac:personalUniqueCode:int:esi:foobar.hu:123456789</nowiki>`</td></tr><tr><td>schacHomeOrganization</td><td>Szervezete domainje.</td><td>`foobar.hu`</td></tr><tr><td>schacHomeOrganizationType</td><td>Szervezet típusa (URN)</td><td>`<nowiki>urn:schac:homeOrganizationType:eu:higherEducationalInstitution</nowiki>`</td></tr></tbody></table>

### 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. <u>országos kód</u>:ha rendelkezésre áll nemzeti hallgatói kód
2. <u>intézményenként</u>:jelenleg ez támogatható Magyarországi szinten

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

- változatlan URN névtér: `<nowiki>urn:schac:personalUniqueCode:int:esi:</nowiki>:`
- szervezet domainje: foobar.hu
- hallgatói azonosító kód (pl. belső nyilvántartási szám): 123456789

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

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

[https://wiki.geant.org/display/SM/European+Student+Identifier](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](https://wiki.geant.org/display/SM/EWP+Admin+Role)

### További információk

[https://wiki.geant.org/display/SM/Identifier+in+Erasmus+mobility](https://wiki.geant.org/display/SM/Identifier+in+Erasmus+mobility)

# SAML

## SAML 1.1

## SAML 2.0

***Binding*ok**

- TODO

***Profilok***

- [SAMLBrowserPOST](#bkmrk-samlbrowserpost-saml)
- [SAMLBrowserArtifact](#bkmrk-samlbrowserpost-saml)
- TODO

# Shibboleth

## Architektúra

## Profilok

- [Shibboleth POST Profile](#bkmrk-jelent%C3%A9s)
- [Shibboleth Artifact Profile](#bkmrk-jelent%C3%A9s)
- [Lazy Session](https://help.edu.hu/books/aai/page/lazy-session)
- [Attribute Push](https://help.edu.hu/books/aai/page/attributepushpull)

## Jelentés

# Common-lib-terms

## Meghatározás

A `common-lib-terms` az [eduPersonEntitlement](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) 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](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) értékkel bíró felhasználók).

További információ (angolul): [http://middleware.internet2.edu/urn-mace/urn-mace-dir-entitlement.html](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.

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

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

```

# SimpleSAMLMixedMetadata

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

- kézzel szerkesztett saml20-sp-remote (vagy saml20-idp-remote) például Google Apps vagy Office365 használatához;
- az intézményi metadata halmazt, azaz a belső SP-k (esetleg teszt IdP-k) halmazát;
- a magyar eduID.hu föderációban levő entitásokat;
- és az eduGAIN-ben levő entitásokat.

Ez utóbbi kettőt a föderáció **[MDX](https://help.edu.hu/books/aai/page/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:

```php
'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á:

```bash
 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
<?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
<?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](https://help.edu.hu/books/aai/page/ssp-entitycategories).

A [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry) felületen belépve állítsuk át az entitást az eduGAIN-ben való publikálásra: ![left](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/metadata-set-chooser.png)

# Károkozási_táblázat

<table id="bkmrk-%2F--x--%3E-user-idp-sp-"><thead><tr><th>/- X -&gt;</th><th>User</th><th>IdP</th><th>SP</th><th>Föderáció</th></tr></thead><tbody><tr><td>User</td><td>1. Azonosító adatok ellopásával más felhasználó nevében vesz igénybe szolgáltatást
</td><td>1. Hamis adatokat ad meg (vagy állíttat be)
2. Az SP rendszerével visszaélve rombolja az IdP presztízsét
</td><td>1. Visszaél a szolgáltatással (abuse)
2. Hamis adatok alapján jogosulatlanul vesz igénybe szolgáltatást
</td><td>1. Visszaélésekkel (ill. próbálkozásokkal) csökkenti a föderációba vetett bizalmat
</td></tr><tr><td>IdP</td><td>1. Visszaélés a jelszóval
2. Pontatlan személyes adatok
3. Szükséges jogosultsági attribútumokat (pl. entitlement) nem adja meg
4. Visszaélés a személyes adatokkal
5. Személyes adatok túl tág körének átadása harmadik félnek
6. Azonosító szolgáltatás kiesése miatt a felhasználó nem tud igénybe venni szolgáltatásokat
</td><td><center>X</center></td><td>1. Rossz Identity Management
2. Hamis scope megadása
3. Hamis attribútum-értékek megadása (pl. jogosulatlan hozzáférés biztosítása entitlement segítségével)
4. Hamis adatok megadása az IdP regisztrációjakor
5. Visszaélések vizsgálatakor az együttműködés megtagadása
</td><td>1. Hamis adatok megadása az IdP regisztrációjakor
2. Rossz felhasználókezeléssel csökkenti a föderációba vetett bizalmat
3. Visszaélésekkel csökkenti a föderációba vetett bizalmat
4. Megbízhatatlanul üzemeltetett informatikai rendszerrel csökkenti a föderatív azonosításba vetett bizalmat
</td></tr><tr><td>SP</td><td>1. Kicsalja a felhasználó jelszavát
2. Visszaél az IdP-től megkapott adatokkal
3. Visszaél a felhasználótól közvetlenül megkapott adatokkal
</td><td>1. Szükségtelenül igényel adatokat felhasználókról (vö. unsolicited attribute query
</td><td>) 2. DOS támadás
</td><td><center>X</center></td></tr><tr><td>FedOp</td><td>1. 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.
2. Metaadatok szándékos meghamisítása
3. A Discovery Service helytelen működtetése miatt elérhetetlenné válnak a szolgáltatások
</td><td>1. Lásd előbb
2. Intézményen belüli szolgáltatások is elérhetetlenné válhatnak
</td><td>1. Lásd előbb
</td><td>1. 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
</td></tr></tbody></table>

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

- [Shibboleth IdP telepítés (Debian)](https://help.edu.hu/books/aai/page/shibboleth-idp-telepites-debian)

**Konfigurációs leírások**

- [IdP alkalmazás konfigurációja](https://help.edu.hu/books/aai/page/shibboleth-idp-konfiguracioja)
- [Attribútumok használata](https://help.edu.hu/books/aai/page/attributum-feloldas)
- [Attribútum kiadás konfigurációja](https://help.edu.hu/books/aai/page/attributum-kiadas)
- [Felhasználó azonosítás](#bkmrk-%C3%9Aj-idp-hozz%C3%A1ad%C3%A1sa-a-)

---

- [Új IdP hozzáadása a föderációhoz](#bkmrk-%C3%9Aj-idp-hozz%C3%A1ad%C3%A1sa-a-)

# 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ó](https://help.edu.hu/books/aai/page/href-metadata-specifikacio) tartalmaz.

##### Elérhetőség kritériumai

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

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

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

#### Vállalt rendelkezésre állás

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

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

A [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry) a metaadat állományban található - az egész föderációt leíró - adatok szerkesztését lehetővé tevő alkalmazás. A Resource Registryben tárolt adatokat a föderációs operátor illetve az intézmények kapcsolattartói szerkeszthetik.

#### Elérhetőség kritériumai

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

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

#### Vállalt rendelkezésre állás

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

### Discovery Service

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

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

#### Elérhetőség kritériumai

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

#### Vállalt rendelkezésre állás

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

### Virtuális azonosítószervezet

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

#### Elérhetőség kritériumai

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

- adminisztrációs felület a felhasználók kezelésére
- azonosító szerver

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

#### Vállalt rendelkezésre állás

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

### Föderációs komponensek monitorozása

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

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

## Támogatás

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

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

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

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

### Egyéb támogatás

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

## Kiegészítő szolgáltatások

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

- URN registry (URN névterek kezelése, delegálása)
- Statisztika
- Audit
- Intézményi AAI komponensek monitorozása
- IdP és SP hosting

# Drupal_Shibboleth_module

Drupal **shib\_auth** module enables [Shibboleth](http://shibboleth.internet2.edu) authentication for [Drupal CMS](http://drupal.org).

!!! 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](http://drupal.org/project/shib_auth).
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](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPProtectContent)) 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](#bkmrk-debug-mode) to dump the whole **$\_SERVER** array. If you can see Shibboleth attributes there, you're fine.

In Shibboleth there are two modes for protecting resources:

- **Lazy Sessions**: session is only initiated if an application redirects user to the SessionInitiator URL. In this module, it is done by clicking the *"Login with Shibboleth"* link. Anonymous access is possible as well as using other authentication methods. 
    - <small>Detailed description of [lazy sessions](https://help.edu.hu/books/aai/page/lazy-session) in Hungarian.</small>
- **"Strict" Sessions** (normal sessions): users can only access Drupal content if they have a valid Shibboleth session. This case, no anonymous access can be granted (not even read-only) and you can not use any auxiliary authentication methods.

!!! warning

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

```

#### Example Shibboleth configuration

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

**/etc/shibboleth/shibboleth2.xml snippet**:

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

```apache
<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. \* <small>Keep in mind that some users might have a specific attribute while others don't.</small>

#### Debug path prefix

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

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

### Setting Shibboleth parameters for the module

#### Handler settings

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

- protocol scheme (`http://` or `https://`)
- host name
- Shibboleth handler URL (usually: `/Shibboleth.sso`)
- 'location' part of the SessionInitiator definition

**/etc/shibboleth/shibboleth2.xml snippet**:

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

```

For this example, you should have:

- **`/Shibboleth.sso`** for *Handler URL*
- **HTTPS** or **HTTP** for *scheme*, depending on whether you are using SSL or not
- **/Login** for *WAYF location*

#### Attribute settings

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

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

##### Using custom e-mail address

- *Require and use only Shibboleth-provided e-mail address* (default): with this option set, Drupal e-mail address is rewritten with the Shibboleth-provided one on each login. This means that your users can only use the e-mail address which is provided by the IdP. **The IdP is required to send the e-mail address attribute otherwise the user gets a fatal error.**
- *Ask for missing e-mail address*: let the user modify her own e-mail address by editing her Drupal account. If the IdP provides an e-mail address, then that value will be the default, otherwise the user is asked to specify her e-mail address.

### Logging out

#### Session expiry

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

!!! info

```
Keep in mind if you leave this option off:

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

```

#### URL to redirect to after logout

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

#### SAML2 Logout

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

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

```

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

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

```

### Automatic role assignment

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

An assignment rule is made of three parameters:

- **$\_SERVER** header name: name of the Shibboleth-derived attribute
- **Value regexp**: regexp applied to (all) the value(s) of the Shibboleth-derived attribute
- **Role(s)**: checklist of roles to be assigned for the matching users

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

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

!!! danger "Figyelem"

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

```

## Using module

### Automatic user creation

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

### Disallowing password change

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

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

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

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

**Steps for disallowing your users to change their passwords:**

1. Install Drupal [User Protect module](http://drupal.org/project/userprotect)
2. At Administer -&gt; User management -&gt; User Protect -&gt; Protected roles tab check **password** for the *authenticated user* role.
3. At Administer -&gt; Permissions -&gt; userprotect module: uncheck **change own password** for *authenticated user*
4. Log in with a normal account, go to "My account" -&gt; 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 -&gt; 3.3

Module update problem was fixed. From now on one should run update.php on updates. [Previous version](https://wiki.aai.niif.hu/index.php?title=Drupal_Shibboleth_module&oldid=1290)

### Version 3.1 -&gt; 3.2

The module now works with caching, but requires disabling and re-enabling. [Previous version](https://wiki.aai.niif.hu/index.php?title=Drupal_Shibboleth_module&oldid=1004)

### Version 3.0 -&gt; 3.1

If you need documentation for 3.0, please [use the previous version of the documentation](https://wiki.aai.niif.hu/index.php?title=Drupal_Shibboleth_module&oldid=906)

# 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](https://help.edu.hu/books/aai/page/href-muszaki-eloirasok), 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](https://help.edu.hu/books/tcs-EJV/page/tcs) 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](https://help.edu.hu/books/aai/page/shib3idpinstall), [SimpleSAMLphp](#bkmrk-a-webszerver-%28apache)) konfigurációjában kell megadni, mert ez az, amivel alá tudja írni az általa küldött üzeneteket, illetve dekódolni tudja a fogadott titkosított adatokat. Ez a tanúsítvány lehetőség szerint hosszú (10+ éves) lejáratú, self-signed tanúsítvány legyen.

- A webszerver (Apache, Jetty) konfigurációban csak akkor szerepeljen a föderációs metadatában szereplő tanúsítvány, ha azt szeretnénk, hogy az IdP támogassa az attribútumok back-channel történő letöltését (a Shibboleth IdP ilyen), esetleg ha valamilyen oknál fogva önálló AttributeAuthority-t építünk. Ha valami fut a szabványos https porton (pl. az IdP SSO szolgáltatása vagy egy SP), akkor az AttributeAuthority szolgáltatást nem tehetjük ide, ezért az jellemzően a 8443-as porton szokott figyelni.

# Shibenv-PHP

Eredeti forrás: [http://shib.kuleuven.be/download/sp/test\_scripts/shibenv.php.txt](http://shib.kuleuven.be/download/sp/test_scripts/shibenv.php.txt)

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

```

</body></html>

# ShibMessages

## HTTP headers

### Discovery Service, SAML2 Artifact

#### Felhasználó -&gt; SP (1)

[https://webadmin.iif.hu/ticketing/](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](#bkmrk-%3C%3Fxml-version%3D%221.0%22-)-hez

#### Felhasználó -&gt; DS

[https://ds.niif.hu/?entityID=https%3A%2F%2Fwebadmin.iif.hu%2Fshibboleth&amp;return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05](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&amp;return=https%3A%2F%2Fwebadmin.iif.hu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253A7ed01b05](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ó -&gt; SP (2)

[https://webadmin.iif.hu/Shibboleth.sso/DS?SAMLDS=1&amp;target=cookie%3A7ed01b05&amp;entityID=https%3A%2F%2Fidp.niif.hu%2Fshibboleth](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ó -&gt; 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&amp;RelayState=cookie%3A7ed01b05](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ó -&gt; SP (3)

[https://webadmin.iif.hu/Shibboleth.sso/SAML2/Artifact?SAMLart=AAQAAhzkZRgbhm%2BltdAF2yKfBGO7t%2BpaTrn3F1DpnZKFEAFI451jQHWhtBs%3D&amp;RelayState=cookie%3A7ed01b05](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 -&gt; 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ó -&gt; Alkalmazás

[https://webadmin.iif.hu/ticketing/](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

```xml
<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
<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](https://help.edu.hu/books/aai/page/attributepushpull)).

- <small>Lehetséges aláírás nélküli választ küldeni, de ebben az esetben nem ellenőrizhető le a küldő személye, ezért ez általában nem megengedett</small>

### SAML response, attribute push

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

```

</body></html>

# HREFPolicyStub

## Általános elvárások

- A Tag és Partner az NIIFI-vel az NIIF AAI üzemeltetése érdekében folyamatosan együttműködik, különösen az NIIF AAI-val összefüggésben felmerülő visszaélések kivizsgálása érdekében.
- Az NIIF AAI Operátor a föderáció zavartalan üzemeltetése érdekében utólagos monitoring vizsgálatot végezhet, amely során jogosult ellenőrizni: 
    - az Üzemeltetéssel kapcsolatos műszaki elvárások és feltételekben meghatározott kötelezettségek betartását;
    - azonosítási eljárások megfelelőségét;
    - a hatályban lévő adatvédelmi és felhasználói szabályzatnak a Tagok Tanácsa Ajánlásainak megfelelő módosítását;
    - a Tagok Tanácsa egyéb Ajánlásainak való megfelelést.
- A Tag biztosítja, hogy a Metadata mindenkor csak az aktuális adatokat tartalmazza, ennek érdekében évente önellenőrzést végez.

## Adatvédelmi elvárások

- A Tag és a Partner biztosítja, hogy az NIIF AAI működése során közöttük a személyes adatok kezelése a vonatkozó jogszabályoknak megfelelő módon történik. Így különösen: 
    - a személyes adatok kezelése csak törvényi felhatalmazás vagy felhasználói önkéntes, határozott és tájékozott hozzájárulásán alapul, amellyel beleegyezését fejezi ki az őt érintő személyes adatok kezelésébe.
    - a Tag vagy a Partner által üzemeltetett föderációs szolgáltatás csak a működtetéséhez feltétlenül szükséges adatokat igényli a felhasználókról
- Mind az Tag, mind a Partner rendelkezik a személyes adatok kezelését megfelelően rendező adatkezelési szabályzattal, amely rendelkezik különösen: 
    - a kezelt személyes adatok köréről;
    - az adatkezelés céljáról;
    - az adatkezelés időtartamáról;
    - az adatalanyokat érintő tiltakozási jog lehetőségéről.
- Mind a Tag, mind a Partner a mindenkor hatályos adatkezelési szabályzatukat, egy az NIIF AAI által fenntartott központi helyen elérhetővé teszik.
- A Tag biztosítja, hogy csak olyan saját szolgáltatást (Saját SP) regisztrál a Metadatába, amely 
    - tiszteletben tartja az NIIF AAI működtetését megalapozó alapelveket továbbá;
    - betartja az Üzemeltetéssel kapcsolatos műszaki elvárások és feltételekben foglalt kötelezettségek, az ott meghatározott feltételeknek már az NIIF AAI-hez való csatlakozás pillanatában, továbbá az NIIF AAI tagsága során mindvégig megfelel;
    - az üzemeltetéssel kapcsolatos műszaki elvárások és feltételekben foglalt kötelezettségeknek való folyamatos megfelelés érdekében feliratkozik az NIIF AAI Operátor által üzemeltetett levelezőlistára, valamint folyamatosan kapcsolatot tart az NIIF AAI Operátorral és az NIIF AAI többi résztvevőjével;
    - biztosítja az azonosítási eljárások megfelelőségét és elérhetőségét;
    - az Üzemeltetéssel kapcsolatos műszaki elvárások és feltételekben foglalt kötelezettségek elmulasztásából eredő károkért teljes körű felelősséggel tartozik;
    - betartja az NIIF AAI működését szabályozó kötelező dokumentumok (Csatlakozási Szerződés, Szabályzat) vonatkozó rendelkezéseit.
- A Tag felelősséget vállal, hogy a Saját SP vállalt kötelezettségeinek eleget tesz, továbbá ezen kötelezettségeinek elmulasztásából eredő károkért teljes körű felelősséggel tartozik.
- Adatminőség 
    - z adatkezelés során a személyes adat felvételének és kezelésének nemcsak tisztességesnek és törvényesnek kell lennie, de az így rögzített adatnak pontosnak, teljesnek, és ha szükséges időszerűnek is kell lennie.
    - személyes adat tárolási módjának alkalmasnak kell lennie arra, hogy az érintett felhasználót csak a tárolás céljához szükséges ideig lehessen azonosítani.
    - z adatminőség biztosítása érdekében az Idp AAI adatbázis adatait authoritatív adatbázisban rögzített adatok alapján célszerű létrehozni, így az adatok folyamatosan frissülésével azok időszerűsége, pontossága nem vitatott.
    - mennyiben nem az IdP AAI adatbázis nem autoratív adatbázis alapján működik az Tagnak meg kell tennie a szükséges lépéseket az adatminőség biztosítása érdekében.

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

- A Tag biztosítja, hogy a Felhasználó regisztrációs folyamata, továbbá az NIIF AAI regisztrációjának törlése megfelelően dokumentált legyen.
- Az Tag mindent megtesz annak érdekében, hogy az általa kiadott személyes adatok megfeleljenek az adatminőség törvényi követelményeinek, így azok pontosak és időszerűek legyenek. 
    - A Tag IdP AAI kapuja által szolgáltatott identitás-csoportokat (pl. hallgatók, oktatók) teljes módon kell nyilvántartani, így ennek megfelelően pl. nem csak egy csoportjuk számára szolgáltat TO DO
    - A Tag a felhasználói identitáskezelés körében biztosítja, hogy a Felhasználók adataiban, ill. státuszában bekövetkezett változtatásoknak a változástól illetve a változás bejelentésétől számított 7 napon belül megjeleníti az NIIF AAI attribútumokban. 
        - Státusz adatok esetében a változást követő 7. napon;
        - Személyi adatok esetében a változás bejelentéstől számított 7. napon;
        - Szervezeti kapcsolódás adatait illetően a kapcsolódást elsődlegesen nyilvántartó rendszerben bekövetkező változástól számított 14. nap;
        - Oktatással kapcsolatos adatok esetben az oktatási adatokat elsődlegesen nyilvántartó rendszerben bekövetkező változástól számított 30. napon.
- A Tag biztosítja, hogy az IdP AAI Kapu az [attribútum specifikációban](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) megkövetelt attribútumokat megvalósítsa.

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

- A Tag az NIIF AAI megfelelő üzemeltetés érdekében biztosítja, hogy az IdP AAI Kapu a Felhasználó azonosítását követően kiadja az attribútumokat (ARP) az SP AAI Kapu részére.
- A Partner feltünteti a [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry)-ben a megkövetelt, ill. opcionális attribútumok körét, továbbá az NIIF AAI-ban történő részvétele során biztosítja, hogy az így megadott adatok mindig naprakészek legyenek.

# AboutEduID.hu

## Purpose of this document

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

## About the federation

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

### Contacts

The Federation is operated by [NIIF Institute](http://www.niif.hu) as a Federation Operator. Questions, concerns or any kind of requests about the Federation should be directed to any of the following addresses:

- **aai@niif.hu**
- **Kristof Bajnok**, *NIIF Institute*
- 18-22 Victor H. str
- H-1132 Budapest
- Hungary

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

### Policy and principles of interoperation

#### Basic principles

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

#### Data protection

- Prior joining the federation, every entity needs to publish the Data Protection Policy under which it operates. This policy must be kept up-to-date.
- Whenever the Data Protection Policy changes, the Federation Operator must be notified.
- Transfer of personal data is only allowed when either 
    - authorised by law, or
    - the user expressed his or her consent on the data transfer.

#### Rules of membership

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

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

### Governance

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

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

MB is authorised to

- accept new Federation documents or modify existing ones,
- accept application of new Members and Partners

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

### Legal

The Federation itself is not a legal entity, Members and Partners establish a legal connection to the Federation Operator. Any legal claims between Members and/or Partners shall be directed to the organisation operating the Identity Provider or the Service Provider.

The Service Agreement between the Federation Operator and Partner is available **[here](http://www.eduid.hu/wp-content/uploads/2012/08/href-contract-partner.doc)**.

## Technical information

### Operational requirements

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

### Attributes

[Attribute Specification](https://help.edu.hu/books/aai/page/attribute-specification) is maintained in a separate document.

As a brief summary, the following attributes are *mandatory* or *recommended*: | Mandatory attributes | Recommended attributes | |---| |eduPersonPrincipalName |displayName | |eduPersonTargetedID |mail | |eduPersonScopedAffiliation |eduPersonEntitlement | |schacHomeOrganizationType |

IdPs may implement other attributes.

### Metadata

[Metadata Specification](https://help.edu.hu/books/aai/page/metadata-specification) is maintained in a separate document.

## How to join

### Production federation

In order to join the production federation as a Partner, you need to send the following information:

- SP metadata URL (HTTPS preferred)
- Name of the SP
- Brief description of the service
- Service URL
- Privacy policy URL
- Administrative and technical contact names and mail addresses (non-personal preferred)
- Required and optional attributes
- Logo URL (optional)
- Helpdesk URL (optional)

This information should be sent to the Federation Operator (see [above](#bkmrk-contacts)) in email. Two copies of the signed Service Agreement (available at [http://eduid.hu/documents](http://eduid.hu/documents)) should be sent by traditional post, one copy will be returned after counter-signing.

After the application has been reviewed by the Federation Operator, it is forwarded to the Members' Board. It usually takes 3-5 working days for the Board to accept the application, after which the entity metadata is be added to the production federation metadata.

### Testing metadata

It is recommended that a new SP should be registered to the testing federation at first, which is much easier and a fully online process.

The following information is necessary to enter into the testing metadata:

- SP metadata URL (HTTPS preferred)
- Name of the SP
- Administrative and technical contact names and mail addresses (non-personal preferred)
- Required and optional attributes

You can ask for test accounts in our Virtual Home Organization. During testing, you might want to use the production federation metadata, because the VHO is present in both metadata files.

You do not need to re-register your entity to proceed to the production federation. If we have all the necessary information, the starting of the joining process is at your discretion.

# Shib2IdpRHELQuickStart

Ideális esetben az alábbi lépéseket végigjárva működő IdP-t kaphatunk RHEL, vagy ezzel rokonrendszereken.

## Előkészületek

### Tűzfal

- Be kell majd engedni a 443-as és a 8443-as portokat

### Shibboleth IdP letöltése

```bash
cd /tmp
wget http://software.niif.hu/maven2/edu/internet2/middleware/shibboleth-identityprovider/2.2.1-slo10/shibboleth-identityprovider-2.2.1-slo10-bin.tar.gz
tar xzf shibboleth-identityprovider-2.2.1-slo10-bin.tar.gz

```

Telepíteni is fogjuk később, de előbb beállítjuk a környezetet. A kicsomagolt állományból is kell majd ezt-azt másolni, ezért vettük előre a folyamatot.

### Tomcat

- Telepítsünk Tomcat 6-ot
    
    cd /etc/yum.repos.d wget 'http://www.jpackage.org/jpackage50.repo' yum update rpm -Uvh 'http://plone.lucidsolutions.co.nz/linux/centos/images/jpackage-utils-compat-el5-0.0.1-1.noarch.rpm' yum install tomcat6 tomcat6-webapps tomcat6-admin-webapps
- Be kell másolni a letöltött Shibboleth pakkban található endorsed library-ket a tomcatnek mkdir /usr/share/tomcat6/endorsed cp /tmp/shibboleth-identityprovider-2.2.1-slo10/endorsed/\*.jar /usr/share/tomcat6/endorsed/

A `/etc/tomcat6/tomcat6.conf` állományba tegyük be az alábbi sort: JAVA\_ENDORSED\_DIRS="/usr/share/tomcat6/endorsed"

- A leendő shibboleth idp webalkalmazás paramétereit is adjuk meg
    
    cd /etc/tomcat6/Catalina/localhost vim idp.xml

A fájl tartalma pedig a következő legyen (úgy tervezzük, hogy a /usr/local/shibboleth-idp alá telepítünk mindjárt)

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

```

### Apache

A webszervernek meg kell mondani, hogy egyfelől hallgasson a 8443-as porton is, másfelől, hogy a /idp-re érkező kéréseket proxyzza tovább a tomcat felé

### SSO URL (443-as port)

Be kell állítani a virtuális hosztot, amelyhez az IdP-t rendeltük. Először a 443-as portot konfiguráljuk. A 443-as porthoz tartozó tanúsítványok nem azonosak a 8443-as porthoz tartozóéval.

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

```xml
 <VirtualHost _default_:8443>
   ServerName aai.example.org:8443
   SSLEngine On
   SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:!SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
   SSLCertificateFile /usr/local/shibboleth-idp/credentials/idp.crt
   SSLCertificateKeyFile /usr/local/shibboleth-idp/credentials/idp.key
   SSLVerifyDepth 10
   SSLVerifyClient optional_no_ca
   SSLOptions -StdEnvVars +ExportCertData
   ProxyRequests Off
   <Proxy ajp://localhost:8009>
     Allow from all
   </Proxy>
   ProxyPass /idp ajp://localhost:8009/idp retry=5
 </VirtualHost>

```

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

## Telepítés

```
cd /tmp/shibboleth-identityprovider-2.2.1-slo10
./install.sh

```

## Utómunkálatok

### Jogosultságok beállítása

Engedjük meg, hogy a tomcat írja a log ill. a metadata könyvtárat

```
chown -R tomcat:tomcat /usr/local/shibboleth-idp/logs /usr/local/shibboleth-idp/metadata

```

### Naplófájlok rotálása

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

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

```xml
 <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](http://jira.qos.ch/browse/LBCORE-147), 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](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](https://help.edu.hu/books/aai/page/shib2idpinstall)

# NIIFSchema

# NIIF LDAP Schema

## Versioning

Current version: **2.3**

### Change log

- changes in 2.3
    
    
    - extend [niifAuthenticatedObject](#bkmrk-niifauthenticatedobject) with [niifValidityStart](#bkmrk-niifvaliditystart) and [niifExpireTime](#bkmrk-niifexpiretime) attributes
- changes since 2.1b2
    
    
    - add [niifAuthenticatedObject](#bkmrk-niifauthenticatedobject) and its [niifEduroamPassword](#bkmrk-niifeduroampassword)
- changes since 2.1b1
    
    
    - updated schema files
- changes since 2.0b5
    
    
    - add [niifCertificateSHA1Fingerprint](#bkmrk-niifcertificatesha1fingerprint)
    - add [niifEduPersonArchiveCourse](#bkmrk-niifedupersonarchivecourse)
    - add [niifEduPersonHeldCourse](#bkmrk-niifedupersonheldcourse)
    - mark [niifCertificateSubjectDN](#bkmrk-niifcertificatesubjectdn) as obsolete

## Schema files

- Sun DS format: [99-niifschema.ldif](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/99-niifschema.ldif)
- OpenLDAP format: [niif-openldap.schema](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/niif-openldap.schema)
- [niifauthentication.ldif](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/niifauthentication.ldif){:doenload="niifauthentication.ldif"}

## ObjectClasses

### niifPerson

<table id="bkmrk-niifperson-parent-in"><thead><tr><th></th><th>niifPerson</th></tr></thead><tbody><tr><td>**Parent**</td><td>inetOrgPerson</td></tr><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.0.0</td></tr><tr><td>**Description**</td><td>-</td></tr><tr><td>**Mandatory attributes**</td><td>-</td></tr><tr><td>**Optional attributes**</td><td>- [niifPersonPrefix](#bkmrk-niifpersonprefix)
- [niifPersonDegree](#bkmrk-niifpersondegree)
- [niifPersonPosition](#bkmrk-niifpersonposition)
- <strike>[niifPrefix](#bkmrk-niifprefix)</strike>
- <strike>[niifStatus](#bkmrk-niifstatus)</strike>
- <strike>[niifTitle](#bkmrk-niiftitle)</strike>
- <strike>[niifCertificateSubjectDN](#bkmrk-niifcertificatesubjectdn)</strike>
- [niifPersonDateOfBirth](#bkmrk-niifpersondateofbirth)
- [niifPersonActivityStatus](#bkmrk-niifpersonactivitystatus)
- [niifActiveMemberOf](#bkmrk-niifactivememberof)
- [niifPersonJoinDate](#bkmrk-niifpersonjoindate)
- [niifPersonQuitDate](#bkmrk-niifpersonquitdate)
- [niifPersonOrgID](#bkmrk-niifpersonorgid)
- [niifPersonCityOfBirth](#bkmrk-niifpersoncityofbirth)
- [niifPersonCountryOfBirth](#bkmrk-niifpersoncountryofbirth)
- [niifPersonMothersName](#bkmrk-niifpersonmothersname)
- [niifPersonIdentityNumber](#bkmrk-niifpersonidentitynumber)
- [niifPersonResidentalAddress](#bkmrk-niifpersonresidentaladdress)
- [niifUniqueId](#bkmrk-niifuniqueid)

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

### niifEduPerson

<table id="bkmrk-niifeduperson-parent"><thead><tr><th></th><th>niifEduPerson</th></tr></thead><tbody><tr><td>**Parent**</td><td>eduPerson</td></tr><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.0.9</td></tr><tr><td>**Description**</td><td>-</td></tr><tr><td>**Mandatory attributes**</td><td>-</td></tr><tr><td>**Optional attributes**</td><td>- [niifEduPersonFaculty](#bkmrk-niifedupersonfaculty)
- [niifEduPersonFacultyDN](#bkmrk-niifedupersonfacultydn)
- [niifEduPersonMajor](#bkmrk-niifedupersonmajor)
- [niifEduPersonAcademicYear](#bkmrk-niifedupersonacademicyear)
- [niifEduPersonAttendedCourse](#bkmrk-niifedupersonattendedcourse)
- [niifEduPersonArchiveCourse](#bkmrk-niifedupersonarchivecourse)
- [niifEduPersonHeldCourse](#bkmrk-niifedupersonheldcourse)

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

### niifAuthenticatedObject

<table id="bkmrk-niifauthenticatedobj-1"><thead><tr><th></th><th>niifAuthenticatedObject</th></tr></thead><tbody><tr><td>**Parent**</td><td>-</td></tr><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.0.10</td></tr><tr><td>**Description**</td><td>An object having extra passwords or time-limited validity</td></tr><tr><td>**Mandatory attributes**</td><td>-</td></tr><tr><td>**Optional attributes**</td><td>- [niifEduroamPassword](#bkmrk-niifeduroampassword)
- [niifValidityStart](#bkmrk-niifvaliditystart)
- [niifExpireTime](#bkmrk-niifexpiretime)

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

## Defined attributes

### Attributes of niifPerson

#### niifUniqueID

<table id="bkmrk-niifuniqueid-oid-1.3"><thead><tr><th></th><th>niifUniqueID</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.3</td></tr><tr><td>**Description**</td><td>Unique ID of a person.</td></tr><tr><td>**Semantics**</td><td>&lt;unique-local-ID&gt;@&lt;organization-domain&gt; The &lt;organization-domain&gt; part equals to the main internet domain of the organization (i.e.: 'sztaki.hu').The &lt;unique-local-ID&gt; 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.</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`organizational`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>gmx3f0@bme.hu</td></tr><tr><td>**Notes**</td><td>It is up to the local policy to define how the &lt;unique-local-ID&gt; 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 &lt;unique-local-ID&gt; from a comprehensive user database (like Neptun and ETR at Hungarian Universities) if such a database exists.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPrefix

<table id="bkmrk-niifprefix-oid-1.3.6"><thead><tr><th></th><th>niifPrefix</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.0</td></tr><tr><td>**Description**</td><td>**OBSOLETED**, use [niifPersonPrefix](#bkmrk-niifpersonprefix)</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonPrefix

<table id="bkmrk-niifpersonprefix-oid"><thead><tr><th></th><th>niifPersonPrefix</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.165</td></tr><tr><td>**Description**</td><td>Prefix of the person's name</td></tr><tr><td>**Semantics**</td><td>A name should have only one prefix, multiple entitlements may be listed one after the other in the same value</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`public`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>Prof. Dr.</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>[HREF\_attribútum\_specifikáció#schacPersonalTitle](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)</td></tr></tbody></table>

#### niifStatus

<table id="bkmrk-niifstatus-oid-1.3.6"><thead><tr><th></th><th>niifStatus</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.1</td></tr><tr><td>**Description**</td><td>**OBSOLETED**, use [niifPersonDegree](#bkmrk-niifpersondegree)</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonDegree

<table id="bkmrk-niifpersondegree-oid"><thead><tr><th></th><th>niifPersonDegree</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.166</td></tr><tr><td>**Description**</td><td>Scientific degree of the person</td></tr><tr><td>**Semantics**</td><td>Only the highest degree should be stored.</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`public`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>kandidátus</td></tr><tr><td>**Notes**</td><td>May be specified in multiple languages by the use of language tags</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifTitle

<table id="bkmrk-niiftitle-oid-1.3.6."><thead><tr><th></th><th>niifTitle</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.2</td></tr><tr><td>**Description**</td><td>**OBSOLETED**, use [niifPersonPosition](#bkmrk-niifpersonposition)</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonPosition

<table id="bkmrk-niifpersonposition-o"><thead><tr><th></th><th>niifPersonPosition</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.167</td></tr><tr><td>**Description**</td><td>Position of the person within a department or organization</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>dékán</td></tr><tr><td>**Notes**</td><td>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.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifCertificateSubjectDN

<table id="bkmrk-niifcertificatesubje-1"><thead><tr><th></th><th>niifCertificateSubjectDN</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.151</td></tr><tr><td>**Description**</td><td>Subject DN of the certificate of the entity. This attribute is **OBSOLETED**, use [niifCertificateSHA1Fingerprint](#bkmrk-niifcertificatesha1fingerprint) instead.</td></tr><tr><td>**Semantics**</td><td>The value must describe a DN which identifies the certificate subject of the entity.</td></tr><tr><td>**Values**</td><td>Unlike standard LDAP DN, this value must contain the same number of spaces between DN elements as it is tied in the certificate.</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>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.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifCertificateSHA1Fingerprint

<table id="bkmrk-niifcertificatesha1f-1"><thead><tr><th></th><th>niifCertificateSHA1Fingerprint</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.173</td></tr><tr><td>**Description**</td><td>Fingerprint of a certificate which belongs to the subject.</td></tr><tr><td>**Semantics**</td><td>Multiple fingerprints may be stored in this attribute, if a subject has multiple valid certificates. This attribute uses case insensitive matching rule.</td></tr><tr><td>**Values**</td><td>SHA-1 hash in hexadecimal string format without any separator characters.</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`IA5String`</td></tr><tr><td>**Examples**</td><td>fe6d5980e2c02912024054cec114ee53ebeb2e6c</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonDateOfBirth

<table id="bkmrk-niifpersondateofbirt-1"><thead><tr><th></th><th>niifPersonDateOfBirth</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.152</td></tr><tr><td>**Description**</td><td>Date of birth of the person</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>YYYYMMDD date format according to RFC 3339 'full-date' format</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`confidential`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>19800316</td></tr><tr><td>**Notes**</td><td>It's recommended to use the schacDateOfBirth attribute instead, as it has the same syntax and semantics.</td></tr><tr><td>**Use in federation**</td><td>[HREF\_attribútum\_specifikáció#schacDateOfBirth](https://help.edu.hu/books/aai/page/href-attributum-specifikacio),[HREF\_attribútum\_specifikáció#schacYearOfBirth](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)</td></tr></tbody></table>

#### niifPersonActivityStatus

<table id="bkmrk-niifpersonactivityst-1"><thead><tr><th></th><th>niifPersonActivityStatus</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.153</td></tr><tr><td>**Description**</td><td>Activity status</td></tr><tr><td>**Semantics**</td><td>Describes whether the person is an active employee/student of the home organization</td></tr><tr><td>**Values**</td><td>One of the term 'active' or 'inactive'</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`organizational`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifActiveMemberOf

<table id="bkmrk-niifactivememberof-o"><thead><tr><th></th><th>niifActiveMemberOf</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.168</td></tr><tr><td>**Description**</td><td>DN of a group entry to which the entity currently belongs.</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>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](#bkmrk-niifedupersonmajor) instead.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonJoinDate

<table id="bkmrk-niifpersonjoindate-o"><thead><tr><th></th><th>niifPersonJoinDate</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.169</td></tr><tr><td>**Description**</td><td>Date of joining to the organization</td></tr><tr><td>**Semantics**</td><td>Date of joining to the organization. For students it may represent the first date of enrollment.</td></tr><tr><td>**Values**</td><td>YYYYMMDD date format according to RFC 3339 'full-date' format</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`organizational`</td></tr><tr><td>**Syntax**</td><td>`Integer`</td></tr><tr><td>**Examples**</td><td>19980901</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonQuitDate

<table id="bkmrk-niifpersonquitdate-o"><thead><tr><th></th><th>niifPersonQuitDate</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.170</td></tr><tr><td>**Description**</td><td>Date of leaving the organization</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>YYYYMMDD date format according to RFC 3339 'full-date' format.</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`organizational`</td></tr><tr><td>**Syntax**</td><td>`Integer`</td></tr><tr><td>**Examples**</td><td>20030627</td></tr><tr><td>**Notes**</td><td>If this date is in the past, niifPersonActivityStatus must be 'inactive', and the user should be locked out.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonOrgID

<table id="bkmrk-niifpersonorgid-oid-"><thead><tr><th></th><th>niifPersonOrgID</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.154</td></tr><tr><td>**Description**</td><td>Organizational ID of a person</td></tr><tr><td>**Semantics**</td><td>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 &lt;unique-local-ID&gt; part of the niifUniqueID as a value for niifPersonOrgID.</td></tr><tr><td>**Values**</td><td>For integration with niifUniqueID, value must not contain the '@' mark.</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>It is recommended to import the user ID into &lt;unique-local-ID&gt; 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.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonCityOfBirth

<table id="bkmrk-niifpersoncityofbirt-1"><thead><tr><th></th><th>niifPersonCityOfBirth</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.155</td></tr><tr><td>**Description**</td><td>The city or settlement where the person was born</td></tr><tr><td>**Semantics**</td><td>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.</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`confidential`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>Kolozsvár</td></tr><tr><td>**Notes**</td><td>It's recommended to use the schacPlaceOfBirth attribute instead.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonCountryOfBirth

<table id="bkmrk-niifpersoncountryofb-1"><thead><tr><th></th><th>niifPersonCountryOfBirth</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.156</td></tr><tr><td>**Description**</td><td>The country where the person was born</td></tr><tr><td>**Semantics**</td><td>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.</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`confidential`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>Románia</td></tr><tr><td>**Notes**</td><td>It's recommended to use the schacPlaceOfBirth attribute instead.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonMothersName

<table id="bkmrk-niifpersonmothersnam-1"><thead><tr><th></th><th>niifPersonMothersName</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.157</td></tr><tr><td>**Description**</td><td>Name of the mother of the person</td></tr><tr><td>**Semantics**</td><td>Maiden name of the mother of the person.</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`confidential`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonIdentityNumber

<table id="bkmrk-niifpersonidentitynu-1"><thead><tr><th></th><th>niifPersonIdentityNumber</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.158</td></tr><tr><td>**Description**</td><td>Number of the Identity Card</td></tr><tr><td>**Semantics**</td><td>Number of the Identity Card of the person or Passport Number for those who are non-Hungarian citizens</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`confidential`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>329906AA</td></tr><tr><td>**Notes**</td><td>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.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifPersonResidentialAddress

<table id="bkmrk-niifpersonresidentia-1"><thead><tr><th></th><th>niifPersonResidentialAddress</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.159</td></tr><tr><td>**Description**</td><td>Home address of the person</td></tr><tr><td>**Semantics**</td><td>Permanent home address of the person. The postal code, the name of the city, street and apartment number shall be included.</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`confidential`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>1234 Budapest, Harap u. 3.</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

### Attributes of niifEduPerson

#### niifEduPersonFaculty

<table id="bkmrk-niifedupersonfaculty-1"><thead><tr><th></th><th>niifEduPersonFaculty</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.160</td></tr><tr><td>**Description**</td><td>Faculty of the person</td></tr><tr><td>**Semantics**</td><td>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](http://www.mab.hu/doc/akkrint040106.doc) (in Hungarian)</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`organizational`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>Villamosmérnöki és Informatikai Kar</td></tr><tr><td>**Notes**</td><td>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.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifEduPersonFacultyDN

<table id="bkmrk-niifedupersonfaculty-3"><thead><tr><th></th><th>niifEduPersonFacultyDN</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.161</td></tr><tr><td>**Description**</td><td>Pointer to the faculty of the person</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`organizational`</td></tr><tr><td>**Syntax**</td><td>`DN`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>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.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifEduPersonMajor

<table id="bkmrk-niifedupersonmajor-o"><thead><tr><th></th><th>niifEduPersonMajor</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.162</td></tr><tr><td>**Description**</td><td>Major(s) of the student</td></tr><tr><td>**Semantics**</td><td>Majors are defined at [http://www.mab.hu/listak2.html](http://www.mab.hu/listak2.html) (in Hungarian)</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`organizational`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>műszaki informatikai</td></tr><tr><td>**Notes**</td><td>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.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifEduPersonAcademicYear

<table id="bkmrk-niifedupersonacademi-1"><thead><tr><th></th><th>niifEduPersonAcademicYear</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.163</td></tr><tr><td>**Description**</td><td>Current academic year of the student. This attribute is **DEPRECATED**.</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>Integer numbers from 1 to the number of years required for graduation</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`confidential`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>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.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifEduPersonAttendedCourse

<table id="bkmrk-niifedupersonattende-1"><thead><tr><th></th><th>niifEduPersonAttendedCourse</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.164</td></tr><tr><td>**Description**</td><td>Code of the courses the student attends to in the current semester</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>Course codes defined in the student calendar.</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>1. BMEVIMM1234
2. BMEVIMA3214
</td></tr><tr><td>**Notes**</td><td>This attribute has a meaning only if the person is a student (eduPersonAffiliation = student), and the values should be taken from the student calendar.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifEduPersonArchiveCourse

<table id="bkmrk-niifedupersonarchive-1"><thead><tr><th></th><th>niifEduPersonArchiveCourse</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.171</td></tr><tr><td>**Description**</td><td>Code of the courses the student have ever attended</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>Course codes defined in the student calendar.</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>This attribute has a meaning only if the person is a student (eduPersonAffiliation = student), and the values should be taken from the student calendar.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifEduPersonHeldCourse

<table id="bkmrk-niifedupersonheldcou-1"><thead><tr><th></th><th>niifEduPersonHeldCourse</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.172</td></tr><tr><td>**Description**</td><td>Code of the courses which are associated with the faculty member or professor in the current semester.</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>Course codes defined in the student calendar.</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>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.</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

### Attributes of niifAuthenticatedObject

#### niifEduroamPassword

<table id="bkmrk-niifeduroampassword-"><thead><tr><th></th><th>niifEduroamPassword</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.4</td></tr><tr><td>**Description**</td><td>Clear text password for eduroam authentication</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Octet String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>SUP userPassword</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifValidityStart

<table id="bkmrk-niifvaliditystart-oi"><thead><tr><th></th><th>niifValidityStart</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.5</td></tr><tr><td>**Description**</td><td>When to enable this account</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Generalized Time`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### niifExpireTime

<table id="bkmrk-niifexpiretime-oid-1"><thead><tr><th></th><th>niifExpireTime</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.11914.0.1.6</td></tr><tr><td>**Description**</td><td>When to disable this account</td></tr><tr><td>**Semantics**</td><td>-</td></tr><tr><td>**Values**</td><td>nincs korlátozás</td></tr><tr><td>**\# of values**</td><td>`single`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Generalized Time`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

# Shib2SP

Az SP-t a **`shibboleth2.xml`** állományon keresztül konfigurálhatjuk. Ebben a leírásban feltételezzük, hogy az SP konfigurációja a **`/etc/shibboleth`** könyvtárban van.

## Előkészületek

- [Telepítsük a shibbolethet](https://help.edu.hu/books/aai/page/shibboleth2-sp)
- Válasszunk egy egyedi azonosítót, ún. `entityID`-t az SP számára. Ez az azonosító URL formájú, létező hosztnév, egy - alapértelmezés szerint - /shibboleth path-szal. Pl: [https://lipton.aai.niif.hu/shibboleth](https://lipton.aai.niif.hu/shibboleth). Megfelelő konfiguráció után az entityID-t meghívva válaszul az adott entitás metaadatát kapjuk válaszul.

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

```xml
<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
    xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    clockSkew="180">

    <!--
    By default, in-memory StorageService, ReplayCache, ArtifactMap, and SessionCache
    are used. See example-shibboleth2.xml for samples of explicitly configuring them.
    -->

    <!--
    To customize behavior for specific resources on Apache, and to link vhosts or
    resources to ApplicationOverride settings below, use web server options/commands.
    See https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPConfigurationElements for help.

    For examples with the RequestMap XML syntax instead, see the example-shibboleth2.xml
    file, and the https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRequestMapHowTo topic.
    -->

    <!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
    <ApplicationDefaults entityID="https://events.prace-ri.eu/shibboleth"
                         REMOTE_USER="eppn"
                         cipherSuites="ECDHE+AESGCM:ECDHE:!aNULL:!eNULL:!LOW:!EXPORT:!RC4:!SHA:!SSLv2">

        <!--
        Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
        You MUST supply an effectively unique handlerURL value for each of your applications.
        The value defaults to /Shibboleth.sso, and should be a relative path, with the SP computing
        a relative value based on the virtual host. Using handlerSSL="true", the default, will force
        the protocol to be https. You should also set cookieProps to "https" for SSL-only sites.
        Note that while we default checkAddress to "false", this has a negative impact on the
        security of your site. Stealing sessions via cookie theft is much easier with this disabled.
        -->
        <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
                  checkAddress="false" handlerSSL="false" cookieProps="http">

            <!--
            Configures SSO for a default IdP. To allow for >1 IdP, remove
            entityID property and adjust discoveryURL to point to discovery service.
            (Set discoveryProtocol to "WAYF" for legacy Shibboleth WAYF support.)
            You can also override entityID on /Login query string, or in RequestMap/htaccess.
            -->

                <SSO discoveryProtocol="SAMLDS" discoveryURL="https://mdx.eduid.hu/role/idp.ds">
                 SAML2 SAML1
                </SSO>


            <!-- SAML and local-only logout. -->
            <Logout>SAML2 Local</Logout>

            <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
            <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>

            <!-- Status reporting service. -->
            <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>

            <!-- Session diagnostic service. -->
            <Handler type="Session" Location="/Session" showAttributeValues="false"/>

            <!-- JSON feed of discovery information. -->
            <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>

        </Sessions>

        <!--
        Allows overriding of error template information/filenames. You can
        also add attributes with values that can be plugged into the templates.
        -->
        <Errors supportContact="prace-indico-admin@niif.hu"
            helpLocation="/about.html"
            styleSheet="/shibboleth-sp/main.css"/>

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

        <!-- Example of remotely supplied batch of signed metadata. -->
        <!--
        <MetadataProvider type="XML" validate="true"
              uri="http://example.org/federation-metadata.xml"
              backingFilePath="federation-metadata.xml" reloadInterval="7200">
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
            <MetadataFilter type="Signature" certificate="fedsigner.pem"/>
            <DiscoveryFilter type="Blacklist" matcher="EntityAttributes" trimTags="true"
              attributeName="http://macedir.org/entity-category"
              attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
              attributeValue="http://refeds.org/category/hide-from-discovery" />
        </MetadataProvider>
        -->

        <!-- Example of locally maintained metadata. -->
        <!--
        <MetadataProvider type="XML" validate="true" file="partner-metadata.xml"/>
        -->

        <!-- Map to extract attributes from SAML assertions. -->
        <AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>

        <!-- Use a SAML query if no attributes are supplied during SSO. -->
        <AttributeResolver type="Query" subjectMatch="true"/>

        <!-- Default filtering policy for recognized attributes, lets other data pass. -->
        <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>

        <!-- Simple file-based resolver for using a single keypair. -->
        <CredentialResolver type="File" key="events-shib.key" certificate="events-shib.cert"/>

        <!--
        The default settings can be overridden by creating ApplicationOverride elements (see
        the https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride topic).
        Resource requests are mapped by web server commands, or the RequestMapper, to an
        applicationId setting.

        Example of a second application (for a second vhost) that has a different entityID.
        Resources on the vhost would map to an applicationId of "admin":
        -->
        <!--
        <ApplicationOverride id="admin" entityID="https://admin.example.org/shibboleth"/>
        -->
    </ApplicationDefaults>

    <!-- Policies that determine how to process and authenticate runtime messages. -->
    <SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>

    <!-- Low-level configuration about protocols and bindings available for use. -->
    <ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>

</SPConfig>

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

<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
    xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    logger="syslog.logger" clockSkew="180">

    <!-- The OutOfProcess section contains properties affecting the shibd daemon. -->
    <OutOfProcess logger="shibd.logger">
        <!--
        <Extensions>
            <Library path="odbc-store.so" fatal="true"/>
        </Extensions>
        -->
    </OutOfProcess>

    <!-- The InProcess section conrains settings affecting web server modules/filters. -->
    <InProcess logger="native.logger">
    </InProcess>

    <!-- Only one listener can be defined, to connect in process modules to shibd. -->
    <UnixListener address="shibd.sock"/>
    <!-- <TCPListener address="127.0.0.1" port="12345" acl="127.0.0.1"/> -->

    <!-- This set of components stores sessions and other persistent data in daemon memory. -->
    <StorageService type="Memory" id="mem" cleanupInterval="900"/>
    <SessionCache type="StorageService" StorageService="mem" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
    <ReplayCache StorageService="mem"/>
    <ArtifactMap artifactTTL="180"/>

    <!-- This set of components stores sessions and other persistent data in an ODBC database. -->
    <!--
    <StorageService type="ODBC" id="db" cleanupInterval="900">
        <ConnectionString>
        DRIVER=drivername;SERVER=dbserver;UID=shibboleth;PWD=password;DATABASE=shibboleth;APP=Shibboleth
        </ConnectionString>
    </StorageService>
    <SessionCache type="StorageService" StorageService="db" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
    <ReplayCache StorageService="db"/>
    <ArtifactMap StorageService="db" artifactTTL="180"/>
    -->

    <!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->
    <RequestMapper type="Native">
        <RequestMap applicationId="default">
            <!--
            The example requires a session for documents in /secure on the containing host with http and
            https on the default ports. Note that the name and port in the <Host> elements MUST match
            Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element
            below.
            -->
		<Host name="wiki.aai.niif.hu" authType="shibboleth"
			  requireSession="false" applicationId="wiki.aai"
			  redirectErrors="https://wiki.aai.niif.hu/index.php/Kezd%C5%91lap">
			<Path name="secure" requireSession="true" />
		</Host>
		<Host name="www.aai.niif.hu" authType="shibboleth"
			  requireSession="false" applicationId="www.aai">
			<Path name="secure" requireSession="true" />
		</Host>
        </RequestMap>
    </RequestMapper>

    <!--
    The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined.
    Resource requests are mapped by the RequestMapper to an applicationId that
    points into to this section.
    -->
    <ApplicationDefaults id="default" policyId="default"
        entityID="https://lipton.aai.niif.hu/shibboleth"
        homeURL="https://lipton.aai.niif.hu/shib-error.php"
        REMOTE_USER="eppn persistent-id targeted-id"
        signing="false" encryption="false"
        >

        <!--
        Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
        You MUST supply an effectively unique handlerURL value for each of your applications.
        The value can be a relative path, a URL with no hostname (https:///path) or a full URL.
        The system can compute a relative value based on the virtual host. Using handlerSSL="true"
        will force the protocol to be https. You should also add a cookieProps setting of "; path=/; secure"
        in that case. Note that while we default checkAddress to "false", this has a negative
        impact on the security of the SP. Stealing cookies/sessions is much easier with this disabled.
        -->
        <Sessions lifetime="28800" timeout="3600" checkAddress="false"
            handlerURL="/Shibboleth.sso" handlerSSL="true"
            exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
            idpHistory="false" idpHistoryDays="7">

            <!--
            SessionInitiators handle session requests and relay them to a Discovery page,
            or to an IdP if possible. Automatic session setup will use the default or first
            element (or requireSessionWith can specify a specific id to use).
            -->

            <!-- Directly to the IdP -->
            <SessionInitiator type="Chaining" Location="/Login" id="Intranet"
                    relayState="cookie" entityID="https://idp.niif.hu/shibboleth">
                <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" defaultACSIndex="5"/>
            </SessionInitiator>

			<!-- Discovery Service -->
            <SessionInitiator type="Chaining" Location="/DS" id="DS"
	                      relayState="cookie" acsByIndex="false"
			      isDefault="true" >
                <SessionInitiator type="SAML2" template="bindingTemplate.html"
				  defaultACSIndex="3" />
                <SessionInitiator type="Shib1" defaultACSIndex="5" />
                <SessionInitiator type="SAMLDS" URL="https://ds.niif.hu/"/>
            </SessionInitiator>
	    <SessionInitiator type="Chaining" Location="/SAML1DS" acsByIndex="false" relayState="cookie"
			      id="Saml1Only">
            	<SessionInitiator type="Shib1" defaultACSIndex="6"/>
            	<SessionInitiator type="SAMLDS" URL="https://ds.niif.hu" />
            </SessionInitiator>

            <!--
            md:AssertionConsumerService locations handle specific SSO protocol bindings,
            such as SAML 2.0 POST or SAML 1.1 Artifact. The isDefault and index attributes
            are used when sessions are initiated to determine how to tell the IdP where and
            how to return the response.
            -->
            <md:AssertionConsumerService Location="/SAML2/POST" index="1"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
            <md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
            <md:AssertionConsumerService Location="/SAML2/ECP" index="4"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
            <md:AssertionConsumerService Location="/SAML/POST" index="5"
                Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
            <md:AssertionConsumerService Location="/SAML/Artifact" index="6"
                Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>

            <!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
            <LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
                <LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
                <LogoutInitiator type="Local"/>
            </LogoutInitiator>

            <!-- md:SingleLogoutService locations handle single logout (SLO) protocol messages. -->
            <md:SingleLogoutService Location="/SLO/SOAP"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
            <md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
            <md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>

            <!-- md:ManageNameIDService locations handle NameID management (NIM) protocol messages. -->
            <md:ManageNameIDService Location="/NIM/SOAP"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
            <md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
            <md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>

            <!--
            md:ArtifactResolutionService locations resolve artifacts issued when using the
            SAML 2.0 HTTP-Artifact binding on outgoing messages, generally uses SOAP.
            -->
            <md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

            <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
            <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>

            <!-- Status reporting service. -->
            <Handler type="Status" Location="/Status" acl="127.0.0.1"/>

            <!-- Session diagnostic service. -->
            <Handler type="Session" Location="/Session"/>

        </Sessions>

        <!--
        You should customize these pages! You can add attributes with values that can be plugged
        into your templates. You can remove the access attribute to cause the module to return a
        standard 403 Forbidden error code if authorization fails, and then customize that condition
        using your web server.
        -->
        <Errors session="sessionError.html"
            metadata="metadataError.html"
            access="accessError.html"
            ssl="sslError.html"
            localLogout="localLogout.html"
            globalLogout="globalLogout.html"
            supportContact="root@localhost"
            logoLocation="/shibboleth-sp/logo.jpg"
            styleSheet="/shibboleth-sp/main.css"/>

        <!-- Uncomment and modify to tweak settings for specific IdPs or groups. -->
        <!-- <RelyingParty Name="SpecialFederation" keyName="SpecialKey"/> -->

        <!-- Chains together all your metadata sources. -->
        <MetadataProvider type="Chaining">
           <MetadataProvider type="XML" uri="https://metadata.eduid.hu/current/href.xml"
               backingFilePath="href.xml" reloadInterval="7200">
              <SignatureMetadataFilter certificate="href-metadata-signer-2010.crt"/>
          </MetadataProvider>
           <MetadataProvider type="XML" uri="https://metadata.eduid.hu/current/niifi.xml"
               backingFilePath="niifi.xml" reloadInterval="7200">
              <SignatureMetadataFilter certificate="href-metadata-signer-2010.crt"/>
          </MetadataProvider>
        </MetadataProvider>

        <!-- Chain the two built-in trust engines together. -->
        <TrustEngine type="Chaining">
            <TrustEngine type="ExplicitKey"/>
            <TrustEngine type="PKIX"/>
        </TrustEngine>

        <!-- Map to extract attributes from SAML assertions. -->
        <AttributeExtractor type="XML" path="attribute-map.xml"/>

        <!-- Use a SAML query if no attributes are supplied during SSO. -->
        <AttributeResolver type="Query"/>

        <!-- Default filtering policy for recognized attributes, lets other data pass. -->
        <AttributeFilter type="XML" path="attribute-policy.xml"/>

        <!-- Simple file-based resolver for using a single keypair. -->
        <!-- <CredentialResolver type="File" key="example.key" certificate="example.crt"/> -->

        <!-- Example of a second application (using a second vhost) that has a different entityID. -->
        <!-- <ApplicationOverride id="admin" entityID="https://admin.example.org/shibboleth"/> -->
	<ApplicationOverride id="wiki.aai" entityID="https://wiki.aai.niif.hu/shibboleth" >
		<CredentialResolver type="File" key="wiki.aai.niif.hu.key"
				    certificate="wiki.aai.niif.hu.crt"/>
	</ApplicationOverride>
	<ApplicationOverride id="www.aai" entityID="https://www.aai.niif.hu/shibboleth" >
		<CredentialResolver type="File" key="www.aai.niif.hu.key"
				    certificate="www.aai.niif.hu.crt"/>
	</ApplicationOverride>
    </ApplicationDefaults>

    <!-- Each policy defines a set of rules to use to secure messages. -->
    <SecurityPolicies>
        <!--
        The predefined policy enforces replay/freshness, standard
        condition processing, and permits signing and client TLS.
        -->
        <Policy id="default" validate="false">
            <PolicyRule type="MessageFlow" checkReplay="true" expires="60"/>
            <PolicyRule type="Conditions">
                <PolicyRule type="Audience"/>
                <!-- Enable Delegation rule to permit delegated access. -->
                <!-- <PolicyRule type="Delegation"/> -->
            </PolicyRule>
            <PolicyRule type="ClientCertAuth" errorFatal="true"/>
            <PolicyRule type="XMLSigning" errorFatal="true"/>
            <PolicyRule type="SimpleSigning" errorFatal="true"/>
        </Policy>
    </SecurityPolicies>


</SPConfig>

```

## Minimális beállítások

### Környezeti beállítások

A konfigurációs fájl első negyedében lévő szekciókban elsősorban a Shibboleth futásával kapcsolatos beállítások találhatók, amelyek alapértelmezett értékei legtöbbször megfelelőek az általunk elvárt működéshez.

- `OutOfProcess`
- `InProcess`
- `UnixListener`
- `StorageService`
- `SessionCache`
- `ReplayCache`
- `ArtifactMap`

### RequestMap

A RequestMap megadja azokat a címeket (Host és Path), amelyeket a Shibboleth SP kezelni fog. Szerkezete:

```xml
        <RequestMap applicationId="default">
		<Host name="wiki.aai.niif.hu" authType="shibboleth"
			  requireSession="false" applicationId="wiki.aai"
			  redirectErrors="https://wiki.aai.niif.hu/index.php/Kezd%C5%91lap">
			<Path name="secure" requireSession="true" />
		</Host>
		<Host name="www.aai.niif.hu" authType="shibboleth"
			  requireSession="false" applicationId="www.aai">
			<Path name="secure" requireSession="true" />
		</Host>
        </RequestMap>

```

A RequestMap több Host elemet is tartalmazhat, a Host elem 0 vagy több Path elemet tartalmazhat.

!!! danger "Figyelem"

```
Ha 1-nél nagyobb mélységű könyvtárat (pl. a `/shibtest/shibreq` nevűt) szeretnénk védeni, akkor **nem** adhatjuk meg a *name* paraméterben a "shibtest/shibreq" értéket, hanem egymásba ágyazott Path elemeket kell használni. A *name* paraméter nem tartalmazhat '/' karaktert.

```

Az egyes elemeknél paraméterekkel szabályozhatjuk, hogy az SP milyen módon kezelje a hostot vagy az útvonalat. A paraméterek felüldefiniálhatók. A legfontosabb paraméterek az alábbiak (ezek ugyanúgy használhatók Host-nál mint Path-nál):

- **`requireSession`**: ha értéke "true", akkor az SP csak akkor továbbítja a HTTP request-et az alkalmazás ill. a webszerver felé, ha sikerült létrehozni egy autentikált session-t. Ha "false", akkor az alkalmazás felelős azért, hogy létrehozza a Shibboleth session-t (ún. [lazy session](https://help.edu.hu/books/aai/page/lazy-session)) Alapértelmezés: "false"
- **`exportAssertion`**: ha értéke "true", akkor az SP átadja a teljes, IdP-től kapott Attribute Assertion-t az alkalmazásnak a SHIB\_ATTRIBUTES HTTP mezőben (base64 kódolással). Alapértelmezés: "false"
- **`applicationId`**: lehetőség van arra, hogy bizonyos helyekre érkező kérésekre az SP más és más módon próbáljon meg session-t létrehozni, ezt ún. [Shibboleth Application](#bkmrk-az-sp-t-regisztr%C3%A1lni)-ben konfigurálhatjuk. Ha nem adunk meg értéket, akkor a "default" application-nél megadott értékek vonatkoznak majd a session-re.
- **`redirectError`**: átirányítási hiba esetén a Shibboleth erre az oldalra irányít át - ennek az \[\[isPassive\]\] -ot használó oldalaknál van jelentősége

### ApplicationDefaults

Ennél a szekciónál tudjuk megadni az általános, minden alkalmazásra érvényes alapbeállításokat. Ezek a beállítások természetesen minden egyes alkalmazás tekintetében felüldefiniálhatók.

#### Alapattribútumok

- **`id` (kötelező)**: a alkalmazás elsődleges belső azonosítója. Az alapbeállíásoknál (tehát itt) elvárt érték: **`default`**
- **`policyId` (kötelező)**: a vonatkozó id-jű **`SecurityPoilicies`** szekcióra mutat
- **`entityID` (kötelező)**: egyedi azonosító, amely egyértelműen azonosít egy SP-t. A külső alkalmazások csak ezt az azonosítót látják, belső id-t...stb nem. Többnyire URL formátumú.
- **`homeURL`**:
- **`REMOTE_USER`**: egy prioritási listát adhatunk meg, melynek elemei azok az attribútumok, melyek közül az az első nem NULL értékű kerül beállításra a HTTP\_REMOTE\_USER változóba
- **`signing`**: az XML üzenetek aláírtságára vonatkozó elvárások állíthatók be
- **`encryption`**: az XML üzenetek titkosítására vonatkozó elvárások állíthatók be

#### Sessions

Ennél a szekciónál állíthatjuk be, hogy az SP miként kezelje a Single Sign-on (SSO) folyamatának egyes részeit. Az alapparamétereken túl (session lejárati idő...stb) ún. handlerek találhatók benne. Természetesen az alapbeállítások alkalmazásonként felülírhatók az `<ApplicationOverride>` résznél.

##### Handlerekről

A handlerek az SP-n belül működnek, de a fő folyamatoktól leválasztva. Egy-egy speciális feladatot látnak el - mintegy szkript jelleggel. Egy handler a megfelelő URL meghívásával érhető el. Ezen URL meghívásakor az SP felismeri, hogy mely handlert illeti az adott részfeladat megoldása, és átadja neki a feladat ellátásához szükséges paramétereket. Az SP-n belül egy "alaphandler" található, amely felel a handlereket illető feladatok kiosztásáért, ez jelenti majd a handlerek elérési útvonalában a gyökeret.

##### Alapattribútumok

- **`handlerURL`**: Az alaphandler elérési útja. Alapértelmezés szerint: `"/Shibboleth.sso"`.
- **`handlerSSL`**: Beállítható, hogy kizárólag titkosított csatornán keresztül történhessen a handlerekkel való kommunikáció. Alapértelmezés szerint: `true`
- **`lifetime`**: Beállítható az SP session maximális hossza. Alapértelmezés szerint ez 28800 másodperc. Fontos megjegyezni, hogy az SP session megszűnése nincs közvetlen hatással a Shibboleth által védett alkalmazás által generált sessionre
- **`timeout`**:
- **`checkAddress`**: Megadható, hogy az SP ellenőrizze-e, hogy a felhasználó IP címe egyezik-e az IdP által az asseirton-ben írttal. Alapértelmezés szerint: `true`
- **`exportLocation`**:
- **`idpHistory`**: Igaz érték esetén a SP beállít egy cookie-et, melyhez értékül adja azt az IdP-t, amelynél sikeres autentikáció történt. Alapértelmezés szerint: `false`
- **`idpHistoryDays`**: Megadhatjuk az `idpHistory` cookie érvényességi idejét napokban. Amennyiben nem kerül beállításra, akkor a cookie az adott munkamenet végén lejár

#### SessionInitiator

Ennél a szekciónál kerülnek beállításra azok a paraméterek, melyek meghatározzák, hogy az SP kihez-mihez irányítsa a felhasználót, mikor az érvényes session nélkül (tehát autentikáció előtt) próbálja elérni a Shibboleth által védett tartalmat.

##### Alapattribútumok

- **`type`**: Meghatározza a SessionInitiator típusát. A főbb típusokat lásd lejjebb.
- **`Location`**: Az URL, amely meghívásakor az adott SessionInitiator handler-e aktivizálódik.
- **`id`**: (opcionális) Az adott SessionInitiator-re lehet ezen id által hivatkozni egyéb beállításoknál
- **`entityID`**: Az SP az itt megadott értékben szereplő IdP-hez irányítja az autentikálni kívánó felhasználót
- **`relayState`**: meghatározza, hogy...
- **`acsByIndex`**: igaz érték esetén él a lehetőség, hogy a megfelelő AssertionConsumerService-hez ne teljes URI-val forduljunk, hanem elég legyen csak annak indexét megadnunk.
- **`defaultACSIndex`**: az `acsByIndex="true"` esetén beállítható, hogy alapértelmezés szerint mely indexxel rendelkező AssertionConsumerService-t használjuk

##### SessionInitiator főbb típusai

- **SAML2 SessionInitiator** (Protocol Handler):
    
    `type"SAML2"`
    
    SAML2-es autentikációs folyamatot kezdeményez, és érti a SAML2 szabványon alapuló paramétereket. Mindenképp szükséges, hogy kapjon egy `entityID` paramétert, értékében egy valós IdP entityID-jával.
- **SHIB1 SessionInitiator** (Protocol Handler):
    
    `type"SHIB1"`
    
    Shibboleth 1.x-es autentikációs folyamatot kezdeményez, és SAML 1.1 szabványon alapuló paramétereket ért. Mindenképp szükséges, hogy kapjon egy `entityID` paramétert, értékében egy valós IdP entityID-jával.
- **SAMLDS SessionInitiator** (Discovery Handler):
    
    `type"SAMLDS"`
    
    Az `url` attribútum értékeként megadott helyre irányítja a böngészőt, ahol SAML2 Discovery Service-t vár. A SAML2DS ismeri az [isPassive](https://help.edu.hu/books/aai/page/ispassive)-ot.
- **WAYF SessionInitiator** (Discovery Handler):
    
    `type"WAYF"`
    
    Az `url` attribútum értékeként megadott helyre irányítja a böngészőt, ahol Shibboleth WAYF szolgáltatást vár.
- **Chaining SessionInitiator**:
    
    `type"Chaining"`
    
    Egy Chaining típusú SessionInitiator elem további SessionInitiator elemeket tartalmazhat, melyek felveszik a keret elem attribútumaiban meghatározott tulajdonságokat.

#### MetadataProvider

Ennél a szekciónál kell beállítani, hogy az SP milyen forrásokból jut hozzá a szükséges [metaadatokhoz](https://help.edu.hu/books/aai/page/metadata).

**A források 3 fő típusa**

- XML MetadataProvider
    
    `type"XML"`
    
    SAML2 szabványos XML fájlt tölt be a rendszer. A fájl lehet lokális, vagy távoli, webszerveren keresztül elérhető. Leggyakrabban használt típus. Példa:
    
    ```
      <MetadataProvider type="XML" uri="https://metadata.eduid.hu/current/href.xml"
          backingFilePath="href.xml" reloadInterval="7200">
          <SignatureMetadataFilter certificate="href-metadata-signer-2020.crt"/>
      </MetadataProvider>
    
    ```
    
    A tanúsítvány innen szerezhető be: [https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt)
- Chaining MetadataProvider További `MetadataProvider`-(eke)t tartalmazhat.
- dinamikus, MDQ
    
    ```
      <MetadataProvider type="MDQ" id="href-2020" ignoreTransport="true" baseUrl="https://mdx.eduid.hu/">
          <MetadataFilter type="Signature" certificate="href-metadata-signer-2020.crt"/>
          <MetadataFilter type="RequireValidUntil" maxValidityInterval="864000"/>
      </MetadataProvider>
    
    ```

A tanúsítvány innen szerezhető be: [https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt)

#### ApplicationOverride

Amennyiben az SP több alkalmazást kezel, és ezek között az alkalmazások között vannak olyanok, melyeknek valamely tulajdonsága nem egyezik az SP alapértelmezettként megadott tulajdonságaival (jellemzően ilyen lehet pl. az entityID), akkor ezeket ebben a szekcióban felül lehet definiálni.

## Kiegészítő beállítások

### POST preservation

Ha legalább 2.2-es verziójú Shibboleth SP-t használunk, úgy lehetőségünk van egy olyan funkció beállítására, amely lehetővé teszi, hogy ha egy felhasználó valamilyen formba ír (pl. egy wikibe), akkor a küldés gomb megnyomásakor a shibboleth egy átmeneti helyen eltárolja a beírt adatokat. Ennek jelentősége, hogy ha írás közben lejárt volna a felhasználó sessionje, így alapértelmezés szerint a bejelentkező oldalra dobná a rendszer, ami által elveszne, amit begépelt, úgy bekapcsolt post preservation esetén ezek az adatok megmenekülnek, nem kell őket újra beírni.

A funkció bekapcsolásához a `<Sessions>` elem attribútumaként kell megadni az alábbi két név-érték párt.

- `postData="ss:mem"` , az érték mondja meg, hogy a form adatait az SP mely, a konfigurációs fájl elején definiált Storage Service-en keresztül tárolja. Alapértelmezés szerint a memóriában, de lehetőség van külső tároló megadására is. [További információ a Storage Service-kről](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPStorageService)
- `postTemplate="/etc/shibboleth/postTemplate.html"`

Hiányossága a funkciónak, hogy ha a form tartalmaz `file` típusú `input` mezőt, akkor nem fog működni.

## HREF integráció

1. Az SP-t regisztrálni kell a [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry)-ben
2. Le kell tölteni a metadatához tartozó tanúsítványt a [https://metadata.eduid.hu/current/](https://metadata.eduid.hu/current/) címről, és elmenteni a shibboleth kofigurációs fájljait tartalmazó könyvtárba
3. A [Metadata](#bkmrk-metadataprovider) beállításoknál meg kell adni a HREF metadata elérhetőségét: [https://metadata.eduid.hu/current/href.xml](https://metadata.eduid.hu/current/href.xml)
4. Az `attribute-map.xml` fájlban el kell távolítani a kommentjeleket azon [attribútumok](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) 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

- **Attribútum**: felhasználóra vonatkozó tulajdonság. A föderációban használt attribútumok listája **[itt érhető el](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)**.
- **SP: Service Provider - Szogáltatás**: Webes alkalmazás, amelynek felhasználóit föderatívan valamilyen IdP által autentikáltatja
- **IdP: Identity Provider - Azonosító szervezet**: Feladata a felhasználó azonosítása, felhasználó attribútumainak kiadása SP-k részére
- **Föderáció**: olyan intézmények halmaza, amelyek között lehetséges az azonosítási-információk átadása. Az intézmények - szabályozott keretek között - megbíznak a másik intézmény által kiállított azonosítási-információkban.
- **Entitás**: föderációt alkotó elem (IdP, SP)

## Áttekintés

A Resource Registry az alakuló magyarországi felsőoktatási és kutatási föderáció (HREF) központi eleme, mellyel a föderációban résztvevő szolgáltatások (SP-k) és azonosító szervezetek (IdP-k) adminisztrálását lehet egy letisztult környezetben, elosztott jogosultságokkal végezni. A rendszer az egyes entitásokért felelős adminisztrátorok számára készül.

A rendszer a svájci [SWITCH Intézet](http://switch.ch) által fejlesztett rendszer alapjaira épül, PHP nyelven íródott, adatbázisként MySQL-t használ.

### Funkciók

*A rendszer saját adatbázisból dolgozik, minden funkciójának kimenete ezeken az adatokon alapul.*

- Föderáció-szintű feladata, hogy a központi metaadatot óránként generálja, melyet a résztvevő "entitások" használnak, ezzel garantálva egyfelől a föderáció egységességét, másfelől a megfelelő formátumú metaadat alkalmazásával megteremtse a lehetőséget, hogy a föderáció kiegészítő alkalmazásai (Discovery Service), ill. nemzetközi szintű együttműködésben - bizonyos keretek közt - más föderációk is dolgozhassanak ebből.
- Az [attribútum-szabályzat](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) szintén föderációs szinten állítható, melyeket kiegészítve, az egyes IdP-k megadhatják, hogy mely attribútumokat milyen feltételekkel adják ki, ill. az egyes SP-k is deklarálhatják, hogy milyen attribútumok megléte esetén tudnak egyáltalán működni, mindezt az egyes intézmények adatvédelmi felelősei által kontrolálva.
- Egyénileg, az adott entitás adminisztrátorai által használhatók az egyes IdP-k, SP-k telepítését és konfigurálását megkönnyítő funkciók, melyek a megfelelő beállításokat webes felületen megadva letölthetővé teszik az ezen beállítások alapján automatikusan generált, és jó eséllyel minimális további kézi konfigurációt igénylő fájlokat. Fontos, hogy ezeket a fájlokat nem kötelező használni, ám segítséget jelenthetnek.

**Shibboleth 2.x SP-hez:**

- `shibboleth2.xml`

*Fontos, hogy ezt akkor lehet szinte egy az egyben használni, amennyiben az adott SP csak egy alkalmazást véd. Amennyiben több alkalmazás is igényel Shibbolethet egyazon hoszton, úgy kézzel kell szerkeszteni az xml-t.*

- `attribute-map.xml`
- `attribure-policy.xml`

*Ez a két fájl egy az egyben használható letöltés után, további konfigurációt alapesetben nem igényel.*

**Shibboleth 2.x IdP-hez:**

- `attribute-resolver.xml`

*Ez csak egy keret fájl, a legtöbb olyan elem szerepel benne, amelyeket a helyi viszonyokra szabva már működhet az IdP, ám itt muszáj kézzel is szerkeszteni, pl. LDAP adatok...*

- `attribure-filter.xml`

*A fájl egyből használható* - [további információk](#bkmrk-attrib%C3%BAtumok-kezel%C3%A9se) a fájl előállításának menetéről.

**SimpleSamlPHP-hoz:**

- `AttributeFilter.xml`

*A fájl egyből használható* - [további információk](#bkmrk-attrib%C3%BAtumok-kezel%C3%A9se) a fájl előállításának menetéről.

### Bejelentkezés a rendszerbe

A Resource Registry a [https://rr.eduid.hu](https://rr.eduid.hu) címen érhető el, és bejelentkezni csak föderatív azonosítás után lehet. A nyitóképernyőn a bejelentkezési lehetőségen túl mindössze általános, nyilvános információk érhetők el a föderáció aktuális állapotával kapcsolatban, ill. a rendszer használatához található segítség.

A rendszerbe történő bejelentkezéshez elengedhetetlen, hogy a felhasználót azonosító IdP az alábbi attribútumokat átadja a Resource Registry-nek.

- [eduPersonPrincipalName](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
- [schacHomeOrganizationType](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
- [eduPersonScopedAffiliation](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
- [email](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) - ez belépés után, manuálisan is beállítható

### Szerepek a rendszerben

*A Resource Registrybe csak föderatív azonosítás után lehet belépni.*

**Felhasználó**

- Lehetősége van rá, hogy a föderációhoz szolgáltatást (SP-t) regisztráljon, amely jóváhagyás után élesedhet.

**SP adminisztrátor**

- Ő felelős egy, vagy több, már jóváhagyott SP-ért, ill. elbírálhat felhasználói SP ajánlásokat.

**IdP adminisztrátor**

- Az általa regisztrált és karbantartott IdP-ért felelős.

**RR adminisztrátor**

- A Resource Registry-n belül tevékenykedő felhasználók jogosultságaiért felelős, ő adhat hozzá egyes entitásokhoz újabb adminisztrátorokat, ill. bírálhat el IdP-ket, és SP-ket.

Alapértelmezés szerint, aki be tud lépni, a legegyszerűbb felhasználói jogosultságokat kapja, bármilyen magasabb szintű szerepkört RR adminisztrátor delegálhat számára, a magasabb jogkörrel járó felelősségi kört pontosan körülhatárolva. (Pl. A RR adminsiztrátor a felhasználót az őt azonosító IdP adminisztrátorává tehet, amely nyomán a felhasználó pontosan ezt az egy IdP-t hangolhatja, de felhasználói jogosultságokat már nem oszthat tovább)

**Fontos**, hogy az RR-ben az egyes szerepek egy-egy intézmény adminisztrálásához köthetők, ily módon megvalósítva az elosztott jogosultságkezelést. Egy példán keresztül bemutatva ez azt jelenti, hogy egy felhasználó ha szeretne SP-t felvenni a föderációba, akkor azt csak az őt azonosító intézmény hatókörébe teheti meg, ami azt is jelenti, hogy az adott intézményhez tartozó, RR adminisztrátor jogosultsággal rendelkező felhasználó hagyhatja ezt a regisztrációs-, vagy módosítási kérelmet jóvá. Ugyanez az adminisztrátor csak a saját intézményéhez tartozó entitásokra vonatkozóan oszthat, vagy vonhat vissza jogosultságokat.

Természetesen létezik Power User, aki mindent lát, mindenhez van jogosultsága, de csak nem várt esemény esetén aktivizálódik valahol az NIIF AAI környékén :), amúgy rendeltetésszerű működés esetén a szubszidiaritás elvét képviselve az intézményeké az őket érintő ügyekben a döntési jog.

## Folyamatok

### SP regisztráció

Bárki, akit a rendszer föderatív azonosítással beléptetett, kezdeményezheti egy SP föderációba történő felvételét, ehhez az „SP adminisztráció“ oldalon az „Új SP regisztrálása“ c. menüpontot kell választani. Varázsló segít a regisztrációban, melynek mindössze a telepített SP metaadatának nyilvánosan elérhető url-jét kell megadni (alapértelmezés szerint: https://#HOSTNAME#/Shibboleth.sso/Metadata), majd az automata a lehető legtöbb beállítási paramétert megpróbálja kiolvasni az xml-ből, és egyből beírni az adatbázisba az új SP adatai közé. Mivel minden adatot nem lehetséges az alapértelmezett metaadatból kinyerni, így a regisztráló felhasználónak néhány további adatot kell megadnia ahhoz, hogy véglegesíthesse az SP regisztrációs kérelmet. Ezeket hat csoportra lehet osztani.

- **Alapinformációk**: itt kerülnek megadásra az alapvető, leíró információk, melyek az SP nevét, leírását tartalmazzák, ill. a legfontosabb azonosító, az entityID. Az adatok egy része (pl: entityID) kiderül már a metaadatból is, így a beviteli mezőt már az automata kitöltötte.
- Itt tudjuk meghatározni első körben azt is, hogy az adott SP nyilvános, vagy belső SP legyen. Ennek szellemében kell a megadott feltételes mezőket kitöltenünk. Ha belső SP, akkor csak a legszükségesebb adatok megadása elvárt.
- **Kapcsolattartók**: ha a metaadatból nem derül ki, akkor kézzel kell megadni technikai, adminisztratív, általános...stb. kapcsolattartó személyeket, akik adatai a központi metaadatban is szerepelni fognak.
- **SP Service Locations**: különböző bindingok elérhetőségei – ezt az automata az esetek nagy hányadában jól kiolvassa a metaadatból, emberi módosítást a legritkább esetben igényel. Kivételt képez a *NameIdFormat* meghatározása, mely kapcsán három opció közül választhatunk.
    
    
    - Tranziens opciót kell választanunk, ha SP-nk számára nem fontos, hogy ki a felhasználó, hiszen nem ez alapján dől el, hogy milyen erőforrásokat érhet el, hanem az alapján hogy milyen, a felhasználóra vonatkozó, pl. [eduPersonScopedAffiliation](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) attribútumot állnak az SP rendelkezésére.
    - Perzisztens opciót kell választanunk, ha SP-nk számára fontos, hogy ki a felhasználó ÉS sz SP által védett alkalmazásaink is felkészültek arra, hogy persistent-idt fogadjanak, ezzel dolgozzanak.
    - Nem meghatározott opciót kell választanunk, amennyiben az SP által védendő alkalmazás mind persistent, mind transient NameID fogadására alkalmas.
- *Megjegyzés* Amennyiben most alakítjuk ki az AAI infrastruktúránkat, újonnan állítjuk be az SP-t annak érdekében, hogy valamilyen alkalmazást védjen, akkor *ajánlott*, hogy támogassa a perzisztens azonosítók használatát.
- **Tanúsítványok**: az SP által használt tanúsítványokat kell PEM formátumban megadni – ehhez is segítséget nyújt varázsló helyben, amelynek az SP metadatájának URL-jét címét kell megadni, ami után az automata beolvassa a tanúsítvány(oka)t.
- **Kötelező attribútumok**: itt lehetséges azon attribútumok megadása, melyek kiadása elvárt az IdP-től, amelyek nélkül az SP által védett alkalmazás nem használható.
- Amennyiben egy attribútumot megkövetel az SP használatához, az azt jelenti, hogy az attribútum kiadása nélkül az SP nem lesz használható. Ha egy attribútumot ajánlottnak jelöl, akkor az IdP kiadja, amennyiben implementálta, ám az SP-nek e nélkül is működnie kell. Ha olyan attribútumot jelöl kötelezőnek, amely a föderációs szabály szerint csak ajánlott, vagy opcionális, úgy könnyen előfordulhat, hogy az IdP nem implementálta, így nem is tudja kiadni, aminek következtében a felhasználó nem fogha tudni használni az Ön SP-jét.
- Ideális esetben nincs szükség külön szabályzásra, amennyiben mégis, úgy törekedjen rá, hogy minél kevesebb attribútumot szabályozzon külön!
- **Hallgatóság**: megadhatók, [milyen jellegű IdP-k](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) érhetik el az adott SP-t, ill. amennyiben ez a szabályzás nem lenne elegendő, úgy egyesével is megadhatók IdP-k aszerint, hogy felhasználói használhatják-e az SP-t, vagy sem.
- Amennyiben belső SP-t regisztráltunk, itt állíthatjuk be, hogy minden intézmény jelleget tiltunk, és egy kivételt megadunk: a saját IdP-nket. Ily módon más IdP nem is fog tudni erről az SP-ről, tehát annak ellenére, hogy szerepel a föderációs metaadatban, csak belső használatra lesz alkalmas.

### SP módosítás

Egy jóváhagyott SP-t csak a megfelelő jogosultsággal rendelkező felhasználó tud módosítani. Általában egy-egy SP-hez tartozó adminisztrációs jogot az intézmény *RR adminisztrátor* jogkörrel rendelkező felhasználója osztja ki az adott SP jóváhagyásával egy ütemben.

A módosítás folyamata teljesen analóg a regisztrációéval, ami a funkciókat illeti.

**FONTOS**: Akár regisztráltunk, akár módosítottunk, a változásokat jóvá kell hagynia az Önt azonosító intézet RR adminisztrátorai közül valakinek. Amíg ezek a változtatások bekerülnek a föderációs metaadatba, az legfejjebb egy óra, ám amíg minden föderációs entitás frissíti a metaadatot, így értesül a változásról.

### IdP regisztráció

A föderációba új IdP-t - mivel a regisztrálandó IdP-t üzemeltető kolléga még nem tud belépni a Resource Registry-be - egy, a föderációs adminisztrációért felelős kolléga tud regisztrálni. Ehhez szükséges, hogy az IdP, minden kapcsolódó programmal együtt telepítve legyen, és az alapértelmezett, telepítéskor generált metaadat egy meghatározott url-en elérhető legyen.

A telepítéshez - *Shibboleth esetében* - pl. a [Shib2IdpInstall](https://help.edu.hu/books/aai/page/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](https://help.edu.hu/books/aai/page/shib2idpinstall) pontnál látjuk a megnyugtató `ok` szöveget, és minimális beállításokat megejtettük

Amennyiben ez működik, úgy írni kell egy e-mailt az aai@niif.hu címre, valaki a föderációs adminisztrátorok közül regisztrálja az IdP-t, és a válasz e-mailben elküld két linket, amelyek tartalmaznak két linket az `attribute-resolver.xml` és `attribute-filter.xml` már testreszabott konfigurációs fájlokra mutatva. Ezeket letöltve, bemásolva az IdP-nek már működnie kell alapszinten, így már lehetségessé válik a Resource Registry-be történő belépés. Sikeres belépés után az intézményhez tartozó RR jogosultságokat átadjuk, s a továbbiakban mehet minden a maga utáján, intézményi szinten.

**Nagyon fontos**, hogy az IdP-n bármilyen módosítás **azonnal érvénybe lép**, így rossz beállítás esetén akár az IdP által hitelesíthető felhasználók belépése is ellehetetlenülhet.

**A beállítási lehetőségek az alábbiak**

- **Alapinformációk**: IdP neve, leírása, jellege – technikai ismereteket nem igénylő, leíró jellegű információk
- **Technikai információk**: EntityID, és különböző bindingok elérhetőségei – ezt az automata az esetek nagy hányadában jól kiolvassa a metaadatból, emberi módosítást a legritkább esetben igényel.
- **Tanúsítványok**: az IdP által használt tanúsítványokat kell PEM formátumban megadni – ehhez is segítséget nyújt varázsló helyben, amelynek a webszerver címét kell megadni, ami után az automata beolvassa a tanúsítvány(oka)t.
- **Kapcsolattartók**: ha a metaadatból nem derül ki, akkor kézzel kell megadni technikai, adminisztratív, általános...stb. kapcsolattartó személyeket, akik adatai a központi metaadatban is szerepelni fognak.

A további négy beállítás némi hozzáértést igényel, lévén az alapértelmezett metaadatból nem olvashatók ki. A rendszer ezeket az értékeket a föderációs szabályoknak, megállapodásoknak megfelelően készíti elő, legtöbb esetben nincs szükség módosításra, ám ha mégis, bármilyen speciális igény okán, akkor nagy odafigyeléssel kell beállítani.

- **Támogatott attribútumok**: beállítandó, hogy az IdP mely attribútumokat, milyen formában támogatja. A föderációs szinten kötelezőket mindenképp támogatnia kell.
- **Általános attribútum kiadási szabályok**: beállítható, hogy amennyiben egy SP az adott attribútumot kötelezően, ill. opcionálisan kiadandóként kéri, akkor az IdP hogyan viselkedjen. Ezek a szabályok általánosak, minden, a föderációban résztvevő SP-r vonatkoznak.
- **Speciális attribútum kiadási szabályok**: beállíthatók külön-külön egyes SP-kkel való viselkedés, amennyiben indokolt az általános szabályoktól való eltérés.
- **Telepítési és környezeti információk**: leíró információk, amelyek pl. hiba esetén segítséget adnak a hiba elhárítójának, hogy milyen rendszerrel lesz dolga. Emellett statisztikai célokat is szolgál.

## Attribútumok kezelése

A föderációban használható attribútumok részletes listája a [föderációs attribútum specifikációban](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) található.

Az egyes attribútumokkal kapcsolatban négy irányból lehetséges beállításokat eszközölni

- Minden SP meghatározhatja, hogy mely attribútumok kiadását követeli meg, és melyek kiadását ajánlja (SP beállítások - Kötelező attribútumok menüpont)
- Minden SP meghatározhatja, hogy mely IdP-ktől hajlandó attribútumokat elfogadni (SP beállítások - Hallgatóság menüpont)
- Minden IdP meghatározhatja általánosságban, hogy ha egy SP tőle egy bizonyos attribútum kiadását megköveteli, vagy ajánlja, akkor azt az attribútumot kiadja-e, vagy sem. (IdP beállítások - Általános attribútum kiadási szabályok menüpont)
- Minden IdP meghatározhat SP-specifikus szabályokat, tehát egy-egy SP-re, vagy egy-egy SP egy-egy attribútumára vonatkozólag megadhat az általános beállításaitól eltérő szabályokat - pl. az eduPersonPrincipalName-t ha általában ajánlva kérik az SP-k, akkor kiadja, de XY SP-nek semmiképp nem adja ki. (IdP beállítások - Egyedi attribútum kiadási szabályok menüpont)

[További információ az attribútumok implementációjáról, kapcsolódó fogalmakról](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)**A fenti beállítások eredőjeként generálódik az IdP-k által használandó XML alapú attirbútum filter fájl**

A generált attribútum filter alapvetően tiltó jellegű, tehát az IdP pontosan azokat az attribútumokat és pontosan azoknak az SP-knek adhatja ki, melyek megadásra kerültek a beállításoknál, egyébként semmit.

**Néhány példa a "leképződésre"**

- Ha egy SP kiadásra ajánl egy attribútumot, de az IdP (akár az általános-, akár az egyedi attribútum kiadási szabálya miatt) nem adja ki azt, akkor az XML fájlban komment formájában jelenik meg, hogy ezt és ezt az attribútumot igényelné az SP, de nem kerül kiadásra
- Ha egy SP hallgatóságából kitilt egy IdP-t, akkor az IdP attribútum filterében az adott SP-re vonatkozólag nem jelenik meg semmi, amelynek következtében nem is kerül számára kiadásra semmi

### XML alapú filter

- Shibboleth IdP-nél: `attribute-filter.xml`
- simpleSAMLphp IdP-nél: `AttributeFilter.xml`

A filter fájlok Resource Registry által előállított változatát használni nem kötelező, de fokozottan ajánlott, hiszen ezzel garantálható egyfelől, hogy az IdP-n keresztül autentikáló felhasználók azokat az SP-ket, melyeket el kell tudniuk érni, jól fogják, megfelelő attribútumokkal "a zsebükben" fogják tudni elérni, másfelől így tudnak érvényesülni a feljebb részletezett korlátozó szabályzások.

### Adatvédelmi szempontok

Ha egy SP megváltoztatja attribútum igényeit pozitív irányba (új attribútumokat kér), úgy a változtatás csak akkor fog belekerülni az IdP-k attirbútum filterébe, amennyiben ezt a változtatást tudomásul veszi az IdP oldaláról az illetékes adatvédelmi felelős. Amennyiben egy SP-nél ilyen jellegű változás történik, a rendszer e-mailben értesíti az érintett IdP-k gazdáit, adatvédelmi felelőseit.

### Gyakorlati ajánlás

Kihasználandó a Resource Registry által biztosított lehetőségeket ajánljuk, hogy az IdP-hez tartozó generált attribútum filter fájlt automatikusan töltsék le az IdP-k, bizonyos időközönként (óránként, naponta párszor...), hiszen ezekbe csak úgy kerülhet változtatás, ha azt az IdP adatvédelmi felelőse jóváhagyta, akkor viszont egyből átvezetődik a változtatás, nem szükséges kézzel letölteni, ill. újraindítani az IdP-t. (Shibboleth esetében be kell állítani egy kapcsolót, SSP-nél automatikusan újratölti a friss XML-t)

**A filter elérhetősége**

- Shibboleth IdP: [https://rr.eduid.hu/gen\_attribute-filter.php/href/IDP\_NEVE/attribute-filter.xml](https://rr.eduid.hu/gen_attribute-filter.php/href/IDP_NEVE/attribute-filter.xml)
- simpleSAMLphp IdP: [https://rr.eduid.hu/gen\_attribute-filter-ssp.php/href/IDP\_NEVE/attribute-filter.xml](https://rr.eduid.hu/gen_attribute-filter-ssp.php/href/IDP_NEVE/attribute-filter.xml)

**Útmutató a beállításhoz**

- [Shibboleth](https://help.edu.hu/books/aai/page/shib2idpinstall)
- [simpleSAMLphp](https://help.edu.hu/books/aai/page/simplesamlphp)

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

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

```php

  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](https://help.edu.hu/books/aai/page/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 &amp; 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&amp;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&amp;S-t támogató IdP-nek, amennyiben nincsenek ezen attribútumok tételesen felsorolva, mint `RequestedAttributes`.

#### **`strict`**

Logikai kapcsoló, `true/false` értékeket vehet fel. Amennyiben `true`, úgy csak és kizárólag a modul konfigurációjában megadott EntityCategory-val érkező SP-k számára kerülnek attribútumok kiadásra, "ismeretlen" EntityCategory-val bíró, és EntityCategory nélküli SP-k számára nem kerül kiadásra semmi.

#### **`allowRequestedAttributes`**

Logikai kapcsoló, `true/false` értékeket vehet fel. Amennyiben `true`, úgy megengedjük, hogy egy SP a hozzátartozó EntityCategory konfigurációjában megadott attribútumlistán túl kért attribútumot kiadásra `RequestedAttributes`-on keresztül, `false` esetén csak a listában szereplő attribútumok kiadását engedi a modul. Amennyiben az érték `true` és a `strict` értéke `false`, úgy az "ismeretlen" EntityCategory-val bíró SP-k számára is a `RequestedAttributes` alapján kerülnek kiadásra az attribútumok.

# FedEntitiesLogging

## Naplózási szintek

\*\* Shibboleth naplózási szintek:\*\*

- NONE: semmi
- ERROR: hibaüzenetek (ebben az esetben általában a felhasználó hibát tapasztal)
- WARN: figyelmeztetések
- INFO: az IdP/SP működésével kapcsolatos információk
- DEBUG: hibakereséshez hasznos állapotinformációk (pl. protokoll üzenetek)
- TRACE: (nagyjából) minden információ, ami a szoftver rendelkezésére áll

### Shibboleth IdP audit naplózás

Az IdP audit logok az alábbi információkat tartalmazzák:

- időbélyeg (auditEventTime)
- bejövő kérés binding-ja (requestBinding)
- bejövő kérés azonosítója (requestId)
- távoli fél azonosítója (relyingPartyId)
- messageProfileId
- assertingPartyId
- válasz binding-ja (responseBinding)
- válasz azonosítója (responseId)
- felhasználó helyi azonosítója (principalName)
- azonosítási mód (authNMethod)
- kiadott attribútumok neve (releasedAttributeId1,releasedAttributeId2)
- IdP-SP közötti azonosító (nameIdentifier)
- assertion(ök) azonosítója(i) (assertion1ID,assertion2ID)

## Naplózott adatok

### IdP

#### Apache

- időbélyeg
- IP cím
- referer (SP-re utal)
- böngészőazonosító
- (amennyiben Apache azonosítás van): felhasználó azonosítója

#### Tomcat

#### IdP alkalmazás

- időbélyeg
- Felhasználónév
- SP
- (INFO): küldött attribútumok neve
- Hibaüzenetek: 
    - téves bejelentkezés
    - működési hiba

### SP

#### Webszerver

- Időpont
- referer (IdP-re utal) (???)
- igénybe vett szolgáltatás elérési útja
- (ha állandó azonosítót kap az SP): állandó azonosító

#### Shibboleth SP

- időbélyeg
- IdP
- IP cím
- (INFO): kapott és feldolgozott attribútumok neve

#### SimpleSAMLphp SP

### Discovery Service

#### SWITCH DS

- időbélyeg
- IP cím
- IdP
- SP

A webszerver hasonló adatokat naplózhat (kivéve: IdP választás)

#### Internet2 DS

#### SimpleSAMLphp DS

## Rotálás

## Statisztikák

# HREF_műszaki_előírások

A dokumentum célja, hogy a HREF Föderációhoz csatlakozó Tagok és Partnerek számára elvárásokat és ajánlásokat fogalmazzon meg, melyek a csatlakozáshoz szükséges identitás-menedzsment, valamint üzemeltetési területeket fednek le.

A dokumentumban a **KÖTELEZŐ**, **TILOS**, **AJÁNLOTT**, **NEM AJÁNLOTT** kifejezések értelmezése az alábbiak szerinti:

- **KÖTELEZŐ** (ill. **"KÖTELES"**, **"kell"**) jelentése: a pontban leírtak betartása a föderációba vetett bizalom kiépítéséhez és megtartásához elengedhetetlenül szükségesek, ettől a résztvevők nem térhetnek el;
- **TILOS** jelentése KÖTELEZŐ NEM, azaz a pontban leírtak szerint az intézmény nem járhat el;
- az **AJÁNLOTT** pontoktól való eltéréseket az intézmények dokumentálni kötelesek.
- **NEM AJÁNLOTT** jelentése: amennyiben az intézmény a pontban leírtak szerint jár el, ezt dokumentálni köteles.

## 1. Identitás-menedzsment

- 1.1. Az intézmény köteles adatkezelési elveit dokumentálni, azt a felhasználókkal megismertetni.
- 1.2. Az intézmény köteles a felhasználóiról általa ismert adatok forrását, karbantartásának módját, illetve ezen adatok becsült adatminőségét dokumentálni, és igény esetén ezt a dokumentációt a föderáció tagjainak rendelkezésére bocsátani.
- 1.3. Kötelező a felhasználónevek egyediségét biztosítani.
- 1.4. Egy természetes személyhez nem ajánlott több felhasználói azonosítót rendelni.
- 1.5. Nem ajánlott szerep felhasználók (dékán, igazgató) használata.
- 1.6. Attribútumok használata:
    
    
    - 1.6.1. A megvalósított attribútumokat az IdP-nek az Attribútum Specifikációban leírt módon kell megvalósítani;
    - 1.6.2. Az IdP-nek kötelező megvalósítania az alábbi attribútumokat:
        
        
        - eduPersonTargetedID
        - eduPersonPrincipalName
        - eduPersonScopedAffialiation
    - 1.6.3. Az IdP-nek ajánlott megvalósítania az alábbi attribútumokat:
        
        
        - displayName
        - mail
        - sn
        - givenName
    - 1.6.4. Az IdP-nek kötelező biztosítania, hogy az eduPersonTargetedID és az eduPersonPrincipalName attribútumok ne legyenek újra kioszthatók.
- 1.7. Teszt felhasználók az alábbi megkötések mentén használhatóak:
    
    
    - 1.7.1. minden teszt felhasználót egyértelműen azonosítani és dokumentálni kötelező (az érte felelős munkatárssal együtt),
    - 1.7.2. teszt felhasználóval valós tranzakciót kezdeményezni tilos, kivéve, ha a tranzakcióban részt vevő SP a teszt felhasználó használatához hozzájárult,
    - 1.7.3. ajánlott ezen felhasználókat a megfelelő homeOrganizationType értékkel megkülönböztetni.
- 1.8. Felhasználói azonosító adatokat (pl. jelszó) publikus hálózaton titkosítatlanul továbbítani (felhasználótól bekérni, adatbázisszerver felé kommunikálni) tilos.
- 1.9. A felhasználói jelszavakat ajánlott nem elektronikus formában kiosztani (pl. személyesen, vagy postai úton).
- 1.10. A felhasználók intézményhez fűződő viszonyában bekövetkezett változásokat 7 napon belül kötelező megjeleníteni az IdP adatbázisában és az eduPersonScopedAffiliation attribútum értékében.
    
    
    - 1.10.1. Amennyiben az intézmény külső adatforrást (tanulmányi- ill. bérügyi rendszert) használ a felhasználói adatok tárolására, úgy ez a 7 napos korlát a hiteles adat elsődleges rendszerben történő megváltozásától számítandó.

## 2. Szolgáltatás-menedzsment

- 2.1. Az intézmény köteles a föderációs operátorral való kapcsolattartásra megfelelő szerepkört kialakítani. Ajánlott a kapcsolattartáshoz szerep e-mail címet megadni.
- 2.2. IdP-t üzemeltető intézmény köteles az IdP-vel kapcsolatban végfelhasználói támogatást nyújtani, és ezen támogatás elérhetőségéről a felhasználóit tájékoztatni.
- 2.3. Az intézmény köteles az általa üzemeltett IdP forgalmi adataiból anonimizált, legalább napi felbontású adatokat szolgáltatni a föderációs operátor számára föderációs célú statisztika készítésének céljából.

## 3. Üzemeltetési kérdések

- 3.1. A személyes adatokkal kapcsolatos tranzakciókról kötelező naplóállományt készíteni, és azt legalább 30 napig megőrizni.
- 3.1.1. Az intézmény ezeket a naplókat köteles a hatályos adatvédelmi szabályokkal összhangban kezelni.
- 3.2. Az AAI infrastruktúra komponensei esetén kötelező legalább 2048 bites kulcsok használata.
    
    
    - 3.2.1. Biztosítani kell a privát kulcsok védelmét.
    - 3.2.2. Amennyiben egy kulcs kompromittálódik, az intézmény köteles a föderációs operátort 24 órán belül értesíteni.
    - 3.2.3. Ajánlott hosszú lejáratú, self-signed tanúsítványok használata.
- 3.3. Vonatkozó SAML szabványok
    
    
    - 3.3.1. Kötelező az *Interoperable SAML 2.0 Web Browser SSO Deployment Profile* ([http://saml2int.org](http://saml2int.org)) dokumentumban kötelezőnek megjelölt elemek támogatása
    - 3.3.2. Ajánlott a SAML2 Single Logout profil támogatása HTTP-Redirect illetve SOAP binding felett.
- 3.4. Az IdP köteles minden végpontját HTTPS (SSL/TLS) protokollok segítségével védeni.
- 3.5. Az IdP minden SAML végpontjának az IdP-t üzemeltető intézmény tulajdonában álló DNS domainnek, vagy az alatt levő névnek kell lennie.
- 3.6. Az IdP által használt scope-oknak az IdP-t üzemeltető intézmény tulajdonában álló DNS domainnek, vagy az alatt levő névnek kell lennie.

# OpenSSO_IdP_-_Shibboleth2_SP

## Cél

[http://maszat.sch.bme.hu](http://maszat.sch.bme.hu) -n futó OpenSSO-n IdP létrehozása, és a [https://sandbox.aai.niif.hu/shibboleth](https://sandbox.aai.niif.hu/shibboleth) alatt futó Shibboleth 2 SP-vel való federáció.

## OpenSSO IdP létrehozása

lásd: [OpenSSO](https://help.edu.hu/books/aai/page/opensso)

Cél Realm: /niif-teszt IDP entityID: [https://idp.sch.bme.hu/niif-teszt](https://idp.sch.bme.hu/niif-teszt)Legalább a "signing certificate alias" -t állítsuk be

A /opensso/famadm.jsp -&gt; 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&amp;realm=/niif-teszt](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:

```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](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](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 -&gt; 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](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 &gt; 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

<table id="bkmrk-tulajdons%C3%A1g-%C3%89rt%C3%A9k-in"><thead><tr><th>Tulajdonság</th><th>Érték</th></tr></thead><tbody><tr><td>Intézmény (IdP) neve</td><td>**MTA SZTAKI**</td></tr><tr><td>IdP szoftver</td><td>nincs megadva</td></tr><tr><td>Technikai kapcsolattartó</td><td>Szabó Gyula, sys-admin@sztaki.hu</td></tr><tr><td>Azonosítható felhasználók száma</td><td>400</td></tr><tr><td>Hallgatók száma</td><td>0</td></tr><tr><td>Alkalmazottak száma</td><td>400</td></tr><tr><td>Külsősök száma</td><td>0</td></tr><tr><td>Nem felhasználóhoz köthető bejegyzések száma</td><td>20</td></tr><tr><td>Hallgatók felvételének folyamata</td><td>Nem alkalmazható</td></tr><tr><td>Alkalmazottak felvételének folyamata</td><td>Ú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.</td></tr><tr><td>Külsősök felvételének folyamata</td><td>A SZTAKI külön IdP-ben tartja nyilván a különböző projektekben résztvevő partnereket (*SZTAKI Partners' IdP*), ez az IdP nem része a [HREF](https://help.edu.hu/books/aai/page/href) föderációnak.</td></tr><tr><td>Hallgatók törlésének folyamata</td><td>Nem alkalmazható</td></tr><tr><td>Alkalmazottak törlésének folyamata</td><td>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.</td></tr><tr><td>Külsősök törlésének folyamata</td><td>HREF föderáció szempontjából érdektelen információ</td></tr><tr><td>Felhasználó intézményhez való kapcsolatát leíró attribútum/érték</td><td>IdP-nk csak munkatársakat azonosít, így minden assertion **eduPersonAffiliaton** attribútuma **employee** értékkel van kiállítva.</td></tr><tr><td>Egyes attribútumok származás helye ill. módosításra jogosultak</td><td>Ú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.</td></tr><tr><td>Jelszavak formai követelményei</td><td>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.</td></tr><tr><td>Naplóállományok rendelkezésre állási ideje</td><td>Havonta</td></tr><tr><td>Autentikációs backend</td><td>LDAP</td></tr><tr><td>Autentikációs mód</td><td>Apache</td></tr><tr><td>Vállalt rendelkezésre állás</td><td>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.</td></tr></tbody></table>

# Dunaújvárosi_Főiskola_IdP

<table id="bkmrk-tulajdons%C3%A1g-%C3%89rt%C3%A9k-in"><thead><tr><th>Tulajdonság</th><th>Érték</th></tr></thead><tbody><tr><td>Intézmény (IdP) neve</td><td>**Dunaújvárosi Főiskola `(idp2.duf.hu)`**</td></tr><tr><td>IdP szoftver</td><td>*nincs megadva*</td></tr><tr><td>Technikai kapcsolattartó</td><td>Kovács Csaba, cs.kovacs@mail.duf.hu; Botka István, boti@makacs.duf.hu</td></tr><tr><td>Azonosítható felhasználók száma</td><td>280</td></tr><tr><td>Hallgatók száma</td><td>5200</td></tr><tr><td>Alkalmazottak száma</td><td>130</td></tr><tr><td>Külsősök száma</td><td>0</td></tr><tr><td>Nem felhasználóhoz köthető bejegyzések száma</td><td>5</td></tr><tr><td>Hallgatók felvételének folyamata</td><td>Neptun rendszerben regisztrált hallgató adatai folyamatosan szinkronizálásra kerülnek a címtárral.</td></tr><tr><td>Alkalmazottak felvételének folyamata</td><td>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).</td></tr><tr><td>Külsősök felvételének folyamata</td><td>-</td></tr><tr><td>Hallgatók törlésének folyamata</td><td>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</td></tr><tr><td>Alkalmazottak törlésének folyamata</td><td>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.)</td></tr><tr><td>Külsősök törlésének folyamata</td><td>-</td></tr><tr><td>Felhasználó intézményhez való kapcsolatát leíró attribútum/érték</td><td>1. Oktató/dolgozó: `edupersonAffiliation: employee`
2. Hallgató: `edupersonAffiliation: students`
3. Egyéb alkalmazott: `edupersonAffiliation: member`
4. Külsős munkatársak: nincs `edupersonAffiliation` attribútum vagy `edupersonAffiliation: affiliate`
</td></tr><tr><td>Egyes attribútumok származás helye ill. módosításra jogosultak</td><td>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.</td></tr><tr><td>Jelszavak formai követelményei</td><td>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ő.</td></tr><tr><td>Naplóállományok rendelkezésre állási ideje</td><td>Jelenleg nincs log rotálás</td></tr><tr><td>Autentikációs backend</td><td>LDAP</td></tr><tr><td>Autentikációs mód</td><td>Apache</td></tr><tr><td>Vállalt rendelkezésre állás</td><td>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).</td></tr></tbody></table>

# 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

```bash
#!/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**:

- **ha Apache + PHP, akkor SimpleSAMLphp;**
- **ha Jetty + Java, akkor Shibboleth.**

---

Az IdP-hez javasolt konfiguráció:

- Linux (tetszőleges)
- 2GB RAM, 2 VCPU
- felhasználók által ismert tanúsítvány

# Shibboleth_troubleshooting

- [Session creation error](https://help.edu.hu/books/aai/page/sessioncreationerror)
- [Invalid assertion consumer service URL](#bkmrk-%2A%2Aha-semmi-sem-seg%C3%ADt)
- [Unauthorized identity provider](#bkmrk-%2A%2Aha-semmi-sem-seg%C3%ADt)
- [Clock skew](#bkmrk-%2A%2Aha-semmi-sem-seg%C3%ADt)
- [Unable to locate valid authentication statement](https://help.edu.hu/books/aai/page/errornostatement)
- [HTTP Status 404](#bkmrk-%2A%2Aha-semmi-sem-seg%C3%ADt)

Lásd még: [Internet2 Shibboleth wiki](https://spaces.internet2.edu/display/SHIB/CommonErrors) (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](https://help.edu.hu/books/aai/page/scope)

Az eduPersonPrincipalName és az eduPersonScopedAffiliation használja a [scope](https://help.edu.hu/books/aai/page/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.

- <small>Azaz használható a *hallgato.intezmeny.hu* scope-ként akkor is, ha ez a név nem feloldható a DNS-ből, feltéve, hogy az *intezmeny.hu* létezik és az intézményhez tartozik.</small>

A [HREF Föderációhoz](https://help.edu.hu/books/aai/page/hrefglossary) történő csatlakozáskor a csatlakozó [Azonosító Szervezetnek](https://help.edu.hu/books/aai/page/hrefglossary) kötelező megadnia legalább egy scope-ot.

A megadott scope-ok megjelennek a [metadatában](https://help.edu.hu/books/aai/page/href-metadata-specifikacio), ez alapján az SP-k ellenőrizhetik, hogy az IdP jogosult-e bizonyos attribútum-értékeket kiadni. Az [attribútum specifikáció](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) az alábbi scope-ot használó attribútumokat használja:

- [eduPersonPrincipalName](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
- [eduPersonScopedAffiliation](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)

---

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](https://help.edu.hu/books/aai/page/intezmeny-atnevezes).

# HREF_attribútum_specifikáció

## A specifikáció célja

A föderációban az IdP SAML attribútumokban ad meg adatokat a felhasználóról az SP-nek. Ahhoz, hogy az adatokban hordozott információ átadása pontos legyen, fontos, hogy a használt attribútumokat a két fél ugyanúgy értelmezze.

Az attribútumok pontos meghatározása az attribútumok sémájában található. A specifikációban az alábbi sémákat használtuk fel:

- *person*, *organizationalPerson* (X.521)
- *inetOrgPerson* (RFC2798)
- *eduPerson* ([http://middleware.internet2.edu/eduperson/](http://middleware.internet2.edu/eduperson/))
- *SCHAC* ([http://www.terena.org/activities/tf-emc2/schacreleases.html](http://www.terena.org/activities/tf-emc2/schacreleases.html))
- *niifPerson*, *niifEduPerson* ([NIIFSchema](https://help.edu.hu/books/aai/page/niifschema))

A fenti dokumentumokban definiált attribútumoknak a föderációban való *értelmezését* határozza meg az Attribútum Specifikáció. Ez néhány esetben valamivel szűkebb, mint az eredeti definíció, azért, hogy az információt az SP-k pontosabban értelmezhessék.

A specifikációban felsoroltakon túl az IdP-k tetszőleges attribútumot megvalósíthatnak és kiadhatnak *bilaterális megállapodás* alapján.

## Attribútumok használata

### Meghatározások

- **Implementáció** (megvalósítás): egy IdP abban az esetben *implementál* egy attribútumot, ha az attribútumban hordozott információ a föderációs specifikációnak megfelelő szemantikai és formai követelmények szerint a rendelkezésére áll. Ez jelentheti azt, hogy a felhasználói adatbázisban a felhasználó bejegyzése tartalmazza ezt az attribútumot, de az attribútum más módon is előállhat (pl. statikusan vagy más attribútumokból dinamikusan generálva). Az implementáció részleteivel kapcsolatban a föderáció nem fogalmaz meg megkötést
- **Attribútum kiadás**: az attribútum átadása néhány (vagy a föderációban található összes) SP-nek.

### Implementációs szintek

- **Kötelező**: az attribútumot kötelező az IdP-nek implementálni. (Nem kötelező kiadnia.)
- **Ajánlott**: az attribútumot ajánlott az IdP-nek implementálni, de ez néhány intézménynél lehetetlen vagy nehézségekbe ütközhet
- **Opcionális**: az attribútumot az IdP a saját döntése szerint megvalósíthatja. 
    - Fontos kiemelni, hogy amennyiben egy IdP implementál egy opcionális attribútumot, azt **a specifikáció szerint KÖTELEZŐ megtennie**, azaz követve a specifikáció szemantikai és szintaktikai előírásait.

### SP attribútum-igények

Az SP-k a [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry)-ben, és ezen keresztül a [metadata](https://help.edu.hu/books/aai/page/metadata) állományban jelezhetik, hogy egy attribútum számukra megkövetelt (required) vagy ajánlott (desired).

- **Megkövetelt**: az alkalmazás működéséhez elengedhetetlen az attribútum 
    - pl. `eduPersonPrincipalName` olyan alkalmazásokhoz, amelyek nincsenek felkészítve átlátszatlan (opaque) azonosítók kezelésére
- **Ajánlott**: az alkalmazás működését megkönnyíti az attribútum 
    - pl. a `cn` attribútum átadásakor az alkalmazás nem kéri be a felhasználó teljes nevét regisztrációkor

### Hibakezelés

Abban az esetben, ha egy IdP nem adja ki egy vagy több az SP számára elengedhetetlen attribútumot, az SP-nek KÖTELEZŐ a felhasználónak hibaüzenetet adnia. (Ugyanis egy SP csak abban az esetben jelölhet meg egy attribútumot *megkövetelt attribútumnak*, ha ez az alkalmazás működéséhez elengedhetetlen, minden egyéb esetben *ajánlott*-nak kell megjelölnie.) Azonban ez a hibaüzenet lehetséges, hogy a felhasználó számára nehezen értelmezhető (pl: *Authorization Required*).

Ezért az IdP-k számára AJÁNLOTT kiadni azokat az attribútumokat, amelyeket az SP-k *megkövetelt*-nek jelölnek meg.

## Attribútumok listája

### Lista

#### Kötelező attribútumok

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

#### Ajánlott attribútumok

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

### Állandó felhasználói azonosítók

Bizonyos alkalmazások esetén szükséges alkalmazás-specifikus adatokat is tárolni. Ilyen példa lehet egy webes naptárnál a felhasználóhoz kötődő bejegyzések, vagy egy wikinél a felhasználó szerkesztései. Ezeket az alkalmazások valamilyen helyi adatbázisban tárolják, a kulcs a felhasználó és az adatbázis bejegyzés között pedig egy **állandó azonosító**.

Az állandó azonosítók lehetnek:

- **statikusak**: a felhasználó létrehozásakor megadott adattal megegyezők
- **számítottak**: a felhasználó valamelyik (vagy több) attribútumából algoritmikusan - általában hash eljárással - generáltak
- **tároltak**: ezek általában olyan azonosítók, amelyet az IdP egy adatbázisban elsődleges kulcsként használ, azaz 
    - a felhasználói attribútumok változása esetén is állandó marad
    - egyediségük biztosított

Az azonosítók az alábbi tulajdonságokkal rendelkezhetnek:

- **állandóság**: az IdP-nek gondoskodnia kell arról, hogy a kiosztott azonosító a felhasználó intézménynél töltött életciklusa során állandó legyen. 
    - Amennyiben egy állandó(nak szánt) azonosító mégis megváltozik, az nagyon nehéz helyzetbe hozhatja mind a felhasználót, mind az alkalmazás üzemeltetőt. Erre megoldás lehet a SAML2 NameID Mapping, azonban ezt jelenleg a föderációban használt szoftverek csak részlegesen vagy egyáltalán nem támogatják.
- **nem osztható ki újra** (*non-reassignable*): az IdP-nek gondoskodnia kell arról, hogy egy felhasználó azonosítóját később nem osztja ki másik felhasználónak. 
    - Ennek algoritmikus biztosítása bizonyos esetekben nehézségekbe ütközhet (pl. hash ütközések, illetve bizonyos IdP-k kézzel osztanak azonosítókat), ezért jelen specifikáció csak azt követeli meg, hogy azonosító a gyakorlatban ne tegye lehetővé, hogy az alkalmazás oldalán a felhasználók összekeveredjenek. Különböző IdP-ktől jövő felhasználók azonosítói abban az esetben nem ütközhetnek, ha az azonosítónak része valamilyen, az IdP-re jellemző adat ([scope](https://help.edu.hu/books/aai/page/scope) vagy [entityID](#bkmrk-niifedupersonstudent-1)).
- **nem átlátszó** (*opaque*): az ilyen azonosítók nem jellemzők a felhasználóra, az értékéből nem lehet következtetni a felhasználó személyére (pl. e-mail címére) 
    - Nem minden azonosító rendelkezik ilyen tulajdonsággal, azonban intézmények között adatvédelmi szempontból kifejezetten kívánatos, hogy egy azonosító ne legyen jellemző a felhasználó személyére. A nem átlátszó azonosítót nem célszerű a felhasználók felé megjeleníteni.
- **célzott** (*targeted*): az ilyen azonosítók minden SP-nél különbözőek, s így az SP-k - az IdP közreműködése nélkül - nem képesek profilt készíteni egy felhasználóról, ami adatvédelmi szempontból kívánatos. 
    - Nem minden azonosító rendelkezik ilyen tulajdonsággal.

Az állandó azonosító kiadható attribútumként, illetve a SAML Assertion NameID mezőjében. Bizonyos SP implementációk (pl. a Shibboleth 2.x) képesek arra, hogy az alkalmazás részére elfedjék azt, hogy az azonosító pontosan milyen attribútumban vagy NameID-ben érkezett, pl. úgy, hogy az azonosítót a REMOTE\_USER változóban adják ki az alkalmazás számára.

#### NameID formátumok - melyiket válasszam?

A föderáció elvárja, hogy az IdP-k támogassák mind a tranziens NameID formátumot, mind a célzott, átlátszatlan azonosítót (melyek lehetnek tároltak vagy számítottak). A tárolt azonosítót célszerű SAML2 perszistens NameID-ként kiadni, a számított azonosító azonban csak az eduPersonTargetedID attribútumban adható ki, mivel nem rendelkezik a perszisztens NameID szemantikájával.

A Shibboleth IdP implementáció esetén a számított azonosítókról a tárolt azonosítókra való áttérés nem változtatja meg a kiadott azonosítókat, ezért az SP-k számára ez az áttérés transzparens.

Ha SP-t üzemeltetünk, akkor célszerű már az üzemeltetés kezdetén eldönteni, hogy melyik formátum mellett tesszük le a voksunkat (ez elsősorban az SP által védett alkalmazás képességeitől függ), mert menet közben átállni körülményes, sok energiát igényel. A problémára reméljük könnyebb lesz a megfelelő választ megtalálni az alábbi kérdés átgondolásával: **Szükséges-e az SP számára, hogy egy-egy felhasználójához tartozzon egy-egy állandó azonosító?**

1. Ha nem, akkor egyértelmű a választás: tranziens formátumot kell használni.
2. Ha igen, és nem szükséges, hogy az állandó azonosító a felhasználóra jellemző legyen, ill. az SP mögötti alkalmazás felkészült ilyen azonosító fogadására ( az alkalmazás szempontjából mindegy, hogy milyen úton, tehát eduPersonTargetedID attribútumként, vagy perzisztens NameID-ként érkezik az érték az SP-hez ), akkor az SP-nek *Nem kell meghatároznia, hogy milyen NameID formátumot támogat*, hiszen ezesetben 
    - a) Ha az IdP nem támogatja a tárolt azonosítókat, akkor a tranziens NameID mellé az eduPersonTargetedID attribútumban ki fogja adni a számított (és célzott) azonosítót.
    - b) Ha az IdP támogatja a tárolt azonosítókat, akkor azt perzisztens NameID-ként fogja kiadni (illetve, ha az SP kéri az eduPersonTargetedID attribútumot, az IdP képes ugyanezt a tárolt értéket ilyen formában is kiadni).
    - Az alkalmazáshoz mindkét esetben ugyanaz az érték jut el, mint felhasználói azonosító.
3. Ugyanaz, mint a 2., kivéve, hogy magasabb szintű felhasználókezelést (például SAML NameID menedzsmentet) is szeretne az SP használni, akkor kizárólag perzisztens NameID-t kell kérnie. A HREF föderáció jelenleg nem rendelkezik a magasabb szintű SAML protokollokról, ezért ezek használata kizárólag az adott SP és IdP közötti megállapodáson alapulhat.
4. Ha szükséges, hogy az állandó azonosító a felhasználóra jellemző legyen, őt egyértelműen azonosítsa, akkor a választás tranziens NameID, amely mellé meg kell követelni az eduPersonPrincipalName kiadását.

A HREF föderációban az IdP-k részéről elvárt, hogy a fenti 1-2. megoldásokat támogassák. A 3-4. esetében minden további nélkül előfordulhat, hogy az IdP és SP közötti kommunikáció hibát jelez, mert valamelyik fél nem támogatja a másik fél által megkövetelt / biztosított azonosító formátumot...

!!! info

```
Egy SP a [Resource Registry](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

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

#### eduPersonPrincipalName

<table id="bkmrk-edupersonprincipalna-1"><thead><tr><th></th><th>eduPersonPrincipalName</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonPrincipalName **OID:** 1.3.6.1.4.1.5923.1.1.1.6</td></tr><tr><td>**Rövid leírás**</td><td>**Állandó**, **nem célzott**, **nem újra kiosztható** egyedi azonosító</td></tr><tr><td>**Implementáció**</td><td>kötelező</td></tr><tr><td>**Részletes leírás**</td><td>Formátum: &lt;egyedi\_lokális\_azonosító&gt;@<scope>Ahol2. **&lt;egyedi\_lokális\_azonosító&gt;**: tetszőleges állandó azonosító, amely az intézményen belül egyértelműen azonosítja a felhasználót. Kézenfekvő megoldás a felhasználói azonosító (**uid**) használata, azonban bármilyen más azonosító használható
3. **<scope></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.**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.
</scope></td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>gipsz.jakab@example.org</td></tr></tbody></table>

#### niifPersonOrgID

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

#### schacPersonalUniqueCode

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

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

#### sn

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

#### givenName

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

#### displayName

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

#### mail

<table id="bkmrk-mail-elnevez%C3%A9s-uri%3A-"><thead><tr><th></th><th>mail</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:mail **OID:** 0.9.2342.19200300.100.1.3</td></tr><tr><td>**Rövid leírás**</td><td>A felhasználó email címe</td></tr><tr><td>**Implementáció**</td><td>ajánlott</td></tr><tr><td>**Részletes leírás**</td><td>A felhasználó értesítési e-mail címe. Az így átadott email címről az intézmény biztosítja, hogy2. azt az intézmény biztosítja a felhasználó részére (pl neptunkod@intemzeny.hu)
3. vagy az intézmény a cím rögzítésekor ellenőrizte, hogy az a felhasználó tulajdonában van (pl egy megerősítő levél kiküldésével).Az attribútumban ellenőrizetlen, felhasználó által megadott email címet átadni tilos.
</td></tr><tr><td>**Lehetséges értékek**</td><td>Létező e-mail cím</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Lásd: [RFC 2822](http://www.faqs.org/rfcs/rfc2822.html)`</td></tr><tr><td>**Példa**</td><td>gipsz.jakab@example.org</td></tr></tbody></table>

#### preferredLanguage

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

#### schacDateOfBirth

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

#### schacYearOfBirth

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

#### schacPersonalTitle

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

#### niifPersonMothersName

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

#### niifPersonResidentalAddress

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

#### homePostalAddress

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

#### telephoneNumber

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

#### mobile

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

#### eduPersonNickName

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

#### cn

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

#### jpegPhoto

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

#### labeledUri

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

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

#### eduPersonScopedAffiliation

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

**Megjegyzés:** lehetséges, hogy a föderációban használható értékek körét a későbbiekben szűkíteni fogjuk6. **&lt;scope&gt;**: helyi biztonsági tartomány. A végződése kötelezően egy DNS domain, amely az IdP-t üzemeltető intézmény tulajdonában áll.
Lásd még: [http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201310.html#eduPersonAffiliation](http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201310.html#eduPersonAffiliation)[Egy lehetséges vizuális ábrázolás](#bkmrk-edupersonscopedaffiliation), azonban a halmazok pontos meghatározása az intézmény feladata.</td></tr><tr><td>**Lehetséges értékek**</td><td>A következő értékek egyike: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, valamint a [Scope](https://help.edu.hu/books/aai/page/scope)</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>1. Hallgatók: *student@example.org;member@example.org*
2. Oktatók: *faculty@example.org;employee@example.org;member@example.org*
3. Nem alkalmazott oktató-hallgatók: *student@example.org;faculty@example.org;member@example.org*
</td></tr></tbody></table>

#### eduPersonEntitlement

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

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

#### schacHomeOrganizationType

<table id="bkmrk-schachomeorganizatio-1"><thead><tr><th></th><th>schacHomeOrganizationType</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:schacHomeOrganizationType **OID:** 1.3.6.1.4.1.25178.1.2.10</td></tr><tr><td>**Rövid leírás**</td><td>Az intézmény jellege</td></tr><tr><td>**Implementáció**</td><td>kötelező</td></tr><tr><td>**Részletes leírás**</td><td>1. **university**: Az Oktatási Minisztérium által elismert felsőoktatási intézmények (egyetemek és főiskolák)
2. **nren**: Nemzeti kutatási és felsőoktatási kutatói hálózat szolgáltatója
3. **library**: Könyvtárak
4. **vho**: Virtuális azonosító szervezet egyének föderációs azonosítása céljára
5. **school**: Általános és középiskolák
6. **business**: Ipari vagy kereskedelmi intézmények
7. **other**: Egyéb
8. **test**: Teszt felhasználóról van szó
</td></tr><tr><td>**Lehetséges értékek**</td><td>urn:schac:homeOrganizationType:hu:{university,nren,library,vho,school,business,other,test}</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`URN`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr></tbody></table>

#### ou

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

#### eduPersonOrgUnitDN

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

#### eduPersonPrimaryOrgUnitDN

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

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

#### niifEduPersonAttendedCourse

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

#### niifEduPersonArchiveCourse

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

#### niifEduPersonHeldCourse

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

#### niifEduPersonMajor

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

#### niifEduPersonFaculty

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

#### niifEduPersonFacultyDN

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

#### niifEduPersonStudentCategory

<table id="bkmrk-niifedupersonstudent-1"><thead><tr><th></th><th>niifEduPersonStudentCategory</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** nincs megadva **OID:** 1.3.6.1.4.1.11914.0.1.174</td></tr><tr><td>**Rövid leírás**</td><td>Tanuló/hallgató képzési szintjének meghatározása</td></tr><tr><td>**Implementáció**</td><td>opcionális</td></tr><tr><td>**Részletes leírás**</td><td>A hallgató képzési szintjének pontosabb meghatározása (az [eduPersonScopedAffiliation](#bkmrk-edupersonscopedaffiliation) kiegészítése)4. **bachelor**: bachelor képzésben részt vevő hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): student,member)
5. **master**: master képzésben részt vevő hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): student,member)
6. \* **doctor**: doktori képzésben részt vevő hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): student,member)
7. **exchange-student**: vendéghallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): student,member)
8. **qualifying-studies**: előkészítős hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): member)
9. **open-university**: nyílt egyetemi képzésben részt vevő hallgató (javasolt [affiliation](#bkmrk-edupersonscopedaffiliation): affiliate)
Ha egy hallgató nem sorolható be egyik kategóriába sem (pl. nem bolognai rendszer szerint tanul), akkor az attribútum ne kapjon értéket!</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr></tbody></table>

# 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](https://help.edu.hu/books/aai/page/attributum-feloldas) 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
<?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](#bkmrk-https%3A%2F%2Fspaces.inter) 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](https://help.edu.hu/books/aai/page/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:

- **urn:mace:shibboleth:arp:matchFunction:stringMatch**: *true*, ha két karakterlánc pontosan megegyezik (ez az alapértelmezett illesztési függvény) 
    - <small>ugyanezt jelenti: **urn:mace:shibboleth:arp:matchFunction:exactShar**</small>
- **urn:mace:shibboleth:arp:matchFunction:stringNotMatch**: *true*, ha két karakterlánc eltér
- **urn:mace:shibboleth:arp:matchFunction:regexpMatch**: *true*, ha a karakterlánc megfelel a paraméterként megadott [reguláris kifejezésnek](http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/package-summary.html)
- **urn:mace:shibboleth:arp:matchFunction:regexpNotMatch**: *true*, ha a karakterlánc nem felel meg a paraméterként megadott [reguláris kifejezésnek](http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/package-summary.html)
- **urn:mace:shibboleth:arp:matchFunction:anyValueMatch**: tetszőleges nem üres string esetén *true*

### Target

A Target elemnek kétféle gyermeke lehet:

- `**AnyTarget**`: minden SP-re vonatkozik a szabály (az azonosítatlan SP-kre is!)
- `**Requester**`: a szabály akkor kerül az effective ARP-be, ha az SP [providerId](https://help.edu.hu/books/aai/page/providerid)-je illeszkedik

### Attribute

Egy Rule 0 vagy több Attribute elemet tartalmazhat. Tartalmaznia kell egy `name` paramétert, amely az attribútum teljes neve (általában URN, lásd az [attribútum feloldás leírását](https://help.edu.hu/books/aai/page/attributum-feloldas)). Az elemnek kétféle gyermeke lehet:

- `**AnyValue**`: az attribútum bármely értékére vonatkozik a szabály
- `**Value**`: ebben az esetben kötelezően szerepel egy `**release**` paraméter, melynek értéke *permit* vagy *deny* lehet. Itt is opcionálisan megadható a `**matchFunction**` paraméter.

### Constraint

A Constraint-ek használatával attribútumok kiadását más attribútumok értékéhez is köthetjük, így pl. megtehetjük, hogy a "hozzajarulasBeszerezve" nevű attribútum `true` értékéhez kössük az attribútumok kiadását.

A megkötések konfigurációjához lásd: [https://spaces.internet2.edu/display/SHIB/ArpConstraint](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)

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

```xml
...
<Attribute xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
		   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		   AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName"
		   AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
  <AttributeValue Scope="niif.hu">bajnokk</AttributeValue>
</Attribute>
...

```

## Hivatkozások

- [https://spaces.internet2.edu/display/SHIB/IdPARPConfig](https://spaces.internet2.edu/display/SHIB/IdPARPConfig)
- [https://spaces.internet2.edu/display/SHIB/AttributeReleaseRule](https://spaces.internet2.edu/display/SHIB/AttributeReleaseRule)
- [https://spaces.internet2.edu/display/SHIB/ArpConstraint](https://spaces.internet2.edu/display/SHIB/ArpConstraint)
- [ShARPE ARP Editor](http://mams.melcoe.mq.edu.au/wiki/display/MAMS/Shibboleth+Attribute+Release+Policy+Editor+%28ShARPE%29)

# ShibSPInstallDebian

Ez egy elavult lap, [használd ezt helyette!](#bkmrk-a-telep%C3%ADt%C3%A9s-ut%C3%A1n-az-)

A Debian 4.0 (Etch) már tartalmazza a Shibboleth SP-t (és függőségeit), ezért csak a megfelelő csomagokat kell telepítenünk.

- **Ez igaz, csakhogy a debianos liblog4cpp4 nem thread-safe, ezért a shibd nagyobb terhelésnél elhasal! A probléma javítása folyamatban van...**
    
    ```
      root@hal:~# <b>apt-get install libapache2-mod-shib opensaml-schemas</b>
      Csomaglisták olvasása... Kész
      Függőségi fa építése... Kész
      Az alábbi extra csomagok kerülnek telepítésre:
      libicu36 liblog4cpp4 libsaml5 libshib-target5 libshib6 libxalan110
      libxerces27 libxml-security-c12
      Javasolt csomagok:
      xalan
      Az alábbi ÚJ csomagok lesznek telepítve:
      libapache2-mod-shib libicu36 liblog4cpp4 libsaml5 libshib-target5 libshib6
      libxalan110 libxerces27 libxml-security-c12 opensaml-schemas
      0 frissített, 10 újonnan telepített, 0 eltávolítandó és 18 nem frissített.
      Letöltés az archívumokból: 12,7MB
      Kicsomagolás után 39,6MB lemezterületet használok fel
      Folytatni akarod [Y/n]? <b>y</b>
    
    ```

A telepítés után az Apache webszervert újra kell indítani.

# ShibTest

Ha már úgy gondoljuk, hogy készen vagyunk

- az [IdP beállításaival](https://help.edu.hu/books/aai/page/shibboleth-idp)
- az [SP beállításaival](https://help.edu.hu/books/aai/page/shibboleth-sp)
- és a közöttük érvényes [metadata állomány](#bkmrk-hi%C3%A1nyzik-a-felhaszn%C3%A1) létrehozásával, akkor itt az idő, hogy teszteljük, jól működik-e a nagy egész.

Erre jó kis eszköz a **[Shibenv](https://help.edu.hu/books/aai/page/shibenv)**. Segítségével kilistázhatjuk a felhasználói attribútumokat, a webszerver változókat, illetve a teljes megkapott [SAML](https://help.edu.hu/books/aai/page/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](https://help.edu.hu/books/aai/page/shibboleth-troubleshooting)

### Nincsenek attribútumok

#### Megtörténik-e a session létrehozás?

#### Van session

#### Nincs session

### Hiányoznak bizonyos attribútumok

**Lehetséges okok:**

- Hiányzik a felhasználó attribútuma a felhasználói adatbázisból
- Az IdP-nek nincs joga lekérdezni az adatbázisból az attribútumot (pl. LDAP ACI)
- Az [IdP nem oldja fel az attribútumot](https://help.edu.hu/books/aai/page/shibidpattrib)
- Az [IdP nem adja ki az attribútumot az SP-nek](https://help.edu.hu/books/aai/page/attributum-kiadas).
- Az [SP nem fogadja el az attribútumot az IdP-től](#bkmrk-hi%C3%A1nyzik-a-felhaszn%C3%A1)
- Az IdP nem ismeri fel az SP-t (hiba az IdP és az SP kölcsönös SSL autentikációjában), és csak az autentikálatlan SP-knek kiadható attribútumokat adja ki.

# Szövetségi_alapon_történő_felhasználó_azonosítás_Huntéka_könyvtári_alkalmazásokban

## Könyvtári alkalmazás használati esetei

### Könyvtári és föderatív azonosságok

A könyvtári alkalmazás olvasói nyilvántartásában szereplő és a föderatív azonosítás szolgáltatónál lévő azonosságokat a könyvtári alkalmazásban célszerűen össze kell kapcsolni. Ez az identitás összekapcsolás mindig feltételezi a felhasználó aktív közreműködését, e nélkül az identitások összekapcsolása nem jöhet létre.

Egy föderatív azonosítással elérhető, SP-vel védett Online könyvtári beiratkozás szolgáltatásnál ez egy tájékoztató szöveg megjelenése és tudomásul vétele után történik meg, a már hagyományos módon beiratkozott, az alkalmazás olvasói nyilvántartásában már szereplő olvasók “könyvtári identitását” viszont külön eljárással kell összekapcsolni az IdP által azonosítottakkal.

Ha a könyvtári alkalmazásban már létezik webes azonosítás, akkor célszerű egy olyan komponenst beilleszteni, ahol a felhasználó mind a könyvtári azonosságát (könyvtári azonosító - jelszó), mind a föderatív azonosságát tudja bizonyítani, és a komponens összeköti a két azonosítót a kapcsoló táblában (account linking). A tájékoztató szöveg megjelenítése és annak elfogadása ekkor történhet meg.

Az MTA SZTAKI könyvtára esetében a felhasználók nem tudtak bejelentkezni a webes felületen, az identitás összekapcsolást segítő kulcs az email cím lehetett, ez alapján az összerendelések nagy tömegét elvégezhettük, a maradék azonosítót pedig kézzel, további adatok összehasonlításával, vagy közvetlenül az olvasó megkeresésével lehetett elvégezni.

#### Identitások összekapcsolása

A könyvtári rendszert fel kell készíteni a szövetségi azonosítás során használt azonosítójukkal érkező felhasználók fogadására. Ehhez szükség van egy kapcsoló táblára, ahol a könyvtári azonosítót és a föderált azonosítókat tároljuk.ű

![img](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/accountlinking.png)

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](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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/spinitslo.png)

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

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

```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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/idpinitslo.png)

## Rendszer architektúra

![img](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/huntekamintsprendszerarchitektura.png)

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

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

```bash
mkdir /opt/jetty-home
useradd -d /opt/jetty-home -U -r -s /bin/false jetty
chown jetty:jetty jetty-home
echo "JETTY_USER=\"jetty\"
JETTY_HOME=/opt/jetty-distribution-9.2.<legutóbbi stabil verzió>
JETTY_BASE=/opt/jetty-shibboleth-idp" > /etc/default/jetty
cp /opt/jetty-distribution-9.2.<legutóbbi stabil verzió>/bin/jetty.sh /etc/init.d/jetty
update-rc.d jetty defaults

```

- Az **1-3.** sorban elkészítjük a *jetty* nevű rendszerszintű felhasználót, akinek a nevében fut a szolgáltatás.
- A **4-6.** sorban a szolgáltatás Debian-specifikus beállítóállományába veszünk fel beállításokat. A JETTY\_HOME helyen található a letöltés után kicsomagolt Jetty alkalmazás-konténer. A JETTY\_BASE helyen a Shibboleth 3 IdP alkalmazáshoz beállított Jetty példány helyezkedik el.
- A **7-8.** sorban a rendszer-szolgáltatások könyvtárába másoljuk az indító script-et és bekapcsoljuk az önműködő indulást.

## Dokumentáció

- [https://www.eclipse.org/jetty/documentation/current/startup-unix-service.html](https://www.eclipse.org/jetty/documentation/current/startup-unix-service.html)

# UApprove

!!! warning

```
Ez jelen formájában egy elavult lap, hamarosan frissítésre kerül

```

# uApprove

## Felépítés

Az [uApprove](http://switch.ch/aai/support/tools/uApprove.html) a [SWITCH.ch](http://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

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

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

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

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

```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](https://help.edu.hu/books/aai/page/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](https://help.edu.hu/books/aai/page/arpfilterproposal) (angol)

# URN

## Registrations in the urn:geant:niif.hu Namespace

GEANT has delegated the operation of urn:geant:niif.hu namespace to NIIFI -&gt; 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Ü

<table id="bkmrk-namespace-purpose-da"><thead><tr><th>Namespace</th><th>Purpose</th><th>Date Registered</th><th>Registry link/email</th></tr></thead><tbody><tr><td>urn:geant:niif.hu:niif</td><td>Namespace supporting KIFÜ systems</td><td>10 March 2010</td><td>urn@niif.hu</td></tr><tr><td>-</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>

# Shib2IdpRHEL

## Előkészületek

### entityID

### Tanúsítvány

## JDK

[https://wiki.shibboleth.net/confluence/display/SHIB2/JVMTuning](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.<b>7</b>=edu.internet2.middleware.shibboleth.DelegateToApplicationProvider
```

- **Megj.:** a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!

### Bouncy Castle JCE

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

Ehhez először le kell tölteni a [Bouncy Castle JCE-t](http://www.bouncycastle.org/latest_releases.html). 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.<b>8</b>=org.bouncycastle.jce.provider.BouncyCastleProvider
```

- **Megj.:** a "security.provider." után következő szám mindig a megelőzőnél legyen eggyel nagyobb!

## Tomcat

Tomcat 6-ot fogunk használni, AJP connectorral

[https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare](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:

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

```bash
#!/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**

- [Shibboleth SP telepítés](https://help.edu.hu/books/aai/page/shibboleth-service-provider-sp)

**Konfigurációs leírások**

- [SP alkalmazás konfigurációja](https://help.edu.hu/books/aai/page/shib2sp)
- [Attribútumok használata](#bkmrk-tesztel%C3%A9s)
- [Naplózási beállítások](#bkmrk-tesztel%C3%A9s)
- [Alkalmazás levédése Shibboleth-tel](#bkmrk-tesztel%C3%A9s)
- [Lazy Session használata](https://help.edu.hu/books/aai/page/lazy-session)

---

- [Új SP hozzáadása a föderációhoz](#bkmrk-tesztel%C3%A9s)

---

- [Tesztelés](https://help.edu.hu/books/aai/page/shibtest)

# AAIGettingStarted

# AAI Getting Started

# ElsevierSP

## Speciális eduPersonTargetedID kiadásának beállítása

### Shibboleth IdP alatt

```
vim [/path/to]/shibboleth-idp/conf/attribute-resolver.xml

```

Szúrjuk be az alábbi attribútumdefiníciót, ahol

- a `scope` értéke az intézményi scope (ugyanaz, amit pl. az eduPersonPrincipalName attribútum előállításakor is használ)
- a `sourceAttributeID` értéke a persistent nameID-t előállító attribútum id-je

```php
    <!-- 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](https://help.edu.hu/books/aai/page/shib2idpinstall) a [Resource Registry](https://help.edu.hu/books/aai/page/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:
    
    ```xml
        <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:
    
    ```xml
        <!--  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.

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

```bash
sudo aptitude -t testing install tomcat6

```

### Konfiguráció

Kapcsoljuk ki a `TOMCAT6_SECURITY` opciót az init konfigurációban:

```bash
sudo vim /etc/default/tomcat6

```

Engedélyezzük az ajp konnektort (alapértelmezett konfigurációban ki van kommentezve):

```bash
sudo vim /etc/tomcat6/server.xml

```

```
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

```

## Konfigurálás Shibboleth IdP-hez

### Alkalmazás descriptor

```
sudo cp /etc/tomcat5.5/Catalina/localhost/idp.xml /etc/tomcat6/Catalina/localhost/

```

### Endorsed library-k

```
cd /usr/share/tomcat6/
sudo mkdir endorsed
sudo cp -i ~/shibboleth-identityprovider-2.1.4-slo3/endorsed/* endorsed/

```

### Logok, metadata írása

```
sudo chown -R tomcat6  /var/log/shibboleth-idp/
sudo chown -R tomcat6  /var/run/shibboleth-idp/

```

### Terracotta

```
sudo chown -R tomcat6 /var/log/terracotta/client/

```

## Tomcat 5.5 eltávolítása

```
sudo aptitude remove tomcat5.5
sudo update-rc.d -f tomcat5.5 remove
sudo rm -r /etc/init.d/tomcat5.5 /etc/default/tomcat5.5 /etc/tomcat5.5/ /var/lib/tomcat5.5 /usr/share/tomcat5.5

```

# SP_Operational_Requirements

## Purpose of this document

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

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

- **MUST** (or **SHALL**, **REQUIRED**): the definition is an absolute requirement of the specification in order to build and keep trust in the federation.
- **MUST NOT**: the definition is an absolute prohibition of the specification
- **SHOULD** (or **RECOMMENDED**): there may be valid reasons for ignoring the definition, however, the divergence from the specification **MUST** be documented
- **SHOULD NOT** (or **NOT RECOMMENDED**): there may be valid reasons for the particular behaviour to be acceptable, however, the divergence from the specification **MUST** be documented

## Identity management

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

<table id="bkmrk-193.224.92.0%2F24-193."><thead><tr><th>193.224.92.0/24</th></tr></thead><tbody><tr><td>193.225.14.128/25</td></tr><tr><td>2001:738:0:431::/64</td></tr></tbody></table>

# EduidFedStats

Ezen az oldalon a föderációban résztvevő IdP-k történő becsatornázásáról lehet olvasni.

- eduID statisztikák:
- statisztikai projektről bővebben, angolul: [FederationStats](https://help.edu.hu/books/aai/page/federationstats)

## Általában

Egy IdP-nek naponta egyszer kell beküldenie az összesített, előző napra vonatkozó statisztikáit. A beküldendő fájl az alábbi módon épül fel:

```

ENTITYID <a href="https://idp.niif.hu/idp/shibboleth">https://idp.niif.hu/idp/shibboleth</a>
APIKEY 0123.......
DATE 2009-03-18

STAT AUTH
68 logins

STAT USER_COUNT
16 unique userids

STAT SSO_TO_SERVICE
1        | urn:geant:niif.hu:niifi:sp:register.ca.niif.hu
12       | <a href="https://repo.niif.hu/shibboleth">https://repo.niif.hu/shibboleth</a>
1        | <a href="https://sandbox.aai.niif.hu/shibboleth">https://sandbox.aai.niif.hu/shibboleth</a>
5        | <a href="https://sysmonitor.hbone.hu/shibboleth">https://sysmonitor.hbone.hu/shibboleth</a>
10       | <a href="https://www.ki.iif.hu/shibboleth">https://www.ki.iif.hu/shibboleth</a>
1        | <a href="https://noc6.vh.hbone.hu/shibboleth">https://noc6.vh.hbone.hu/shibboleth</a>
21       | <a href="https://webadmin.iif.hu/shibboleth">https://webadmin.iif.hu/shibboleth</a>
3        | <a href="https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth">https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth</a>
7        | <a href="https://ugyeletes.vh.hbone.hu/shibboleth">https://ugyeletes.vh.hbone.hu/shibboleth</a>
2        | <a href="https://noc.grid.niif.hu/shibboleth">https://noc.grid.niif.hu/shibboleth</a>
1        | <a href="https://wiki.voip.niif.hu/shibboleth">https://wiki.voip.niif.hu/shibboleth</a>
2        | <a href="https://netmonitor.hbone.hu/shibboleth">https://netmonitor.hbone.hu/shibboleth</a>
2        | <a href="https://idp.sch.bme.hu:443/opensso/sp/test">https://idp.sch.bme.hu:443/opensso/sp/test</a>
```

A fájl szerkezetileg két részre osztható. Az első három sorban kerül megadásra, hogy a statisztika miről szól (az idp entityID-ja, egy speciális 40 karakteres azonosítója és a dátum), a továbbiakban pedig az egyelőre három különböző statisztika típusra vonatkozó értékek.

- AUTH: az adott napon történt autentikációk száma
- USER\_COUNT: az adott napon autentikált felhasználók száma
- SSO\_TO\_SERVICE: SP-k szerinti bontásban mutatja, hogy az adott napon egy-egy SP-hez hány felhasználót irányított az IdP

## Teendők

1. Kivonatoló python szkript letöltése. Jelenleg [Shibboleth-hez](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/Audit_shib.py) és [simpleSAMLphp-hez](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/Audit_ssp.py) készítettük el.
2. A beküldendő fájlt elkészítő [szkript](https://help.edu.hu/books/aai/page/federationstats) letöltése - ugyanaz Shibboleth-hez is és impleSAMLphp-hez is, lévén a forrás, melyből dolgoznak (a fenti szkript kimenete) ugyanaz.
3. Az utóbbi szkript elején meg kell adni a beállításokat.

```bash
PARSER_COMMAND="/opt/shibboleth-idp/bin/audit_r7.py" //Az első lépésben letöltött szkript elérési útvonala
SOURCEDIR="/opt/shibboleth-idp/logs" //A statisztika alapját képző logok elérési útvonala
TARGETDIR="/tmp" //Munkakönyvtár - itt hozza létre a beküldendő fájlokat a szkript, majd beküldés után törli is őket innen

ENTITYID="idp-entity-id" //Az idp entityID-je
APIKEY="aaa..." //A 40 karakteres egyedi azonosító. Ezt az első beküldés előtt meg kell kérni: aai@niif.hu
LOCATION2PUT="ttp://eduid.hu/stats/import_stats" //Az eduID statisztikái ezen az url-en keresztül kerülnek fogadásra

//Az alábbi két sorban az audit logokat tartalmazó fájlnév mintáját adjuk meg - ez idp-nként változhat, az alábbi példa egy Shibboleth IdP-re vonatkozik
DATE=`date -d "yesterday" +"%Y-%m-%d"`
SOURCEFILE="$SOURCEDIR/idp-audit-$DATE.log"

```

Mindezek után az utóbbi szkriptet célszerű betenni egy cronjobba, mindennapi futtatással. Érdemes kora hajnali időpontot megadni, hisz ekkor már elérhetők az előző napi statisztikák, és az adott nap munkaidőben pedig már tudjuk nézegetni a beküldött adatokat :)

### Alternatív megoldás

Shibboleth-hez választható cstamas python szkriptje is, amely által kihagyható a shell szkriptes ügyeskedés, és minden egy python configon keresztül adható meg.

- Szkript: [Audit\_shib\_cstamas.py](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/Audit_shib_cstamas.py)
- Példa konfig: [Audit\_shib\_cstamas.cfg](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/Audit_shib_cstamas.cfg)

Használata:

```
review
./Audit_shib_cstamas.py -lupe -d 2010-11-28 --config Audit_shib_cstamas.cfg /tmp/idp-audit-2010-11-28.log

upload
./Audit_shib_cstamas.py -lupe -d 2010-11-28 --config Audit_shib_cstamas.cfg --up /tmp/idp-audit-2010-11-28.log

```

Természetesen a megfelelő beállítások után ezt is napi rendszerességgel kell lefuttatni.

Erre ime egy megoldas, ez cronjobbal vagy valami alternativ utemezovel indithato.

```bash
 #!/bin/sh

 set -e

 cd /ahol-a-script-van
 # vagy a scriptet berakod a pathba es teljes utvonallal hivatkozol a konfigra

 for i in /usr/local/shibboleth-idp-2.2.0-slo9/logs/idp-audit-201*log
 do
   d=$(echo $i | cut -b 53-62)
   # XXX a cut -nak a datumot kell kiszednie a fajlnevbol, igy valtoztatas szukseges
   ./Audit_shib_cstamas.py -lupe -d $d --config Audit_shib_cstamas.cfg --up $i
   gzip -v9 $i
   sleep 5
 done

```

# SessionCreationError

Ha **Session creation failure** üzenetet kapunk, azt jelenti, hogy a Shibboleth SP-nek - ugyan a webszerver modul aktiválódik - nem sikerült létrehoznia megfelelő session-t. Ennek számos oka lehet, de első körben az SP naplóállományában (általában: `/var/log/shibboleth/shibd.log`) kell keresni a hiba okát.

**Lehetséges hibák:**

- Nem fut a shibd
- Nem sikerült csatlakozni az IdP-hez. Ennek is több oka lehet: 
    - Hálózati probléma az IdP és az SP között (default portok: 443, 8443)
    - Az IdP nem válaszol az SP-nek (lásd: [404-es IdP hiba](#bkmrk-https%3A%2F%2Fspaces.inter), load balanced IdP környezetben leginkább)
    - Az IdP tanúsítványa hibás (nem egyezik meg a [metadata állományban](https://help.edu.hu/books/aai/page/metadata) levővel)
    - SSL hiba: 
        - `error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate`, lásd: [Shibbleth tanúsítványok](#bkmrk-https%3A%2F%2Fspaces.inter)
    - Invalid credential: 
        - Lejárt az SP tanúsítványa (Lásd: [Tanúsítvány frissítése](#bkmrk-https%3A%2F%2Fspaces.inter))
        - Nem sikerül hozzáférni a - titkosított - privát kulcshoz

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

```
A felsorolás nem tartalmazza az összes előforduló hibát, kiegészítésre szorul!

```

**Lásd még:**

- [https://spaces.internet2.edu/display/SHIB/BrowserErrors](https://spaces.internet2.edu/display/SHIB/BrowserErrors)
- [https://spaces.internet2.edu/display/SHIB/CPPSPCommonErrors](https://spaces.internet2.edu/display/SHIB/CPPSPCommonErrors)

# Föderáció

Az **Identitás Föderáció** olyan intézmények halmaza, amelyek között lehetséges az identitás-információk átadása. Az intézmények - szabályozott keretek között - *megbíznak* a másik intézmény által kiállított identitás-információkban.

A Föderáció a [pont-pont bizalmi kapcsolati modell](https://help.edu.hu/books/aai/page/pont-pont-bizalmi-kapcsolati-modell) általánosítása. Ekkor nem szükséges egy intézménynek minden egyes társintézménnyel külön megállapodást kötnie, hanem a szövetséghez csatlakozással automatikusan létrejön közöttük a lehetőség az identitás-információk átadására. Általában lehetőség van arra, hogy egy intézmény több Föderációhoz is kapcsolódjon, ill. külön bilaterális megállapodásai legyenek.

## Célja

A föderációk célja, hogy az identitás információk egyébként autonóm rendszerek között átjárhatók legyenek. Ez a következő előnyökkel járhat:

- **redundáns felhasználó-adminisztráció elkerülése**: az identitáshoz kapcsolódó adatoknak elegendő egy helyen rendelkezésre állni; nem kell "idegen", "külsős" felhasználókat felvenni az intézményi adatbázisba
- **Single Sign-on**: a felhasználónak elég egyszer megadni az azonosító adatait, a többi rendszer automatikusan megszerzi az identitáshoz kötődő információkat. Ez egyrészt kényelmesebb a felhasználónak, másrészt megkönnyíti a több faktoros (pl. smartcard) azonosítási módszerek bevezetését.

## Szerepek

A legtöbb [föderációs modell](https://help.edu.hu/books/aai/page/foderacios-modellek) lehetővé teszi azt, hogy egy intézmény egyszerre több szereppel is részt vegyen egy föderációban.

### Identitás szolgáltatók (Identity Provider, IdP)

A felhasználók adatait az identitás szolgáltató tárolja. Az identitás szolgáltató funkciói: **Azonosítás**

- Felhasználó azonosítása
- Felhasználó azonosítással kapcsolatos információk átadása a tartalomszolgálatóknak (SP)
- Tartalomszolgáltatóktól érkező azonosítási kérések (AuthRequest) feldolgozása

**Attribútumok kiadása**

- Felhasználóhoz köthető attribútumok meghatározása
- A tartalomszolgáltató számára hozzáférhető felhasználói adatok átadása a tartalomszolgáltatónak (közvetlenül ill. a felhasználón keresztül)

**Felhasználó menedzsment**

- Felvétel / törlés
- Attribútumok, role-ok kezelése
- Jelszó ill. adatmódosítás

### Tartalom / erőforrás szolgáltatók (Service Provider, SP)

A tartalomszolgáltatók védett tartalmakat szolgáltatnak a felhasználók számára. Általában nincsenek közvetlenül a felhasználókhoz kapcsolatos adataik, ezért nem szükséges a felhasználókat adminisztrálniuk sem.

A tartalomszolgáltató funkciói (a funkciók föderációs modelltől függően ezektől eltérhetnek):

- azonosított kapcsolat létrehozása az identitás szolgáltató segítségével (általában HTTP átirányítás használatával)
- az identitás szolgáltatótól kapott adatok értelmezése
- az identitás szolgáltatótól kapott adatok alapján meghatározni, hogy a felhasználó jogosult-e a művelet végrehajtására (**autorizáció**)

### Metadata adminisztráció

A szolgálatókhoz kötődő háttérinformációkat (pl. tanúsítvány, név, scope, stb.) sok esetben a föderációs szoftver számára is elérhetővé kell tenni, ez esetben [Metadata](https://help.edu.hu/books/aai/page/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)](https://help.edu.hu/books/aai/page/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

- [Föderációs modellek](https://help.edu.hu/books/aai/page/foderacios-modellek)

## Szabályozás

A lazán csatolt modellek (pl. az OpenID) nem igényelnek központi szabályozást, de a magasabb biztonság-igényű, nagy bizalmat igénylő modellek esetén szükséges az, hogy a föderációban résztvevő intézmények kidolgozzák (esetleg szerződésbe is foglalják) az együttműködés feltételeit.

A megállapodás pl. az alábbi területeket érintheti

- Felhasználó-kezelés (pl. lejárt azonosítók inaktívvá tétele, password policy)
- Felhasználói adatok védelme (privacy követelmények)
- Felhasználó-azonosítási technológiák, ezek elnevezése
- Scope-ok kiosztása
- Felhasználói attribútumok használatának a feltételei (pl. milyen feltételekkel mondhatja egy intézmény XY-ról, hogy ő egy *oktató*?)
- Metadata információk karbantartása
- Új intézmény csatlakozásának feltételei (IdP, ill. SP szerepben)
- Audit, nemmegfelelőségi szankciók
- Költségviselés szabályai
- stb.

# SamlSign

Parancssoros eszköz, melyhez debian alatt az `opensaml2-tools` csomagot kell telepíteni. A program kétféle üzemmódban képes működni: **metaadat aláírása** és **metaadat ellenőrzése**.

**Metaadat aláírása**

```
samlsign -s -k /path/to/mainkey.key -f /path/to/metadatatosign.xml

```

Alapértelmezés szerint a samlsign az eredményeket az alapértelmezett kimenetre írja ki (STDOUT), így célszerű ezt egy új fájlba átirányítani:

```
samlsign -s -k /path/to/mainkey.key -f /path/to/metadatatosign.xml > /path/to/metadatasigned.xml

```

**Metaadat ellenőrzése**

```
samlsign -c /path/to/maincert.crt -f /path/to/metadatatosign.xml

```

**Samlsign legfontosabb kapcsolói**

- -s ez határozza meg, hogy aláírunk, vagy ellenőrzünk. Ha megadtuk kapcsolóként, akkor a program megpróbálja aláírni a megadott xml fájlt, ha nem, akkor ugyanezt a fájlt ellenőrizni fogja.
- -f az ellenőrzendő/aláírandó fájl elérhetősége **abszolút útvonallal** megadva
- -k a privát kulcs elérhetősége **abszolút útvonallal** megadva
- -c az ellenőrzésre használt publikus kulcs elérhetősége **abszolút útvonallal** megadva
- [További részletes leírás a samlsign man oldalán](http://man.sourcentral.org/debian-unstable/1+samlsign)

**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](http://www.anandsekar.com/wp-content/uploads/2006/01/ExportPrivateKey.zip). Használata rendkívül egyszerű:

```
java -jar ExportPrivateKey.zip {jks fájl elérhetősége} JKS {jks jelszó} {alias} {célfájl}

```

Ezek után a létrehozott kulccsal már használhatjuk is a samlsign-t.

# FedReqDef

- **KÖTELEZŐ**: az együttműködés minimális feltételeinek biztosítása érdekében egy intézmény vagy szolgáltató nem csatlakozhat a föderációhoz, ha a követelményt nem elégíti ki. A kötelező követelmények megszegése az intézmény kizárását eredményezheti.
- **AJÁNLOTT**: a követelmény nem teljesítése gondokat okozhat más intézményekkel vagy szolgáltatókkal történő együttműködésben, ezért csak alapos okkal lehet a követelménytől eltekinteni. A föderációhoz csatlakozáskor a nem teljesített AJÁNLOTT követelményeket meg kell vizsgálni, és dokumentálni kell.
- **OPCIONÁLIS**: a követelmény teljesítése az intézmény döntésére van bízva.
- **KELL**: lásd **KÖTELEZŐ**
- **LEHETSÉGES**: lásd **OPCIONÁLIS**
- **TILOS**: TODO
- **NEM JAVASOLT**: TODO

# HREFContract

A HREF Föderáció nem jogi személy, így a szerződést formálisan a [Föderációs Operátor](https://help.edu.hu/books/aai/page/hrefglossary) és a [Tag](https://help.edu.hu/books/aai/page/hrefglossary) illetve a [Partner](https://help.edu.hu/books/aai/page/hrefglossary) kötik. A csatlakozáshoz szükséges egy egyoldalú szándéknyilatkozat aláírása is.

A dokumentumok letölthetők [eduid.hu/dokumentumok](http://www.eduid.hu/hu/dokumentumok/) oldalról.

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

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

---

# Metadata

Ahhoz, hogy a [föderációban](https://help.edu.hu/books/aai/page/foderacio) 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](http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf)

A metadata állomány az alábbi fontosabb információkat tartalmazza

- Érvényesség, aláírás
- [Identity Providerek](https://help.edu.hu/books/aai/page/foderacio)
- [Attribute authorityk](#bkmrk-%21%21%21-warning-%22a-sz%C3%B3ci-1)
- [Service Providerek](https://help.edu.hu/books/aai/page/foderacio)
- IdP-k és SP-k tanúsítványai
- IdP-khez és SP-khez kapcsolódó szervezeti és kontakt információk

### Metadata érvényesége és hitelessége

### IdP

### AA

### SP

### Tanúsítványok

### Kontakt információk

### Példák

#### Egy IdP-hez tartozó metadata

A meglehetősen komplex eseteket leszámítva általában az Identity Provider és az [Attribute Authority](#bkmrk-%21%21%21-warning-%22a-sz%C3%B3ci-1) egyetlen entitásként kezelhető.

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

```xml
<EntityDescriptor entityID="https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth">
        <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol">
                <KeyDescriptor use="signing">
                    <ds:KeyInfo>
                        <ds:X509Data>
                                <ds:X509Certificate>
MIIEmjCCA4KgAwIBAgICArwwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCSFUx
DTALBgNVBAoTBE5JSUYxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVz
MRUwEwYDVQQDEwxOSUlGIFJvb3QgQ0EwHhcNMDcxMTMwMTMwNzE4WhcNMDgxMTI5
MTMwNzE4WjBvMQswCQYDVQQGEwJIVTEQMA4GA1UEChMHTklJRiBDQTEOMAwGA1UE
CxMFSEJPTkUxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMSUwIwYDVQQDExxycmQt
bWEucGVyZnNvbmFyLnZoLmhib25lLmh1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC2x6Hpjr4yB6EDkXUHNMlHz250kqWBXf/UI6TziV5rvMjvS8pdFnsZcIt1
coT03Fu4wzs6N8gtC5uW7f3JaBsG32sYZUorWcbecpgVy5ttcIqTM1RnxUsOktsM
RuBz7qYAQ1/B9VvBH7P7DeREgIGm7Skel/Q3Qhl4oG9PtFe1wQIDAQABo4IB3DCC
AdgwEQYJYIZIAYb4QgEBBAQDAgbAMA4GA1UdDwEB/wQEAwIE8DAaBgNVHREEEzAR
gQ9wb2xha292aUBpaWYuaHUwggFZBgNVHR8EggFQMIIBTDCBvKBboFmkVzBVMQsw
CQYDVQQGEwJodTENMAsGA1UEChMETklJRjEgMB4GA1UECxMXQ2VydGlmaWNhdGUg
QXV0aG9yaXRpZXMxFTATBgNVBAMTDE5JSUYgUm9vdCBDQYECAN6iWaRXMFUxCzAJ
BgNVBAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZpY2F0ZSBB
dXRob3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMIGKoCmgJ4YlaHR0cDov
L3d3dy5jYS5uaWlmLmh1L25paWYtY2EtY3JsLmNybIECAN6iWaRXMFUxCzAJBgNV
BAYTAmh1MQ0wCwYDVQQKEwROSUlGMSAwHgYDVQQLExdDZXJ0aWZpY2F0ZSBBdXRo
b3JpdGllczEVMBMGA1UEAxMMTklJRiBSb290IENBMB8GA1UdIwQYMBaAFIxuIeJx
r6Aqp7Dk/rx+o/0PoOOIMBkGA1UdIAQSMBAwDgYMKwYBBAHdCgEBCQEAMA0GCSqG
SIb3DQEBBQUAA4IBAQAVuG4+KUxQZcYCedQmW6Ih83gqMS7inxfBFeadc4Ts1egY
Wf6Y4CoEOrsdI7FmC7CCccarDaMC6PVJg1WlDV01LMGM2+6rcoMeMs/J5pCFTDhn
c6MPz6KedRcMvVJajY+BZvJPG9CNpyxdiUf/aDa28yRryVM0Jbm6BOFH+UrVHlVw
w2JxlmsHtk1fNmEU7gluzwo3FEZrx8nnLWkeTfMzz/iM+dudNm4sL99uGNEWGNFf
tLi+R35McE7CfyNNfOvlskZX++dSX/Re8CERTo3wZrHmFKIoOnJzo6v48d2tEbw0
a15Yl93MJCNlC5BUyvUMqKDLmHhTxmgO+HIaV7Kf
                                </ds:X509Certificate>
                        </ds:X509Data>
                    </ds:KeyInfo>
                </KeyDescriptor>

                <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>

                <AssertionConsumerService index="1" isDefault="true"
                        Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
                        Location="https://rrd-ma.perfsonar.vh.hbone.hu/Shibboleth.sso/SAML/Artifact"/>
                <AssertionConsumerService index="2"
                        Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
                        Location="https://rrd-ma.perfsonar.vh.hbone.hu/Shibboleth.sso/SAML/POST"/>
        </SPSSODescriptor>
</EntityDescriptor>

```

## Shibboleth 1.3

A Shibboleth (mind az SP, mind az IdP) a metaadatokat kizárólag a másik féllel kapcsolatban használja, tehát a saját konfigurációjával kapcsolatban figyelmen kívül hagyja.

Az 1.3-as verzió kizárólag lokális állományokkal dolgozik (ez változni fog a 2.0-ban).

### Scope

A Shibboleth 1.3 kiterjesztette a SAML2 metadata struktúrát egy saját, `Scope` mezővel. Ez a "scope" igazából egy *postfix* tagot definiál, melynek segítségével bizonyos attribútumok értelmezési helye jól meghatározható.

Erre jó példa az `eduPersonPrincipalName` attribútum, mely a felhasználó egyedi azonosítóját adja meg. Ez az azonosító két részből áll:

- egy intézményen belüli egyedi azonosítóból (pl. `bajnokk`)
- az intézmény azonosítójából, a scope-ból (pl. `niif.hu`)

Ha a metadatában használjuk a `Scope` mezőt, akkor az SP ellenőrizni tudja, hogy az IdP jogosult-e ilyen scope-pal rendelkező attribútumot kiadni.

Szintén gyakran használt scope-os attribútum az `eduPersonScopedAffiliation`.

### Metadata eszközök

- [Metadatatool](#bkmrk-%21%21%21-warning-%22a-sz%C3%B3ci-1)
- [Siterefresh](#bkmrk-%21%21%21-warning-%22a-sz%C3%B3ci-1)

### 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](#bkmrk-%21%21%21-warning-%22a-sz%C3%B3ci-1) és a [Metadatatool](#bkmrk-%21%21%21-warning-%22a-sz%C3%B3ci-1) 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](https://help.edu.hu/books/aai/page/simplesamlphp) 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

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

# AAIInterop-Shib2SimpleSAMLphp

!!! bug "Elavult információ"

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

```

# Shibboleth2 IdP - SimpleSAMLphp SP Interoperabilitás

- IdP: [papigw-shibboleth2-idp.xml](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/papigw-shibboleth2-idp.xml)
- SP: [papigw-simplesaml-saml2-sp.xml](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/papigw-simplesaml-saml2-sp.xml)

## SAML2.0 Single Sign on

### HTTP-Post

- Működik
- A SimpleSAMLphp nem támogatja a NameID titkosítását, csak az egész assertion titkosítását (FIXME) 
    - ezért be kell állítani hogy a NameID-t ne titkosítsa az IdP, ugyanígy kényszeríteni kell az Attribute Push használatát is

```
<RelyingParty id="https://papigw.aai.niif.hu/simplesaml"
   provider="https://papigw.aai.niif.hu/idp/shibboleth"
   defaultSigningCredentialRef="IdPCredential">
   <ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
      encryptNameIds="never" includeAttributeStatement="true"/>
</RelyingParty>

```

- A SimpleSAMLphp SP metaadatába kézzel kell beletenni az aláíró és titkosító publikus kulcsokat, mivel a kiexportált metaadat ezeket nem tartalmazza (ráadásul a php-s konfigurációban szereplő certificate/privatekey paramétereket nem lehet abszolut elérési úttal hivatkozni, mindenképp a cert/ könyvtárban kell lenniük)

### HTTP-Artifact

- A SimpleSAMLphp nem támogatja a HTTP-Artifact bindingot (és általában a SOAP-ot használó bindingokat)

### Attribute push

- Működik

### Attribute pull

- A SimpleSAMLphp nem támogatja az AttributeRequest protokollt (a SOAP binding miatt)

### NameIDFormat

- Általában urn:oasis:names:tc:SAML:2.0:nameid-format:transient

## SAML2.0 Single Log out

- A SimpleSAMLphp támogatná az SLO-t, de a shibboleth2 IdP nem. A metaadatnál panaszkodik is hogy a Shibboleth metadata nem tartalmaz SingleLogoutService-t.

# DrupalShibbolethReadmeDev

Drupal **shib\_auth** module enables [Shibboleth](http://shibboleth.internet2.edu) authentication for [Drupal CMS](http://drupal.org).

## 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](http://drupal.org/project/shib_auth).
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](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPProtectContent) 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](https://help.edu.hu/books/aai/page/drupal-shibboleth-module) to dump the whole **$\_SERVER** array. If you can see Shibboleth attributes there, you're fine.

In Shibboleth there are two modes for protecting resources:

- **Lazy Sessions**: session is only initiated if an application redirects user to the SessionInitiator URL. In this module, it is done by clicking the *"Login with Shibboleth"* link. Anonymous access is possible as well as using other authentication methods. This is what you want to use for a CMS that contains *public information*. 
    - <small>Detailed description of [lazy sessions](https://help.edu.hu/books/aai/page/lazy-session) in Hungarian.</small>
- **"Strict" Sessions** (normal sessions): users can only access Drupal content if they have a valid Shibboleth session. In this case, no anonymous access can be granted (not even read-only) and you can not use any auxiliary authentication methods. Most of the advanced features don't work with strict sessions. You should not use this unless you want to protect all the information in the CMS from viewing.

!!! note

```
after enabling "strict" sessions, you won't be able to login with admin user. [Read on further](#bkmrk-administering-drupal-with-strict-sessions) how to give your own user administrator rights.

```

##### Example Shibboleth configuration

!!! note

```
this example uses lazy sessions.

```

**/etc/shibboleth/shibboleth2.xml snippet**:

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

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

- <small>Keep in mind that some users might have a specific attribute while others don't.</small>

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

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

```

Then your

- **Login URL** is: `http(s?)://your_fully_qualified_domain_name/Shibboleth.sso/Login`
- **Logout URL** is: `http(s?)://your_fully_qualified_domain_name/Shibboleth.sso/Logout`

!!! note

```
Most common errors are (please check Shibboleth documentation):

* using *http* when your Shibboleth SP is configured for *https* only (either by Apache settings or the*handlerSSL* parameter)
* you want to use another SessionInitiator (for example with Discovery Service), such as `/DS`

```

##### Attribute settings

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

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

##### Redirecting authenticated users to HTTPS

It's a common problem if Shibboleth SP is configured on HTTPS only (`handlerSSL="true"`), while the site also works on plain HTTP. By using *Force HTTPS on login* feature, you can redirect your users to HTTPS at login time. This way you can have your anonymous users view your site unencrypted (which saves some CPU cycles), but once they login, they get redirected to HTTPS (which is the only secure use of Shibboleth SP).

!!! note

```
If you don't see Shibboleth attributes in DEBUG although you have double checked that you have set `AuthType shibboleth`, `require shibboleth` in your `.htaccess` file, you most probably need to turn this feature on.

```

## Understanding features

### Automatic user creation

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

Drupal needs 3 pieces of information to create a new user:

- username
- e-mail address
- password

The module by default uses the username and e-mail address taken from the `$_SERVER` headers, see \[Attribute settings\](#bkmrk-attribute settings) right above. On new user creation a random password is generated. This can be overwritten by the user unless you [disallow it](#bkmrk-disallowing-password-change) 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](http://drupal.org/project/userprotect)
2. At Administer -&gt; User management -&gt; User Protect -&gt; Protected roles tab check **password** for the *authenticated user* role.
3. At Administer -&gt; Permissions -&gt; userprotect module: uncheck **change own password** for *authenticated user*
4. Log in with a normal account, go to "My account" -&gt; 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**:

```sql
INSERT INTO shib_authmap (uid, targeted_id)
  SELECT uid, name
  FROM users
  WHERE uid > 1 AND (uid) NOT IN
    (SELECT uid
    FROM shib_authmap);

INSERT INTO authmap (uid, authname)
  SELECT uid, targeted_id
  FROM shib_authmap
  WHERE (uid) NOT IN
    (SELECT uid
    FROM authmap);

UPDATE authmap SET module = 'shib_auth'
WHERE (uid) IN
  (SELECT uid
  FROM shib_authmap);

```

!!! note

```
These queries add all your existing users to `shib_authmap` with their usernames and make sure that your `authmap` table contains all of the user entries. You should optimize these queries if you have a large number of users.

```

!!! danger "Figyelem"

```
You should repeat these queries each time after you add pre-created users.

```

### Role assignment

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

An assignment rule is made of three parameters:

- **$\_SERVER** header name: name of the Shibboleth-derived attribute
- **Value regexp**: regexp applied to (all) the value(s) of the Shibboleth-derived attribute
- **Role(s)**: checklist of roles to be assigned to the matching users

#### Dynamic rules (default)

Dynamic rules add roles to the user, but **do not save them to the user's profile**. This means that

- the roles assigned by dynamic rules are **NOT displayed on the user page**, even though the permissions assigned to the role are in effect
- the roles assigned by dynamic rules are **automatically revoked** if the Shibboleth attributes change (ie. `eduPersonAffiliation` changes from `student` to `alum`),
- thus if the user logs in by other means than Shibboleth, the rule will not be triggered, so the roles will not be assigned.

Additional roles can be assigned statically to the user (as an individual) by the administrator as normally. Every logged in user gets the role `Authenticated user` automatically.

#### Sticky rules

On the other hand, sticky rules do **save the roles to the user's profile**. Thus

- the roles assigned by sticky rules are displayed on the user page,
- the roles are not revoked automatically by the module,
- the roles will be in effect regardless of the login procedure.

### User profile mapping

From the 7.x-4.2 version (D6 is not supported) it is possible to define a mapping between Shibboleth attributes and Drupal Fields. You must have the *Field UI* and the *Shibboleth profile fields* modules enabled to use this functionality. Unlike other features of the module, this mapping is configured together with the field definition.

Go to *Administration » Configuration » People » Account settings » Manage fields* (`admin/config/people/accounts/fields`) and create a new field or edit an existing one. The Shibboleth mapping is available on the Field Edit form and can be used in three ways:

- *Disabled*: no mapping (this is the default);
- *Initial value from Shibboleth, later editable by User*: the value of the mapping is only assigned to the field if the field has no values;
- *Always update value on User login, not editable by User*: the field is updated on every login.

You can use the values of the server variables by referring to them with square brackets like `[sn]`. You can reference multiple server variables in one mapping. Anything that is not matched to a server variable will be treated as string and copied to the value of the field. The server variable match is case insensitive.

As an example, consider the user's request containing the following server variables (regardless of being set by Shibboleth or by something else):

```
[givenName] -> John
[sn]        -> Doe
[email]     -> jdoe@example.com

```

The following mappings would produce the results as indicated:

`[sn], [givenName] <[email]>` ***Doe, John <jdoe@example.com>***`[firstName] [sn]` ***\[firstname\] Doe*** (note the mistaken header name)

### Account linking

There might be cases when you have a number of existing users and you want them to (optionally) log in through the federation. If you enable **account linking**, a user can add her SSO login to her existing Drupal account. The process of adding an SSO login -&gt; 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`:

```xml

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

```

### User consent

In certain scenarios you are only allowed to store personal data if the user accepted some kind of legal agreement such as the Terms of Use or the Privacy Policy.

When a new user arrives, she gets a screen with a link to the legal document and a checkbox. This page also contains the user's name and the e-mail address. Personal data required for login are stored only if the user accepts the agreement. If it's allowed by the administrator, the user might set [custom values](#bkmrk-using-custom-values) for those attributes.

If the document changes, the administrator might increment the version. This case all users are forced to accept the new version of the agreement before logging in.

!!! note

```
Version matching is an exact match, so the user must accept exactly the same version what was specified by the administrator

```

#### Personal data handled by the module

- username
- user's e-mail address
- user's targeted identifier(s) (what is sent by the IdP, if different from username), along with a mapping to the Drupal username
- Identity Provider(s) that identified the user
- random password (this might not be considered personal data)
- time of the registration

### Advanced SAML2 features

SAML2 defines several properties of the authentication request message which may affect the authentication performed by the IdP.

!!! warning

```
**Be careful when using these options.**

IdPs that do not support these features might signal an error instead of performing any kind of authentication of the user. Or might show errors *after* authenticating the user. Some kind of authentication handlers (ie. HTTP Basic Auth) will never work even if the IdP software is capable of handling these properties.

```

#### isPassive

If `isPassive` is set, then the user is redirected to the IdP or to the Discovery Service in advance, but neither of them are allowed to take over the control of the user interface (such as performing any visible authentication). If authentication (or IdP selection) can not be performed silently, an error is returned, which is then handled by the module.

By using this option, you can auto-login users who are already logged in to the IdP even if you are using lazy sessions. If auto-login can not be performed, the user returns to Drupal unauthenticated without seeing any error message.

!!! danger "Figyelem"

```
You need to instruct Shibboleth to redirect errors back to Drupal to handle passive authentication failures. This is done by setting `redirectErrors` parameter in the RequestMap. See [Shibboleth wiki](https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPContentSettings) for details.

**IMPORTANT**: current implementation does not handle any errors except for NoPassive error. This means, that on every possible Shibboleth SP error you will get an unauthenticated Drupal page instead of a Shibboleth error page.

```

!!! note

```
this feature requires JavaScript.

```

#### forceAuthn

This feature requires reauthentication of the user at the IdP even if she is having an SSO session there. Just like isPassive, it's not generally supported by authentication handlers.

In general, you should never mix **isPassive** and **forceAuthn**. The standard states that in this case, the IdP must reauthenticate the user without visibly taking control of the user interface. It's up to you, how you interpret it...

#### Non-implemented features

There are several other SAML features which are not yet implemented, because there seems to be very little practical interest for them. Please file a feature request if you really need them, but before doing so, please, spend a little time on thinking how things should really work.

- **AuthnContextClass**: the SP can request some specific authentication context from the IdP.
- **NameID management**: the IdP can request to change the user's NameID (targeted identifier) or to remove it.
- **Logout notification**: this is a Shibboleth2 feature, not a SAML one. You generally do not need this, because you can terminate the Drupal session on Shibboleth session expiry. This workaround has the disadvantage that the module will not be notified at the time when the user was logged out, only on the next page refresh.

## Change log

### Version 3.0 -&gt; 3.1

If you need documentation for 3.0, please [use the previous version of the documentation](https://wiki.aai.niif.hu/index.php?title=Drupal_Shibboleth_module&oldid=906)

## Release notes

### Version 4.0

**Bug fixes**

- The module now works with caching enabled
- Code refactoring

**New features**

- Allow specifying Drupal username, thus support opaque identifiers
- Support for sticky rules (roles saved permanently to the users' profile)
- Basic support for account linking
- Basic support for getting user consent on personal data
- Support for isPassive and forceAuthn session initiation
- Support for redirecting users to HTTPS on login

# Shib3IdpAuth

Shibboleth 3 Identity Provider (IdP) hitelesítés

## Shibboleth 3 OpenLDAP címtárhoz kapcsolása

Szerkesszük az *{idp.home}/conf/ldap.properties* állományt az alábbiak szerint

```ini
...
## 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](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

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

```xml
<resolver:AttributeDefinition id="cn" xsi:type="simple:Simple"
        xmlns="urn:mace:shibboleth:2.0:resolver:ad">

```

- **id** - az attribútum egyedi neve (nagyon fontos a jó névválasztás :)
- **xsi:type** - értéke lehet `Simple` vagy `Scoped`, de mivel a második nem szabványos, így törekedni kellene a `Simple` használatára
- **xmlns** - alapértelmezett értéke: `urn:mace:shibboleth:2.0:resolver:ad`

Az `<AttributeDefinition>` elemen belül meg kell adni az attribútum függőségét és az attribútum kódolási tulajdonságait

**Attribútumok függősége**

Egy attribútum függhet bármilyen más, az attribute-resolver.xml fájlban definiált elemtől, legyen az másik `<AttributeDefinition>`, vagy `<DataConnector>`. Egy attributum több más elemtől is függhet. Az egyetlen attribútuma a forrás elem azonosítója.

`<resolver:Dependency ref="ID_DEPENDENCY1" />`

**Attribútumok kódolási tulajdonságai**

Egy attribútumhoz többféle kódolási mechanizmust megadhatunk, melyek meghatározzák, hogy az attribútum kiadásakor milyen formátum(ok)ban lesz elérhető az aktuális attribútum értéke. Ha nem adunk meg kódolási mechanizmust, alapértelmezetten `SAML2String` alapon kódol. Egy kódolás megadása az `<AttributeEncoder>` elem segítségével történik. A szükséges attribútumok

- **xsi:type** - értéke a kódolás típusa
- **xmlns** - alapértelmezett értéke: `urn:mace:shibboleth:2.0:resolver:encoder`
- **name** - a megadott típuson belüli azonosító
- **friendlyName** - :)

*Példa*

```xml
<resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                           name="oid:1.3.6.1.4.1.5923.1.1.1.7"
                           friendlyName="commonName" />


```

## Kapcsolódások adattárakhoz

Ahhoz, hogy megkaphassuk az egyes attribútumokhoz tartozó értéket, valamilyen adattárból (adatbázis, címtár) kell őket kinyernünk, hiszen ekkor még csak a sikeres azonosítás után tartunk, és csak a felhasználói nevet tudjuk, amivel az azonosítás megtörtént. **Fontos**, hogy az egyes kapcsolódások definiálásakor erre a felhasználói névre a **`$requestContext.principalName`** néven hivatkozhatunk, amely kiindulópontként szolgálhat lekérdezéseinkhez.

### Kapcsolódás címtárhoz

**1. Konnektor definiálása**

Új adatbáziskapcsolat létrehozásához definiálnunk kell a konnektort `<DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc">` az alábbi attribútumokkal

*Attribútumok, melyeket kötelező megadni*

- **id** - egyedi azonosító, mellyel az attribútum definicióknál elérhetjük a konnektort
- **ldapURL** - a címtár elérési útja. Több is megadható vesszőkkel elválasztva, ekkor a megadott sorrend alapján addig próbálkozik, amíg valahol nem tud csatlakozni
- **baseDN** - a címtárban való kereséshez tartozó BaseDN
- **principal** - a címtár bind-olására használandó felhasználói név
- **principalCredential** - a címtár bind-olására használandó felhasználói névhez tartozó jelszó

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

```xml
<resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                        id="UNIQUE_ID"
                        ldapURL="LDAP_URL"
                        baseDN="BASE_DN"
                        principal="PRINCIPAL_NAME"
                        principalCredential="PRINCIPAL_CREDENTIAL">

    <FilterTemplate>
        <![CDATA[
            (uid=${requestContext.principalName})
        ]]>
    </FilterTemplate>

     <!-- Ide kerülhet a lekérdezési eredmény mezőneveinek és értékeinek felüldefiniálása -->

</resolver:DataConnector>

```

### Kapcsolódás relációs adatbázisokhoz

**1. Konnektor definiálása**

Új adatbáziskapcsolat létrehozásához definiálnunk kell a konnektort `<DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc">` az alábbi attribútumokkal

*Attribútumok, melyeket kötelező megadni*

- **id** - egyedi azonosító, mellyel az attribútum definicióknál elérhetjük a konnektort

*Attribútumok, melyeket opcionálisan megadhatók*

- **readOnlyConnection** - logikai érték, mely meghatározza, hogy az adatbázis csak olvasható, vagy esetleg írható is. Alapértelmezés szerint `true`, azaz csak olvasható
- **queryUsesStoredProcedure** - logikai érték, mely meghatározza, hogy az 5. lépésnél bemutatott módon definiált SQL lekérdezések használhatnak-e előre meghatározott eljárásokat. Alapértelmezés szerint nem, azaz `false`
- **cacheResults** - logikai érték, mely meghatározza, hogy a lekérdezés eredménye eltárolható-e a felhasználó munkamenetének lejártáig. Alapértelmezés szerint igen, azaz `true`

```xml
<resolver:DataConnector xsi:typ="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                        id="UNIQUE_ID">

     <!-- Ide kerülnek majd az további konfigurációs beállítások a következő lépések alapján -->

</resolver:DataConnector>

```

**2. Függőségek definiálása**

*Opcionális*

**3. Másodlagos adatkapcsolat definiálása**

*Opcionális*

**4/a. Idp által natívan vezérelt adatbáziskapcsolatok beállítása**

Az Idp alkalmazás által vezérelt kapcsolathoz definiálnunk kell egy `<ApplicationManagedConnection>` elemet az alábbi (mind kötelezően megadandó) attribútumokkal

- **jdbcDriver** - a JDBC meghajtó teljes elérési útvonala
- **jdbcURL** - URL, melyen elérjük az adatbázist
- **jdbcUserName** - adatbázis eléréséhez tartozó felhasználó
- **jdbcPassword** - a fenti felhasználóhoz tartozó jelszó

*Példa MySQL adatbázis eléréséhez*

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

```xml
<resolver:DataConnector xsi:type="RelationalDatabase" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                        id="UNIQUE_ID">

     <!-- Ide kerülhetnek a függőségek a másodlagos adatkapcsolatokkal kapcsolatos beállítások -->

     <ContainerManagedConnection resourceName="RESOURCE_NAME" />

     <QueryTemplate>
          <![CDATA[
               SELECT * FROM PEOPLE WHERE userid='$requestContext.principalName'
          ]]>
     </QueryTemplate>

     <!-- Ide kerülhet a lekérdezési eredmény mezőneveinek és értékeinek felüldefiniálása -->

</resolver:DataConnector>

```

**6. Lekérdezési eredmény mezőneveinek és értékeinek felüldefiniálása**

*Opcionális*

Alapértelmezés szerint a lekérdezések eredményét mezőnevenként és a hozzákapcsolódó értékként egy-egy attribútumba szervezi a konnektor, melyet lehetőségünk van felüldefiniálni, ehhez a `<Column>` elemet használhatjuk az alábbi atttribútumokkal

*Kötelező megadni*

\***columnName** - az lekérdezés eredményének mezője, mellyel kapcsolatban módosításokat hajtanánk végre

*Az alábbiak közül minimum egyet kötelező megadni*

- **attributeID** - az attribútum azonosítója, melyhez hozzárendeljük az eredményt
- **type** - az eredmény típusa. A következők közül választhatunk: BigDecimal, Boolean, Byte, ByteArray, Date, Double, Float, Integer, Long, Object, Short, String, Time, Timestamp, URL

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

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

```xml
<!-- ###### ###### ###### ###  -->
<!-- Principal Connectors -->
<!-- ###### ###### ###### ###  -->

<resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="shibTransient"
                             nameIDFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
<resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="saml1Unspec"
                             nameIDFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
<resolver:PrincipalConnector xsi:type="Transient" xmlns="urn:mace:shibboleth:2.0:resolver:pc" id="saml2Transient"
                             nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />


```

Attribútum

# HREF_metadata_specifikáció

A föderációs metaadat célja, hogy a föderációban részt vevő intézmények illetve entitások technikai, bizalmi és adminisztratív adatait egy helyre gyűjtse. A metaadatok formátuma megfelel a SAML2 metaadat szabványnak.

## Biztonsági megfontolások

Mivel a metadata tartalmazza a föderációban részt vevő tagok és komponensek technikai információit, ezért a benne tárolt információkkal kapcsolatban figyelembe kell venni a következő biztonsági megfontolásokat:

- Téves vagy kompromittálódott adatok eltávolítása esetén a sérülékenységi ablak megegyezik a metadata gyorstárazhatósági (`cacheDuration`) idejével, **amennyiben a támadó nem képes blokkolni a központi metaadatok elérhetőségét (DOS)**
- Amennyiben a támadó képes blokkolni a központi metaadatok elérhetőségét, a sérülékenységi ablak a legutolsó letöltött metadata állomány érvényességéig (`validUntil` paraméterében meghatározott ideig) tart.
- Amennyiben a metaadatok érvényességi ideje lejár, az entitás nem képes azonosítani a többi föderációs résztvevőt, ezért nem tud föderációs szolgáltatást (pl. IdP esetén azonosítási szolgáltatást) nyújtani.

## Metaadatban tárolt információk

- Bizalom a metaadatban 
    - a metaadat integritásvédelmét és hitelességét egy digitális aláírás biztosítja.
    - a metaadat visszavonhatóságát a lejárati idő (`validUntil`) biztosítja, ami jelenleg 3 nap.
    - az egyes rendszerek gyorstárazhatják a metaadatot, de legalább naponta egyszer kötelesek a hiteles állományt frissíteni.
    - az aláírási procedúrát a [Metaadat\_aláírásának\_módja](#bkmrk-metaadat-al%C3%A1%C3%ADr%C3%A1s%C3%A1nak-m%C3%B3dja) fejezet írja le.
- Tanúsítványok 
    - kötelező legalább 1024 bites kulcspárt használni
    - az entitások által használt tanúsítvánnyal kapcsolatban a föderáció nem tesz különleges megkötést, sőt: ajánlott hosszú lejáratú self-signed tanúsítványok használata
- További információk 
    - minden szöveges mezőt legalább két nyelven: magyarul és angolul ki kell tölteni
    - kötelezően kitöltendőek az intézményi, adminisztratív információk (`Organization` illetve `ContactPerson` elemek)
    - ajánlott megadni egy helpdesk URL-r, ahova hiba esetén a felhasználók fordulhatnak (`errorURL` attribútum)
    - SP-k esetén további kötelező elemek 
        - `AttributeConsumingService`, ami megadja a kért attribútumokat 
            - `RequestedAttributes` - itt az attribútum informális neve is szerepeljen
            - `ServiceName`, `ServiceDescription` az SP szolgáltatás neve és leírása
        - a szolgáltatás elérhetősége, amin a szolgáltatás bemutatkozik (extension)
        - adatkezelési szabályzatra mutató URL (extension)
    - IdP-k esetén 
        - a scope csak az adott intézmény kezelésében levő domain név lehet (Shibboleth extension)
    - lehetőség van további adatok megadására is 
        - logó
        - gps koordináták, IP cím tartomány
        - különböző tagek, például a szolgáltatás publikus-e, vagy épp bevezetés alatt áll-e

### Metaadat kiterjesztések használata

Ezen kiegészítő adatok tárolására az internet2 szabványtervezetet készít, ennek a sémának a jelenlegi verziója megtalálható [itt](http://wiki.oasis-open.org/security/SAML2MetadataUI).

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

<table id="bkmrk-element-n%C3%A9v-szemanti"><thead><tr><th>element név</th><th>szemantika</th><th>értékekre vonatkozó megkötések</th></tr></thead><tbody><tr><td>GeolocationHint</td><td>szélesség és hosszúság érték, a + előjel az északi szélességet illetve keleti hosszúságot jelöli</td><td>47.47359,19.052891</td></tr><tr><td>InformationURL</td><td>az entitásról további információkat (pl. helpdesk) szolgáltató oldal.</td><td></td></tr><tr><td>PrivacyStatementURL</td><td>Az SP adatvédelmi nyilatkozátnak elérhetősége (URL)</td><td>Engedélyezett formátumok: HTML, PDF</td></tr><tr><td>Logo</td><td>Az IdP/SP logójának elérhetősége</td><td>Formátummal kapcsolatban lásd [Logo](#bkmrk-logo)</td></tr><tr><td>IPHint</td><td>(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.</td><td>CIDR, több érték is megadható</td></tr><tr><td>DomainHint</td><td>(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.</td><td>Több érték is megadható</td></tr></tbody></table>

#### Logo

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

### Egy IdP példa

```xml
 <EntityDescriptor entityID="https://idp.niif.hu/shibboleth"
  xmlns:mdui="urn:oasis:names:tc:SAML:2.0:metadata:ui">
  <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0">
   <Extensions>
    <shibmd:Scope>niif.hu</shibmd:Scope>
    <mdui:DiscoHints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <mdui:GeolocationHint>47.518356,19.055437</mdui:GeolocationHint>
      <mdui:DomainHint>niif.hu</mdui:DomainHint>
      <mdui:DomainHint>iif.hu</mdui:DomainHint>
    </mdui:DiscoHints>
   </Extensions>
   <KeyDescriptor use="signing">
    <ds:KeyInfo>
     <ds:X509Data>
      <ds:X509Certificate>...</ds:X509Certificate>
     </ds:X509Data>
    </ds:KeyInfo>
   </KeyDescriptor>
   <!-- endpoints, nameidformats -->
   </IDPSSODescriptor>
  <ContactPerson contactType="technical">
   <SurName>NIIF AAI</SurName>
   <EmailAddress>aai@niif.hu</EmailAddress>
  </ContactPerson>
  <ContactPerson contactType="support">
   <SurName>NIIF AAI</SurName>
   <EmailAddress>aai@niif.hu</EmailAddress>
  </ContactPerson>
  <ContactPerson contactType="administrative">
   <SurName>NIIF AAI</SurName>
   <EmailAddress>aai@niif.hu</EmailAddress>
  </ContactPerson>
 </EntityDescriptor>

```

### Egy SP példa

```xml
 <EntityDescriptor entityID="https://rr.aai.niif.hu/shibboleth"
  xmlns:mdui="urn:oasis:names:tc:SAML:2.0:metadata:ui">
 <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol">
  <Extensions>
    <mdui:UIInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <mdui:PrivacyStatementURL>https://rr.aai.niif.hu/privacy-policy</mdui:PrivacyStatementURL>
      <mdui:InformationURL>https://rr.aai.niif.hu/about</mdui:InformationURL>
    </mdui:UIInfo>
  </Extensions>
  <KeyDescriptor use="signing">
   <ds:KeyInfo>
    <ds:X509Data>
     <ds:X509Certificate>...</ds:X509Certificate>
    </ds:X509Data>
   </ds:KeyInfo>
  </KeyDescriptor>
  <KeyDescriptor use="encryption">
   <ds:KeyInfo>
    <ds:X509Data>
     <ds:X509Certificate>...</ds:X509Certificate>
    </ds:X509Data>
   </ds:KeyInfo>
  </KeyDescriptor>
  <!-- endpoints -->
  <AttributeConsumingService index="1">
   <ServiceName xml:lang="hu">HREF Resource Registry</ServiceName>
   <ServiceName xml:lang="en">HREF Resource Registry</ServiceName>
   <ServiceDescription xml:lang="hu">Resource Registry - a föderáció adminisztrációs alkalmazása http://rr.aai.niif.hu/</ServiceDescription>
   <ServiceDescription xml:lang="en">Resource Registry - federation administration tool http://rr.aai.niif.hu/</ServiceDescription>
   <RequestedAttribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" isRequired="true"/>
   <RequestedAttribute FriendlyName="surname" Name="urn:oid:2.5.4.4" isRequired="true"/>
   <RequestedAttribute FriendlyName="givenName" Name="urn:oid:2.5.4.42" isRequired="true"/>
   <RequestedAttribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" isRequired="true"/>
   <RequestedAttribute FriendlyName="schacHomeOrganizationType" Name="urn:oid:1.3.6.1.4.1.25178.1.2.10" isRequired="true"/>
   <RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" isRequired="true"/>
  </AttributeConsumingService>
 </SPSSODescriptor>
 <Organization>
  <OrganizationName xml:lang="hu">NIIF - Nemzeti Információs Infrastruktúra Fejlesztési Intézet</OrganizationName>
  <OrganizationName xml:lang="en">NIIF Institute - National Information Infrastructure Development</OrganizationName>
  <OrganizationDisplayName xml:lang="hu">NIIF - Nemzeti Információs Infrastruktúra Fejlesztési Intézet</OrganizationDisplayName>
  <OrganizationDisplayName xml:lang="en">NIIF Institute - National Information Infrastructure Development</OrganizationDisplayName>
  <OrganizationURL xml:lang="hu">http://www.niif.hu</OrganizationURL>
  <OrganizationURL xml:lang="en">http://www.niif.hu/en</OrganizationURL>
 </Organization>
 <ContactPerson contactType="administrative">
  <SurName>NIIF AAI</SurName>
  <EmailAddress>aai@niif.hu</EmailAddress>
 </ContactPerson>
 <ContactPerson contactType="technical">
  <SurName>NIIF AAI</SurName>
  <EmailAddress>aai@niif.hu</EmailAddress>
 </ContactPerson>
 <ContactPerson contactType="support">
  <SurName>NIIF AAI</SurName>
  <EmailAddress>aai@niif.hu</EmailAddress>
 </ContactPerson>
 </EntityDescriptor>

```

## Metaadat aláírásának módja

### Aláíró kulcs és tanúsítványok

#### HREF-2011

- Az aláíró kulcsot smart cardon, pin kóddal védve tároljuk.
- Az aláírás on-line történik, a kártya pin kódját az aláíró szoftver indításakor az AAI adminisztrátor adja meg, a jelszó nem kerül tárolásra az aláírást végző rendszeren (sem másutt).

#### HREF-2020

- 4096 bites, SHA-384 RSA aláíró kulcs.
- Az aláírás on-line történik, több telephelyes tartalékolt infrastruktúrával.

### Aláírási folyamat

Az aláíratlan metaadat frissítése:

1. Az aláíratlan metaadat a [https://rr.eduid.hu](https://rr.eduid.hu) oldalról ütemezetten, minden óra 15. és 45. percében letöltésre kerül.
2. A letöltött metaadat XML séma ellenőrzése ellenőrzése.
3. A metadat feltöltése az objektum tárolóba.

### Aláírás ellenőrzése explicit tanúsítvánnyal

A föderáció entitásai a föderációs metaadat hitelességéről a digitális aláírás ellenőrzésével győződhetnek meg. Az explicit ellenőrzés esetén a `[http://metadata.eduid.hu/current/](http://metadata.eduid.hu/current/)` URL-ről kell letölteni a metadata fájlokat.

**Ajánlott a tanúsítvány lejárati idejét figyelmen kívül hagyni.**

#### HREF-2011

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

<table id="bkmrk-sha-1-fe%3Aae%3A0b%3Ae8%3Afb"><thead><tr><th>SHA-1</th><th>`FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66`</th></tr></thead><tbody><tr><td>Serial Number</td><td>1</td></tr><tr><td>Version</td><td>3</td></tr><tr><td>C</td><td>HU</td></tr><tr><td>O</td><td>NIIF Institute</td></tr><tr><td>OU</td><td>eduID Federation Operator</td></tr><tr><td>CN</td><td>Metadata Signer</td></tr><tr><td>emailAddress</td><td>aai@niif.hu</td></tr><tr><td>Érvényesség kezdete</td><td>2011.10.05.</td></tr><tr><td>Érvényesség vége</td><td>2031.09.30.</td></tr></tbody></table>

#### HREF-2020

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

<table id="bkmrk-sha-1-c3%3A72%3Adc%3A75%3A4c"><thead><tr><th>SHA-1</th><th>`C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61`</th></tr></thead><tbody><tr><td>Serial Number</td><td>80:21:EF:F0:BA:16:04:BD</td></tr><tr><td>Version</td><td>1</td></tr><tr><td>C</td><td>HU</td></tr><tr><td>ST</td><td>Budapest</td></tr><tr><td>L</td><td>Budapest</td></tr><tr><td>O</td><td>Governmental Agency for IT Development</td></tr><tr><td>OU</td><td>eduID Federation Operator</td></tr><tr><td>CN</td><td>Metadata Signer</td></tr><tr><td>emailAddress</td><td>info@eduid.hu</td></tr><tr><td>Érvényesség kezdete</td><td>2020.06.13.</td></tr><tr><td>Érvényesség vége</td><td>2025.06.14.</td></tr></tbody></table>

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

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

## Metaadat elérése

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

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

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

<table id="bkmrk-href.xml-az-%C3%A9les-f%C3%B6d"><thead><tr><th>`href.xml`</th><th>Az éles föderációban részt vevő, és a föderáció kritériumait teljesítő entitások.</th></tr></thead><tbody><tr><td>`href-test.xml`</td><td>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ó.</td></tr><tr><td>`href-pending.xml`</td><td>A HREF föderáció "előszobája". Az újonnan csatlakozó intézmények IdP-je először itt lesz elérhető.</td></tr><tr><td>`href-edugain.xml`</td><td>A HREF föderációból az [eduGAIN](http://edugain.org) konföderációba kiajánlott entitások. Ide csak olyan entitások kerülhetnek be, melyek megfelelnek a föderációs kritériumoknak, és képesek az [eduGAIN](http://edugain.org) konföderációval való együttműködésre. Ezen entitások be kell hogy olvassák az eduGAIN metaadatot is.</td></tr><tr><td>`edugain.xml`</td><td>Az [eduGAIN](http://edugain.org) konföderáció metaadata, a HREF aláíró kulccsal aláírva.</td></tr><tr><td>`intézmény-specifikus`</td><td>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.</td></tr></tbody></table>

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

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

A HREF föderációban teszt jelleggel működik és elérhető MDX-kiszolgáló: [http://mdx.eduid.hu](http://mdx.eduid.hu). A megfelelő beállításokhoz [itt](https://help.edu.hu/books/aai/page/mdx) érhető el segédlet.

**Az MDX kiszolgáló eltérő kulcsot és tanúsítványt használ. Jelenleg az MDX elérés még csak teszt jelleggel működik, az élesüzemre váltáskor a HREF-2020 tanúsítvánnyal fog működni.**

A jelenlegi tanúsítvány innen tölthető le: [http://metadata.eduid.hu/current/mdx-test-signer-2015.crt](http://metadata.eduid.hu/current/mdx-test-signer-2015.crt)

#### HREF-2015

<table id="bkmrk-sha-1-91%3A81%3Aad%3A2b%3Af1"><thead><tr><th>SHA-1</th><th>`91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43`</th></tr></thead><tbody><tr><td>Serial Number</td><td>AA:90:7C:D9:0C:D5:64:8D</td></tr><tr><td>Version</td><td>3</td></tr><tr><td>C</td><td>HU</td></tr><tr><td>ST</td><td>-</td></tr><tr><td>L</td><td>Budapest</td></tr><tr><td>O</td><td>NIIFI</td></tr><tr><td>OU</td><td>AAI</td></tr><tr><td>CN</td><td>eduID MDX metadata signer</td></tr><tr><td>emailAddress</td><td>aai@niif.hu</td></tr><tr><td>Érvényesség kezdete</td><td>2015.10.13.</td></tr><tr><td>Érvényesség vége</td><td>2034.12.12.</td></tr></tbody></table>

# 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](https://help.edu.hu/books/aai/page/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](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](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

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

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

```php
    '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
<?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
<?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/](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](https://idp._DOMAIN_/simplesaml/module.php/saml/sp/metadata.php/default-sp)
5. "Token configuration" # &gt; "Add optional claim"&gt; "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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/token_configuration.png)
7. Állítsuk be az API persmissions-t az alábbi alapján: ![bélyegkép](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/api_permissions.png)

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](http://metadata.eduid.hu/current/href.xml) and [https://metadata.eduid.hu/current/href.xml](https://metadata.eduid.hu/current/href.xml), however the unencrypted method is preferred. The file is stored on a highly available file server.

The metadata file is re-published every *4 hours* or whenever the entity information changes (eg. entities are added or modified). Entities are expected to refresh metadata information regularly, although the `cacheDuration` attribute is currently not in use (for interoperability reasons).

## Trust in metadata

The information inside the metadata file must not be trusted after the date specified in the `validUntil` field of the topmost `EntitiesDescriptor` is expired. The expiration time is is set to **7 days** after the instant of the signature.

### Verification of the metadata file

The contents of the metadata file must be trusted only if the signature of the Federation Operator can be validated.

The Federation Operator uses a self-signed certificate for signing the metadata file, therefore the signing key must be explicitly trusted. Properties of the signing certificate:

- DN: `C=HU, O=NIIF Institute, OU=eduID Federation Operator, CN=Metadata Signer/emailAddress=aai@niif.hu`
- MD5 fingerprint: `21:8C:BE:B4:D1:D6:12:C4:67:9F:16:FA:93:36:F6:A4`
- SHA1 fingerprint: `FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66`
- Availability: from `Oct 5 08:18:46 2011 GMT` until `Sep 30 08:18:46 2031 GMT`

The certificate used for signing can be downloaded from [https://metadata.eduid.hu/2011/href-metadata-signer-2011.crt](https://metadata.eduid.hu/2011/href-metadata-signer-2011.crt) , which link should lead to a page without certificate warnings with most browsers. It is recommended to request the signing certificate from the Federation Operator by using some other verifiable transport as well (such as PGP-signed email).

### Signing procedure

Information about the entities is retrieved from the Resource Registry by using strong server authentication. If the contents of the metadata changes, it is saved to a version control system and the 'diff' is sent to a public mailing list ([href-metadata-changes](https://listserv.niif.hu/mailman/listinfo/href-metadata-changes))

The signing operation is done by a PIN-protected hardware token.

### Signing key change or revocation

Changes of the signing key/certificate is always negotiated with the technical contacts of all federation entities.

## Authenticating peer entities

It is recommended for all entities to use self-signed certificates, however, even if an entity uses a certificate signed by an external CA, it shall not be assumed that peers use any kind of PKI path validation or revocation checking.

### Entity certificate change or revocation

An entity should change its signing certificate by allowing a time frame, when both the old and the new certificate is available in the metadata.

If an entity certificate is compromised, the Federation Operator must be notified immediately. The certificate is removed from the metadata and either replaced by a new one or the entity is removed from the metadata file. On such an incident, all technical contacts are notified to do an immediate metadata refresh to shorten the attack window.

## Metadata extensions

Extension elements must be either interpreted according to their specification or ignored completely (while they are valid XML).

## Non-federation metadata sets

The federation signing engine is able to produce files other than the federation metadata (called metadata sets). These files are available at [https://metadata.eduid.hu/current/](https://metadata.eduid.hu/current/), all signed with the same credentials as the federation metadata, therefore it is easy to add them as an auxiliary metadata source.

- `href-test.xml`: staging federation metadata. Any federation member may register entities in this set.
- `href-edugain.xml`: entities that are **exported** to [eduGAIN](http://edugain.org) confederation. This file is consumed by eduGAIN MDS only. As eduGAIN follows an opt-in policy, only those entities are present in this set, whose administrators explicitly requested to be published in eduGAIN.
- `edugain.xml`: entities that are **imported** from [eduGAIN](http://edugain.org) confederation (minus Hungarian entities). If an entity wants to collaborate with eduGAIN entities from other federations, it needs to load this file.
- `<institution>.xml`: institution-specific metadata sets, which are maintained by the administrators of the institution. SPs inside this set are not required to be accepted by the federation, thus they are assumed to be used within the institution only.

Although an entity might appear in multiple sets, the entity information (including the entityID) must be the same across all sets. It is not allowed to register the same entity into multiple institution sets; the federation set must be used instead.

## Metadata registration

Entity metadata management is performed by using Resource Registry, no direct editing is supported.

Depending on the access level, the following administrative tasks may be performed:

- *Federation administrators* are entitled to: 
    - register new institutions
    - manage *Institutional Administrators*
    - manage Partner SPs
    - add or remove IdPs
    - manage production federation set and eduGAIN export set (see the section about metadata sets above)
- *Institutional Administrators* are entitled to: 
    - register new SPs and place them to the institutional metadata and/or staging federation metadata sets
    - manage the SPs of the institution
    - request the inclusion of an SP to the federation metadata or the eduGAIN export from the Federation Operator
    - add or remove SP administrators
    - add or remove Privacy Administrators
    - manage the IdP(s) of the institution
- *SP administrators* are entitled to: 
    - manage the SPs, which are assigned to them
- *Privacy Administrators* are entitled to: 
    - manage attribute release rules of the IdP of the institution

Accordingly, all partner SP metadata management is performed by the Federation Operator, by the request of the Techical/Administrative Contact of the Partner.

# JoiningEduGAIN

## Metaadatok

Az eduGAIN csatlakozáshoz a csatlakozó entitásnak - akár IdP, akár SP - ismernie kell az eduGAIN-ben résztvevő többi entitást. Ezt vagy a hagyományos módszerrel, az eduGAIN aláírt metaadatainak betöltésével lehet elérni, vagy az igény szerinti metaadat-kiszolgáló (MDX) használatával.

### Hagyományos XML állomány

Töltse be és rendszeresen frissítse az általunk aláírt eduGAIN metadatát: [http://metadata.eduid.hu/current/edugain.xml](http://metadata.eduid.hu/current/edugain.xml). Az aláírókulcs megegyezik a többi metadata setet aláíró kulccsal ([https://metadata.eduid.hu/href-metadata-signer-2011.crt](https://metadata.eduid.hu/href-metadata-signer-2011.crt)). Félreértések elkerülése végett a magyar entitások az újra aláírt eduGAIN metaadatok között nem szerepelnek, hogy ne legyen duplikáció.

Ennél a módszernél fel kell készülni arra, hogy a metaadat-frissítés hosszadalmas, több percet igénylő folyamat lehet. Néhány jellemző probléma:

- Shibboleth SP el- vagy újraindításakor több percen keresztül `ListenerException` hiba jelentkezik.
- SimpleSAMLphp esetén a *metarefresh* kifut a rendelkezésre álló memóriából, vagy tovább fut, mint a `max_execution_timeout` vagy a webszerver beállításai ezt lehetővé tennék.

### Igény szerinti metaadat kiszolgálás

Ebben az esetben a metaadatokat csak akkor töltjük le, ha éppen szükség van rájuk. Részletes leírás itt: [MDX](https://help.edu.hu/books/aai/page/mdx).

Ennek a módszernek előnye, hogy sokkal kevesebb erőforrást igényel a szerveren. Az alapértelmezés szerinti gyorstárazási idő is jóval rövidebb, mint a hagyományos esetben, így a változások valamivel hamarabb érvényre jutnak.

### Egyidejű használat

Mind a Shibboleth, mind a SimpleSAMLphp lehetővé teszi, hogy a hagyományos fájl-alapú és az MDX alapú metaadat forrásokat egyidőben használjuk. Például:

- helyi statikus metaadat-állományokat használunk,
- a magyar entitásokat hagyományos módon, az eduGAIN-es entitásokat MDX-szel akarjuk letölteni.

Ilyen esetben az MDX metaadat-forrást célszerű utolsó helyre tenni a sorban. Ekkor az metaadat-kérés csak akkor hajtódik végre, ha az entitás egyik statikus forrásban sem található meg.

HOWTO: [SimpleSAMLphp metaadatforrások egyidejű használata](https://help.edu.hu/books/aai/page/simplesamlmixedmetadata).

## IdP csatlakozása az eduGAIN-hez

Az IdP-nek értelmeznie kell SP-k attribútum-igényeit. Erre **erősen ajánlott** az EntityCategory alapú attribútum kiadást használni, kiegészítve a metadata-alapú (RequestedAttributes) attribútum kiadási mechanizmussal.

- *SimpleSAMLphp*: a javasolt megoldásról [bővebben erre](https://help.edu.hu/books/aai/page/ssp-entitycategories).
- *Shibboleth*: natívan ismeri mindkét attribútumkiadási mechanizmust: 
    - [https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeInMetadata](https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeInMetadata)
    - [https://wiki.shibboleth.net/confluence/display/IDP30/EntityAttributeExactMatchConfiguration](https://wiki.shibboleth.net/confluence/display/IDP30/EntityAttributeExactMatchConfiguration)

A metaadatok, illetve az attribútum-kiadás megfelelő konfigurációja **után** az IdP csatlakozását az IdP technikai kapcsolattartója kezdeményezi a föderációs adminfelületen ([https://rr.eduid.hu](https://rr.eduid.hu)), ügyelve arra, hogy az entitáshoz beállított logó is https-en keresztüli url-en legyen elérhető, ill. rögzítésre kerüljenek a különböző leíró dokumentumok angol nyelvű változataira mutató url-ek is.

## SP csatlakozása az eduGAIN-hez

A metaadatok megfelelő konfigurációja **után** az SP adminisztrátora a Resource Registry-ben állíthatja be, hogy az SP az eduGAIN-ben publikálásra kerüljön.

A Discovery felület integrációjával kapcsolatban lásd az [MDX leírás vonatkozó részét](https://help.edu.hu/books/aai/page/mdx)!

### Entitás kategóriák

Amennyiben nemzetközi együttműködésben vesz részt az SP, az entitás kategóriák használatával megkönnyíthetjük, hogy az IdP-k az igényelt attribútumokat kiadják.

Az entitás kategóriák beállítását az SP kapcsolattartója az info@eduid.hu címen kezdeményezheti.

#### Research &amp; Scholarship

Amennyiben a szolgáltatás a kutatást vagy az oktatást támogatja, beállítható a *Research &amp; Scholarship* entitás kategória. Részletes szabályok: [https://refeds.org/category/research-and-scholarship](https://refeds.org/category/research-and-scholarship)

#### GÉANT Data Protection Code of Conduct

Az entitás kategória részletes szabályai itt találhatóak: [https://wiki.edugain.org/Recipe\_for\_a\_Service\_Provider](https://wiki.edugain.org/Recipe_for_a_Service_Provider) . Fontos kiemelni, hogy ez a kategória az entitás metaadatainak részletes kitöltését ([https://rr.eduid.hu](https://rr.eduid.hu)) igényli, valamint egy olyan angol nyelvű adatvédelmi szabályzat meglétét, amely hivatkozik a [http://www.geant.net/uri/dataprotection-code-of-conduct/v1](http://www.geant.net/uri/dataprotection-code-of-conduct/v1) dokumentumra.

# Shibenv-PHP-Lazy

[http://shib.kuleuven.be/download/sp/test\_scripts/shibenv.php.txt](http://shib.kuleuven.be/download/sp/test_scripts/shibenv.php.txt) alapján:

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

```

</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](https://www.google.com/accounts/o8/id)

címen érhető el, a megfelelő paramétereket ide kell átadni.

### Rendelkezésre álló paraméterek

<table id="bkmrk-openid.ns-k%C3%B6telez%C5%91--"><thead><tr><th>**openid.ns**</th><th>Kötelező - a használandó OpenID protokollt definiálja, ajánlott érték: "[http://specs.openid.net/auth/2.0](http://specs.openid.net/auth/2.0)"</th></tr></thead><tbody><tr><td>**openid.claimed\_id**</td><td>Opcionális - a kérelem típusát azonosítja, ajánlott érték: "[http://specs.openid.net/auth/2.0/identifier\_select](http://specs.openid.net/auth/2.0/identifier_select)"</td></tr><tr><td>**openid.identity**</td><td>Opcionális, egy alternatív azonosítót definiál, ajánlott érték: "[http://specs.openid.net/auth/2.0/identifier\_select](http://specs.openid.net/auth/2.0/identifier_select)"</td></tr><tr><td>**openid.return\_to**</td><td>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.</td></tr><tr><td>**openid.realm**</td><td>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.</td></tr><tr><td>**openid.assoc\_handle**</td><td>Opcionális - részletes ismetető: [http://openid.net/specs/openid-authentication-2\_0.html#associations](http://openid.net/specs/openid-authentication-2_0.html#associations)</td></tr><tr><td>**openid.mode**</td><td>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ó)</td></tr><tr><td>**openid.ns.ext1**</td><td>Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "[http://openid.net/srv/ax/1.0](http://openid.net/srv/ax/1.0)"</td></tr><tr><td>**openid.ext1.mode**</td><td>Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "fetch\_request"</td></tr><tr><td>**openid.ext1.type.email**</td><td>Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "[http://axschema.org/contact/email](http://axschema.org/contact/email)"</td></tr><tr><td>**openid.ext1.required**</td><td>Opcionális (attribútum kiadatáskor kötelező) - ajánlott érték: "email" (Jelenleg csak az email attribútum elérhető)</td></tr></tbody></table>

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

- [http://code.google.com/intl/hu-HU/apis/accounts/docs/OpenID.html](http://code.google.com/intl/hu-HU/apis/accounts/docs/OpenID.html)

# 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](https://help.edu.hu/books/aai/page/foderacio) 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](https://help.edu.hu/books/aai/page/foderacio) részt venniük).

- <small>Kutatói föderációkban piaci szereplők általában nem vehetnek részt mint azonosítási szolgáltatók. Előfordulhat, hogy egy projektben - ahol megosztott közös erőforrásokat kell használni több intézmény munkatársainak - piaci és kutató intézmény dolgozik együtt, ilyenkor jó megoldás lehet a közvetlen megállapodás</small>

# Eszközök

- [uApprove](https://help.edu.hu/books/aai/page/uapprove): User-consent (beleegyezési nyilatkozat) eszköz
- [SamlSign](https://help.edu.hu/books/aai/page/samlsign): Metaadat aláíró és ellenőrző eszköz

# Log4whatever

A Shibboleth korábban a [**log4cpp**](http://sourceforge.net/projects/log4cpp/) library 0.35-ös változatát használta, azonban ebben számos threading és egyéb hiba volt, ami miatt a shibd instabil lett. A Shibboleth fejlesztője kijavította a forrást, azonban az eredeti szoftverbe ez nem került vissza (valószínűleg átmenetileg szünetelt a fejlesztése).

Később a log4cpp fejlesztése újrakezdődött, majd komolyabb változtatások után kijött az 1.0-ás verzió. Ez *részben* javította a Shibboleth fejlesztő által jelzett hibákat, azonban változott az API. A kezdeti instabilitások miatt Scott Cantor kiadta a 0.35-ös log4cpp forkjaként létrejött **log4shib** csomagot. Ez teljesen megegyezik a 0.35-össel, csak a Shibboleth használatához feltétlen szükséges hibajavításokat tartalmazza. A fejlesztő nem is tervezi a csomag további fejlesztését, álláspontja szerint a csomagra csak az Internet2 fejlesztésekben van szükség.

**A helyzet jelenleg (2008.04.28.) a következő:**

- Úgy tűnik, a **log4cpp** 1.0 kijavította a shibd elszállásához vezető hibát
- A lenny-ben levő Shibboleth (1.3) Debian csomag már az 1.0-ás log4cpp csomagot használja (liblog4cpp5)
- A Shibboleth2 és függőségei (opensaml, xmltooling) ***hivatalosan*** vagy a log4cpp 0.35 vagy a log4shib csomagot tudják használni
- A gyakorlatban a shibboleth2-sp és az opensaml lefordul az 1.0-ás log4cpp-vel is, de figyelmeztető üzenetet küld, mely szerint a log4cpp problémákat okozhat
- Az xmltooling lefordításához szükség van [erre a patch-re](https://help.edu.hu/books/aai/page/xmltooling-log4cpp-patch)
- Ahhoz, hogy a Shibboleth2 bekerülhessen a Debianba, semmiképpen sem használhatja a log4shib-et.

# SLODemo

!!! warning

```
For more complete description please go and see [how Single Logout is implemented](https://help.edu.hu/books/aai/page/single-logout-in-shibboleth-idp) in Shibboleth IdP.

```

To demonstrate the features we have prepared a [demo application](https://www.aai.niif.hu/SLODemo/sloDemo.php). The main purpose of the demo is to test the UI and various error conditions.

## Preparing

- [Metadata](https://idp.niif.hu/slotest-metadata.xml) (unsigned)
- IdP: Based on Adam's [Git repository](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;ashortlog;h=refs/heads/frontchannel-slo)

!!! 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](https://help.edu.hu/books/aai/page/shibidpx509ldapauthentication) / Kerberos)**.

## Service Providers

### SP1: (Not-so) Old Release

<table id="bkmrk-sp-software-shibbole"><thead><tr><th>**SP software**</th><th>Shibboleth 2.2.1 (Debian backports)</th></tr></thead><tbody><tr><td>**Front channel logout**</td><td>supported</td></tr><tr><td>**Back channel logout**</td><td>supported</td></tr><tr><td>**Notes**</td><td>This was a 2.1 SP which used to report partial logout on backchannel. Now it's working OK.</td></tr></tbody></table>

### SP2: Bright Shining Star

<table id="bkmrk-sp-software-shibbole-1"><thead><tr><th>**SP software**</th><th>Shibboleth 2.2.1 (Debian SID)</th></tr></thead><tbody><tr><td>**Front channel logout**</td><td>supported</td></tr><tr><td>**Back channel logout**</td><td>supported</td></tr><tr><td>**Notes**</td><td>Both front- and back-channel logout should work properly</td></tr></tbody></table>

### SP3: The Pretender

<table id="bkmrk-sp-software-simplesa"><thead><tr><th>**SP software**</th><th>SimpleSAMLphp SAML2 SP</th></tr></thead><tbody><tr><td>**Front channel logout**</td><td>supported</td></tr><tr><td>**Back channel logout**</td><td>not supported</td></tr><tr><td>**Notes**</td><td>SimpleSAMLphp does not support back-channel bindings, therefore the metadata does not contain it</td></tr></tbody></table>

### SP4: Use The Backdoor, Please!

<table id="bkmrk-sp-software-shibbole-2"><thead><tr><th>**SP software**</th><th>Shibboleth 2.2.1 (Debian SID)</th></tr></thead><tbody><tr><td>**Front channel logout**</td><td>not supported</td></tr><tr><td>**Back channel logout**</td><td>supported</td></tr><tr><td>**Notes**</td><td>The metadata of this SP does not contain front-channel bindings for logout</td></tr></tbody></table>

### SP5: Old Slowhand

<table id="bkmrk-sp-software-shibbole-3"><thead><tr><th>**SP software**</th><th>Shibboleth 2.2.1 (Debian backports)</th></tr></thead><tbody><tr><td>**Front channel logout**</td><td>not working (times out)</td></tr><tr><td>**Back channel logout**</td><td>not working (times out)</td></tr><tr><td>**Notes**</td><td>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. <small>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</small></td></tr></tbody></table>

### SP6: Shibboleth Neanderthalensis

<table id="bkmrk-sp-software-shib-1.3"><thead><tr><th>**SP software**</th><th>Shib 1.3 (IRL: Shibboleth 2.2.1 Debian backports)</th></tr></thead><tbody><tr><td>**Front channel logout**</td><td>not supported</td></tr><tr><td>**Back channel logout**</td><td>not supported</td></tr><tr><td>**Notes**</td><td>The metadata of this SP does not contain any logout services, just like a normal Shib1.3 SP</td></tr></tbody></table>

### SP7: Good Guy Speaking Ancient Greek

<table id="bkmrk-sp-software-shibbole-4"><thead><tr><th>**SP software**</th><th>Shibboleth 2.2.1 (Debian SID)</th></tr></thead><tbody><tr><td>**Front channel logout**</td><td>supported</td></tr><tr><td>**Back channel logout**</td><td>supported</td></tr><tr><td>**Notes**</td><td>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.</td></tr></tbody></table>

### SP8: Blitzkrieg

<table id="bkmrk-sp-software-shibbole-5"><thead><tr><th>**SP software**</th><th>Shibboleth 2.2.1 (Debian SID)</th></tr></thead><tbody><tr><td>**Front channel logout**</td><td>not working (if timed out)</td></tr><tr><td>**Back channel logout**</td><td>not working (if timed out)</td></tr><tr><td>**Notes**</td><td>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.</td></tr></tbody></table>

### SP9: Knight Without Armour

<table id="bkmrk-sp-software-shibbole-6"><thead><tr><th>**SP software**</th><th>Shibboleth 2.2.1 (Debian SID)</th></tr></thead><tbody><tr><td>**Front channel logout**</td><td>supported</td></tr><tr><td>**Back channel logout**</td><td>supported</td></tr><tr><td>**Notes**</td><td>This SP only supports HTTP for both SSO and SLO. Presumably, it would not work if the SSO was using HTTPS (not checked).</td></tr></tbody></table>

## How this demo works

The [SLO Demo](https://www.aai.niif.hu/SLODemo/sloDemo.php) 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 Redirect`s to the SPs SessionInitiator by specifying only the IdP entityID ([https://sandbox.slotest.aai.niif.hu/idp/shibboleth](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](https://help.edu.hu/books/aai/page/single-logout-in-shibboleth-idp)
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 &amp; 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](https://idp.niif.hu/slotest-metadata.xml) (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](https://bugs.internet2.edu/jira/browse/SSPCPP-230) for background. If you have a pre-2.2.1 SP, you should use:

```xml
<LogoutInitiator type="Chaining" Location="/BackChannelLogout" relayState="cookie">
  <LogoutInitiator type="SAML2" outgoingBindings=" " />
  <LogoutInitiator type="Local"/>
</LogoutInitiator>

```

## Expected results

### SAML2

Single Logout profile is for SAML2 only. Therefore SP6 (Neanderthalensis) will always fail. Note that SP7 (Ancient Greek) actually *speaks* SAML2 although it initiates SSO with Shibboleth protocol. Therefore you cannot **initiate** SLO from SP7 but you can participate in SLO.

SP5 (Old Slowhand) will always fail unless the Logout request is initiated by it.

### Front-channel, back-channel

The IdP can fallback to back-channel, if the logout is front-channel and the SP software does support only back-channel bindings. **Not the other way**, because front-channel bindings need the information held in browser cookies. Therefore front-channel SLO will work with SP4 (Backdoor) if initiated by some other SP's, but SP4 can only initiate back-channel SLO (which is not supported by many of the SP's above.)

## Unexpected results

## TODO

### Support NoScript

!!! warning "TODO"

```
NoScript support has been added recently to front-channel logout, thorough testing is still necessary.

The user interface is a bit clumsy, because the daisy-chain of redirects is a no-go and some browser not even support frames. Ideas, tips are welcome for making it better.

The main rationale behind supporting noscript is to make it even possible to use logout with other clients than web browsers. Bach-channel is much more convenient for them, though.

```

### Test with Application Notification

!!! warning "TODO"

```
Contribution is welcome!

```

### Try it with various browsers

!!! warning "TODO"

```
Contribution is welcome!

```

### Misc

- Publish shibd and IdP logs on a web page (real-time?)
- Add IPv6 addresses to the vhosts
- Add OpenSSO test SP

# Shibboleth2_IdP

**Telepítési leírások**

- [Shibboleth 2 IdP telepítése (Debian + Tomcat6)](https://help.edu.hu/books/aai/page/shib2idpinstall)
- [Shibboleth 2 IdP telepítése (RHEL5/CENTOS5 + Tomcat6)](https://help.edu.hu/books/aai/page/shib2idprhelquickstart)
- [OpenSUSE-specifikus kiegészítések](https://help.edu.hu/books/aai/page/shib2idpsuse)
- [Shibboleth 2 IdP klaszterezése](https://help.edu.hu/books/aai/page/shib2idpcluster)

**Konfigurációs leírások**

- [Felhasználók azonosítása](https://help.edu.hu/books/aai/page/shib2idpauth)
- [Attributumok feloldása](https://help.edu.hu/books/aai/page/shib2idpattrib)
- [Attributumok kiadása](https://help.edu.hu/books/aai/page/shib2idparp)
- [Perzisztens azonosító használata Shibboleth 2 IdP-ben](https://help.edu.hu/books/aai/page/shib2persistentid)
- [Alkalmazásszerverhez delegált adatbázis kapcsolat kezelés (connection pooling) Shibboleth 2 IdP-ben](https://help.edu.hu/books/aai/page/shib2idpconnectionpool)
- [Belépő oldal optimalizálása mobilra](https://help.edu.hu/books/aai/page/shib2idpmobilelogin)

**Kiegészítő programok konfigurációs leírásai**

- [uApprove (ArpViewer) telepítése](https://help.edu.hu/books/aai/page/uapprove)

**Shibboleth fejlesztések(angolul) / Shibboleth IdP development (in English)**

- [Single Logout in Shibboleth](https://help.edu.hu/books/aai/page/single-logout-in-shibboleth-idp)
- [Single Logout demo description](https://help.edu.hu/books/aai/page/slodemo)
- [X.509 authentication with LDAP](https://help.edu.hu/books/aai/page/shibidpx509ldapauthentication)
- [Using Shibboleth SSO with webmail applications](https://help.edu.hu/books/aai/page/webmailshibboleth)

# MDX

Az MDX, azaz MetaDataeXchange protokolt erőforrás optimalizálás céljából találták ki, hogy ne kelljen egyes IdP-knek és SP-knek indokolatlanul nagy XML fájlokat feldolgozniuk és tárolniuk, mikor a felhasználóiknak jó eséllyel a fájlokban tárolt entitások töredékére van csak szükségük. Ezért az egyes entitásokat be lehet úgy állítani, hogy csak akkor töltsék le az adott entitás metaadatát, mikor arra szükség van (az első letöltés után természetesen helyben tároldóik a metaadat a `cacheDuration`-ben megadott ideig). Az MDX kiszolgáló az alábbi szabvány szerint tudja visszaadni egy-egy entitás metaadatát: `https://mdx.eduid.hu/entities/{urlencoded}$entityID`, pl: `https://mdx.eduid.hu/entities/https%3A%2F%2Fdev.aai.niif.hu%2Fshibboleth`

## Dinamikus metadata kiszolgálás a HREF-ben

Az MDX kiszolgáló a **[https://mdx.eduid.hu](https://mdx.eduid.hu)** alatt szolgáltat, és a *href* és az *edugain* metadata halmazokat tartalmazza.

Mindkét kiszolgáló ugyanazzal a kulccsal írja alá a lekért metaadat-állományt.

- A tanúsítvány letölthető innen: [https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt)
- SHA-1 lenyomata: `C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61` .

### Fontos tudnivaló Discovery Service használattal kapcsolatban

Lévén az MDX-et használó SP-knél nem áll rendelkezésre folyamatosan az összes potenciális IdP listája, így a beépített Discovery Service-ek nem működnek. Ha MDX-et használunk, akkor valamilyen külső Discvery Service-t kell használnunk. A HREF-ben a [https://discovery.eduid.hu](https://discovery.eduid.hu) a központi Discovery Service.

Emellett maga az MDX kiszolgáló is biztosít Discovery Service felületet, ehhez akár Shibboleth SP-nél, akár simpleSAMLphp SP-nél a konfigurációban az alábbi URL-t kell megadni, mint Discovery Service: [https://mdx.eduid.hu/role/idp.ds](https://mdx.eduid.hu/role/idp.ds) . Ez a Discovery Service tartalmazza a hazai eduID-ben, valamint az eduGAIN-ben levő összes IdP-t. (És, ellentétben a hagyományos [https://discovery.eduid.hu/edugain](https://discovery.eduid.hu/edugain) szolgáltatással, ez tartlamazza a magyar VHO-t is VHO IdP néven.)

## MDX használata kliens oldalon

### SimpleSAMLphp

Az 1.14-es kiadástól kezdve a SimpleSAMLphp tartalmazza az dinamikus metadata lekérdezés funkciót, amely mind IdP, mind SP szerepben egységes módon használható. A config/config.php állományban metadata.sources szekcióban kell elhelyezni az alábbi blokkot:

```php
'metadata.sources' => array(
     array('type' => 'flatfile'), // ez a *-hosted metadata konfiguráció betöltése miatt szükséges
     array(
         'type' => 'mdx',
         'server' => 'https://mdx.eduid.hu',
         'cachedir' => '/var/simplesamlphp/mdx-cache', //opcionális, de ajánlott
         'cachelength' => 86400, //opcionális,
         'validateFingerprint' => 'C3:72:DC:75:4C:FA:BA:65:63:52:D9:6B:47:5B:44:7E:AA:F6:45:61' //opcionális
      ),
),

```

A dinamikus és a statikus metadataforrások egyidejű használatára egy példa: [SimpleSAMLMixedMetadata](https://help.edu.hu/books/aai/page/simplesamlmixedmetadata)

### Shibboleth SP

- Le kell tölteni a /etc/shibboleth alá az aláíró tanúsítványát innen: [https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt)
- Az alábbi blokkot be kell szúrni a `/etc/shibboleth/shibboleth2.xml` fájlba

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

```

### Shibboleth IdPv3

- Le kell tölteni a `${idp.home}/credentials/` alá az aláíró tanúsítványát innen: [https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt](https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt)
- A `conf/metadata-providers.xml` fájlt kell szerkeszteni az alábbi módon:

```xml
<MetadataProvider
     xmlns="urn:mace:shibboleth:2.0:metadata"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd"
     id="dynamicMDQ" xsi:type="DynamicHTTPMetadataProvider">


     <!--
       Require a validUntil XML attribute on the EntityDescriptor element
       and make sure its value is no more than 14 days into the future
     -->
     <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P14D" />


      <!-- Verify the signature on the metadata file -->
     <MetadataFilter xsi:type="SignatureValidation" requireSignedMetadata="true"
         certificateFile="${idp.home}/credentials/href-metadata-signer-2020.crt" />

     <!-- The MetadataQueryProtocol element specifies the base URL for the query protocol. -->
     <MetadataQueryProtocol>https://mdx.eduid.hu/</MetadataQueryProtocol>
</MetadataProvider>

```

# 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
<?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](http://shib.kuleuven.be/download/sp/test_scripts/shibenv.jsp.txt)

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

```

</body></html>

# MetadataTrust

Ez a szócikk a [Metadata](https://help.edu.hu/books/aai/page/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](https://wiki.shibboleth.net/confluence/display/SHIB2/TrustManagement) a Shibboleth wikin.

## Központi metadata bizalmi modellek

Alapvetően kétféle módon lehet biztosítani a metadata hitelességét:

- aláírás + lejárati idő
- hiteles helyről letöltés (SSL/TLS) + gyorstárazási idő

Előbbi módszer esetén a szállítási protokoll biztonsága nem szükséges (tehát a metadata nem hiteles helyről is beszerezhető - pl. http, email, ...), a digitális aláírás ellenőrzésével a hitelesség megállapítható.

A lejárati idő - `validUntil` ebben az esetben kulcsfontosságú, hiszen egy lejárati idő nélküli metadatát nem lehetséges visszavonni (egy rosszindulatú támadó egy régi metadata példányt később bármikor felhasználhat), így az esetleg kompromittált entitások az egész föderáció biztonságát veszélyeztethetik.

Utóbbi módszer használata esetén a föderációs entitások kötelesek a metadatát egy központi helyről, biztonságos csatornán (pl. https megfelelő tanúsítvány-ellenőrzéssel) adott időközönként letölteni. Ezt a frissítési időközt határozza meg a gyorstárazási idő, a `cacheDuration`.

## Metadata bizalom a HREF Föderációban

A HREF Föderációban a metadata biztonságát digitális aláírás és 72 órás lejárati idő együttes alkalmazása biztosítja. A metadata óránként generálódik a [Resource\_Registry](https://help.edu.hu/books/aai/page/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](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:

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

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

```xml
 <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ó](https://help.edu.hu/books/aai/page/simplesamlphp) 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.

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

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

!!! 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](https://repo.niif.hu/gitweb/gitweb.cgi?p=mdsigner-j.git)).

# Shib2IdpCluster

# Shibboleth 2.1 IdP klaszterezése

## Klaszter terminológia

**Node**

- egy, a szolgáltatást futtató csomópont

**Klaszter**

- kívülről nem megkülönböztethető nodeok összessége

**Szerver**

- fizikai (vagy virtuális) gép, amely a nodeokat futtatja (egy gépen lehet több node is)

**Failover**

- amennyiben egy csomópont kiesik, egy másik csomópont automatikusan és transzparensen átveszi a munkáját

**High availability**

- amennyiben egy csomópont kiesik, nem veszhet el adat, a kliensek nem veszik észre a kiesést

**Load balancing**

- a terhelés elosztása az egyes csomópontok között

## Terracotta

A Shibboleth2 IdP a [Terracotta](http://terracotta.org) 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](https://wiki.shibboleth.net/confluence/display/SHIB2/IdPCluster) nyújt segítséget.

1. Terracotta letöltése, kicsomagolása
2. tűzfalbeállítások (TCP/9510 kliens-&gt;szerver és TCP/9530 szerver-&gt;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:

```bash
 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:

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

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

```xml
 <tc-properties>
  <!-- server-to-server reconnect -->
  <property name="l2.nha.tcgroupcomm.reconnect.enabled" value="true" />
  <property name="l2.nha.tcgroupcomm.reconnect.timeout" value="15000" />
  <!-- client-to-server reconnect -->
  <property name="l2.l1reconnect.enabled" value="true" />
  <property name="l2.l1reconnect.timeout.millis" value="15000" />
 </tc-properties>

```

## Debian initszkript a Terracotta szerver indításához

- /etc/init.d/terracotta néven mentsük el root tulajdonossal a következő szkriptet, majd adjunk rá execute jogot:

```bash
#!/bin/sh
TC_USER=nobody
TC_GROUP=nogroup
PIDFILE=/var/run/terracotta.pid

if [`id -u` -ne 0 ](); then
        echo "You need root privileges to run this script"
        exit 1
fi

if [-f /etc/default/terracotta ](); then
    . /etc/default/terracotta
fi

if [-z "$TC_INSTALL_DIR" -o ! -d "$TC_INSTALL_DIR" ](); then
    echo "No TC_INSTALL_DIR specified or invalid TC_INSTALL_DIR"
    exit 1
fi
if [-z "$TC_CONFIG_PATH" -o ! -f "$TC_CONFIG_PATH" ](); then
    echo "No TC_CONFIG_PATH specified or invalid TC_CONFIG_PATH"
    exit 1
fi
if [-z "$NODENAME" ](); then
    echo "No NODENAME specified"
    exit 1
fi

export JAVA_HOME

JAVA_OPTS="-server -Xms512m -Xmx512m -XX:+HeapDumpOnOutOfMemoryError $JAVA_OPTS"
TC_START_OPTS="$JAVA_OPTS \
   -Dcom.sun.management.jmxremote \
   -Dtc.install-root=$TC_INSTALL_DIR \
   -cp $TC_INSTALL_DIR/lib/tc.jar \
   com.tc.server.TCServerMain -n $NODENAME -f $TC_CONFIG_PATH"
TC_STOP_OPTS="-Dtc.install-root=$TC_INSTALL_DIR \
  -cp $TC_INSTALL_DIR/lib/tc.jar \
  com.tc.admin.TCStop -n $NODENAME"

. /lib/lsb/init-functions
. /etc/default/rcS

check_stopped () {
    return `/sbin/start-stop-daemon --test --start --pidfile "$PIDFILE" \
        --user $TC_USER --startas "$JAVA_HOME/bin/java" \
        >/dev/null`
}
start () {
    log_daemon_msg "Starting Terracotta server node ($NODENAME)..."

    if check_stopped; then

        /sbin/start-stop-daemon -S -v --make-pid --pidfile "$PIDFILE" \
            --chuid $TC_USER:$TC_GROUP --background \
            --exec $JAVA_HOME/bin/java -- $TC_START_OPTS

    else
        log_progress_msg "(already running)"
    fi
    log_end_msg 0
}
stop () {
    log_daemon_msg "Stopping Terracotta server node ($NODENAME)..."
    if $JAVA_HOME/bin/java $TC_STOP_OPTS; then
        log_progress_msg "(shutdown command sent)"
    else
        log_progress_msg "(could not send shutdown command)"
    fi
    sleep 5
    if check_stopped; then
        log_progress_msg "(cleaning persistent store)"
        rm -r /var/lib/terracotta/server/*
        log_end_msg 0
    else
        log_progress_msg "(stopping in progress)"
    fi
}
force_stop () {
    log_daemon_msg "Killing Terracotta server node ($NODENAME)..."
    /sbin/start-stop-daemon -K --pidfile $PIDFILE -x $JAVA_HOME/bin/java
}

case "$1" in
  start)
      start
      ;;
  stop)
      stop
      ;;
  force-stop)
      force_stop
      ;;
  restart)
      stop
      sleep 10
      start
      ;;
  *)
    echo "Usage terracotta start|stop|force-stop|restart"
    exit 1;;
esac

exit $?

```

- A konfiguráció az /etc/default/terracotta fájlban található:

```bash
NODENAME=terracotta-node-name
TC_CONFIG_PATH=/path/to/shibboleth-idp/conf/tc-config.xml
JAVA_HOME=/path/to/jvm
TC_INSTALL_DIR=/path/to/terracotta

```

## Monitoring (JMX, Munin, Nagios)

- JMX: Java Management Extensions
- A Terracotta támogatja a JMX-en keresztüli monitorozást és bevatkozást 
    - alapértelmezésképp jmxmp protokollon keresztül 
        - másoljuk be a jmxremote\_optional.jar -t a terracotta lib/ könyvtárából egy üres könyvtárba
        - indítsuk a jconsole-t a következő paranccsal: *jconsole -J-Djava.endorsed.dirs=.*
        - kapcsolódjunk a `service:jmx:jmxmp://<tc-szerver-node>:9520` url-re
    - usernév/jelszavas authentikáció esetén rmi protokollon keresztül is elérhetjük a tc szervert
- [Check\_jmx szkriptek nagioshoz és muninhoz](http://www.nagiosexchange.org/cgi-bin/page.cgi?g=2338.html;d=1)

### Fontosabb Terracotta MBean attribútumok

- org.terracotta:type=Terracotta Server,name=DSO 
    - LiveObjectCount (int)
    - ClientLiveObjectCount (string)
- org.terracotta.internal:type=DSO Client,name=Client Transactions,subsystem=Transactions,clients=Clients,node=... 
    - AvgModifiedObjectsPerTransaction (int)
    - AvgNewObjectsPerTransaction (int)
    - ObjectCreationRateBySecond (int)
    - ReadTransactionCount (int)
    - WriteTransactionCount (int)
- org.terracotta.internal:type=Terracotta Server,name=Terracotta

Server

```
* Active (bool)
* PassiveStandby (bool)
* PassiveUninitialized (bool)
* HealthStatus (String)
* State (string)
* StartTime (timestamp)
* Shutdownable (bool)

```

### Nagios Terracotta szerver check

```bash
#!/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:

```bash
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:

```bash
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:

```bash
[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:

```bash
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:

```bash
[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](http://jira.terracotta.org/jira/browse/CDV-1252) a javítás elkészült, azonban a 2.7.3 -ba még nem került be.

Workaround-ként ki lehet kapcsolni az l2 újracsatlakozást a konfigurációban. Ilyenkor azonban rövid hálózati megszakadás is teljes node újraindítást fog okozni.

## Terracotta 3.2.1 ismert hibák

Még nincs :)

## Troubleshooting

- Mindig ellenőrizni kell a logfájlokat! Ha egy szerver folyton írja a logfájlját, az általában rossz jel és elárvult kliensre utal ("Could not find communication stack..." üzenet).
- A teljes klaszter újraindítása után kötelező újraindítani a klienseket (Tomcat), ugyanis a Terracotta nem fogja engedni újra csatlakozni. Ezt egyébként a szerver logfájlban jelzi is.
- Nem érdemes egyszerre indítani a két Terracotta szervert, annak könnyen összeakadás lehet a vége, ha nem tudnak dönteni egymás között. 
    - ilyenkor az egyik szerver felszólítja a másik szervert a megállásra, ilyenkor azonban a diszken tárolt állapot megmarad, amit egy start parancs kiadása után nem hajlandó felhasználni a szerver processz.
    - a megoldás az initszkript 'restart' parancsa (vagy két egymás utáni start, ugyanis második kísérletre már hajlandó elindulni 'dirty' adatokkal is).
- Az `/etc/nagios/check_terracotta --verbose` parancs a teljes klaszter állapotát visszaadja (szerverek és kliensek is).
- Ha egy probléma nem oldható meg csak az egyik szerver és a kliensek újraindításával, akkor a teljes klasztert újra kell indítani: mindkét szerver leállítása és a perzisztens adatok gondos törlése után egyesével újraindíthatóak a szerverek majd az aktív szerver indulása után a kliensek (Tomcat).

### Kliens library

- a Tomcat webkonténerben fut
- a `/var/log/terracotta/client/log*/terracotta-client.log` fájlba logol
- **JVM váltáskor, frissítéskor újra kell generálni!** Ezt a `/usr/local/terracotta/bin/make-boot-jar.sh` szkripttel lehet megtenni, előtte törölni kell a `/usr/local/terracotta/lib/dso-boot` könyvtár tartalmát.

### Szerver processz

- külön processzként fut
- a `/var/log/terracotta/server/log*/terracotta-server.log` fájlba logol
- a `/var/lib/terracotta/server/` könyvtárban tárol saját adatokat, amit kézzel történő tiszta újraindítás előtt törölni kell

### Nagios riasztások és megoldásuk

- Túl kevés a kliens (client count is xxx)
    
    
    - **OK**: a Tomcat kliens megállt vagy megszakadt a kommunikáció a szerverrel.
    - **Megoldás**: a kliens listában nem szereplő Tomcat-et újra kell indítani.
- Nincs passzív node (not enough passive node)
    
    
    - **OK**: az egyik Terracotta szerver épp adatot szinkronizál a másiktól és ezért `passive-uninitialized` állapotban van.
    - **Megoldás**: pár percet érdemes várni, amíg a szinkronizáció befejeződik. Ha nem oldódik meg a probléma magától, akkor újra kell indítani a Terracotta szerver processzt.
- Nem elérhető egy node (node xxx is down)
    
    
    - **OK**: az egyik Terracotta szerver nem elérhető.
    - **Megoldás**: újra kell indítani.

## Adminisztrációs feladatok

### JVM frissítése

A következő leírás meglehetősen az NIIF Intézet saját infrastruktúrájára specifikus, de talán más környezetekben is felhasználható.

#### Lépések összefoglalása

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

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

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

```xml
    <AttributeRule attributeID="eduPersonAffiliation">
        <PermitValueRule xsi:type="basic:OR">
            <Rule xsi:type="basic:AttributeValueString" value="faculty" ignoreCase="true"/>
            <Rule xsi:type="basic:AttributeValueString" value="student" ignoreCase="true"/>
            <Rule xsi:type="basic:AttributeValueString" value="staff" ignoreCase="true"/>
            <Rule xsi:type="basic:AttributeValueString" value="alum" ignoreCase="true"/>
            <Rule xsi:type="basic:AttributeValueString" value="member" ignoreCase="true"/>
            <Rule xsi:type="basic:AttributeValueString" value="affiliate" ignoreCase="true"/>
            <Rule xsi:type="basic:AttributeValueString" value="employee" ignoreCase="true"/>
            <Rule xsi:type="basic:AttributeValueString" value="library-walk-in" ignoreCase="true"/>
        </PermitValueRule>
    </AttributeRule>


```

Magyarázat: a kiadási szabály, akkor adja ki az `eduPersonAffiliation` attribútumot, amennyiben annak értéke egyezik a felsoroltak valamelyikével (`OR` szabály - tehát elég, hogy egyikkel egyezzen).

Az alábbi listában található egyezési szabályok alkalmazhatók egy-egy `<PermitValueRule>` megadásakor:

- ANY - Always evaluates to true
- AND - Evaluates to true if all contained rules are true
- OR - Evaluated to true if any contained rule is true
- NOT - Evaluates to true if the contained rule evaluates to false
- AttributeRequesterString - Evaluates to true if the attribute requester's entity ID matches a given string
- AttributeIssuerString - Evaluates to true if the attribute issuer's entity ID matches a given string
- PrincipalNameString - Evaluates to true if the user's principal name matches a given string
- AuthenticationMethodString - Evaluates to true if the method used to authenticate the user matches a given string
- AttributeValueString - Evaluates to true if the value of a given attribute matches a given string
- AttributeScopeString - Evaluates to the true if the scope of a value of a given attribute matches a given string
- AttributeRequesterRegex - Evaluates to true if the attribute requester's entity ID matches a given regular expression
- AttributeIssuerRegex - Evaluates to true if the attribute issuer's entity ID matches a given regular expression
- PrincipalNameRegex - Evaluates to true if the user's principal name matches a given regular expression
- AuthenticationMethodRegex - Evaluates to true if the method used to authenticate the user matches a given regular expression
- AttributeValueRegex - Evaluates to true if the value of a given attribute matches a given regular expression
- AttributeScopeRegex - Evaluates to the true if the scope of a value of a given attribute matches a given regular expression
- Script - Evaluates a scriptlet to determine if the rule evaluates to true
- AttributeRequesterInEntityGroup - Evaluates to true if the attribute requester is defined within a given entity group in SAML metadata
- AttributeIssuerInEntityGroup - Evaluates to true if the attribute issuer is defined within a given entity group in SAML metadata
- AttributeScopeMatchesShibMDScope - Evaluates to true the scope of an attribute value matches the scope defined in the attribute issuer's metadata.

# ShibIdpSLO

1. ÁTIRÁNYÍTÁS [Single Logout in Shibboleth IdP](https://help.edu.hu/books/aai/page/single-logout-in-shibboleth-idp)

# FedDev

Föderáció létrehozásával kapcsolatos lap.

- [Föderáció](https://help.edu.hu/books/aai/page/foderacio)
- [Károkozási táblázat](https://help.edu.hu/books/aai/page/karokozasi-tablazat)
- [Döntési táblázat](https://help.edu.hu/books/aai/page/dontesi-tablazat)
- [Metadata specifikáció](https://help.edu.hu/books/aai/page/href-metadata-specifikacio)
- [Attribútum specifikáció](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
- [Föderációs operátor szolgáltatásai](https://help.edu.hu/books/aai/page/href-szolgaltatasi-szint-megallapodas)
- [Naplózás a föderációban](https://help.edu.hu/books/aai/page/fedentitieslogging)
- [HREFPolicyStub](https://help.edu.hu/books/aai/page/hrefpolicystub)

# EduPersonAffiliation

![img](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/affiliation.png)

A kép az eduPersonAffiliation értékeinek egy lehetséges ábrázolása. A pontos meghatározás az intézmények feladata, erre a föderációnak nincsenek szigorúbb megkötései

- A *student*, *staff*, *faculty* viszonnyal rendelkezők jellemzően *member* -ek is. 
    - Kivételek előfordulhatnak, például nem kapnak *member* viszonyt: 
        - ideiglenes hallgatók (pl. nyári egyetem)
        - nem aktív hallgatók (pl. passzív féléven, abszolutorium és a diploma átvétele közötti időszakban, stb.)
        - vendégoktatók
        - eseti szerződéses munkatársak
    - E három affiliation tetszőleges kombinációja előfordulhat, például 
        - Oktató és hallgató egyszerre (pl. PhD)
        - Dolgozik és hallgató (pl. rendszergazda)
        - Alkalmazott és oktató (pl. rendszergazda, aki kurzusokat is tart)
- Az *employee* -t leginkább belül érdemes használni, jellemzően ők is member-ek
- Az öregdiákok és a könyvtári és az egyéb külsős felhasználók jellemzően nem member-ek

# Attribute_Conversion_for_simpleSAMLphp

This page describes the features of Attribute Conversion and Filtering library for simpleSAMLphp

## Introduction

[eduGAIN](http://edugain.org) uses Bridging Elements for interconnecting federations. To provide attribute translation and filtering services, an [attribute 'mangling' library](https://help.edu.hu/books/aai/page/attribute-conversion-for-edugain) was developed for the Java-based bridging elements. As [simpleSAMLphp](http://rnd.feide.no/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](https://www.aai.niif.hu/ssp-attributes). 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](https://repo.niif.hu/gitweb/gitweb.cgi?p=simplesamlphp-edugain).

## Compatibility

### eduGAIN

This library is intended to be configuration-compatible with the [eduGAIN](http://edugain.org) [Attribute\_Conversion\_for\_eduGAIN](https://help.edu.hu/books/aai/page/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](https://help.edu.hu/books/aai/page/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:

```php
 'authproc' => array(
   50 => array(
    'class' => 'edugain:Attributes',
    'mode' => 'idp',
    'converterconfig' => '/path/to/AttributeConverter.xml',
    'filterconfig' => '/path/to/AttributeFilter.xml',
    'cache' => true
   )
 )

```

**Configuration parameters for the module**

- **class** (required): defines the eduGAIN filter for simpleSAMLphp.
- **mode** (required): configures the way this module operates (`idp` or `sp`). See [below for more information on operating modes](#bkmrk-operating-modes)
- **converterconfig** (optional): configures the path of the attribute converter configuration xml file.
- **filterconfig** (optional): configures the path of the attribute filter configuration xml file.
- **cache** (optional, default: true): enables or disables the internal configuration cache. See the [Configuration\_cache](#bkmrk-configuration-cache) section below for more.

!!! info

```
If either `converterconfig` or `filterconfig` is omitted, than the relevant part of the module (conversion or filtering respectively) is disabled. Note that **disabling filter means you let all the attributes through**.

```

## Operating modes

EduGAIN module can operate in two modes, **idp** or **sp**. This mode affects two behaviors: the conversion-filtering order, and the provider matching.

- in **idp** mode, attribute filter is run **after** conversion, and the RemoteProvider match is done against the SP (or R-BE in eduGAIN bridged environment) which initiated the SSO session .
- in **sp** mode, attribute filter is run **before** conversion, and the RemoteProvider match is done against the IdP (or H-BE in eduGAIN bridged environment) which released the attributes to our simpleSAMLphp SP.

## Configuration file

The simpleSAMLphp eduGAIN module reads the eduGAIN XML configuration format and transforms it into php arrays using XSL transformation. The submodules (*edugain:SplitMerge* and *edugain:Filter*) are configured automatically by the edugain:Attributes class.

PHP configuration interface for these filters are not supported at the moment and may be subject to change, so please use the XML configuration.

### Configuration cache

The XML reading is very time-consuming but conversion and filtering rules should be evaluated on every request. Because of that, the eduGAIN module can cache the XML configuration into a serialized PHP array, which is stored locally in a directory named `cache`. If the XML file is not updated since the last cache file generation then the cache is used and the XML parsing part is skipped. Cache file name is computed according to the following:

```
md5(full_configuration_file_path).cache.php

```

!!! info

```
Enabling the cache is strongly recommended in production environments.

```

## Differences between the Java and the PHP implementations

- There is no **CustomRule** for attribute conversion. One can use simpleSAMLphp authentication processing filter API to implement arbitrary conversion rules.
- **LocalProvider** matching is unsupported in simpleSAMLphp. Unfortunately when simpleSAMLphp is in bridging mode (using the SP module to protect an IdP), the IdP processing filters do not see the peer entity of the SP module. However, you can achieve the correct behavior by putting one *edugain:Attributes* processing filter in the SP configuration and use **RemoteProvider** matches to filter and convert attributes there.
- You don't need to use a separate attribute name mapper, because simpleSAMLphp contains built-in **name2oid**,**oid2name**, **name2urn** and **urn2name** methods, which provide the same functionality.
- Regular expressions are somewhat different in PHP. The eduGAIN module uses perl-compatible regular expressions (see [preg\_match documentation](http://hu.php.net/manual/en/function.preg-match.php) for details).

# HREF_alapelvek_és_alapvető_szabályok

## Föderációs alapelvek

1. A [föderáció](https://help.edu.hu/books/aai/page/hrefglossary) célja, hogy a felhasználók úgy vehessenek igénybe szolgáltatásokat - amennyiben erre jogosultak -, hogy a saját intézményük azonosítja őket.
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](https://help.edu.hu/books/aai/page/hrefglossary)) 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](https://help.edu.hu/books/aai/page/hrefglossary) és a [Partner](https://help.edu.hu/books/aai/page/hrefglossary) biztosítja, hogy a [HREF Föderáció](https://help.edu.hu/books/aai/page/hrefglossary) működése során közöttük a személyes adatok kezelése a vonatkozó jogszabályoknak megfelelő módon történik. Így a személyes adatok kezelése csak törvényi felhatalmazáson vagy felhasználói önkéntes, határozott és tájékozott hozzájárulásán alapul, amellyel beleegyezését fejezi ki az őt érintő személyes adatok kezelésébe.
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](https://docs.google.com/document/d/1XkFqQx9npWVgftAU1b0cRoqiTNrhj9oqEWpMWaIJO6o/edit?hl=en_US), [SP üzemeltetési szabályok](https://docs.google.com/document/d/1QZWwFqHm4VNyIn6GdKnOzyA0Xdg2uYgwlAkJA1ffpM8/edit?hl=en_US)
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](https://help.edu.hu/books/aai/page/href-metadata-specifikacio) megfelelően történjen, így: 
    - a Tag a [Resource Registry](https://help.edu.hu/books/aai/page/hrefglossary) használatával gondoskodik arról, hogy az őt érintő föderációs metaadatok naprakészek legyenek,
    - a metaadatokat a specifikációnak megfelelő gyakorisággal frissítik és ellenőrzik.
4. A felhasználói [attribútumok](https://help.edu.hu/books/aai/page/hrefglossary) átadása során az IdP és a SP az [attribútum specifikáció](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) előírásait betartják.

### Adatkezeléssel kapcsolatos szabályok

1. Az Azonosító Szervezet biztosítja, hogy a felhasználó regisztrációs folyamatai dokumentáltak legyenek.
2. Csak olyan felhasználó azonosítható, akinek az intézményhez való [viszonya](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) 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](https://help.edu.hu/books/aai/page/hrefglossary) számára hozzáférhetővé tett felhasználói adatokat célszerű autoritatív adatbázisban rögzített adatok alapján létrehozni, így a rendszeres frissítéssel azok időszerűsége, pontossága nem vitatott.
    - Amennyiben az IdP AAI Kapu adatbázisa nem autoritatív adatbázis alapján működik, a Tagnak meg kell tennie a szükséges lépéseket az adatminőség biztosítása érdekében.
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](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) megkövetelt attribútumokat megvalósítsa.

### Tagsággal kapcsolatos szabályok

A HREF Föderáció infrastruktúrájának üzemeltetője az országos kutatói hálózatot működtető Föderációs Operátor. A HREF Föderáció további résztvevői egy már megkötött csatlakozási szerződés alapján a [Tagok](https://help.edu.hu/books/aai/page/hrefglossary) és a [Partnerek](https://help.edu.hu/books/aai/page/hrefglossary).

1. A föderáció **Tagjai** az alábbi intézmények lehetnek: 
    - felsőoktatási intézmények;
    - akadémiai intézmények, kutatással foglalkozó intézmények;
    - oktatással foglalkozó intézmények;
    - közgyűjtemények.
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](https://help.edu.hu/books/aai/page/hrefglossary) 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.

```xml
<SPConfig xmlns="urn:mace:shibboleth:sp:config:2.0"
	xmlns:conf="urn:mace:shibboleth:sp:config:2.0"
	xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
	logger="shibboleth/syslog.logger" clockSkew="180">

    <Extensions/>

    <OutOfProcess logger="shibboleth/shibd.logger"/>

    <InProcess logger="shibboleth/native.logger"/>

    <Listener/>

    <StorageService/>
    <SessionCache/>
    <ReplayCache/>
    <ArtifactMap/>

    <RequestMapper/>

    <ApplicationDefaults id="default" policyId="default"
        entityID="https://sp.example.org/shibboleth"
        homeURL="https://sp.example.org/index.html"/>

    <SecurityPolicies/>

</SPConfig>

```

Látható, hogy a szerkezet keretét egy `<SPConfig>` elem adja, ez fogja közre a különböző összetevők részletes konfigurációit. Az `<SPConfig>` opcionális attribútumai

- **`logger`**Annak a konfigurációs fájlnak a helyét adhatjuk meg, amelyben a loggolási tulajdonságok kerültek definiálásra. Alapértelmezés szerint ez a `shibboleth/shid.logger` fájl.
- **`clockSkew`**A legtöbb elosztott rendszerhez hasonlóan a Shibbolethnél is nagyon fontos, hogy szinkronban legyenek a rendszerben résztvevő elemek órái. Mivel komoly sebezhetőséget jelentene, ha a szerverek közti üzeneteken nem lenne megjelölve a feladás időpontja, ezért ezek az üzenetek időbélyeggel ellátottak, s minden rendszer elem csak egy bizonyos időnél nem régebbi üzenetekkel hajlandó foglalkozni. Ezt az értéket tudjuk itt megadni. Alapértelmezés szerint 3 perc, azaz 180 másodperc az értéke.

## Összetevők

### `<Extensions>`

### `<OutOfProcess>`

### `<InProcess>`

### `<Listener>`

### `<StorageService>`

### `<SessionCache>`

### `<ReplayCache>`

### `<ArtifactMap>`

### `<RequestMapper>`

A RequestMap megadja azokat a címeket (Host és Path), amelyeket a Shibboleth SP kezelni fog. Szerkezete:

```xml
<RequestMap applicationId="default">
    <Host name="www.example.org">
        <Path name="secure" authType="shibboleth" requireSession="true"/>
    </Host>
    <Host name="admin.example.org" applicationId="admin" authType="shibboleth" requireSession="true">
        <AccessControl>
            <Rule require="affiliation">faculty@osu.edu student@osu.edu</Rule>
        </AccessControl>
    </Host>
</RequestMap>

```

A RequestMap több Host elemet is tartalmazhat, a Host elem 0 vagy több Path elemet tartalmazhat.

!!! danger "Figyelem"

```
Ha 1-nél nagyobb mélységű könyvtárat (pl. a `/shibtest/shibreq` nevűt) szeretnénk védeni, akkor **nem** adhatjuk meg a *name* paraméterben a "shibtest/shibreq" értéket, hanem egymásba ágyazott Path elemeket kell használni. A *name* paraméter nem tartalmazhat '/' karaktert.

```

Az egyes elemeknél paraméterekkel szabályozhatjuk, hogy az SP milyen módon kezelje a hostot vagy az útvonalat. A paraméterek felüldefiniálhatók. A legfontosabb paraméterek az alábbiak (ezek ugyanúgy használhatók Host-nál mint Path-nál):

- **`requireSession`**: ha értéke "true", akkor az SP csak akkor továbbítja a HTTP request-et az alkalmazás ill. a webszerver felé, ha sikerült létrehozni egy autentikált session-t. Ha "false", akkor az alkalmazás felelős azért, hogy létrehozza a Shibboleth session-t (ún. [lazy session](https://help.edu.hu/books/aai/page/lazy-session)) Alapértelmezés: "false"
- **`applicationId`**: lehetőség van arra, hogy bizonyos helyekre érkező kérésekre az SP más és más módon próbáljon meg session-t létrehozni, ezt ún. [Shibboleth Application](#bkmrk-%3Capplicationdefaults)-ben konfigurálhatjuk. Ha nem adunk meg értéket, akkor a "default" application-nél megadott értékek vonatkoznak majd a session-re.

### `<ApplicationDefaults>`

# IsPassive

Az **isPassive** SAML2-ben bevezetett lehetőség, mellyel azt szabhatjuk meg, hogy az azonosításnak úgy kell megtörténnie, hogy közben semmiféle látható felhasználói interakciónak nem szabad történnie. Ha az azonosítás így nem hajtható végre, akkor hibát kell visszaadni az SP-nek.

## Miért jó?

Az isPassive használatával elérhetjük, hogy [Lazy Session](https://help.edu.hu/books/aai/page/lazy-session)-nel védett oldalunkra a felhasználó bejelentkezése automatikusan - azaz "Bejelentkezés" gombra kattintás nélkül - megtörténjen. Ehhez három feltétel együttes teljesülése szükséges:

- a felhasználó már rendelkezik az IdP-je által hitelesített munkamenettel
- az IdP által használt autentikációs mechanizmus támogatja az isPassive-ot 
    - erre kizárólag SAML2 IdP esetén van lehetőség
- ha használunk Discovery Service-t, akkor az a felhasználó IdP-jét képes megállapítani interakció nélkül 
    - ez általában azt jelenti, hogy a felhasználónak van olyan cookie-ja, amely alapján a DS meg tudja határozni az IdP-t. Érdemes megjegyezni, hogy a SWITCH Discovery Service IP cím alapján is képes meghatározni IdP-t.

Amennyiben ezen feltételek közül valamelyik nem teljesül, úgy az SP hibát fog dobni. Ezt `redirectErrors` attribútum segítségével átirányíthatjuk a saját alkalmazásunkra.

## Hátrányok

Lehetséges olyan helyzet, hogy a hiba nem jut vissza az SP-hez:

- az IdP nem SAML2-t használ
- az IdP azonosítási mechanizmusa nem támogatja a passzív azonosítást (pl. azért, mert webszerver-alapú azonosítást használ)
- a Discovery Service vagy a WAYF nem támogatja a passzív választást

Ebben az esetben a felhasználó olyan üzenetet kap, amit valószínűleg nem tud értelmezni. Pl.:

- hibaüzenet az IdP vagy a DS részéről
- IdP azonosítási felület (ami esetleg nem is a felhasználó IdP-je)

Ezért isPassive-ot csak abban az esetben szabad használni, ha garantálni tudjuk, hogy az IdP-k mind támogatják a passzív autentikációt!

## Működése a gyakorlatban

- Az [alábbi szkriptet](#bkmrk-k%C3%B3d) szúrjuk be az oldalunk főlapjára / fejlécébe.
- A Shibboleth SP konfigurációjában (`shibboleth2.xml`) az adott alkalmazásra vonatkozó beállításoknál új attribútumként adjuk meg a `redirectErrors="SAJÁT KEZDŐLAPOM"` direktívát.
- Bizonyosodjunk meg róla, hogy az oldalt lazy session-nel védjük

## Kód

```javascript
<!-- 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](#bkmrk-nagym%C3%A9ret%C5%B1-attrib%C3%BAtu) á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](#bkmrk-nagym%C3%A9ret%C5%B1-attrib%C3%BAtu) á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](#bkmrk-nagym%C3%A9ret%C5%B1-attrib%C3%BAtu) állít ki és ezeket egyetlen válaszként elküldi az SP-nek

## Alkalmazási terület

Shibboleth esetén [Browser/POST](#bkmrk-nagym%C3%A9ret%C5%B1-attrib%C3%BAtu) profil használata esetén a *pull* modell, míg [Browser/Artifact](#bkmrk-nagym%C3%A9ret%C5%B1-attrib%C3%BAtu) 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](https://help.edu.hu/books/aai/page/simplesamlphp)) csak a *push* modellt támogatják, mivel ennek implementációja egyszerűbb.

!!! info

```
Nagyméretű attribútumok használata esetén a válasz mérete is elég nagy lehet, ezért ez [POST]() profil esetén esetleg kényelmetlenséget (lassú működést) okozhat.

```

# Alkalmazások_illesztése

- [Drupal shib\_auth module](https://help.edu.hu/books/aai/page/drupal-shibboleth-module) (angolul / in English)
- [Drupal illesztése Shibboleth-hez](https://help.edu.hu/books/aai/page/drupalshibboleth) (elavult)
- [MediaWiki illesztése Shibboleth-hez](https://help.edu.hu/books/aai/page/mediawikishibboleth)
- [Webmail szoftverek illesztése Shibboleth-hez](https://help.edu.hu/books/aai/page/webmailshibboleth)
- [Moinmoin illesztése Shibboleth-hez](http://moinmo.in/ShibbolethSupport)
- [Könyvtári rendszerek illesztése](#bkmrk-drupal-shib_auth-mod)
- [Office 365 illesztése Shibboleth IdP-hez](https://help.edu.hu/books/eduid-cloud365-eQ0/page/o365-saml)

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

```java
<%@ 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\\-")) {
%>


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

%>


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

```

</body></html>

# Shib3IdpARP

Shibboleth 3 IdP attribútum szűrés beállítása

**Vonatkozó állományok:**

- `{idp.home}/conf/attribute-filter.xml`
- `{idp.home}/conf/idp.properties`

Az `{idp.home}/conf/attribute-filter.xml` állomány már tartalmaz néhány egyszerű példa beállítást. Az alábbi módosítások lehetővé teszik, hogy az attribútum feloldó által feloldott *sn* és *givenName* attribútumok az SP-k számára elérhetők legyenek. Bővítsük az állományt az alábbiak szerint.

```xml
<afp:AttributeFilterPolicyGroup id="ShibbolethFilterPolicy"
        xmlns:afp="urn:mace:shibboleth:2.0:afp"
        xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
        xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:afp http://shibboleth.net/schema/idp/shibboleth-afp.xsd
                            urn:mace:shibboleth:2.0:afp:mf:basic http://shibboleth.net/schema/idp/shibboleth-afp-mf-basic.xsd
                            urn:mace:shibboleth:2.0:afp:mf:saml http://shibboleth.net/schema/idp/shibboleth-afp-mf-saml.xsd">

<!-- ... további tartalom ... -->

    <!-- ezeket az attribútumokat minden SP megkapja -->
    <afp:AttributeFilterPolicy id="mindensp">
        <afp:PolicyRequirementRule xsi:type="basic:ANY"/>

        <afp:AttributeRule attributeID="sn">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
        <afp:AttributeRule attributeID="givenName">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

    <!-- ezeket az attribútumokat csak a megadott SP kapja meg -->
    <afp:AttributeFilterPolicy id="intezmenysp1">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://sp1.intezmenyneve.hu/shibboleth"/>

        <afp:AttributeRule attributeID="description">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

</afp:AttributeFilterPolicyGroup>

```

- A **14.** sor szerint minden SP-re vonatkozik a szabály.
- A **16, 19.** sorban megadott attribútumokat a 14. sor alapján minden SP látja.
- A **26.** sorban megadott SP-re vonatkozóan rendelkezünk.
- A **28.** sor szerint ez az SP megkapja a *description* attribútumot.

**Dokumentáció:**

- [https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterConfiguration](https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterConfiguration)
- [https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterPolicyConfiguration](https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterPolicyConfiguration)

# OpenSSO

## OpenSSO telepítése

Az OpenSSO szerver letölthető a [projekt oldaláról](https://opensso.dev.java.net/public/use/index.html). 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](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](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

- [OpenSSO IdP - Shibboleth2 SP](https://help.edu.hu/books/aai/page/opensso-idp-shibboleth2-sp)
- [OpenSSO SP - Shibboleth2 IdP](#bkmrk-%3Cmd%3Anameidformat%3Eurn)
- [OpenSSO IdP - SimpleSAMLphp SAML2 SP](https://help.edu.hu/books/aai/page/opensso-idp-simplesamlphp-saml2-sp)

## 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](https://help.edu.hu/books/aai/page/hrefglossary) felé.
2. Mind jogilag, mind technikailag előkészül a csatlakozáshoz: [Föderáció alapelvek](https://help.edu.hu/books/aai/page/href-alapelvek-es-alapveto-szabalyok), [Műszaki előírások IdP-k számára](https://docs.google.com/document/d/1XkFqQx9npWVgftAU1b0cRoqiTNrhj9oqEWpMWaIJO6o/edit?hl=en_US), [Műszaki előírások SP-k számára](https://docs.google.com/document/d/1QZWwFqHm4VNyIn6GdKnOzyA0Xdg2uYgwlAkJA1ffpM8/edit?hl=en_US).
3. Egyeztetés után elküldi az [aláírt szerződést, ill. nyilatkozatot](http://www.eduid.hu/dokumentumok/), és ezzel párhuzamosan elérhetővé teszi a csatlakozás előtti ellenőrzéskor [átnézendő dokumentumokat](https://help.edu.hu/books/aai/page/hrefchecklist). Különösen fontos, hogy megadja az azonosítható felhasználók számát és elérhetővé tegye az adatkezelési szabályzatát.
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](https://help.edu.hu/books/aai/page/hrefglossary)
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](https://help.edu.hu/books/aai/page/hrefglossary) az új entitást. Negatív válasz esetén a hiányosságok ismertetése mellett lehetőséget biztosít azok a pótlására, javítására.

**Azonosító szervezet (IdP) felvétele a föderációba**

1. A Föderációs Operátor az intézményi adminisztrátorral egyeztetve rögzíti a [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry)-be az IdP adatait. Egyúttal a Föderációs Operátor az IdP-t hozzáadja a föderációs tesztmetaadathoz, ezáltal az intézményi adminisztrátor, amennyiben helyesen konfigurálta az IdP-t, be fog tudni lépni a Resource Registrybe.
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](https://help.edu.hu/books/aai/page/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](https://help.edu.hu/books/aai/page/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](https://refeds.org/sirtfi) kezdeményezést a REFEDS (the Research and Education FEDerations group) koordinálja, célja, hogy a föderációs és különösen a föderációközi együttműködéshez kapcsolódó incidenskezelés számára kereteket szabjon, a föderációban résztvevő felek számára egy magasabb biztonsági szintet adjon azáltal, hogy a SIRTFI-nak megfelelő entitások kapcsán biztosak lehetnek az alábbiakban:

- az intézményi üzemeltető az adott entitáshoz kapcsolódó biztonsági frissítéseket, mind operációs rendszer, mind kapcsolódó szoftverek, mind pedig a föderációs együttműködést megvalósító middleware tekintetében a lehető leggyorsabban telepíti,
- biztosított intézményi szinten az incidenskezeléshez kapcsolódó kompetencia, mellyel párhuzamosan az intézmény föderációs szinten (a metadatán keresztül) megjelöl egy speciális elérhetőséget, melyen keresztül az esetleges biztonsági incidensek kapcsán biztosan felvehető a kapcsolat a kompetens intézményi személlyel,
- az adott entitáshoz kapcsolódóan megfelelő naplózás történik, szükség esetén visszakereshetők az esetleges incidensekhez kapcsolódó alapvető információk,
- az adott intézmény rendelkezik AUP-val és biztosítja, hogy felhasználói be is tartják.

Fontos, hogy a SIRTFI-képesség metadatában való jelzése önbevallás útján történik, tehát föderációs szinten nem kerül vizsgálatra, hogy az intézmény az állításának megfelelően ténylegesen bír-e a fenti listában jelzett kompetenciákkal. Az eduID entitások kapcsán a Resource Registry-ben állítható be a SIRTFI-képesség.

# Attribute_Specification

## Purpose of this document

In a federation, information about the user is represented in SAML attributes transferred from the Identity Provider to the Service Provider. It is important for both parties to interpret the data in the same way.

Exact definitions of the attributes are maintained in their defining schemas. Within this specification, we use the following schemas:

- *person*, *organizationalPerson* (X.521)
- *inetOrgPerson* (RFC2798)
- *eduPerson* ([http://middleware.internet2.edu/eduperson/](http://middleware.internet2.edu/eduperson/), version 200806)
- *SCHAC* ([http://www.terena.org/activities/tf-emc2/schacreleases.html](http://www.terena.org/activities/tf-emc2/schacreleases.html), version 1.4.1)
- *niifPerson*, *niifEduPerson* ([NIIFSchema](https://help.edu.hu/books/aai/page/niifschema))

This Attribute Specification provides an *interpretation* of the defined attributes for their use within the federation. It might be somewhat more specific than the original definition, in order to let the SPs get more specific information about the user.

Beyond the specification, parties may bilaterally agree on any other attributes.

## Use of attributes

### Terms

- An attribute is **implemented**, if the information is available according to the semantics of the specification. Releasing an implemented attribute is simply a policy decision of the IdP.
- An attribute is **released**, when the data is transferred from the IdP to an SP. Not all available information is sent out normally, only the attributes that are relevant for the SP.

### Levels of implementation

- **Mandatory**: every IdP must implement the attribute.
- **Recommended**: it is recommended for every IdP to implement the attribute, however, it is understood that it might be impossible or very complex for certain IdPs
- **Optional**: an IdP may freely implement the attribute, however, the implementation must follow this specification.

### Attribute Requirements of the SP

SPs can indicate attribute requirements among the information provided to [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry). This information also shows up in the federation metadata. From the point of view of the SP, an attribute can be:

- **Required**: the information is a requirement for the proper operation of the SP application 
    - i.e. `eduPersonPrincipalName` is often required for applications, which are not prepared for handling opaque identifiers.
- **Desired**: the information can add extra functionality to the application or can provide better user experience 
    - i.e. when `displayName` is transferred, the user is not prompted to supply his or her common name.

## Attributes

### Summary

#### Mandatory attributes

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

#### Recommended attributes

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

#### Optional attributes

<table id="bkmrk-attributes-describin"><thead><tr><th>Attributes describing user properties</th><th>Attributes describing institutional relationship</th><th>Attributes for educational use</th></tr></thead><tbody><tr><td>sn</td><td>ou</td><td>niifEduPersonAttendedCourse</td></tr><tr><td>givenName</td><td>eduPersonOrgUnitDN</td><td>niifEduPersonArchiveCourse</td></tr><tr><td>preferredLanguage</td><td>eduPersonPrimaryOrgUnitDN</td><td>niifEduPersonHeldCourse</td></tr><tr><td>schacDateOfBirth</td><td></td><td>niifEduPersonMajor</td></tr><tr><td>schacYearOfBirth</td><td></td><td>niifEduPersonFaculty</td></tr><tr><td>schacPersonalTitle</td><td></td><td>niifEduPersonFacultyDN</td></tr><tr><td>niifPersonMothersName</td><td></td><td>niifEduPersonStudentCategory</td></tr><tr><td>niifPersonResidentalAddress</td><td></td><td></td></tr><tr><td>homePostalAddress</td><td></td><td></td></tr><tr><td>telephoneNumber</td><td></td><td></td></tr><tr><td>mobile</td><td></td><td></td></tr><tr><td>eduPersonNickName</td><td></td><td></td></tr><tr><td>cn</td><td></td><td></td></tr><tr><td>jpegPhoto</td><td></td><td></td></tr><tr><td>labeledUri</td><td></td><td></td></tr></tbody></table>

### Persistent user identifiers

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

Persistent identifiers can be:

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

Identifiers can hold the following properties:

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

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

### List of attributes

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

#### eduPersonTargetedID

<table id="bkmrk-edupersontargetedid--1"><thead><tr><th></th><th>eduPersonTargetedID</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonTargetedID **OID:** 1.3.6.1.4.1.5923.1.1.1.10</td></tr><tr><td>**Rövid leírás**</td><td>**Opaque**, **targeted**, **non-reassignable** identifier</td></tr><tr><td>**Implementáció**</td><td>kötelező</td></tr><tr><td>**Részletes leírás**</td><td>See: [https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID](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 ('!').</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Must be a SAML2 persistent NameID; the unique identifier part must not be longer than 256 ASCII characters.`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>An IdP sends the attribute on the wire such as:```
<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"<br></br>   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"<br></br>   NameQualifier="<a href="https://idp.example.org/idp/shibboleth">https://idp.example.org/idp/shibboleth</a>"<br></br>   SPNameQualifier="<a href="https://sp.example.org/shibboleth">https://sp.example.org/shibboleth</a>"><br></br>84e411ea-7daa-4a57-bbf6-b5cc52981b73<br></br></saml2:NameID>
```

 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](https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73)</td></tr></tbody></table>

#### eduPersonPrincipalName

<table id="bkmrk-edupersonprincipalna-1"><thead><tr><th></th><th>eduPersonPrincipalName</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonPrincipalName **OID:** 1.3.6.1.4.1.5923.1.1.1.6</td></tr><tr><td>**Rövid leírás**</td><td>**Persistent**, **non-targeted**, **non-reassignable** personal identifier</td></tr><tr><td>**Implementáció**</td><td>kötelező</td></tr><tr><td>**Részletes leírás**</td><td>Format: `<local_id>`@`<scope>` where: 6. **`<local_id>`**: arbitrary persistent key which unambiguously maps to a person within an institution.
7. **`<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 reassigned**As some applications do not support special characters in identifiers, eduPersonPrincipalName MUST only contain the following characters: alpanumeric characters, dot ('.'), hyphen ('-') and underscore ('\_').
</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>gipsz.jakab@example.org</td></tr></tbody></table>

#### displayName

<table id="bkmrk-displayname-elnevez%C3%A9"><thead><tr><th></th><th>displayName</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:displayname **OID:** 2.16.840.1.113730.3.1.241</td></tr><tr><td>**Rövid leírás**</td><td>Display name of the person</td></tr><tr><td>**Implementáció**</td><td>ajánlott</td></tr><tr><td>**Részletes leírás**</td><td>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.</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`single`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Példa**</td><td>Gipsz Jakab Aladár</td></tr></tbody></table>

#### mail

<table id="bkmrk-mail-elnevez%C3%A9s-uri%3A-"><thead><tr><th></th><th>mail</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:mail **OID:** 0.9.2342.19200300.100.1.3</td></tr><tr><td>**Rövid leírás**</td><td>Mail address of the person</td></tr><tr><td>**Implementáció**</td><td>ajánlott</td></tr><tr><td>**Részletes leírás**</td><td>Notification email address of the person. The institution asserts that2. either the address is provided by the institution to the person
3. 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.
</td></tr><tr><td>**Lehetséges értékek**</td><td>Valid email address</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`See also: [RFC 2822](http://www.faqs.org/rfcs/rfc2822.html)`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>gipsz.jakab@example.org</td></tr></tbody></table>

#### eduPersonScopedAffiliation

<table id="bkmrk-edupersonscopedaffil-1"><thead><tr><th></th><th>eduPersonScopedAffiliation</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.5923.1.1.1.9</td></tr><tr><td>**Description**</td><td>Describes the relationship between the person and the institution</td></tr><tr><td>**Semantics**</td><td>**`<affiliation>`@`<scope>`**2. **`<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
3. **`<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](http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation)
</td></tr><tr><td>**Values**</td><td>One of the following: {student,faculty,staff,employee,member,affiliate,alum,library-walk-in}, followed by the **scope**</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>1. Learners: *student@example.org;member@example.org*
2. Teachers: *faculty@example.org;member@example.org*
</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

#### eduPersonEntitlement

<table id="bkmrk-edupersonentitlement-1"><thead><tr><th></th><th>eduPersonEntitlement</th></tr></thead><tbody><tr><td>**Elnevezés**</td><td>**URI:** urn:mace:dir:attribute-def:eduPersonEntitlement **OID:** 1.3.6.1.4.1.5923.1.1.1.7</td></tr><tr><td>**Rövid leírás**</td><td>URI (either URN or URL) that indicates a set of rights to specific resources.</td></tr><tr><td>**Implementáció**</td><td>ajánlott</td></tr><tr><td>**Részletes leírás**</td><td>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**</td></tr><tr><td>**Lehetséges értékek**</td><td>nincs korlátozás</td></tr><tr><td>**Értékek száma**</td><td>`multi`</td></tr><tr><td>**Szintaktika**</td><td>`Directory String`</td></tr><tr><td>**Adatgazda**</td><td>intézmény</td></tr><tr><td>**Példa**</td><td>urn:geant:niif.hu:niif:entitlement:vhoadmin</td></tr></tbody></table>

#### schacHomeOrganizationType

<table id="bkmrk-schachomeorganizatio-1"><thead><tr><th></th><th>schacHomeOrganizationType</th></tr></thead><tbody><tr><td>**OID**</td><td>1.3.6.1.4.1.25178.1.2.10</td></tr><tr><td>**Description**</td><td>Type of the Home Organisation</td></tr><tr><td>**Semantics**</td><td>1. **university**: universities and colleges
2. **nren**: National research and educational network
3. **library**: Libraries
4. **vho**: Virtual home organisation
5. **school**: Primary and secondary education
6. **business**: Industrial or commercial companies
7. **other**: Other
8. **test**: The principal is a test account
</td></tr><tr><td>**Values**</td><td>urn:schac:homeOrganizationType:hu:{university,nren,library,vho,school,business,other,test}</td></tr><tr><td>**\# of values**</td><td>`multi`</td></tr><tr><td>**Availability**</td><td>`-`</td></tr><tr><td>**Syntax**</td><td>`Directory String`</td></tr><tr><td>**Examples**</td><td>-</td></tr><tr><td>**Notes**</td><td>-</td></tr><tr><td>**Use in federation**</td><td>-</td></tr></tbody></table>

# SSP2

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

## Telepítés

Először is nagyvonalakban leírásra kerülnek az előkészületek ezt követően pedig maga a szoftver telepítése és beállítása.

### Előkészületek

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

- A következő könyvtárakat kiegészítőket telepíteni kell: `wget openssl unzip build-essential libldap2-dev libldap-common`
- PHP futtatására alkalmas webszerver
- PHP környezet (&gt;=8.0)
- A következő PHP kiterjesztéseket engedélyezni kell 
    - `posix, date , dom , fileinfo , filter , hash , json , libxml , mbstring , openssl , pcre , session , simplexml , sodium , SPL, zlib, ldap`
    - Adatbázisból történő autentikáció esetén a megfelelő adatbázis-csatolót `mysqli, pdo, pdo_mysql`
    - RADIUS szerveren keresztül történő autentikáció esetén: `radius`
- Információk, certek: 
    - Bár a szoftver képes futni mariadb, és redis nélkül, ezek vagy hasonló megoldások használata éles környezetben ajánlott.
        
        
        - Amennyiben ezeket szándékozunk használni database connection stringgel kell rendelkezni, redis elérhetőséggel és jelszóval rendelkezni.
        - Az adatbázis szerkezetének kialakítása a használt moduloktól függ, a leggyakoribb a consent modul, ott van is dokumentáció az adatbázis inicializálásáról.
    - Szükséges 2 certpár, az egyik az apachenak a másik az SSP-nek ezutóbbi lehet önalárírt, és nem ajánlott ugyan azt használni.

#### Composer

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

### Telepítés

Elvégezhető composerrel például a `/var/` mappában:

`composer create-project simplesamlphp/simplesamlphp:2.1.3`

Mappaszerkezet módosítása:

```
mv simplesamlphp simplesamlphp-prod #Tetszőleges átnevezés
mkdir -p simplesamlphp-prod/cert
mkdir -p /var/simplesamlphp-prod/log/stats/
mkdir -p /var/simplesamlphp-prod/mdx-cache/
chown -R www-data:www-data /var/simplesamlphp-prod/mdx-cache/
chown -R www-data:www-data /var/simplesamlphp-prod/log/
chown -R www-data:www-data /var/simplesamlphp-prod/metadata/

```

Composerrel a szükséges modulok telepítése (például LDAP, REDIS, vagy consent):

```
composer require simplesamlphp/simplesamlphp-module-ldap:v2.3.2
composer require predis/predis:2.2.2
composer require simplesamlphp/simplesamlphp-module-consent:1.3.2

```

Ezzel a telepítés, és a szükséges kiegészítők telepítése megtörtént.

### Apache konfigurálás

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

```
Alias /simplesaml /var/simplesamlphp-prod/public
<Directory /var/simplesamlphp-prod/public>
  Require all granted
</Directory>

```

### Simplesamlphp Alapbeállítások

#### Konfigurációs fájlok

Amennyiben korábbi verziókat használtunk,

jó megközelítés lehet diff segítségével ellenőrizni a különbségeket a korábbi `config.php` fileunk és a `config.php.dist` között.

Ha ilyennel nem rendelkezünk akkor lehet rögtön alapul venni a `config.php.dist`-et és hasonlóképp a metadata-templates mappát.

#### Konfigurációs fájlok szerkesztése

##### Baseurlpath beállítása

- Állítsuk be a baseurlpath opciót. Mutasson a telepítés URL-jére, ahol a SimpleSAMLphp elérhető:

`'baseurlpath' => 'https://your.canonical.host.name/simplesaml/',`

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

- **Az "admin" felhasználó jelszavát, mellyel webes felületen keresztül be tud lépni a települő SSP-be.**
    
    ```
    'auth.adminpassword'        => 'ujjelszotirdide',
    
    ```
- **Titkosítási feladatokhoz szükséges "salt", azaz véletlenszerűen összeálló karaktersorozat**
    
    ```
    'secretsalt' => 'randombytesinsertedhere',
    
    ```
    
    A karaktersorozat előállításában segíthet az alábbi parancs:
    
    ```
    tr -c -d '0123456789abcdefghijklmnopqrstuvwxyz' </dev/urandom | dd bs=32 count=1 2>/dev/null;echo
    
    ```
- **Elérhetőségeket, amely adatok bekerülnek majd a generált metaadatba**
    
    ```
    'technicalcontact_name'     => 'Gipsz Jakab',
    'technicalcontact_email'    => 'jakab.gipsz@example.org',
    
    ```
- **Nyelv és időzóna adatok**
    
    ```
    'language.default'      => 'hu',
    'timezone' => 'Europe/Budapest',
    
    ```

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

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

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

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

- Naplózási szint beállítása a **config/config.php**-ban
    
    ```php
    'debug' => array(
           'saml' => true,
           'backtraces' => true,
           'validatexml' => false,
    ),
    'logging.level' => SimpleSAML\Logger::DEBUG,
    'logging.handler' => 'file',
    
    ```

<span style="color:red">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.</span>

##### Modulok engedélyezése

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

<span style="color:red">Nem ajánlott a SimpleSAMLphp-hoz és webszerverhez ugyanazt a tanúsítvány használni!</span>

- A SimpleSAMLphp alapértelmezetten a tanúsítványt a **cert** mappában keresi.
- Az alábbi paranccsal egy 10 éves [self-signed tanúsítvány](#bkmrk-figyelj%C3%BCnk-arra%2C-hog) generálunk a SimpleSMALphp számára.
    
    ```
    openssl req -new -newkey rsa:3072 -x509 -days 3652 -nodes -out cert/saml-example-org.crt -keyout cert/saml-example-org.key
    
    ```

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

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

```

### Telepítés kész

Amennyiben elkészültünk a fenti lépésekkel, úgy a [https://service.example.org/simplesaml/admin](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
 <?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.

```php
'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/](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](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](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
<?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
<?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](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
<?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](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)](https://help.edu.hu/books/aai/page/mdx) használni, opcionálisan kiegészítve statikus állományokkal. Részletes leírás itt: [SimpleSAMLMixedMetadata](https://help.edu.hu/books/aai/page/simplesamlmixedmetadata)()

### IdP

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

- (Az adminisztratív teendőktől itt most eltekintünk, a csatlakozás folyamata [itt van leírva](https://help.edu.hu/books/aai/page/hrefjoin))
- Kell küldeni egy levelet a info@eduid.hucímre, benne néhány mondat mellett az IdP metaadatának URL-jével ([https://example/org/simplesaml/module.php/saml/idp/metadata](https://example/org/simplesaml/module.php/saml/idp/metadata))
- Ha minden rendben megy, akkor az IdP bekerül a [Resource\_Registry](https://help.edu.hu/books/aai/page/resource-registry)-be, ezáltal a föderációs metaadatba is.
- Az előző pontban leírt módon be kell állítani a központi metadata feldolgozását.
- Amennyiben a föderációs metaadatban már szerepel a mi IdP-nk is, úgy a föderáció valamelyik, tesztelési célokat szolgáló SP-jénél ki is próbálhatjuk a bejelentkezést.
- **Fontos**, hogy a föderációs Discovery Service óránként generálja újra az IdP-k listáját, így ennyi idő mindenképp szükséges, hogy az új IdP megjelenjen itt, az egyes SP-k pedig két óránként töltik újra a metaadatot, így előfordulhat, hogy azonnal nem fog minden működni, de néhány óra alatt várhatóan beindul. :)
- Tesztelésre használható oldal: [https://attributes.eduid.hu](https://attributes.eduid.hu)
- Ahhoz, hogy a Resource Registry-be is be tudjunk lépni és az IdP további, a föderációra vonatkozó beállításait meg tudjuk ejteni, ehhez az IdP-nek ki kell adnia az alábbi attribútumokat:
    
    
    - [mail](https://help.edu.hu/books/aai/page/href-attributum-specifikacio) - ez belépés után, manuálisan is beállítható
    - [eduPersonPrincipalName](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
    - <del>[schacHomeOrganizationType](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)</del> (az attribútumot hamarosan kivezetjük a kötelező attribútumok közül)
    - [eduPersonScopedAffiliation](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)

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

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

```

- További tudnivalók a [Resource Registry-ről](https://help.edu.hu/books/aai/page/resource-registry), ill. a [Föderációs attribútum specifikációról](https://help.edu.hu/books/aai/page/href-attributum-specifikacio).
- Ha minden rendben ment, akkor a Resource Registry-ben regisztrált IdP-hez tartozó adminisztrációs jogok átkerülnek az IdP technikai gazdájához, s ezzel a folyamat kész is.

### SP

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

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

#### Attribútum scopeok használata

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

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](https://github.com/NIIF/simplesamlphp-module-attributescope), 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](https://github.com/NIIF/simplesamlphp-module-attributescope)

- Az `attributescope` modul használata esetén a következőképp kell módosítani a `config/config.php` fájlt:

```php
 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](https://help.edu.hu/books/aai/page/shibboleth-idp) azonosítania kell tudnia a felhasználót, tehát valamilyen [központi adatbázisban](#bkmrk-lehet%C5%91s%C3%A9g-van-arra-i) léteznie kell.

Ha egy olyan felhasználó jelentkezik be a Drupalba, aki még korábban nem jelentkezett be (pontosabban ha a Shibboleth-en keresztül megkapott azonosító még nem létezik), akkor a modul létrehoz egy új Drupal felhasználót. A felhasználó jelszava egy olyan véletlenszerűen generált megfelelően hosszú karakter sorozat, amely egyaránt tartalmazhat kis- és nagybetűket, valamint számokat. Alapesetben a felhasználó számára a jelszó változtatása tiltott, így a hagyományos úton (felhasználó név/ jelszó párossal) nem tud. A későbbiekben a jelszó változtatásának joga azonban egyénileg, vagy csortosan kiosztható ezzel engedélyezve a két authentikáció párhuzamos használatát. Néhány felhasználói beállítás kezdeti értéke származhat a Shibboleth-től kapott attribútumokból:

- teljes név
- email cím

(Ez utóbb funkciót az implementáció nem tartalmazza, ugyanis a különböző Shibboleth beállításoknak megfelelően rendszerenként más információk állnak rendelkezésre. Ennek kezelése a modul jövőbeli fejlesztései közé tartozik.)

A felhasználói attribútumok változtatása az IdP-ben nem terjed át a Drupalra (leszámítva természetesen a felhasználói azonosítót), az Drupalban található attribútumok megváltoztathatók, ha ezt az oldal konfigurációja megengedi.

Az újonnan létrejött felhasználó alap jogosultságokkal rendelkezik, ezután az adminisztrátor további jogokat biztosíthat számára.

### Felhasználó törlése

A felhasználót a [központi adatbázisból](#bkmrk-lehet%C5%91s%C3%A9g-van-arra-i) kell törölni, ezáltal megszűnik a hozzáférése a Drupalhoz. A Drupal azonosítója és beállításai azonban megmaradnak, ami az alábbi következményekkel jár (Vigyázat! Ha korábban egedélyeztük számára a jelszavas belépést, akkor azt külön le kell tiltani!):

- ha újra kiosztják a felhasználó azonosítóját, akkor a régi beállítások lesznek érvényesek
- lehetséges privát üzenetet küldeni a felhasználó email címére
- a törölt felhasználó mindaddig be tud lépni, amíg a Drupal által használt cookie érvényes, ezért célszerű memóriában tárolt cookie-kat használni (ld.: [Drupal modul konfiguráció](#bkmrk-konfigur%C3%A1ci%C3%B3))

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](#bkmrk-RequestMap) 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](#bkmrk-lehet%C5%91s%C3%A9g-van-arra-i).

!!! 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](#bkmrk-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ó](https://help.edu.hu/books/aai/page/drupal-shibboleth-module)

!!! 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](http://drupal.org/project/userprotect)!
    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](http://drupal.org/project/shib_auth)!
    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 &lt;drupal telepítési könyvtára&gt;/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.: &lt;drupal telepítési könyvtára&gt;/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 &lt;Drupal CMS elérhetősége&gt;/?q=user oldalt anélkül, hogy Shibboleth-en keresztül authentikáltad volna magad.

### Required session

Lehetőség van arra is, hogy a felhasználók Shibboleth-en keresztüli authentikációját kötelezően megköveteld az oldal valamennyi megtekintése előtt. Ebben az esetben azonban nem lehetséges a nem shib\_auth-on keresztüli belépés, így amíg ez a kényszer fenn áll, nem megoldható, hogy adminisztrátorként lépj be.

# Publikációk

- [AAI előadás a 2007-es Networkshopon](#bkmrk-aai-el%C5%91ad%C3%A1s-a-2007-e)
- [AAI és Shibboleth](https://help.edu.hu/books/aai/page/aai-es-shibboleth-20071107) (HBONE Workshop)

# Federation_Policy

## About eduID

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

## Contacts

The Federation is operated by [NIIF Institute](http://www.niif.hu) as a Federation Operator. Questions, concerns or any kind of requests about the Federation should be directed to any of the following addresses:

- **aai@niif.hu**
- **Kristof Bajnok**, *NIIF Institute*
- 18-22 Victor H. str
- H-1132 Budapest
- Hungary

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

## Policy and principles of interoperation

### Basic principles

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

### Data protection

- Prior joining the federation, every entity needs to publish the Data Protection Policy under which it operates. This policy must be kept up-to-date.
- Whenever the Data Protection Policy changes, the Federation Operator must be notified.
- Transfer of personal data is only allowed when either 
    - authorised by law, or
    - the user expressed his or her consent on the data transfer.

### Rules of membership

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

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

## Governance

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

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

MB is authorised to

- accept new Federation documents or modify existing ones,
- accept application of new Members and Partners

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

## Legal

The Federation itself is not a legal entity, Members and Partners establish a legal connection to the Federation Operator. Any legal claims between Members and/or Partners shall be directed to the organisation operating the Identity Provider or the Service Provider.

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

- [http://wiki.shibboleth.net/](http://wiki.shibboleth.net/)
- [https://docs.docker.com/](https://docs.docker.com/)

## Apache 2.4

Az alábbi példákban az SP és az alkalmazás konténer [SSL termination proxy](https://en.wikipedia.org/wiki/TLS_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](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](https://en.wikipedia.org/wiki/Hosts_(file)) meglehetősen egyszerűen használható eszköz arra, hogy élesben működő szolgáltatás átalakítása során tudjunk. Mivel az eduID-ban elterjedten használt SAML profilokban az üzenetváltás a legtöbb esetben a böngészőn keresztül zajlik, ezért elegendő a böngészőt arra rávenni, hogy a tesztelni kívánt SP-t vagy IdP-t ne a világ által látott helyen, hanem a tesztelni kívánt ponton keresse. Ez a módszer **mind SP, mind IdP tesztelésre használható**.

**Néhány tipp:**

- A tesztelni kívánt IdP vagy SP föderációs konfigjában megadott [tanúsítványok](https://help.edu.hu/books/aai/page/tanusitvanyok-a-foderacioban) egyezzenek meg az éles rendszerben használt tanúsítvánnyal. Ennek hiányában az aláírás nem lesz valid, illetve az esetlegesen titkosítottan küldött adatokat nem lehet kibontani.
- Ha végül az új gép a régi nevén fog hallgatni, akkor nincs szükség a [Resource Registry](https://help.edu.hu/books/aai/page/resource-registry)-ben módosítani az adatokon.
- *Bármely* SP-vel / IdP-vel tesztelhetjük az IdP-nket / SP-nket, hacsak nem rontunk el valamit (vö. első két pont) a távoli fél nem fogja észrevenni, hogy nem az "éles" partnerrel beszél.
- Tesztelésre privát IP cím is megfelelő, feltéve, hogy a saját gépünk eléri azt a tartományt.
- \[SP\]: [HEXXA](#bkmrk-a-szolg%C3%A1ltat%C3%A1sunk-sa) kapcsolat is tesztelhető a módszerrel, feltéve, hogy a tesztelt SP képes kapcsolatot nyitni a hexaa.eduid.hu 8443-as portjára. A HEXAA kizárólag a használt SSL tanúsítvány alapján azonosítja be a kérdezőt, így ugyanazt a tanúsítványt és entityID-t használva ugyanazt a választ kapjuk a tesztelt és az éles SP-n is.
- \[IdP\]: Az IdP-nk helyes működését például itt tudjuk ellenőrizni: [https://attributes.eduid.hu](https://attributes.eduid.hu)

## SP tesztelés

A szolgáltatásunk SAML integrációjának tesztelésére remekül használható eszköz a **[https://samlidp.io](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](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](https://winscp.net/eng/download.php)

**Szükséges adatok:**

**SFTP host:** ftp.pws.niif.hu

**SFTP user:** &lt; felhasználói név &gt;

**SFTP password:** &lt; jelszó &gt;

![WinSCP - Munkamenet](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/winscp.png)

*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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/konyvtarszerkezet.png)

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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupalkezdo.png)

Válasszuk ki az **English** opciót majd kattintsunk a **Save and continue** opcióra.

![Drupal - Profil választás](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupal_profil.png)

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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/fajlhiba.png)

Az alábbi fájlt nevezzük át:**/protected/www/sites/default/default.settings.php** -&gt; **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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/atnevezes.png)

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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupal_adatbazis.png)

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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupal_install.png)

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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupal_configure1.png)![Drupal - Oldalbeállítás 2](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupal_configure2.png)

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](http://sajtdomain/admin/reports/status)

![Drupal hiba](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupal_hiba.png)

**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](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/settings.php_jogosultsag.png)

A default mappa jogosultságát módosítsuk 0555-re. ![Drupal default mappa](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupal_default_mappa.png)

**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)](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupal_trusted_host_pattern.png)

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)](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/images/gallery/2025-03/drupal_host_pattern.png)

# FederationStats

# Federation usage statistics

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

```
I am a stub, please fix me!

```

Federation visualization project - discountinued.

- source (ruby on rails) [https://repo.niif.hu/gitweb/gitweb.cgi?p=federation-stats.git;a=summary](https://repo.niif.hu/gitweb/gitweb.cgi?p=federation-stats.git;a=summary)
- live demo

## Running the sample project

- Install Ruby
- Install Rails (`gem install rails`)
- Setup a `development.sqlite3` database with the `rake db:setup` command
- Fire up `script/server`, it will run the project on localhost:3000

## Statistic types

Currently we have the following types of statistics:

- Unique users per day (`USER_COUNT`)
- AuthnResponse per day (`AUTH`)
- AuthnResponse per service per day (`SSO_TO_SERVICE`)

## Log statistics format

The following simple format is used to convey statistics from IdPs to the central module - the white spaces (new lines) are important:

```
ENTITYID #ENTITYID#
APIKEY #API_KEY#
DATE yyyy-mm-dd

STAT #STAT_ID#
xxxx

STAT #STAT_ID#
yyyy

STAT #STAT_ID#
ww | #PEER_ENTITY_1#
zz | #PEER_ENTITY_2#

```

The following sample might help understanding the format:

```

ENTITYID <a href="https://idp.niif.hu/idp/shibboleth">https://idp.niif.hu/idp/shibboleth</a>
APIKEY 0123.......
DATE 2009-03-18

STAT AUTH
68 logins

STAT USER_COUNT
16 unique userids

STAT SSO_TO_SERVICE
1        | urn:geant:niif.hu:niifi:sp:register.ca.niif.hu
12       | <a href="https://repo.niif.hu/shibboleth">https://repo.niif.hu/shibboleth</a>
1        | <a href="https://sandbox.aai.niif.hu/shibboleth">https://sandbox.aai.niif.hu/shibboleth</a>
5        | <a href="https://sysmonitor.hbone.hu/shibboleth">https://sysmonitor.hbone.hu/shibboleth</a>
10       | <a href="https://www.ki.iif.hu/shibboleth">https://www.ki.iif.hu/shibboleth</a>
1        | <a href="https://noc6.vh.hbone.hu/shibboleth">https://noc6.vh.hbone.hu/shibboleth</a>
21       | <a href="https://webadmin.iif.hu/shibboleth">https://webadmin.iif.hu/shibboleth</a>
3        | <a href="https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth">https://rrd-ma.perfsonar.vh.hbone.hu/shibboleth</a>
7        | <a href="https://ugyeletes.vh.hbone.hu/shibboleth">https://ugyeletes.vh.hbone.hu/shibboleth</a>
2        | <a href="https://noc.grid.niif.hu/shibboleth">https://noc.grid.niif.hu/shibboleth</a>
1        | <a href="https://wiki.voip.niif.hu/shibboleth">https://wiki.voip.niif.hu/shibboleth</a>
2        | <a href="https://netmonitor.hbone.hu/shibboleth">https://netmonitor.hbone.hu/shibboleth</a>
2        | <a href="https://idp.sch.bme.hu:443/opensso/sp/test">https://idp.sch.bme.hu:443/opensso/sp/test</a>
```

## Running the log statistics collector

This following script can be used the collect statistics from the idp audit logs of Shibboleth 2 IdP generated on the day before running. It is based on Peter Schober's audit\_r7.py, and good for run from daily cronjob:

```bash
#!/bin/bash

#Config section
PARSER_COMMAND="/opt/shibboleth-idp/bin/audit_r7.py"
SOURCEDIR="/opt/shibboleth-idp/logs"
TARGETDIR="/tmp"

ENTITYID="idp-entity-id"
APIKEY="aaa..."
LOCATION2PUT="https://fedstats.example.org/import_stats"

DATE=`date -d "yesterday" +"%Y-%m-%d"`
SOURCEFILE="$SOURCEDIR/idp-audit-$DATE.log"

#Should not edit below this

if [-f $SOURCEFILE ]()
then
    LOGINS=`$PARSER_COMMAND -l $SOURCEFILE`
    UNIQUE_LOGINS=`$PARSER_COMMAND -u $SOURCEFILE`
    SERVICES=`$PARSER_COMMAND -p $SOURCEFILE | sed '/^[0-9]/p' -n`

    TARGETFILE="stat-$DATE.log"

echo "ENTITYID $ENTITYID
APIKEY $APIKEY
DATE $DATE

STAT AUTH
$LOGINS

STAT USER_COUNT
$UNIQUE_LOGINS

STAT SSO_TO_SERVICE
$SERVICES
" > $TARGETDIR/$TARGETFILE

    wget -q --no-check-certificate --post-file=$TARGETDIR/$TARGETFILE $LOCATION2PUT -O /dev/null
    rm $TARGETDIR/$TARGETFILE
fi


```

The script below can be used the collect statistics from all the idp audit logs placed in a folder.

```bash
#!/bin/bash

#Config section
PARSER_COMMAND="/opt/shibboleth-idp/bin/audit_r7.py"
SOURCEDIR="/opt/shibboleth-idp/logs"
TARGETDIR="/tmp"

ENTITYID="idp-entity-id"
APIKEY="aaa..."
LOCATION2PUT="https://fedstats.example.org/import_stats"

FILES="idp-audit-*.log"

#Should not edit below this
cd $SOURCEDIR
for f in $FILES
do
  if [-f $f ]()
  then
    echo "Processing $f file..."
    DATE=${f:10:10}
    LOGINS=`$PARSER_COMMAND -l $f`
    UNIQUE_LOGINS=`$PARSER_COMMAND -u $f`
    SERVICES=`$PARSER_COMMAND -p $f | sed '/^[0-9]/p' -n`

    TARGETFILE="stat-$DATE.log"

    echo "ENTITYID $ENTITYID
APIKEY $APIKEY
DATE $DATE

STAT AUTH
$LOGINS

STAT USER_COUNT
$UNIQUE_LOGINS

STAT SSO_TO_SERVICE
$SERVICES
" > $TARGETDIR/$TARGETFILE

    wget -q --no-check-certificate --post-file=$TARGETDIR/$TARGETFILE $LOCATION2PUT -O /dev/null
    rm $TARGETDIR/$TARGETFILE
  fi
done

```

## Feeding the database with the statistics

The federation statistics rails project contains the `script/stat_parser/file.rb` command which can process the statistics format and load the data to the database. Note that this script currently contains an absolute path for the `script/runner` script, so you must fix this before use.

## Using HTTP-Post to feed the database

When deployed, the rails project provides a `/import_stats` URL to which one could POST the generated statistics file.

## Creating IdPs

Use the rails console to create new idps:

```
$ RAILS_ENV=production script/console

>> Entity.create :name => 'foo', :entity_type => 'idp'

=> #<Entity id: 1, name: "foo", entity_type: "idp", created_at: "2010-11-29 14:55:40", updated_at: "2010-11-29 14:55:40", api_key: "da9l233a45698fa5c4a252e301e3da2sf5ece24e">

```

# HREFGlossary

## Föderáció

Olyan bizalmi szövetség, melynek résztvevői elfogadják egymás felhasználóit azonosítottnak.

## HREF Föderáció

(Hungarian Research and Education Federation, Magyar Kutatási és Felsőoktatási Föderáció), magyar felsőoktatási, kutatási intézmények és közgyűjtemények [föderációja](https://help.edu.hu/books/aai/page/foderacio).

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

A Föderációs Operátor a [Tagokkal](#bkmrk-tag) és [Partnerekkel](#bkmrk-partner) megkötött csatlakozási szerződés alapján a HREF föderáció központi szolgáltatásainak működtetője. Elsődleges szerepe az, hogy a tagok közötti bizalmi viszonyt kialakítsa és fenntartsa.

Gyakorlati feladatai közé tartozik a központi szolgáltatások működtetése ([Discovery Service](#bkmrk-discovery-service), [Resource Registry](#bkmrk-resource-registry)), a [Metadata](#bkmrk-metaadatok) állomány karbantartása és rendszeres aláírása, valamint a tagokkal ill. partnerekkel való szerződéses viszony kialakítása. A Föderációs Operátor vállalt feladatait és ezek szolgáltatási szint paramétereit az [SLA megállapodás](https://help.edu.hu/books/aai/page/href-szolgaltatasi-szint-megallapodas) tartalmazza.

## Felhasználó

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

## Tag

A [HREF Föderációhoz](#bkmrk-href-f%C3%B6der%C3%A1ci%C3%B3) a [Föderációs Operátorral](#bkmrk-f%C3%B6der%C3%A1ci%C3%B3s-oper%C3%A1tor) megkötött csatlakozási szerződés alapján csatlakozó intézmény. Ilyen módon csak magyar felsőoktatási, kutatási, ill. oktatási és közgyűjteményi tevékenységet folytató jogi személyek csatlakozhatnak.

A Tag azonosított [felhasználói](#bkmrk-felhaszn%C3%A1l%C3%B3) igénybe vehenek más tagok ill. [Partnerek](#bkmrk-partner) által biztosított szolgáltatásokat.

## Partner

A [HREF Föderációhoz](#bkmrk-href-f%C3%B6der%C3%A1ci%C3%B3) a [Föderációs Operátorral](#bkmrk-f%C3%B6der%C3%A1ci%C3%B3s-oper%C3%A1tor) megkötött csatlakozási szerződés alapján csatlakozó partner intézmény.

Partner intézmény szolgáltatásokat biztosíthat [Tagok](#bkmrk-tag) által azonosított felhasználók számára.

## Tagok Tanácsa

A [Föderáció](#bkmrk-href-f%C3%B6der%C3%A1ci%C3%B3) működését szabályozó dokumentumokat a [Föderációs Operátor](#bkmrk-f%C3%B6der%C3%A1ci%C3%B3s-oper%C3%A1tor) a Tagok Tanácsa jóváhagyásával módosíthatja.

## IdP

Identity Provider. Szövegkörnyezettől függően jelentheti az [Azonosító Szervezetet](#bkmrk-azonos%C3%ADt%C3%B3-szervezet), ill. az [IdP AAI Kaput](#bkmrk-idp-aai-kapu).

## Azonosító Szervezet

A felhasználók azonosítását elvégző intézmény ("saját intézmény"). Az azonosító szervezet - az adatvédelmi szabályok betartása mellett - a felhasználóról [Attribútumokat](#bkmrk-attrib%C3%BAtum) adhat át a [Tartalomszolgáltatónak](#bkmrk-tartalomszolg%C3%A1ltat%C3%B3)

## Attribútum

A felhasználóhoz kapcsolódó személyes adat, illetve a felhasználó intézményhez való viszonyát leíró adat. A felhasználó attribútumait az [Azonosító Szervezet](#bkmrk-azonos%C3%ADt%C3%B3-szervezet) tartja karban. Az attribútumok egy jól meghatározott halmazát az azonosítási folyamat részeként az [IdP AAI Kapu](#bkmrk-idp-aai-kapu) átadja a [Tartalomszolgáltatónak](#bkmrk-tartalomszolg%C3%A1ltat%C3%B3).

## IdP AAI Kapu

Az a szoftver, amely elvégzi a felhasználók azonosítását és lehetőséget biztosít az azonosítással kapcsolatos információk, valamint felhasználói adatok ([Attribútumok](#bkmrk-attrib%C3%BAtum)) kiadására.

## SP

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

## Tartalomszolgáltató

A Tartalomszolgáltató az [Azonosító Szervezet](#bkmrk-azonos%C3%ADt%C3%B3-szervezet) azonosítása alapján, az arra jogosult felhasználók számára webes szolgáltatásokat nyújtó szervezet. A [HREF Föderációban](#bkmrk-href-f%C3%B6der%C3%A1ci%C3%B3) Tartalomszolgáltatóként részt vehet mind a Tag, mind a Partner.

## SP AAI Kapu

Az a szoftver, amely értelmezi az [Azonosító Szervezettől](#bkmrk-azonos%C3%ADt%C3%B3-szervezet) kapott adatokat, ellenőrzi a kapott üzenet az érvényességét és sértetlenségét, majd jogosultságellenőrzést végez.

## Entitás

Az [SP AAI Kapu](#bkmrk-sp-aai-kapu) és az [IdP AAI Kapu](#bkmrk-idp-aai-kapu) összefoglaló neve.

## Saját SP

[Tag](#bkmrk-tag) által üzemeltett webes szolgáltatás, amely kizárólag intézményen belül elérhető. Saját SP-k regisztrálhatók a [Resource Registry](#bkmrk-resource-registry) segítségével, azonban a föderációs [metadatában](#bkmrk-metaadatok) nem jelennek meg.

## Resource Registry

A Resource Registry az [HREF Föderáció](#bkmrk-href-f%C3%B6der%C3%A1ci%C3%B3) működtetéséhez szükséges olyan nyilvántartás, amely az [Azonosító Szervezetekre](#bkmrk-azonos%C3%ADt%C3%B3-szervezet) és a [Tartalomszolgáltatókra](#bkmrk-tartalomszolg%C3%A1ltat%C3%B3) vonatkozó információkat kezeli. A Resource Registry segítségével előállítható és szerkeszthető a föderációs [Metadata](#bkmrk-metaadatok), valamint az Azonosító Szervezetek által a Tartalomszolgáltatók részére átadandó információkra vonatkozó szabályok.

## Discovery Service

A [Föderációs Operátor](#bkmrk-f%C3%B6der%C3%A1ci%C3%B3s-oper%C3%A1tor) által üzemeltetett Keresőszolgáltatás (Discovery Service) egy olyan webes felület, ahol a felhasználók kiválaszthatják az őket azonosítani tudó [Azonosító Szervezetet](#bkmrk-azonos%C3%ADt%C3%B3-szervezet).

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

## Metaadatok

(Metadata) Az [HREF Föderációban](#bkmrk-href-f%C3%B6der%C3%A1ci%C3%B3) résztvevő intézményeket leíró adatállomány. Az állomány tartalmaz:

- technikai információkat
- kontaktok elérhetőségi adatokat
- leíró adatokat Az állományban található adatokat, valamint az állomány kezelésével kapcsolatos előírásokat a [Metadata Specifikáció](https://help.edu.hu/books/aai/page/href-metadata-specifikacio) részletezi.

## Virtuális Azonosító Szervezet

(VHO, Virtual Home Organization) A [Föderációs Operátor](#bkmrk-f%C3%B6der%C3%A1ci%C3%B3s-oper%C3%A1tor) által üzemeltetett szolgáltatás, mely azonosítási szolgáltatást nyújt a Föderációban Tagként nem szereplő intézmények felhasználói számára, illetve lehetőséget biztosít a Tagok vendég felhasználói adminisztrálására is.

# Shibboleth_IdP_telepítés__Debian_

!!! bug "Elavult információ"

```
**Figyelem**: a Shibboleth szoftver ezen változata már nem támogatott. Az új verziókhoz a leírások itt találhatók:

* [Shibboleth2_IdP](https://help.edu.hu/books/aai/page/shibboleth2-idp)
* [Shibboleth2_SP](https://help.edu.hu/books/aai/page/shibboleth2-sp)

```

## Előkészületek

### Tanúsítvány

Kell készíteni egy megfelelő SSL szerver tanúsítványt. Ha más nem szól ellene, érdemes ugyanazt a tanúsítványt használni a felhasználók felé, mint az SP-k felé.

### Tűzfal

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

## Tomcat

### JDK telepítés

Sajnos Etch alatt a `sun-java5-jdk` csomag függ egy csomó X-es csomagtól, melyeket nem biztos, hogy szeretnénk telepíteni egy szerveren, érdemes lehet

- feltenni a `sun-java5-jre` csomagot ÉS
- kézzel telepíteni egy JDK-t, mondjuk a [http://java.sun.com](http://java.sun.com) oldalról letöltve

Ez igazából egy nagy *hack*, ugyanis ahhoz, hogy a tomcat-et csomagból telepíteni tudjuk, kell a `java2-runtime` csomag, amelyet biztosít a JRE is, **viszont** a Tomcat-nek JDK kell, hogy JSP-t tudjon futtatni.

```
* <small>**Megj.:** Minden JSP-t első futtatáskor a konténer (Tomcat) lefordít Java kóddá, aztán byte-kóddá, ezért tart jó sokáig az - újraindítás utáni - első request. Ezután az eredményt elcache-eli, így csak akkor kell újrafordítania, ha a JSP megváltozik.</small>

```

A JDK telepítés elég egyszerű, letöltjük a java.sun.com oldalról a nekünk tetsző verziót, aztán kicsomagoljuk, mondjuk a `/usr/lib` alá, aztán csinálunk egy szimbolikus linket, hogy a `/usr/jdk` mindig a "jó" JDK-ra mutasson.

### Tomcat telepítés

Ha minden rendben meg, akkor elegendő egy

```
apt-get install tomcat5.5

```

Ez felpakolja a tomcat különböző függőségeit is.

Ahhoz, hogy a Tomcat rendben elinduljon, szükséges neki megmondani, hogy hol találja a JDK-t. Ezért tegyük a `/etc/default/tomcat5.5` fájlba a következőt:

```
JAVA_HOME=/usr/jdk

```

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

```
TOMCAT5_SECURITY=no

```

### Tomcat konfiguráció

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

```xml
<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 :)](#bkmrk-shibboleth-identity-)

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:

- <strike>`libapache-mod-ssl`</strike>: a `mod_ssl` az `apache2` csomag része.
- `libapache2-mod-jk`

A konfiguráció lépései:

- `mod_ssl` modul betöltése; figyelés a 8443-as porton is
- `mod_jk` modul betöltése, konfigurálása
- VirtualHost konfigurálása
- autentikáció konfigurálása

### mod\_ssl

`/etc/apache2/ports.conf`

```
Listen 443
Listen 8443

```

Engedélyezzük az SSL modult.

```
a2enmod ssl

```

### mod\_jk

A `mod_jk` telepítés után alapértelmezetten engedélyezve van, ha mégsem lenne, az `a2enmod jk` paranccsal engedélyezhetjük.

A `/etc/libapache2-mod-jk/workers.properties` file-ban állítsuk be a `workers.tomcat_home` és a `workers.java_home` paramétereket a Tomcat ill. a JDK telepítésénél használt értékekre. (tomcat\_home=/usr/share/tomcat5.5 az alapértelmezett telepítésnél.)

Már csak az van hátra, hogy bizonyos URI-kra érkező kéréseket a modul átküldje a Tomcat-nek. Ehhez az alábbi konfigurációs direktívákat kell megadnunk valahol a szerver konfigurációban (pl. `/etc/apache2/apache2.conf`)

```
<IfModule mod_jk.c>
   JkWorkersFile /etc/libapache2-mod-jk/workers.properties
   JkLogFile /var/log/apache2/mod_jk.log
   JkLogLevel info
   JkMount /shibboleth-idp/* ajp13_worker
</IfModule>

```

A fenti példában a **shibboleth-idp** az IdP servlet telepítése során (később) megadott URI. Ez azt jelenti, hogy a `/shibboleth-idp` URI alá jövő összes kérést a Tomcat fogja megkapni.

- <small>RedHat ES4 disztribúció alatt az **ajp13\_worker** helyett **ajp13**-t kellett használni.</small>

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

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

```

- <small>**Megj.:** IPv6-on is figyelünk :)</small>

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

- <small>**Megj.:** Az LDAP SSL használatához a [leírás itt található](https://help.edu.hu/books/ldap-l5f/page/ldap-kliens-ssl)</small>

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

- <small>A Debian alatti tomcat5.5 csomag használatakor a `/usr/share/tomcat5.5/common/endorsed` könyvtárba kell tenni a jar file-okat.</small>

### Installer

```
export JAVA_HOME=/usr/jdk
./ant

```

A telepítés során az alábbi paramétereket kell megadnunk:

- Shibboleth IdP alkalmazás neve: az URI, amelyre érkező kéréseket a Tomcat az IdP servletnek ad át. Default: `shibboleth-idp`
- Filesystem- vagy manager-alapú telepítést akarunk? (Javasolt: Filesystem)
- Az IdP alkalmazás könyvtára. Default: `/usr/local/shibboleth-idp`
- Tomcat home. Default: `/usr/local/tomcat`, Debian alatt a `/var/lib/tomcat5.5` könyvtárat érdemes használni.

### Könyvtárak

A telepítő minden file-t (binárisok, konfiguráció, logok, stb) egyetlen könyvtár alatti struktúrába tenne, de valószínűleg jobban járunk, ha az alkalmazásunk konfigurációja a `/etc`, a logok pedig a `/var/log` alatt találhatók.

Például:

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

```bash
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](https://hostnev/shibboleth-idp/Status) URI-t, amelynek az "AVAILABLE" stringet kell visszaadni.

## Forrás

- [Shibboleth Identity Provider Installation](https://spaces.internet2.edu/display/SHIB/JKIdPInstall)
- [Shibboleth IdP installation with Debian and Tomcat](http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/idp/install-idp-1.3-debian-apache.html)
- [Shibboleth IdP telepítése Debian 4.0 / Ubuntu 7.04 alatt](https://www.aai.dfn.de/dokumentation/identity-provider/installation-debian-4-0-ubuntu-7-04/) (német nyelvű)
- Más környezetekre vonatkozó telepítési leírások 
    - [SUSE 10](http://www.lrz-muenchen.de/~hommel/shibboleth/shib13c_on_SuSE10.0.html#idpinstallation)
    - [OpenSUSE 10.2](https://www.aai.dfn.de/dokumentation/identityprovider/installation-opensuse-102.html) (német)
    - **Tomcat-only telepítési leírások**
    - ["Hivatalos" Tomcat-only leírás](https://spaces.internet2.edu/display/SHIB/TomcatAlone)
    - [Debian + Tomcat](http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/idp/install-idp-1.3-debian.html)

# 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

```php
...
        'authproc.sp' => array(
...
               11 => array(
                       'class' => 'core:AttributeMap', 'oid-href'
               ),
...
   ),
...

```

attributemap/href-oid.php

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

/**
*  Hungarian Research and Education Federation AttributeSchema representation
*  source: [https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif](https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif)
*  @author: Szabó Gyula, aai.sztaki.hu  <gyufi@sztaki.hu>
*
*/

$attributemap = array(
        'urn:oid:1.3.6.1.4.1.11914.0.1.155' => 'niifPersonCityOfBirth',
        'urn:oid:1.3.6.1.4.1.11914.0.1.152' => 'niifPersonDateOfBirth',
        'urn:oid:1.3.6.1.4.1.11914.0.1.153' => 'niifPersonActivityStatus',
        'urn:oid:1.3.6.1.4.1.11914.0.1.169' => 'niifPersonJoinDate' ,
        'urn:oid:1.3.6.1.4.1.11914.0.1.154' => 'niifPersonOrgID',
        'urn:oid:1.3.6.1.4.1.11914.0.1.151' => 'niifCertificateSubjectDN',
        'urn:oid:1.3.6.1.4.1.11914.0.1.161' => 'niifEduPersonFacultyDN',
        'urn:oid:1.3.6.1.4.1.11914.0.1.167' => 'niifPersonPosition' ,
        'urn:oid:1.3.6.1.4.1.11914.0.1.1' => 'niifStatus',
        'urn:oid:1.3.6.1.4.1.11914.0.1.158' => 'niifPersonIdentityNumber',
        'urn:oid:1.3.6.1.4.1.11914.0.1.2' => 'niifTitle',
        'urn:oid:1.3.6.1.4.1.11914.0.1.173' => 'niifCertificateSHA1Fingerprint',
        'urn:oid:1.3.6.1.4.1.11914.0.1.164' => 'niifEduPersonAttendedCourse',
        'urn:oid:1.3.6.1.4.1.11914.0.1.171' => 'niifEduPersonArchiveCourse',
        'urn:oid:1.3.6.1.4.1.11914.0.1.172' => 'niifEduPersonHeldCourse',
        'urn:oid:1.3.6.1.4.1.11914.0.1.0' => 'niifPrefix',
        'urn:oid:1.3.6.1.4.1.11914.0.1.166' => 'niifPersonDegree' ,
        'urn:oid:1.3.6.1.4.1.11914.0.1.160' => 'niifEduPersonFaculty',
        'urn:oid:1.3.6.1.4.1.11914.0.1.162' => 'niifEduPersonMajor',
        'urn:oid:1.3.6.1.4.1.11914.0.1.170' => 'niifPersonQuitDate' ,
        'urn:oid:1.3.6.1.4.1.11914.0.1.157' => 'niifPersonMothersName',
        'urn:oid:1.3.6.1.4.1.11914.0.1.163' => 'niifEduPersonAcademicYear',
        'urn:oid:1.3.6.1.4.1.11914.0.1.156' => 'niifPersonCountyOfBirth',
        'urn:oid:1.3.6.1.4.1.11914.0.1.3' => 'niifUniqueId',
        'urn:oid:1.3.6.1.4.1.11914.0.1.165' => 'niifPersonPrefix' ,
        'urn:oid:1.3.6.1.4.1.11914.0.1.168' => 'niifActiveMemberOf' ,
        'urn:oid:1.3.6.1.4.1.11914.0.1.159' => 'niifPersonResidentalAddress',
        'urn:oid:1.3.6.1.4.1.11914.0.1.100' => 'niifIDPrefix',
);
?>

```

# Shibboleth3_IdP

**Telepítési leírások**

- [Shibboleth 3 IdP telepítése (Debian 8 + Jetty 9.2)](https://help.edu.hu/books/aai/page/shib3idpinstall)
- [Shibboleth 3 IdP éles szolgáltatás építése (unix service)](https://help.edu.hu/books/aai/page/shib3idpprod)

**Konfigurációs leírások**

- [Shibboleth 3 IdP metaadat beállítása](https://help.edu.hu/books/aai/page/shib3idpmetadata)
- [Shibboleth 3 IdP hitelesítés beállítása](https://help.edu.hu/books/aai/page/shib3idpauth)
- [Shibboleth 3 IdP attribútum feloldás beállítása](https://help.edu.hu/books/aai/page/shib3idpattrib)
- [Shibboleth 3 IdP attribútum szűrés beállítása](https://help.edu.hu/books/aai/page/shib3idparp)

# Interoperabilitás_mátrix

# Interoperabilitás mátrix

## Tesztelt szoftverek

- Shibboleth 2.0 IdP 
    - metadata: [papigw-shibboleth2-idp.xml](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/papigw-shibboleth2-idp.xml)
    - telepítési útvonal: /usr/local/shibboleth-idp-2.0.0
    - protokollok: SAML1.1, Shibboleth1.3, SAML2.0
- Shibboleth 2.0 SP 
    - metadata: [papigw-shibboleth2-sp.xml](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/papigw-shibboleth2-sp.xml)
    - telepítés Debian csomagból, konfiguráció /etc/shibboleth/ alatt
    - protokollok: SAML1.1, Shibboleth1.3, SAML2.0
- OpenSSO/FAM 8.0 CVS build - IdP 
    - metadata: [maszat-opensso-idp.xml](https://s3.public.doc.einfra.hu/public-doc-einfra/uploads/files/2025-03-Mar/maszat-opensso-idp.xml)
    - host: maszat.sch.bme.hu
    - protokollok: SAML2.0
- simpleSAMLphp (?) - SP 
    - entityID: [https://papigw.aai.niif.hu/simplesaml](https://papigw.aai.niif.hu/simplesaml)
    - protokollok: Shibboleth1.3, SAML2.0

## Tesztelt protokollok és bindingok

- SAML2.0 AuthnRequest/AuthnResponse protokoll (Web browser SSO profil) 
    - HTTP-GET / HTTP-POST binding
    - HTTP-GET / HTTP-Artifact binding
- SAML2.0 AttributeQuery protokoll
- SAML2.0 Single Logout

## SAML2.0 Interoperabilitás mátrix

Jelmagyarázat:

- Single Sign on - AuthnRequest/Response (Attribute push-sal együtt)
- HTTP-POST - SAML2.0 HTTP-Post binding
- HTTP-Artifact - SAML2.0 HTTP-Artifact binding
- Attribute query - SAML2.0 Attribute Query protocol
- Signing / encryption - az Assertion aláírása, aláírt és titkosított Assertion feldolgozása
- Metadata management - mennyire egyszerű megoldani hogy az IdP és az SP ismerje egymást

A zöld-del jelölt funkciók tökéletesen működnek, a narancssárgák nem triviálisan, de működésre bírhatók (ilyenkor mindig van megjegyzés is hozzájuk), a pirossal jelölt funkciók nem működtek. Az áthúzott funkciókat nem implementálja az adott szoftverpáros.

Sure, here's the HTML conversion of the provided MediaWiki table:

<table border="1" cellpadding="5" cellspacing="0" id="bkmrk-shibboleth2-sp-opens"> <tr> <th></th> <th>Shibboleth2 SP</th> <th>OpenSSO SP</th> <th>simpleSAMLphp SP</th> </tr> <tr> <th>Shibboleth2 IdP</th> <td> <table> <tr> <th>[Shib2-Shib2](AAIInterop-Shib2Shib2)</th> </tr> <tr> <td style="background:green;">Single Sign on</td> </tr> <tr> <td style="background:green;">HTTP-POST</td> </tr> <tr> <td style="background:green;">HTTP-Artifact</td> </tr> <tr> <td style="background:green;">Attribute query</td> </tr> <tr> <td style="background:green;">Signing / encryption</td> </tr> <tr> <td style="background:green;">Metadata management</td> </tr> </table>

 </td> <td> <table> <tr> <th>[Shib2-OpenSSO](AAIInterop-Shib2OpenSSO)</th> </tr> <tr> <td>Single Sign on</td> </tr> <tr> <td>HTTP-POST</td> </tr> <tr> <td>HTTP-Artifact</td> </tr> <tr> <td>Attribute query</td> </tr> <tr> <td>Signing / encryption</td> </tr> <tr> <td>Metadata management</td> </tr> </table>

 </td> <td> <table> <tr> <th>[Shib2-SimpleSAMLphp](AAIInterop-Shib2SimpleSAMLphp)</th> </tr> <tr> <td style="background:green;">Single Sign on</td> </tr> <tr> <td style="background:green;">HTTP-POST</td> </tr> <tr> <td style="text-decoration:line-through;">HTTP-Artifact</td> </tr> <tr> <td style="text-decoration:line-through;">Attribute query</td> </tr> <tr> <td style="background:orange;">Signing / encryption</td> </tr> <tr> <td style="background:green;">Metadata management</td> </tr> </table>

 </td> </tr> <tr> <th>OpenSSO IdP</th> <td> <table> <tr> <th>[OpenSSO-Shib2](AAIInterop-OpenSSOShib2)</th> </tr> <tr> <td style="background:green;">Single Sign on</td> </tr> <tr> <td style="background:green;">HTTP-POST</td> </tr> <tr> <td>HTTP-Artifact</td> </tr> <tr> <td style="text-decoration:line-through;">Attribute query</td> </tr> <tr> <td>Signing / encryption</td> </tr> <tr> <td style="background:orange;">Metadata management</td> </tr> </table>

 </td> <td> <table> <tr> <th>OpenSSO-OpenSSO</th> </tr> <tr> <td>Single Sign on</td> </tr> <tr> <td>HTTP-POST</td> </tr> <tr> <td>HTTP-Artifact</td> </tr> <tr> <td>Attribute query</td> </tr> <tr> <td>Signing / encryption</td> </tr> <tr> <td>Metadata management</td> </tr> </table>

 </td> <td> <table> <tr> <th>OpenSSO-simpleSAML</th> </tr> <tr> <td>Single Sign on</td> </tr> <tr> <td>HTTP-POST</td> </tr> <tr> <td>HTTP-Artifact</td> </tr> <tr> <td>Attribute query</td> </tr> <tr> <td>Signing / encryption</td> </tr> <tr> <td>Metadata management</td> </tr> </table>

 </td> </tr> <tr> <th>simpleSAMLphp IdP</th> <td> <table> <tr> <th>simpleSAML-Shib2</th> </tr> <tr> <td>Single Sign on</td> </tr> <tr> <td>HTTP-POST</td> </tr> <tr> <td>HTTP-Artifact</td> </tr> <tr> <td>Attribute query</td> </tr> <tr> <td>Signing / encryption</td> </tr> <tr> <td>Metadata management</td> </tr> </table>

 </td> <td> <table> <tr> <th>simpleSAML-OpenSSO</th> </tr> <tr> <td>Single Sign on</td> </tr> <tr> <td>HTTP-POST</td> </tr> <tr> <td>HTTP-Artifact</td> </tr> <tr> <td>Attribute query</td> </tr> <tr> <td>Signing / encryption</td> </tr> <tr> <td>Metadata management</td> </tr> </table>

 </td> <td> <table> <tr> <th>simpleSAML-simpleSAML</th> </tr> <tr> <td>Single Sign on</td> </tr> <tr> <td>HTTP-POST</td> </tr> <tr> <td>HTTP-Artifact</td> </tr> <tr> <td>Attribute query</td> </tr> <tr> <td>Signing / encryption</td> </tr> <tr> <td>Metadata management</td> </tr> </table>

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

# HREF

Magyarországi felsőoktatási és kutatói [föderáció](https://help.edu.hu/books/aai/page/foderacio) (Hungarian Research &amp; Education Federation)

A föderáció jelenleg *technikai pilot* státuszban van, azaz elsősorban a technikai együttműködésre, ill. a hosszú távú szabályozás előkészítésére koncentrálunk.

## Tagjai

- [Debreceni Egyetem](#bkmrk-a-f%C3%B6der%C3%A1ci%C3%B3-a-saml2-)
- [Dunaújvárosi Főiskola](#bkmrk-a-f%C3%B6der%C3%A1ci%C3%B3-a-saml2-)
- [ELTE](#bkmrk-a-f%C3%B6der%C3%A1ci%C3%B3-a-saml2-)
- [Georgikon Keszthely](#bkmrk-a-f%C3%B6der%C3%A1ci%C3%B3-a-saml2-)
- [MTA KFKI Csillebérc](#bkmrk-a-f%C3%B6der%C3%A1ci%C3%B3-a-saml2-)
- [MTA Sztaki](#bkmrk-a-f%C3%B6der%C3%A1ci%C3%B3-a-saml2-)
- [NIIF Intézet](https://help.edu.hu/books/aai/page/niifi-idp)
- [PPKE](#bkmrk-a-f%C3%B6der%C3%A1ci%C3%B3-a-saml2-)
- [ZMNE](#bkmrk-a-f%C3%B6der%C3%A1ci%C3%B3-a-saml2-)

## Szolgáltatások

## URN

## Támogatott szabványok

A föderáció a SAML2 szabvány protokolljait használja. Minden résztvevő támogatja a SAML2 SSO Profile-t HTTP POST bindingon keresztül, néhányan Artifact bindingon keresztül is. A legtöbb résztvevő támogatja a SAML2 Single Logout profile-t.

# WebmailShibboleth

# Shibboleth, Webmail, IMAP Proof-of-concept

## In English

### Requirements

- The webmail software must not see or use users' LDAP password, the IdP must not release even the hashed form of the password.
- IMAP must authenticate with username and password.
- If one has access to the webmail server, she must not have access to the IMAP on behalf of all users (she can however access to active users session).

### Solution concepts

- The IdP and the IMAP server share an authentication database.
- With every webmail SP request the IdP generates a new password for that particular user and writes it to the database.
- The webmail SP receives this password with the attribute set and uses the username (e-mail address) and password to access the IMAP server.
- The IMAP server tries to authenticate against the database.
- In order to secure access, this password entry should contain an expiration time, which invalidates the password after the IdP session ends, so IMAP accepts only those users who has recently initiated active session at the IdP side.

### Shibboleth IdP plugin

- We have developed an IdP plugin -attribute resolver- which can generate this short-lifetime password (called service token) for the user and write it to the database.
- Shibboleth IdP attribute resolver configuration is independent from the actual SP, so the plugin must check whether the current request came from an SP for which it needs to generate the token.
- The service token is sent in plain-text, so the Shibboleth attribute statement must be encrypted either by using artifact resolution over SSL/TLS or by using XML encryption with HTTP-Post.

### IMAP configuration

- As we don't want to force the use of webmail, IMAP needs to use LDAP authentication as well.
- Most IMAP servers can be configured to use PAM, which can be configured to use arbitrary SQL tables for authentication and it also supports authentication chaining.

### Webmail softwares

- For our proof-of-concept we have tried squirrelmail and roundcube with its HTTP-authentication plugin. If the SP is releasing the username and service token as PHP\_AUTH\_USER and PHP\_AUTH\_PW, this authentication module works out-of-the-box.

## Magyarul

### Koncepció

A webmail és a levelezőszerver (IMAP/POP3) együttes működését szeretnénk Shibbolizálni. A fő probléma abból áll, hogy a webmail az IMAP szerver felé felhasználónévvel és jelszóval autentikál. Az címtárban tárolt jelszót azonban nem adhatjuk ki az alkalmazásoknak, ráadásul legtöbb esetben ez egy hashelt jelszó.

A következő kritériumoknak kell teljesülniük:

- a webmail nem fér hozzá a felhasználó SSO jelszavához (még hashelt formátumban sem)
- az IMAP szerver jelszavas autentikációt használ, minden felhasználónak egyedi jelszava van
- a webmail feltörése esetén nem férhetnek hozzá az összes felhasználó levelezéséhez

A fenti kritériumokat az 'egyszer használatos', rövid lejáratú jelszó használata ('service token') kielégíti. Ebben az esetben az IdP minden egyes webmail bejelentkezéshez generál egy véletlen jelszót, és ezt elmenti egy adatbázisban, (beállítva a jelszóhoz egy rövid lejárati időt) valamint elküldi a webmail SP-nek. A webmail ezen rövid lejáratú jelszó használatával autentikál az IMAP szerver felé.

A leírt gondolatmenet megvalósításához három komponens együttműködése szükséges:

- az IdP jelszót kell generáljon egy adatbázisba
- a webmailnek el kell érnie ezt a jelszót
- az IMAP szervernek a jelszóadatbázist kell használnia az autentikációra

### Adatbázis struktúra

MySQL használata esetén a következő adatbázisstruktúra használható:

```sql
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](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
 <!--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:

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

```xml
  <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](http://www.squirrelmail.org/plugin_view.php?id=34) 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](http://trac.roundcube.net/browser/trunk/roundcubemail/plugins/http_authentication) 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
<?xml version="1.0" encoding="ISO-8859-1"?>
<IdPConfig
        xmlns="urn:mace:shibboleth:idp:config:1.0"
        xmlns:cred="urn:mace:shibboleth:credentials:1.0"
        xmlns:name="urn:mace:shibboleth:namemapper:1.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:idp:config:1.0 ../schemas/shibboleth-idpconfig-1.0.xsd"
        AAUrl="https://idp.niif.hu:8443/shibboleth-idp/AA"
        resolverConfig="file:/etc/shibboleth-idp/resolver.ldap.xml"
        defaultRelyingParty="urn:niif.hu:aai:HREF"
        defaultAuthMethod="urn:oasis:names:tc:SAML:1.0:am:password"
        providerId="https://idp.niif.hu/shibboleth">

        <RelyingParty name="urn:niif.hu:aai:HREF" signingCredential="href_cred">
                <NameID nameMapping="shm"/>
        </RelyingParty>
        <RelyingParty name="urn:geant:niif.hu:niifi:sp:register.ca.niif.hu"
                      signingCredential="href_cred"
                      forceAttributePush="true">
                <NameID nameMapping="shm"/>
        </RelyingParty>

        <ReleasePolicyEngine>
                <ArpRepository implementation="edu.internet2.middleware.shibboleth.aa.arp.provider.FileSystemArpRepository">
                        <Path>file:/etc/shibboleth-idp/arps/</Path>
                </ArpRepository>
        </ReleasePolicyEngine>

        <Logging>
                <ErrorLog level="DEBUG" location="file:/var/log/shibboleth-idp/shib-error.log" />
                <TransactionLog level="INFO" location="file:/var/log/shibboleth-idp/shib-access.log" />
        </Logging>

        <NameMapping
                xmlns="urn:mace:shibboleth:namemapper:1.0"
                id="shm"
                format="urn:mace:shibboleth:1.0:nameIdentifier"
                type="SharedMemoryShibHandle"
                handleTTL="28800"/>

        <ArtifactMapper implementation="edu.internet2.middleware.shibboleth.artifact.provider.MemoryArtifactMapper" />

        <Credentials xmlns="urn:mace:shibboleth:credentials:1.0">
                <FileResolver Id="href_cred">
                        <Key>
                                <Path>file:/etc/httpd/conf/ssl.key/idp.niif.hu.key</Path>
                        </Key>
                        <Certificate>
                                <Path>file:/etc/httpd/conf/ssl.crt/idp.niif.hu.crt</Path>
                        </Certificate>
                </FileResolver>
        </Credentials>

        <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.ShibbolethV1SSOHandler">
                <Location>https?://[^:/]+(:(443|80))?/shibboleth-idp/SSO</Location> <!-- regex works when using default protocol ports -->
        </ProtocolHandler>
        <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.SAMLv1_AttributeQueryHandler">
                <Location>.+:8443/shibboleth-idp/AA</Location>
        </ProtocolHandler>
        <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.SAMLv1_1ArtifactQueryHandler">
                <Location>.+:8443/shibboleth-idp/Artifact</Location>
        </ProtocolHandler>
        <ProtocolHandler implementation="edu.internet2.middleware.shibboleth.idp.provider.Shibboleth_StatusHandler">
                <Location>https://[^:/]+(:443)?/shibboleth-idp/Status</Location>
        </ProtocolHandler>

        <MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata"
                uri="file:/etc/shibboleth-idp/href-metadata.xml"/>
</IdPConfig>

```

## XML elemek magyarázata

### IdPConfig

Az IdPConfig elem attribútumai közül az xmlns: és xsi: attribútumokat nem szabad megváltoztatni, de van néhány, amit kötelező:

- *defaultRelyingParty*: ez adja meg, hogy melyik [RelyingParty](https://help.edu.hu/books/aai/page/relyingparty)-t kell használni, ha a request alapján nem állapítható meg. Ha nincs ehhez tartozó RelyingParty elem, akkor az IdP nem indul el.
- *providerID*: ez adja meg az IdP egyedi azonosítóját a [föderációban](https://help.edu.hu/books/aai/page/foderacio). Általában URN vagy URL formában adjuk meg.
- *resolverConfig*: az [attribútum feloldás](https://help.edu.hu/books/aai/page/attributum-feloldas) konfigurációs állományát adja meg.
- *AAUrl*: az [Attribute Authority](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) elérhetősége. <small>(Erre csak a Shibboleth 1.1-el való kompatibilitás megőrzése érdekében van szükség. Nem biztos, hogy kötelező megadni...)</small>

Általában nem szükséges megadni:

- *authHeaderName*: itt kell megadni, ha az [SSO Handler](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) más változóban kapja meg a felhasználó azonosítóját (principal), mint a REMOTE\_USER szerver változó
- *defaultAuthMethod*: megadható, hogy az elkészített SAML [Assertion](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) milyen autentikációs metódust tartalmazzon. A lehetséges értékek a [SAML 1.1 specifikáció](http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf) 7.1-es szakaszában találhatók. Ha nincs megadva, akkor az értéke `urn:oasis:names:tc:SAML:1.0:am:unspecified`. A `defaultAuthMethod` értéke RelyingParty szintjén felülbírálható
- *maxSigningThreads*: az üzenet aláírására és egyéb műveletekre indított thread-ek maximális száma. Az IdP teljesítménye hangolható ezzel.
- *passThruErrors*: boolean változó, amely azt szabályozza, hogy a hibákat az IdP továbbadja-e az SP felé

Az IdP konfigurációban a többi XML Element az IdPConfig gyereke.

### RelyingParty

Egy IdP tetszőleges mennyiségű [RelyingParty](https://help.edu.hu/books/aai/page/relyingparty)-t kezelhet.

A legfelső szintű alapértelmezett beállításokon kívül minden egyes [RelyingParty](https://help.edu.hu/books/aai/page/relyingparty)-ra beállíthatjuk az alábbi értékeket:

- *name* (kötelező): a [RelyingParty](https://help.edu.hu/books/aai/page/relyingparty) neve. Ha nem egyezik meg az SP által küldött [providerId](https://help.edu.hu/books/aai/page/providerid)-vel, akkor az IdP a [metadata](https://help.edu.hu/books/aai/page/metadata) segítségével próbálja megállapítani, hogy az SP-re melyik RelyingParty definíció vonatkozik.
- *providerId*: az a [providerId](https://help.edu.hu/books/aai/page/providerid), amelyet az IdP használ a [RelyingParty](https://help.edu.hu/books/aai/page/relyingparty)-k felé.
- *signingCredential*: az [Assertion](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-)-ök és az SSL sessionben használt SSL kulcsokra vonatkozó FileResolver elem ID-jét adhatjuk meg itt.
- *AAUrl*: az [Attribute Authority](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) elérhetősége.
- *defaultAuthMethod*: megadható, hogy a [RelyingParty](https://help.edu.hu/books/aai/page/relyingparty) számára elkészített SAML [Assertion](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) milyen autentikációs metódust tartalmazzon. A lehetséges értékek a [SAML 1.1 specifikáció](http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf) 7.1-es szakaszában találhatók. Ha nincs megadva, akkor az értéke az IdPConfig element-nél megadott érték, ill. `urn:oasis:names:tc:SAML:1.0:am:unspecified`.
- *passThruErrors*: boolean változó, amely azt szabályozza, hogy a hibákat az IdP továbbadja-e az SP felé. Alapértelmezett érték: false
- *signAssertions*: boolean változó, amely azt szabályozza, hogy az IdP aláírja-e a kiállított [Assertion](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-)-öket. Leginkább akkor van rá szükség, ha az Assertion-t más alkalmazásnál is fel akarjuk használni. Alapértelmezett érték: false
- *forceAttributePush*: boolean változó, ennek segítségével ki lehet kényszeríteni az [Attribute Push](https://help.edu.hu/books/aai/page/attributepushpull) használatát. Alapértelmezett érték: false

A RelyingParty element NameID gyermeke segítségével állítható be a használt [NameID kezelés](#bkmrk-namemapping).

### ReleasePolicyEngine

Itt adhatjuk meg az [attribútum kiadás](https://help.edu.hu/books/aai/page/attributum-kiadas) implementációját (ezt általában nem kell változtatni) és az [ARP](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) á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)](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-))

### NameMapping

Ebben az elemben adható meg a NameMapper implementációja, illetve az [assertionökben](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) használt azonosító (Subject Identifier) formátuma.

- <small>Az alapértelmezett értékek az esetek többségében megfelelők, csak akkor módosítsd, ha tudod, mit csinálsz!</small>

**Attribútumok:**

- *id*: egyedi név, erre lehet hivatkozni a NameID elementben.
- *format* (URI): ez határozza meg a Subject Identifier formátumát. Tetszőleges URN használható, amiben az IdP és az SP megegyezik. Néhány gyakrabban használt formátum: 
    - `urn:mace:shibboleth:1.0:nameIdentifier`: alapértelmezett Shibboleth azonosító (tranziens, átlátszó)
    - `urn:oasis:names:tc:SAML1.1:nameid-format:X509SubjectName`: X.509 tanúsítvány DN. A [GridShib](http://gridshib.globus.org/) használja ezt a formátumot.
    - `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`: email-cím, használata nem javasolt
    - `http://schemas.xmlsoap.org/claims/UPN`: MS UPN, az [ADFS](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) integrációhoz használható
- *class*: a NameMapper implementációjának a javaclass útvonala. ([HAShib](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) használatához módosítani kell.) A további attribútumok csak az alapértelmezett implementáció esetén értelmezhetők.
- *handleTTL*: azt határozza meg, hogy az IdP mennyi ideig őrizze a Session Cache-ében a kiosztott azonosítókat. (Csak `urn:mace:shibboleth:1.0:nameIdentifier` formátum esetén értelmezhető.) Ezt követően erre az azonosítóra történő hivatkozás már nem lesz megengedett, a felhasználónak esetleg újra kell azonosítania magát.
- *type*: azt adja meg, hogy az [SSO Handler](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) és az [Attribute Authority](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) között milyen formában utazzanak az azonosítók. Lehetséges értékek: 
    - `CryptoHandleGenerator`: szimmetrikus kódolással titkosított azonosítók használata
    - `Principal`: az [SSO Handler](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-)-től megkapott azonosító átadása az [Attribute Authority](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-)-nek
    - `SharedMemoryShibHandle`: (alapértelmezett) megosztott, memóriában tárolt session cache. Ha az [SSO Handler](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) és az [Attribute Authority](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) egy konténerben futnak, ezt érdemes használni.

### ArtifactMapper

Itt adható meg az ArtifactMapper implementációja. [HAShib](#bkmrk-idp-f%C5%91-konfigur%C3%A1ci%C3%B3-) 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](#bkmrk-relyingparty).

### 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\*\*

- [IdP fő konfiguráció](https://spaces.internet2.edu/display/SHIB/IdPMainConfig)
- [Relying Party konfiguráció](https://spaces.internet2.edu/display/SHIB/IdPRelyingConfig)
- [NameMapping](https://spaces.internet2.edu/display/SHIB/IdPUserAuthnConfig)

# 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](http://en.wikipedia.org/wiki/HTTP_cookie#Third-party_cookies).

Every cookie which is sent to a foreign domain via img, iframe, script, etc. tags is considered to be third party, so the session cookie of the SP software in a foreign domain is third party cookie when it is sent in an IFrame. By blocking these cookies, the SP doesn't receive the session cookie and thus it could stop processing the logout request at this point.

Additional links:

- [Shibboleth-dev thread on the issue](http://n2.nabble.com/Frames-cookies-question-td4127538.html#a4127538)
- [How to disable third party cookies in firefox](http://support.mozilla.com/en-US/kb/Disabling+third+party+cookies)
- [Additional explanation in Mozilla Bugzilla](https://bugzilla.mozilla.org/show_bug.cgi?id=417800#c11)
- [Same origin policy for cookies](http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies)
- [Further information on third party cookie handling](http://code.google.com/p/browsersec/wiki/Part2#Third-party_cookie_rules)

"Although any third-party cookie restrictions are not a sufficient method to prevent cross-domain user tracking, they prove to be rather efficient in disrupting or impacting the security of some legitimate web site features, most notably certain web gadgets and authentication mechanisms."

### Why service providers might need the session cookie

Most of the services do not need the session cookie itself, they only need the NameIdentifier, which is carried by the logout request, so back-channel logout requests are enough for them. But there might be service providers which do not implement back-channel bindings (eg. SimpleSAMLphp), or need front-channel application notification.

### Why not fully back-channel?

SAML profiles specification (section 4.4.3.1) clearly states that front-channel should be preferred when sending the logoutrequest to the session authority (IdP). If the user interface is generated by the IdP, it could inform the user about the whole logout process, and each SP response. If the SP would use back-channel logoutrequest, the IdP's response would only contain minimal information (ie. success or failure), and this is not desirable. Also, the IdP would need to execute back-channel requests in parallel and synchronize them with the originating request, so this would make the processing code much more complex.

### Technical solution

Our proposal is to prefer back-channel endpoints at the service provider side, unless your application needs to be notified via front-channel. For example,

- if your application behind your SP needs the session cookie with the notification, use only front-channel bindings in the SP metadata,
- otherwise use only back-channel binding in the SP metadata.

By these mutually exclusive endpoint sets, the SP can clearly advise the IdP which binding it should use when contanting this SP. Thus on the IdP side, both implementations need to be available.

### Non-technical solution

Another option would be to add a new requirement for your end users. You can claim that banning third-party cookies is unsupported (because it breaks SLO), just like disabling all cookies (which breaks SSO). Convincing your users (and the Shibboleth developers to accept this solution) might be dubious, though.

## Features

- Implements SAML2 Single Logout profile
- If initiated by an SP, user must confirm the single logout process: one can choose to logout only from the initiating SP and the IdP.
- Highly customizable front-channel logout interface which leverages javascript and asynchronous operations in order to provide a clean, simple UI.
- UI is usable with javascript disabled.
- Supports localized SP name lookup via Organization elements in SAML metadata .
- Fallback to back-channel logout if front-channel is not supported by the SP.
- Supports Shibboleth SSO sessions (if the SP initiates sessions using Shibboleth1.3 protocol, but supports SAML2 logout).
- Supports full back-channel operation.
- Supports IdP-initiated Single Logout.

## UI customization

The UI is located in two JSP files:

- `sloQuestion.jsp` the user chooses whether she wants to logout from all service providers or just from the provider where she came from.
- `sloController.jsp` is the logout UI where every session participant and their corresponding logout status is shown. At the end of the logout process, the user is notified if the single logout was completed.

### How it works

#### SLOServlet

The heart of the logout process is the `SLOServlet`. This servlet is responsible for these actions:

- rendering the logout question and controller page
- initiating front-channel or back-channel logout to one SP (`SLOServlet?action&entityID=...`)
- returning the logout status as a JSON string (`SLOServlet?status`)

#### With javascript

The controller renders a page where an iframe is placed for every active session participant. This iframe calls the `SLOServlet?action&entityID=...` URL where the logout request is issued for the given session participant. If the request is front-channel, the iframe will make a front-channel SAML message exchange with the peer (using HTTP-Redirect or POST bindings).

The status of the single logout process is queried via asynchronous requests. The status response from `SLOServlet` is a JSON array. This JSON array contains one object with the `entityID` and `logoutStatus` properties for each session participant.

The logout status can be one of the followings:

- `LOGGED_IN`: logout is not initiated for this participant yet.
- `LOGOUT_ATTEMPTED`: logout was initiated.
- `LOGOUT_FAILED`: logout failed.
- `LOGOUT_UNSUPPORTED`: SAML2 logout is not supported by the participant (the metadata does not contain the necessary endpoints).
- `LOGOUT_TIMED_OUT`: timed out waiting for a response.
- `LOGOUT_SUCCEEDED`: logout was successful.

Status queries are issued using exponential backoff timing, until the timeout is reached. Please see the `sloController.jsp` for the exact timing used.

#### Without javascript

Controller renders an HTML page with `<noscript>` tags. There is one link for each session participant opening up in new window/tab, which can initiate the logout process for that particular SP. Depending on the current logout status, several other controls are enabled on the page:

- `Refresh` button, which will reload the controller HTML with the current status icons to follow the overall logout process.
- `Logout failed` message when logout process was finished, and there was at least one failed session participant.
- `Logout succeeded` message when logout process was finished, and all session participants completed the logout.

#### IdP-initiated Logout (available since v2.1.3-slo2)

The user can initiate their logout process from the IdP (the URL is `/idp/Logout`). IdP-initiated logout has a clear advantage over SP-initiated logout, because the URL and the UI is fully independent from the current SP software used, thereby providing a unique logout URL for all users of the given IdP.

## Non-trivial settings

### Security

SAML Single Logout Profile requires the logout requests and responses to be signed or otherwise authenticated. Without this, a user session could be DOS-ed knowing the NameID.

**You have two choices**

- instruct the SP to sign messages
- configure the IdP not to require authentication of logout messages (and bear with possible DOS-attacks)

#### Signing messages

Signing can be turned on by setting the **`signing`** property to **`front`** (for front-channel only) or **`true`** in the `ApplicationDefaults` or `ApplicationOverride` element in shibboleth2.xml.

!!! note

```
Signing messages is normally unnecessary for back-channel, as the transport is usually authenticated with the certificates in the metadata. However, for back-channel logout it is the IdP who initiates the HTTP connection to the SP, and it is the **webserver**, who answers the request. Because of the different needs, the webserver almost always uses a different certificate (a server certificate signed by a well-known CA) than the SP (possibly self-signed, client certificate). Therefore the SP must sign back-channel messages as well to authenticate itself to the IdP. Unfortunately, you can only enable signing all (otherwise transport protected) messages, and this may affect performance.

```

#### Not requiring peer authentication

Message issuer authentication can be turned off by changing the security policy of processing Single Logout messages. You can do this by commenting out the following line from the block **`SAML2SLOSecurityPolicy`** at **`relying-party.xml`**:

```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](https://bugs.internet2.edu/jira/browse/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](https://bugs.internet2.edu/jira/browse/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](https://bugs.internet2.edu/jira/browse/SIDP-333)

## How to use

### How to build

- install the maven2 build tool
- source code is available from our [git repository](https://repo.niif.hu/gitweb/gitweb.cgi)
    - you can use the convenient snapshot links below to start playing
    - if you are brave enough, feel free to clone the whole repository and track our development branches (frontchannel-slo for the idp project and slo-configuration branch for the shibboleth-common project)
- compile the shib-java-common project first with the `mvn -DskipTests install` command (the first build might take quite a long time if you haven't used maven before)
- compile the java-idp project with the same maven command
- install the `java-idp/target/shibboleth-identityprovider-{version}-bin.zip` binary package the same way as you'd install a vanilla Shibboleth IdP bundle

### Released versions

- download the latest binary snapshot version from our [software distribution site](http://software.niif.hu)

#### v2.2.0-slo10

- fix configuration templates
- source code snapshots 
    - [shibboleth-common-1.2.0-slo2](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=23593c89903cff2fb53bdb939bd463754496a439;sf=tgz)
    - [shibboleth-identityprovider-2.2.0-slo10](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=275bda0758df9f5f26f35eb69a690b63b697e520;sf=tgz)

#### v2.2.0-slo9

- allow EncryptedID to be used in the initiating request (patch contributed by Michael Simon from Karlsruher Institut für Technologie)
- expose method for programatical back-channel logout
- source code snapshots 
    - [shibboleth-common-1.2.0-slo2](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=23593c89903cff2fb53bdb939bd463754496a439;sf=tgz)
    - [shibboleth-identityprovider-2.2.0-slo9](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=46ae3f6475ed578440c72bec3c9a63b387854a70;sf=tgz)

#### v2.1.5-slo7

- use AttributeConsumingService/ServiceName to feed the logout interface
- source code snapshots 
    - [java-shib-common-1.1.4-slo2](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=3f7fa9509d8751787943a32817dab55b69736488;sf=tgz)
    - [java-idp-2.1.5-slo7](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=88e7334e7fdc36454ef5c3bf1342bb402c08bdd4;sf=tgz)

#### v2.1.5-slo6

- skip session-indexing under error conditions
- source code snapshots 
    - [java-shib-common-1.1.4-slo2](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=3f7fa9509d8751787943a32817dab55b69736488;sf=tgz)
    - [java-idp-2.1.5-slo6](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=df79269261fc1fdd3ac99cf4aca2fa7fffd38e33;sf=tgz)

#### v2.1.5-slo5

- fixed NullPointerException with non-existent or filtered NameIdentifiers
- fixed a flaw in session-indexing logic, use the whole NameIdentifier as the index, not just the value
- source code snapshots 
    - [java-shib-common-1.1.4-slo2](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=3f7fa9509d8751787943a32817dab55b69736488;sf=tgz)
    - [java-idp-2.1.5-slo5](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=bb5b5d27831d06915cba52e474dc3aae62343238;sf=tgz)

#### v2.1.5-slo4

- upstream version bump 
    - [java-shib-common](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=97590490012a10586efe8c49c873c36460ef0a2e;sf=tgz)
    - [java-idp](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=8e863b05d849e0ce6ffc224d7b9ca49d4f59742f;sf=tgz;)

#### v2.1.4-slo4

- updated Shibboleth-core
- fixed NullPointerException introduced by an erroneous merge in v2.1.4-slo3 
    - [java-shib-common](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=9ca9935759326d14fb7044da13bf1a886861bf0a;sf=tgz)
    - [java-idp](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=eb7b7e3ddbadb21fcb819f0b2458593657046df9;sf=tgz)

#### v2.1.3-slo3

- support Terracotta clustering
- source code snapshots 
    - [java-shib-common](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=9ca9935759326d14fb7044da13bf1a886861bf0a;sf=tgz)
    - [java-idp](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=2b222548cfbac07520ae3a068097a9a5db0b0ba8;sf=tgz)

#### v2.1.3-slo2

- support IdP initiated logout
- source code snapshots 
    - [java-shib-common](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-shib-common.git;a=snapshot;h=9ca9935759326d14fb7044da13bf1a886861bf0a;sf=tgz)
    - [java-idp](https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git;a=snapshot;h=b181480e7d9b50de41aa0c2b26c24d673a640dac;sf=tgz)

#### v2.1.3-slo1

- support SP initiated front- and back-channel logout

### Hints

> - Don't forget to include Single Logout endpoints in the IdP metadata
> - Shibboleth SP prior to 2.1 [did not include NameID properly](https://bugs.internet2.edu/jira/browse/SSPCPP-110) in the LogoutRequest, therefore you cannot initiate SLO with Shibboleth SPs older than 2.1
> - Shibboleth SP prior to 2.2.1 answered with Partial logout for back-channel requests due to a [bug](https://bugs.internet2.edu/jira/browse/SSPCPP-223)
> - Shibboleth SP (currently released versions) do not distinguish between Success and Partial logout when showing the UI (see [this report](https://bugs.internet2.edu/jira/browse/SSPCPP-236) for details). This is not needed unless you are using back-channel logout.
> - If you plan to upgrade a clustered IdP to this version, don't forget to check the new tc-config.xml and rebuild the terracotta boot jar

## Missing features

- Administrative logout
- Logout the user in the underlying JAAS provider

# Shib2IdpTomcat6

Ezt a lapot össze kellene vonni [ezzel](https://help.edu.hu/books/aai/page/shib2idpinstall), é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" />

```