Pro-M - Oktatási Üzletág - Wiki - Szerkesztő közreműködései [hu]

HREF Key Rollover 2020

2021-08-19T07:40:01Z

Gyufi(AT)sztaki.hu: /* FAQ /GYIK */ eduGAINable IdPs

== 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ót 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 ===

{| class="wikitable"
! Elnevezés || Metaadat aláíró tanúsítvány || Kivezetés tervezett időpontja
|-
|-
| HREF-2011 || style="text-align:center;" | [https://metadata.eduid.hu/certs/href-metadata-signer-2011.crt href-metadata-signer-2011.crt] || style="text-align:center;" | 2022.01.01.
|-
| HREF-2015 || style="text-align:center;" | [https://metadata.eduid.hu/certs/mdx-test-signer-2020.crt mdx-test-signer-2015.crt] || style="text-align:center;" | 2022.01.01.
|-
| HREF-2020 || style="text-align:center;" | [https://metadata.eduid.hu/certs/href-metadata-signer-2020.crt href-metadata-signer-2020.crt] || style="text-align:center;" | 2025.06.14.
|}

=== SHA1 fingerprints ===

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

=== Domain név változások ===

{| class="wikitable"
|-
! Domain || Technikai domain || Kulcs || Állapot
|-
| rowspan="2" | metadata.eduid.hu || <code>metadata.eduid.hu/2011/href.xml</code> || HREF-2011 || style="text-align:center;" | Prod
|-
| <code>metadata.eduid.hu/2020/href.xml</code> || HREF-2020 || style="text-align:center;" | Prod
|-
| rowspan="2" | mdx.eduid.hu || <code>mdx-2015.eduid.hu</code> || HREF-2015 || style="text-align:center;" | Prod
|-
| <code>mdx-2020.eduid.hu</code> || HREF-2020 || style="text-align:center;" | Prod
|-
|}

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

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

=== XML ===

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

<syntaxhighlight lang="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>
</syntaxhighlight>

=== MDX ===

==== Shibboleth 3.X ====

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

<syntaxhighlight lang="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>
</syntaxhighlight>

==== Shibboleth 2.X ====

<syntaxhighlight lang="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>
</syntaxhighlight>

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

=== XML ===

==== Shibboleth 4.X ====

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

<syntaxhighlight lang="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>
</syntaxhighlight>

==== Shibboleth 3.X ====

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

<syntaxhighlight lang="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>
</syntaxhighlight>

=== MDX ===

==== Shibboleth 4.X ====

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

<syntaxhighlight lang="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>
</syntaxhighlight>

==== Shibboleth 3.X ====

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

<syntaxhighlight lang="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>
</syntaxhighlight>

== SimpleSAMLphp ==

=== MDX ===

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

=== metarefresh ===

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

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

<syntaxhighlight lang="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',
],
],
];
</syntaxhighlight>

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

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

Sirtfi

2018-06-14T07:06:29Z

Gyufi(AT)sztaki.hu: /* Security Incident Response Trust Framework for Federated Identity (SIRTFI) */ typo fixek

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

A [https://refeds.org/sirtfi 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.

Fájl:Uni-nke-logo-main.png

2017-10-17T06:51:31Z

Gyufi(AT)sztaki.hu:

Fájl:Aote-logo png (1200×80) (1).jpg

2017-10-17T06:49:47Z

Gyufi(AT)sztaki.hu:

Fájl:Www uni-neumann.hu-core-templates-pae v2-gfx-pae-logo hu.svg.jpg

2017-10-17T06:37:21Z

Gyufi(AT)sztaki.hu:

Intézmény átnevezés

2017-09-05T11:53:29Z

Gyufi(AT)sztaki.hu: /* Discovery leírá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 ==
<blockquote>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?</blockquote>

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

=== [[Scope]] ===
Az eduPersonPrincipalName és az eduPersonScopedAffiliation használja a [[Scope|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. <code>require affiliation member@kefo.hu</code> vagy <code>require eppn bekre.pal@kefo.hu</code>) 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 <code>SingleSignOnService</code> és <code>SingleLogoutService</code> 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.)

[[Kategória: AAI]]

SimpleSAMLphp

2017-09-05T11:52:18Z

Gyufi(AT)sztaki.hu: /* IdP */

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ő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 (legalább 5.2.0 verzió)
* A következő PHP kiterjesztéseket engedélyezni kell
** <code>date</code>, <code>dom</code>, <code>hash</code>, <code>libxml</code>, <code>openssl</code>, <code>pcre</code>, <code>SPL</code>, <code>zlib</code>
** LDAP-ból történő autentikáció esetén: <code>ldap</code>
** Adatbázisból történő autentikáció esetén a megfelelő adatbázis-csatolót <code>mysql</code>, <code>pgsql</code>
** RADIUS szerveren keresztül történő autentikáció esetén: <code>radius</code>
** Assertion-ök titkosítása esetén: <code>mcrypt</code>
** Memcache használata esetén: <code>memcache</code>

===Letöltés===
A legfrissebb változat letölthető a https://simplesamlphp.org/download címről

cd /var
tar xzf simplesamlphp-1.x.y.tar.gz
mv simplesamlphp-1.x.y simplesamlphp

Alapértelmezés szerint a <code>/var/simplesamlphp</code> alatt szeretne majd működni, ez természetesen változtatható, de most maradunk az eredeti beállításoknál.

===Apache konfigurálás===

A webről csak a <code>/var/simplesamlphp/www</code> könyvtárat kell elérni.

Alias /simplesaml /var/simplesamlphp/www

===Alapbeállítások===
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 konfigurációs fájlban <code>config/config.php</code>.
* '''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',

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

==IdP beállítás==
===IdP funkció engedélyezése===
A <code>config/config.php</code> fájlt kell szerkesztenünk, s engedélyezni a saml20 idp lehetőséget.
'enable.saml20-idp' => true,
===Autentikáció LDAP alapon===
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 <code>modules</code> 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.

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

/* The hostname of the LDAP server. */
'hostname' => 'ldap.example.org',

/* Whether SSL/TLS should be used when contacting the LDAP server. */
'enable_tls' => FALSE,

/*
* Which attributes should be retrieved from the LDAP server.
* This can be an array of attribute names, or NULL, in which case
* all attributes are fetched.
*/
'attributes' => NULL,

/*
* The pattern which should be used to create the users DN given the username.
* %username% in this pattern will be replaced with the users username.
*
* This option is not used if the search.enable option is set to TRUE.
*/
'dnpattern' => 'uid=%username%,ou=people,dc=example,dc=org',

/*
* As an alternative to specifying a pattern for the users DN, it is possible to
* search for the username in a set of attributes. This is enabled by this option.
*/
'search.enable' => FALSE,

/*
* 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' => NULL,
'search.password' => NULL,
),

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

$metadata['__DYNAMIC:1__'] = array(
/*
* The hostname for this IdP. This makes it possible to run multiple
* IdPs from the same configuration. '__DEFAULT__' means that this one
* should be used by default.
*/
'host' => '__DEFAULT__',

/*
* The private key and certificate to use when signing responses.
* These are stored in the cert-directory.
*/
'privatekey' => 'idp.example.org.key',
'certificate' => 'idp.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',
);

Teszteléshez is érdemes, éles használathoz pedig elengedhetetlen, hogy a csomagban érkezett tanúsítványt felülírjuk, ezt célszerű mihamarabb megtenni. Ehhez az alábbi parancs lehet segítségünkre.
openssl req -new -newkey rsa:2048 -x509 -days 3652 -nodes -out idp.example.org.crt -keyout idp.example.org.key

A fingerprint az alábbi módon kérdezhető le a legegyszerűbben
openssl x509 -fingerprint -noout -in idp.example.org.crt

Megfelelő beállítások után a dinamikusan generált metadata a <code>/saml2/idp/metadata.php</code> ú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.

==SP beállítás==
===Alapadatok===
A telepített alkalmazásunk által kezelt SP-ket a <code>config/authsources.php</code> fájlban tudjuk beállítani.

'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.pem',
'certificate' => 'saml.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 IdP beállításához hasonlóan itt is szükség lesz egy tanúsítvány generálására a <code>cert</code> könyvtárba. Ehhez segítség lehet az alábbi parancs.

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

===Tesztelés===
Amennyiben IdP is beállításra került, úgy a legcélszerűbb ezt összehangolni az SP-vel. Ehhez egyfelől a <code>metadata/saml20-idp-remote.php</code> fájlban meg kell adni az IdP adatait, amely esetünkben az alábbiak szerint fest.

$metadata['https://example.org/simplesaml/saml2/idp/metadata.php'] = array(
'name' => array(
'en' => 'TestSP'
),
'SingleSignOnService' => 'https://example.org/simplesaml/saml2/idp/SSOService.php',
'SingleLogoutService' => 'https://example.org/simplesaml/saml2/idp/SingleLogoutService.php',
'certFingerprint' => 'afe71c28ef740bc87425be13a2263d37971da1f9'
);

Ehhez hasonlóan a <code>metadata/saml20-sp-remote.php</code> fájlban meg kell adnunk az SP adatait. Teszteléshez az alábbiak elegendők:

$metadata['https://example.org/simplesaml/module.php/saml/sp/metadata.php/default-sp'] = array (
'AssertionConsumerService' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
'SingleLogoutService' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp',
);

Ezek után az IdP tesztelésénél már említett oldalon a default-sp opciót kiválasztva, majd a legördülő menüben a TestSP-re kattintva be kell tudnunk jelentkezni az IdP-n keresztül. Ha működik, akkor 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)===
* Az SSP-nél be kell állítani metaadat forrásként a központi metaadatot
:*Első lépésként engedélyezzük, hogy az SSP automatikusan frissíthesse a metaadatot, ill. az ezt elvégző két modult
touch modules/metarefresh/enable
cp modules/metarefresh/config-templates/*.php config/
touch modules/cron/enable
cp modules/cron/config-templates/*.php config/

:*Létrehozunk egy könyvtárat, ahová letöltésre kerül az központi metaadat XML fájlja
mkdir metadata/metarefresh-href
chmod g+rw metadata/metarefresh-href

{{ATTENTION|Ahhoz, hogy az automatikus metadata frissítés gond nélkül működjön, legalább '''1.13.2'''-es verziójú simpleSAMLphp kell, vagy korábbi változatokon frissíteni kell a <code>/path/to/simplesamlphp/lib/xmlseclibs.php</code> fájlt [http://goo.gl/ilRHkV erre a fájlra]! Bővebb információ ehhez kapcsolódóan [http://simplesamlphp.org/metaprocessing erre.]

Ha az eduGAIN metaadatait is feldolgozzuk, akkor fontos, hogy néhány paramétert emeljük legalább az alábbi értékekre:
* maximum memória foglalás (<code>memory_limit</code>): '''512MB'''
* maximum végrehajtási idő (<code>max_execution_time</code>): '''120 sec'''}}

:*Ezek után be kell állítani a metaadat kokrét adatait a <code>config/config-metarefresh.php</code> fájlban
$config = array(
'sets' => array(
'hu' => array(
'cron' => array('hourly'),
'sources' => array(
array(
'src' => 'http://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' => 60*60*24*4, // Maximum 4 days cache time.
'outputDir' => 'metadata/metarefresh-href/',
'outputFormat' => 'flatfile',
),
),
);
:*Be kell állítani, hogy az SSP az automata által generált fájlokból dolgozzon. Ehhez a <code>config/config.php</code> fájlban keressük ki a <code>metadata.source</code> szakaszt, és az alábbiak szerint szerkesszük át. Amennyiben nem csak a központi metaadatból szeretnénk dolgozni, úgy további sorokat is megadhatunk itt bemutatott mintájára.
'metadata.sources' => array(
array('type' => 'flatfile'), // IdP esetén kell, itt van az önmagát leíró metadata
array('type' => 'flatfile', 'directory' => 'metadata/metarefresh-href'),
),

:*Végül le kell futtatni kézzel a cronjobot, amelyet az SSP webes felületén tudunk megtenni a Configuration fül alatt, a Cron module information page menüpontban. Ekkor létrejönnek a fájlok (majd óránként frissülnek is, ha beállítjuk cronjobként).

===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.
* (A jelenleg is formálódó adminisztratív teendőktől itt most eltekintünk)
* Kell küldeni egy levelet a [mailto:info@eduid.hu 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)
* Ha minden rendben megy, akkor az IdP bekerül a [[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 egy-két óra alatt várhatóan beindul. :)

:Tesztelésre használható oldal: [https://wiki.aai.niif.hu/shibtest.php https://wiki.aai.niif.hu/shibtest.php]

* 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:
** [[HREFAttributeSpec#mail|mail]] - ez belépés után, manuálisan is beállítható
** [[HREFAttributeSpec#eduPersonPrincipalName|eduPersonPrincipalName]]
** [[HREFAttributeSpec#schacHomeOrganizationType|schacHomeOrganizationType]]
** [[HREFAttributeSpec#eduScopedAffiliation|eduPersonScopedAffiliation]]

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

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

: További tudnivalók a [[Resource_Registry|Resource Registry-ről]], ill. a [[HREFAttributeSpec|Föderációs attribútum specifikációról]].

* 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: [[HREFAttributeSpec#eduPersonAffiliation|eduPersonScopedAffiliation]] illetve [[HREFAttributeSpec#eduPersonPrincipalName|eduPersonPrincipalName]]).

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

A telepítésről és konfigurációról bővebben itt lehet olvasni:

https://github.com/NIIF/simplesamlphp-module-attributescope

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

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.

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

[[Category: AAI]] [[Category: simpleSAMLphp]] [[Category: HOWTO]]

SimpleSAMLphp

2017-09-05T11:50:07Z

Gyufi(AT)sztaki.hu: /* Attribútumok kezelése */

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ő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 (legalább 5.2.0 verzió)
* A következő PHP kiterjesztéseket engedélyezni kell
** <code>date</code>, <code>dom</code>, <code>hash</code>, <code>libxml</code>, <code>openssl</code>, <code>pcre</code>, <code>SPL</code>, <code>zlib</code>
** LDAP-ból történő autentikáció esetén: <code>ldap</code>
** Adatbázisból történő autentikáció esetén a megfelelő adatbázis-csatolót <code>mysql</code>, <code>pgsql</code>
** RADIUS szerveren keresztül történő autentikáció esetén: <code>radius</code>
** Assertion-ök titkosítása esetén: <code>mcrypt</code>
** Memcache használata esetén: <code>memcache</code>

===Letöltés===
A legfrissebb változat letölthető a https://simplesamlphp.org/download címről

cd /var
tar xzf simplesamlphp-1.x.y.tar.gz
mv simplesamlphp-1.x.y simplesamlphp

Alapértelmezés szerint a <code>/var/simplesamlphp</code> alatt szeretne majd működni, ez természetesen változtatható, de most maradunk az eredeti beállításoknál.

===Apache konfigurálás===

A webről csak a <code>/var/simplesamlphp/www</code> könyvtárat kell elérni.

Alias /simplesaml /var/simplesamlphp/www

===Alapbeállítások===
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 konfigurációs fájlban <code>config/config.php</code>.
* '''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',

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

==IdP beállítás==
===IdP funkció engedélyezése===
A <code>config/config.php</code> fájlt kell szerkesztenünk, s engedélyezni a saml20 idp lehetőséget.
'enable.saml20-idp' => true,
===Autentikáció LDAP alapon===
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 <code>modules</code> 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.

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

/* The hostname of the LDAP server. */
'hostname' => 'ldap.example.org',

/* Whether SSL/TLS should be used when contacting the LDAP server. */
'enable_tls' => FALSE,

/*
* Which attributes should be retrieved from the LDAP server.
* This can be an array of attribute names, or NULL, in which case
* all attributes are fetched.
*/
'attributes' => NULL,

/*
* The pattern which should be used to create the users DN given the username.
* %username% in this pattern will be replaced with the users username.
*
* This option is not used if the search.enable option is set to TRUE.
*/
'dnpattern' => 'uid=%username%,ou=people,dc=example,dc=org',

/*
* As an alternative to specifying a pattern for the users DN, it is possible to
* search for the username in a set of attributes. This is enabled by this option.
*/
'search.enable' => FALSE,

/*
* 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' => NULL,
'search.password' => NULL,
),

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

$metadata['__DYNAMIC:1__'] = array(
/*
* The hostname for this IdP. This makes it possible to run multiple
* IdPs from the same configuration. '__DEFAULT__' means that this one
* should be used by default.
*/
'host' => '__DEFAULT__',

/*
* The private key and certificate to use when signing responses.
* These are stored in the cert-directory.
*/
'privatekey' => 'idp.example.org.key',
'certificate' => 'idp.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',
);

Teszteléshez is érdemes, éles használathoz pedig elengedhetetlen, hogy a csomagban érkezett tanúsítványt felülírjuk, ezt célszerű mihamarabb megtenni. Ehhez az alábbi parancs lehet segítségünkre.
openssl req -new -newkey rsa:2048 -x509 -days 3652 -nodes -out idp.example.org.crt -keyout idp.example.org.key

A fingerprint az alábbi módon kérdezhető le a legegyszerűbben
openssl x509 -fingerprint -noout -in idp.example.org.crt

Megfelelő beállítások után a dinamikusan generált metadata a <code>/saml2/idp/metadata.php</code> ú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.

==SP beállítás==
===Alapadatok===
A telepített alkalmazásunk által kezelt SP-ket a <code>config/authsources.php</code> fájlban tudjuk beállítani.

'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.pem',
'certificate' => 'saml.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 IdP beállításához hasonlóan itt is szükség lesz egy tanúsítvány generálására a <code>cert</code> könyvtárba. Ehhez segítség lehet az alábbi parancs.

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

===Tesztelés===
Amennyiben IdP is beállításra került, úgy a legcélszerűbb ezt összehangolni az SP-vel. Ehhez egyfelől a <code>metadata/saml20-idp-remote.php</code> fájlban meg kell adni az IdP adatait, amely esetünkben az alábbiak szerint fest.

$metadata['https://example.org/simplesaml/saml2/idp/metadata.php'] = array(
'name' => array(
'en' => 'TestSP'
),
'SingleSignOnService' => 'https://example.org/simplesaml/saml2/idp/SSOService.php',
'SingleLogoutService' => 'https://example.org/simplesaml/saml2/idp/SingleLogoutService.php',
'certFingerprint' => 'afe71c28ef740bc87425be13a2263d37971da1f9'
);

Ehhez hasonlóan a <code>metadata/saml20-sp-remote.php</code> fájlban meg kell adnunk az SP adatait. Teszteléshez az alábbiak elegendők:

$metadata['https://example.org/simplesaml/module.php/saml/sp/metadata.php/default-sp'] = array (
'AssertionConsumerService' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
'SingleLogoutService' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp',
);

Ezek után az IdP tesztelésénél már említett oldalon a default-sp opciót kiválasztva, majd a legördülő menüben a TestSP-re kattintva be kell tudnunk jelentkezni az IdP-n keresztül. Ha működik, akkor 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)===
* Az SSP-nél be kell állítani metaadat forrásként a központi metaadatot
:*Első lépésként engedélyezzük, hogy az SSP automatikusan frissíthesse a metaadatot, ill. az ezt elvégző két modult
touch modules/metarefresh/enable
cp modules/metarefresh/config-templates/*.php config/
touch modules/cron/enable
cp modules/cron/config-templates/*.php config/

:*Létrehozunk egy könyvtárat, ahová letöltésre kerül az központi metaadat XML fájlja
mkdir metadata/metarefresh-href
chmod g+rw metadata/metarefresh-href

{{ATTENTION|Ahhoz, hogy az automatikus metadata frissítés gond nélkül működjön, legalább '''1.13.2'''-es verziójú simpleSAMLphp kell, vagy korábbi változatokon frissíteni kell a <code>/path/to/simplesamlphp/lib/xmlseclibs.php</code> fájlt [http://goo.gl/ilRHkV erre a fájlra]! Bővebb információ ehhez kapcsolódóan [http://simplesamlphp.org/metaprocessing erre.]

Ha az eduGAIN metaadatait is feldolgozzuk, akkor fontos, hogy néhány paramétert emeljük legalább az alábbi értékekre:
* maximum memória foglalás (<code>memory_limit</code>): '''512MB'''
* maximum végrehajtási idő (<code>max_execution_time</code>): '''120 sec'''}}

:*Ezek után be kell állítani a metaadat kokrét adatait a <code>config/config-metarefresh.php</code> fájlban
$config = array(
'sets' => array(
'hu' => array(
'cron' => array('hourly'),
'sources' => array(
array(
'src' => 'http://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' => 60*60*24*4, // Maximum 4 days cache time.
'outputDir' => 'metadata/metarefresh-href/',
'outputFormat' => 'flatfile',
),
),
);
:*Be kell állítani, hogy az SSP az automata által generált fájlokból dolgozzon. Ehhez a <code>config/config.php</code> fájlban keressük ki a <code>metadata.source</code> szakaszt, és az alábbiak szerint szerkesszük át. Amennyiben nem csak a központi metaadatból szeretnénk dolgozni, úgy további sorokat is megadhatunk itt bemutatott mintájára.
'metadata.sources' => array(
array('type' => 'flatfile'), // IdP esetén kell, itt van az önmagát leíró metadata
array('type' => 'flatfile', 'directory' => 'metadata/metarefresh-href'),
),

:*Végül le kell futtatni kézzel a cronjobot, amelyet az SSP webes felületén tudunk megtenni a Configuration fül alatt, a Cron module information page menüpontban. Ekkor létrejönnek a fájlok (majd óránként frissülnek is, ha beállítjuk cronjobként).

===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.
* (A jelenleg is formálódó adminisztratív teendőktől itt most eltekintünk)
* Kell küldeni egy levelet a [mailto:aai@niif.hu aai@niif.hu] címre, benne néhány mondat mellett az IdP metaadatának URL-jével (https://example.org/simplesamlphp/saml2/idp/metadata.php)
* Ha minden rendben megy, akkor az IdP bekerül a [[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 egy-két óra alatt várhatóan beindul. :)

:Tesztelésre használható oldal: [https://wiki.aai.niif.hu/shibtest.php https://wiki.aai.niif.hu/shibtest.php]

* 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:
** [[HREFAttributeSpec#mail|mail]] - ez belépés után, manuálisan is beállítható
** [[HREFAttributeSpec#eduPersonPrincipalName|eduPersonPrincipalName]]
** [[HREFAttributeSpec#schacHomeOrganizationType|schacHomeOrganizationType]]
** [[HREFAttributeSpec#eduScopedAffiliation|eduPersonScopedAffiliation]]

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

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

: További tudnivalók a [[Resource_Registry|Resource Registry-ről]], ill. a [[HREFAttributeSpec|Föderációs attribútum specifikációról]].

* 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: [[HREFAttributeSpec#eduPersonAffiliation|eduPersonScopedAffiliation]] illetve [[HREFAttributeSpec#eduPersonPrincipalName|eduPersonPrincipalName]]).

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

A telepítésről és konfigurációról bővebben itt lehet olvasni:

https://github.com/NIIF/simplesamlphp-module-attributescope

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

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.

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

[[Category: AAI]] [[Category: simpleSAMLphp]] [[Category: HOWTO]]

SimpleSAMLphp

2017-09-05T11:40:30Z

Gyufi(AT)sztaki.hu: 2048 bit kulcsok

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ő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 (legalább 5.2.0 verzió)
* A következő PHP kiterjesztéseket engedélyezni kell
** <code>date</code>, <code>dom</code>, <code>hash</code>, <code>libxml</code>, <code>openssl</code>, <code>pcre</code>, <code>SPL</code>, <code>zlib</code>
** LDAP-ból történő autentikáció esetén: <code>ldap</code>
** Adatbázisból történő autentikáció esetén a megfelelő adatbázis-csatolót <code>mysql</code>, <code>pgsql</code>
** RADIUS szerveren keresztül történő autentikáció esetén: <code>radius</code>
** Assertion-ök titkosítása esetén: <code>mcrypt</code>
** Memcache használata esetén: <code>memcache</code>

===Letöltés===
A legfrissebb változat letölthető a https://simplesamlphp.org/download címről

cd /var
tar xzf simplesamlphp-1.x.y.tar.gz
mv simplesamlphp-1.x.y simplesamlphp

Alapértelmezés szerint a <code>/var/simplesamlphp</code> alatt szeretne majd működni, ez természetesen változtatható, de most maradunk az eredeti beállításoknál.

===Apache konfigurálás===

A webről csak a <code>/var/simplesamlphp/www</code> könyvtárat kell elérni.

Alias /simplesaml /var/simplesamlphp/www

===Alapbeállítások===
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 konfigurációs fájlban <code>config/config.php</code>.
* '''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',

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

==IdP beállítás==
===IdP funkció engedélyezése===
A <code>config/config.php</code> fájlt kell szerkesztenünk, s engedélyezni a saml20 idp lehetőséget.
'enable.saml20-idp' => true,
===Autentikáció LDAP alapon===
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 <code>modules</code> 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.

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

/* The hostname of the LDAP server. */
'hostname' => 'ldap.example.org',

/* Whether SSL/TLS should be used when contacting the LDAP server. */
'enable_tls' => FALSE,

/*
* Which attributes should be retrieved from the LDAP server.
* This can be an array of attribute names, or NULL, in which case
* all attributes are fetched.
*/
'attributes' => NULL,

/*
* The pattern which should be used to create the users DN given the username.
* %username% in this pattern will be replaced with the users username.
*
* This option is not used if the search.enable option is set to TRUE.
*/
'dnpattern' => 'uid=%username%,ou=people,dc=example,dc=org',

/*
* As an alternative to specifying a pattern for the users DN, it is possible to
* search for the username in a set of attributes. This is enabled by this option.
*/
'search.enable' => FALSE,

/*
* 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' => NULL,
'search.password' => NULL,
),

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

$metadata['__DYNAMIC:1__'] = array(
/*
* The hostname for this IdP. This makes it possible to run multiple
* IdPs from the same configuration. '__DEFAULT__' means that this one
* should be used by default.
*/
'host' => '__DEFAULT__',

/*
* The private key and certificate to use when signing responses.
* These are stored in the cert-directory.
*/
'privatekey' => 'idp.example.org.key',
'certificate' => 'idp.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',
);

Teszteléshez is érdemes, éles használathoz pedig elengedhetetlen, hogy a csomagban érkezett tanúsítványt felülírjuk, ezt célszerű mihamarabb megtenni. Ehhez az alábbi parancs lehet segítségünkre.
openssl req -new -newkey rsa:2048 -x509 -days 3652 -nodes -out idp.example.org.crt -keyout idp.example.org.key

A fingerprint az alábbi módon kérdezhető le a legegyszerűbben
openssl x509 -fingerprint -noout -in idp.example.org.crt

Megfelelő beállítások után a dinamikusan generált metadata a <code>/saml2/idp/metadata.php</code> ú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.

==SP beállítás==
===Alapadatok===
A telepített alkalmazásunk által kezelt SP-ket a <code>config/authsources.php</code> fájlban tudjuk beállítani.

'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.pem',
'certificate' => 'saml.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 IdP beállításához hasonlóan itt is szükség lesz egy tanúsítvány generálására a <code>cert</code> könyvtárba. Ehhez segítség lehet az alábbi parancs.

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

===Tesztelés===
Amennyiben IdP is beállításra került, úgy a legcélszerűbb ezt összehangolni az SP-vel. Ehhez egyfelől a <code>metadata/saml20-idp-remote.php</code> fájlban meg kell adni az IdP adatait, amely esetünkben az alábbiak szerint fest.

$metadata['https://example.org/simplesaml/saml2/idp/metadata.php'] = array(
'name' => array(
'en' => 'TestSP'
),
'SingleSignOnService' => 'https://example.org/simplesaml/saml2/idp/SSOService.php',
'SingleLogoutService' => 'https://example.org/simplesaml/saml2/idp/SingleLogoutService.php',
'certFingerprint' => 'afe71c28ef740bc87425be13a2263d37971da1f9'
);

Ehhez hasonlóan a <code>metadata/saml20-sp-remote.php</code> fájlban meg kell adnunk az SP adatait. Teszteléshez az alábbiak elegendők:

$metadata['https://example.org/simplesaml/module.php/saml/sp/metadata.php/default-sp'] = array (
'AssertionConsumerService' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp',
'SingleLogoutService' => 'https://example.org/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp',
);

Ezek után az IdP tesztelésénél már említett oldalon a default-sp opciót kiválasztva, majd a legördülő menüben a TestSP-re kattintva be kell tudnunk jelentkezni az IdP-n keresztül. Ha működik, akkor 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)===
* Az SSP-nél be kell állítani metaadat forrásként a központi metaadatot
:*Első lépésként engedélyezzük, hogy az SSP automatikusan frissíthesse a metaadatot, ill. az ezt elvégző két modult
touch modules/metarefresh/enable
cp modules/metarefresh/config-templates/*.php config/
touch modules/cron/enable
cp modules/cron/config-templates/*.php config/

:*Létrehozunk egy könyvtárat, ahová letöltésre kerül az központi metaadat XML fájlja
mkdir metadata/metarefresh-href
chmod g+rw metadata/metarefresh-href

{{ATTENTION|Ahhoz, hogy az automatikus metadata frissítés gond nélkül működjön, legalább '''1.13.2'''-es verziójú simpleSAMLphp kell, vagy korábbi változatokon frissíteni kell a <code>/path/to/simplesamlphp/lib/xmlseclibs.php</code> fájlt [http://goo.gl/ilRHkV erre a fájlra]! Bővebb információ ehhez kapcsolódóan [http://simplesamlphp.org/metaprocessing erre.]

Ha az eduGAIN metaadatait is feldolgozzuk, akkor fontos, hogy néhány paramétert emeljük legalább az alábbi értékekre:
* maximum memória foglalás (<code>memory_limit</code>): '''512MB'''
* maximum végrehajtási idő (<code>max_execution_time</code>): '''120 sec'''}}

:*Ezek után be kell állítani a metaadat kokrét adatait a <code>config/config-metarefresh.php</code> fájlban
$config = array(
'sets' => array(
'hu' => array(
'cron' => array('hourly'),
'sources' => array(
array(
'src' => 'http://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' => 60*60*24*4, // Maximum 4 days cache time.
'outputDir' => 'metadata/metarefresh-href/',
'outputFormat' => 'flatfile',
),
),
);
:*Be kell állítani, hogy az SSP az automata által generált fájlokból dolgozzon. Ehhez a <code>config/config.php</code> fájlban keressük ki a <code>metadata.source</code> szakaszt, és az alábbiak szerint szerkesszük át. Amennyiben nem csak a központi metaadatból szeretnénk dolgozni, úgy további sorokat is megadhatunk itt bemutatott mintájára.
'metadata.sources' => array(
array('type' => 'flatfile'), // IdP esetén kell, itt van az önmagát leíró metadata
array('type' => 'flatfile', 'directory' => 'metadata/metarefresh-href'),
),

:*Végül le kell futtatni kézzel a cronjobot, amelyet az SSP webes felületén tudunk megtenni a Configuration fül alatt, a Cron module information page menüpontban. Ekkor létrejönnek a fájlok (majd óránként frissülnek is, ha beállítjuk cronjobként).

===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.
* (A jelenleg is formálódó adminisztratív teendőktől itt most eltekintünk)
* Kell küldeni egy levelet a [mailto:aai@niif.hu aai@niif.hu] címre, benne néhány mondat mellett az IdP metaadatának URL-jével (https://example.org/simplesamlphp/saml2/idp/metadata.php)
* Ha minden rendben megy, akkor az IdP bekerül a [[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 egy-két óra alatt várhatóan beindul. :)

:Tesztelésre használható oldal: [https://wiki.aai.niif.hu/shibtest.php https://wiki.aai.niif.hu/shibtest.php]

* 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:
** [[HREFAttributeSpec#mail|mail]] - ez belépés után, manuálisan is beállítható
** [[HREFAttributeSpec#eduPersonPrincipalName|eduPersonPrincipalName]]
** [[HREFAttributeSpec#schacHomeOrganizationType|schacHomeOrganizationType]]
** [[HREFAttributeSpec#eduScopedAffiliation|eduPersonScopedAffiliation]]

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

:1. Az <code>attributemap/name2oid.php</code> fájlba az 's'-betűhöz szúrjuk be az alábbi sort:
'schacHomeOrganizationType' => 'urn:oid:1.3.6.1.4.1.25178.1.2.10',
:2. A <code>metadata/saml20-idp-hosted.php</code> fájlba szerkesszük be az alábbi kódrészlet értelemszerűen módosított változatát. Az <code>'auth' => 'example-ldap',</code> sor alatt kezdjük. Fontos, hogy egyúttal a config.php <code>authproc.idp</code> részét kikommentezzük, nehogy az ottani sorszámokkal megadott default feladatok bekavarjanak.

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

: További tudnivalók a [[Resource_Registry|Resource Registry-ről]], ill. a [[HREFAttributeSpec|Föderációs attribútum specifikációról]].

* 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: [[HREFAttributeSpec#eduPersonAffiliation|eduPersonScopedAffiliation]] illetve [[HREFAttributeSpec#eduPersonPrincipalName|eduPersonPrincipalName]]).

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

A telepítésről és konfigurációról bővebben itt lehet olvasni:

https://github.com/NIIF/simplesamlphp-module-attributescope

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

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.

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

[[Category: AAI]] [[Category: simpleSAMLphp]] [[Category: HOWTO]]

Shibboleth Service Provider (SP)

2017-06-25T12:26:19Z

Gyufi(AT)sztaki.hu: /* Alapbeállítások */

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/SHIB2/Installation https://wiki.shibboleth.net/confluence/display/SHIB2/Installation] címről. Célszerű valamilyen előre csomagolt változattal dolgozni, melyet az adott rendszer csomagkezelőjén keresztül egy mozdulattal feltelepíthetünk minden függőségével együtt.

====Debian Squeeze====
A [http://wiki.debian.org/Teams/DebianShibboleth Debian Shibboleth] csapat által készített új verziók időről időre bekerülnek [http://backports.org 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 <code>/etc/apt/sources.list</code> 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.

====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/ <code>/etc/yum.repos.d/CentOS-Base.repo</code> 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 <code>shibd.te</code> 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 <code>shibboleth2.xml</code> és az <code>attribute-map.xml</code> fájlokkal lesz dolgunk.

=== <code>shibboleth2.xml </code>===
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: <code>https://hosztnev/shibboleth</code>, ezt az azonosítót beírni az <code >ApplicationDefaults</code> 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):
<code lang="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">
</code>

* 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

<SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.eduid.hu">
SAML2 SAML1
</SSO>

** Fix IdP beállítása

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

<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 <code>RequestMapper</code> 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:

<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 <code>/secure</code> location. Ha valahol shibbolethes azonosítást kívánunk használni, azt ezen kívül az adott hoszt webszerver konfigjában is jeleznünk kell. Apache-nál az alábbi módon.

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

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

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

== HEXAA integráció ==

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

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

== Kapcsolódó lapok ==
* [[FastCGI | Shibboleth 2 SP telepítése FastCGI alapú webszerver környezetben]]

[[Category: AAI]] [[Category: Shibboleth SP]] [[Category: HOWTO]]

HREF metadata specifikáció

2017-06-08T10:16:08Z

Gyufi(AT)sztaki.hu: /* Aláírási folyamat */ rr migrálás rr.eduid.hu-ra

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 (<code>cacheDuration</code>) 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 (<code>validUntil</code> 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ő (<code>validUntil</code>) biztosítja, ami jelenleg 3 nap.
** az egyes rendszerek gyorstárazhatják a metaadatot, de legalább naponta egyszer kötelesek a hiteles állományt frissíteni.
** az aláírási procedúrát a [[#Metaadat_aláírásának_módja]] fejezet írja le.
* Tanúsítványok
** kötelező legalább 1024 bites kulcspárt használni
** az entitások által használt tanúsítvánnyal kapcsolatban a föderáció nem tesz különleges megkötést, sőt: ajánlott hosszú lejáratú self-signed tanúsítványok használata
* További információk
** minden szöveges mezőt legalább két nyelven: magyarul és angolul ki kell tölteni
** kötelezően kitöltendőek az intézményi, adminisztratív információk (<code>Organization</code> illetve <code>ContactPerson</code> elemek)
** ajánlott megadni egy helpdesk URL-r, ahova hiba esetén a felhasználók fordulhatnak (<code>errorURL</code> attribútum)
** SP-k esetén további kötelező elemek
*** <code>AttributeConsumingService</code>, ami megadja a kért attribútumokat
**** <code>RequestedAttributes</code> - itt az attribútum informális neve is szerepeljen
**** <code>ServiceName</code>, <code>ServiceDescription</code> 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ó [http://wiki.oasis-open.org/security/SAML2MetadataUI itt].

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

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

=== 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
** <code>xml:lang</code>: lokalizációs információ
** <code>href</code>: opcionális link
** <code>height</code>: opcionális magasság érték pixelben
** <code>width</code>: opcionális szélesség érték pixelben

== Egy IdP példa ==
<source lang="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>

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

== Egy SP példa ==
<source lang="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>

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

= Metaadat aláírásának módja =
== Aláíró kulcs és tanúsítványok ==
* 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).

== Aláírási folyamat ==
* Aláíratlan metaadat frissítése
** az aláíratlan metaadat a https://rr.eduid.hu oldalról ütemezetten (5 perc) letöltésre kerül. A letöltés során az rr.eduid.hu tanúsítványa explicit módon ellenőrzésre kerül.
** a letöltött metaadat formai ellenőrzése
** az ellenőrzött entitások egy verziókövető rendszerbe kerülnek, az esetleges változásról e-mail értesítés készül ([https://listserv.niif.hu/mailman/listinfo/href-metadata-changes href-metadata-changes] nevű levelezőlistára)
* Az aláíró szoftver rendszeresen (1-2 percenként) ellenőrzi a metaadatot a verziókövető rendszerben, és változás esetén új aláírt metaadatokat készít
** amennyiben nincs változás, fix időközönként (naponta legalább egyszer) új aláírt állományok készülnek

== 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 <code>http://metadata.eduid.hu/current/</code> URL-ről kell letölteni a metadata fájlokat.
* A tanúsítvány a https://metadata.eduid.hu oldalról érhető el.
** DN-je <code>EMAILADDRESS=aai@niif.hu, CN=Metadata Signer, OU=eduID Federation Operator, O=NIIF Institute, C=HU</code>
** SHA-1 <code>FE:AE:0B:E8:FB:59:ED:F7:CB:7F:69:DF:19:4F:8B:6D:C7:F6:96:66</code>
* Ajánlott a tanúsítvány lejárati idejét figyelmen kívül hagyni.
* A tanúsítványcsere koordinálása out-of-band módszerrel történik (a <code>href-tech</code> levelezőlista segítségével).

== Aláíró kulcs cseréje ==
* A föderációs entitások számára ajánlott a tanúsítvány lejárati idejének figyelmen kívül hagyása.
* A kulccsere koordinálása a <code>href-tech</code> levelezőlistán keresztül történik.
* Kulcs visszavonásakor (kompromittálódás gyanúja esetén) a régi aláíró kulcs azonnal eltávolításra kerül, kontrollált kulcscsere esetén az aláírás párhuzamosan történik a régi és az új kulccsal.

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

A metadata elérés URL-je a következő: http://metadata.eduid.hu/${alairo_kulcs_kibocsatas_eve}/${metadata_forras}.xml. A metadata források jelenleg a következők lehetnek:
* <code>href.xml</code>: az éles föderációban részt vevő, és a föderáció kritériumait teljesítő entitások
* <code>href-test.xml</code>: a HREF föderáció tesztrendszerei. Bármely, 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ó.
* <code>href-edugain.xml</code>: a HREF föderációból az [http://edugain.org eduGAIN] konföderációba kiajánlott entitások. Ide csak olyan entitások kerülhetnek be, melyek megfelelnek a föderációs kritériumoknak, és képesek az [http://edugain.org eduGAIN] konföderációval való együttműködésre. Ezen entitások be kell hogy olvassák az eduGAIN metaadatot is.
* <code>edugain.xml</code>: az [http://edugain.org eduGAIN] konföderáció metaadata, a HREF aláíró kulccsal aláírva.
* intézmény-specifikus metaadat fájlok, melyeket a föderáció kérésre biztosítja, tetszőleges entitások halmazba gyűjtésével.

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

A HREF föderációban teszt jelleggel működik és elérhető MDX-kiszolgáló: <code>http://mdx.eduid.hu</code>. A megfelelő beállításokhoz [[MDX|itt]] érhető el segédlet.

Az MDX kiszolgáló eltérő (nem fizikai) kulcsot és tanúsítványt használ. Ennek SHA-1 lenyomata: <code>91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43</code>. Jelenleg (2015. október) az MDX elérés még csak teszt jelleggel működik, az élesüzemre váltáskor a kulcs és a tanúsítvány változni fog. A jelenlegi tanúsítvány innen tölthető le: <code>http://metadata.eduid.hu/current/mdx-test-signer-2015.crt</code>

Shibboleth Service Provider (SP)

2017-05-22T15:56:32Z

Gyufi(AT)sztaki.hu:

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/SHIB2/Installation https://wiki.shibboleth.net/confluence/display/SHIB2/Installation] címről. Célszerű valamilyen előre csomagolt változattal dolgozni, melyet az adott rendszer csomagkezelőjén keresztül egy mozdulattal feltelepíthetünk minden függőségével együtt.

====Debian Squeeze====
A [http://wiki.debian.org/Teams/DebianShibboleth Debian Shibboleth] csapat által készített új verziók időről időre bekerülnek [http://backports.org 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 <code>/etc/apt/sources.list</code> 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.

====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/ <code>/etc/yum.repos.d/CentOS-Base.repo</code> 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 <code>shibd.te</code> 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 <code>shibboleth2.xml</code> és az <code>attribute-map.xml</code> fájlokkal lesz dolgunk.

=== <code>shibboleth2.xml </code>===
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: <code>https://hosztnev/shibboleth</code>, ezt az azonosítót beírni az <code >ApplicationDefaults</code> 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):
<code lang="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">
</code>

* 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

<SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.eduid.hu">
SAML2 SAML1
</SSO>

** Fix IdP beállítása

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

<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 <code>RequestMapper</code> 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:

<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 <code>/secure</code> 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>

== 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|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.aai.niif.hu/list

== HEXAA integráció ==

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

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

== Kapcsolódó lapok ==
* [[FastCGI | Shibboleth 2 SP telepítése FastCGI alapú webszerver környezetben]]

[[Category: AAI]] [[Category: Shibboleth SP]] [[Category: HOWTO]]

Shibboleth Service Provider (SP)

2017-04-12T16:29:12Z

Gyufi(AT)sztaki.hu: /* SP adatainak közzététele */

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/SHIB2/Installation https://wiki.shibboleth.net/confluence/display/SHIB2/Installation] címről. Célszerű valamilyen előre csomagolt változattal dolgozni, melyet az adott rendszer csomagkezelőjén keresztül egy mozdulattal feltelepíthetünk minden függőségével együtt.

====Debian Squeeze====
A [http://wiki.debian.org/Teams/DebianShibboleth Debian Shibboleth] csapat által készített új verziók időről időre bekerülnek [http://backports.org 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 <code>/etc/apt/sources.list</code> 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.

====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/ <code>/etc/yum.repos.d/CentOS-Base.repo</code> 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 <code>shibd.te</code> 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 <code>shibboleth2.xml</code> és az <code>attribute-map.xml</code> fájlokkal lesz dolgunk.

=== <code>shibboleth2.xml </code>===
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: <code>https://hosztnev/shibboleth</code>, ezt az azonosítót beírni az <code >ApplicationDefaults</code> 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):
<code lang="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">
</code>

* 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

<SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.eduid.hu">
SAML2 SAML1
</SSO>

** Fix IdP beállítása

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

<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 -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 <code>RequestMapper</code> 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:

<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 <code>/secure</code> 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>

== 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|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.aai.niif.hu/list

== HEXAA integráció ==

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

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

== Kapcsolódó lapok ==
* [[FastCGI | Shibboleth 2 SP telepítése FastCGI alapú webszerver környezetben]]

[[Category: AAI]] [[Category: Shibboleth SP]] [[Category: HOWTO]]

Alkalmazások samlizálást segítő teszt IdP simplesamlPHP segítségével

2011-11-15T14:37:22Z

Gyufi(AT)sztaki.hu: Új oldal, tartalma: „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 me…”

1. Telepítünk egy SSP egyedet valamelyik szerverünkre.

2. Engedélyezzük a '''userpass''' auth forrás modult.
touch modules/exampleauth/enable

3. Elrendezzük a metadatákat.

4. Az authsources.php file-t valahogy így alakítjuk ki:

<?php

$config = array(

// This is a authentication source which handles admin authentication.
'admin' => array(
// The default is to use core:AdminPassword, but it can be replaced with
// any authentication source.

'core:AdminPassword',
),

'multi' => array(
'multiauth:MultiAuth',

/*
* The available authentication sources.
* They must be defined in this authsources.php file.
*/
'sources' => array('projekt1', 'projekt2'),
),
'projekt1' => array(
'exampleauth:UserPass',
'tesztuser1:tesztuser1' => array(
'eduPersonPrincipalName' => array('tesztuser1@example.com'),
'uid' => array('tesztuser1'),
'cn' => "Nemecsek Ernő",
'sn' => "Nemecsek",
'givenName' => "Ernő",
'mail' => "devnull@example.com",
'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
'schacDateOfBirth' => "19751221",
'schacPlaceOfBirth' => "Budapest",
'niifPersonMothersName' => "Törőcsik Mari",
'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
),
'tesztuser2:tesztuser2' => array(
'eduPersonPrincipalName' => array('tesztuser2@example.com'),
'uid' => array('tesztuser2'),
'cn' => "Nemecsek Ernő 2",
'sn' => "Nemecsek",
'givenName' => "Ernő",
'mail' => "devnull@example.com",
'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
'schacDateOfBirth' => "19751221",
'schacPlaceOfBirth' => "Budapest",
'niifPersonMothersName' => "Törőcsik Mari",
'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
),
),
'projekt2' => array(
'exampleauth:UserPass',
'tesztuser1:tesztuser1' => array(
'eduPersonPrincipalName' => array('tesztuser1@example.com'),
'uid' => array('tesztuser1'),
'cn' => "Nemecsek Ernő",
'sn' => "Nemecsek",
'givenName' => "Ernő",
'mail' => "devnull@example.com",
'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
'schacDateOfBirth' => "19751221",
'schacPlaceOfBirth' => "Budapest",
'niifPersonMothersName' => "Törőcsik Mari",
'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
),
'tesztuser2:tesztuser2' => array(
'eduPersonPrincipalName' => array('tesztuser2@example.com'),
'uid' => array('tesztuser2'),
'cn' => "Nemecsek Ernő 2",
'sn' => "Nemecsek",
'givenName' => "Ernő",
'mail' => "devnull@example.com",
'homePostalAddress' => "1234 Budapest, Nincsisilyen utca 2.",
'schacDateOfBirth' => "19751221",
'schacPlaceOfBirth' => "Budapest",
'niifPersonMothersName' => "Törőcsik Mari",
'niifPersonResidentalAddress' => "3456 Nagyabajom, Mitírjakide utca 2.",
),
),
);

Szerkesztő:Gyufi(AT)sztaki.hu

2011-11-15T14:27:15Z

Gyufi(AT)sztaki.hu:

;2010. szeptember
: [[Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban]]
: [[simpleSAMLphp NIIF ldap séma mapping]]

=Networkshop 2010.=

simpleSAMLphp, mint IdP a Sztakiban.

http://docs.google.com/present/view?id=dgxggrcj_105djxkgkdq

[[Alkalmazások samlizálást segítő teszt IdP simplesamlPHP segítségével]]

Tagok Tanácsának Működése

2011-09-07T09:34:07Z

Gyufi(AT)sztaki.hu: /* Döntéshozatal módjai */

== A döntéshozatal módja ==
=== Döntéshozatal módjai ===
* '''Tiltakozás hiányában meghozott döntés''': a Föderációs Operátor elektronikus úton eljuttatja a határozati javaslatot a Tagok Tanácsa tagjainak. Amennyiben a megadott határidőn belül a Tagok Tanácsának egyetlen szavazati joggal rendelkező tagja sem emel kifogást, a határozat elfogadásra kerül. Ellenkező esetben — amennyiben a Föderációs Operátor fenntartja a határozati javaslatot — Egyszerű szótöbbséggel döntenek
* '''Egyszerű szótöbbség:''' a Tagok Tanácsának tagjai vagy egy ülésen személyesen, vagy meghatározott módon elektronikus úton, vagy egyéb – a Tagok Tanácsa által előzetesen meghatározott módon – szavaznak a határozati javaslatról. A határozat elfogadásra kerül, ha a leadott szavazatok 50%-a +1 szavazat támogatja azt.
* '''Minősített többség:''' a Tagok Tanácsának tagjai vagy egy ülésen személyesen, vagy meghatározott módon elektronikus úton, vagy egyéb – a Tagok Tanácsa által előzetesen meghatározott módon – szavaznak a határozati javaslatról. A határozat elfogadásra kerül, ha az összes Tag 66%-a + 1 szavazat támogatja azt.

; Tagok Tanácsának tiltakozása hiányában három (3) nap elteltét követően elfogadásra kerő döntések:
* új Tag vagy Partner felvételéhez a Föderációba;
* Tag vagy Partner új IdP-jének vagy SP-jének regisztrálása

; Tagok Tanácsának tiltakozás hiányában tíz (10) nap elteltét követően elfogadásra kerülő döntések:
* a Műszaki Dokumentumokat érintő kisebb módosítások.

; Tagok Tanácsának egyszerű szótöbbséggel meghozott döntése szükséges:
* Tagok Tanácsának saját eljárási szabályainak elfogadása, módosítása;
* Föderációs Szabályzat Műszaki Dokumentumainak jelentősebb módosításához, illetve bármely más dokumentum módosításához;
* a Föderációs Szabályzathoz kapcsolódó új dokumentum elfogadásához;
* Tagok ill. Partnerek vitás kérdéseivel kapcsolatos döntésekhez

; Tagok Tanácsának minősített többségű döntése szükséges:
* a Döntéshozatal rendjének megváltoztatásához
* nemzetközi szervezetekhez és együttműködésekhez történő csatlakozásról szóló döntéshez.
* a Szolgáltatási díj bevezetéséhez, összegének megváltoztatásához;
* a Föderáció megszüntetéséhez.

; Szavazásra jogosult a Tag szerződésben rögzített adminisztratív kapcsolattartó, vagy egy írásban meghatalmazott személy.

Szerkesztő:Gyufi(AT)sztaki.hu

2010-09-27T12:28:34Z

Gyufi(AT)sztaki.hu:

SimpleSAMLphp NIIF ldap séma mapping

2010-09-27T12:28:15Z

Gyufi(AT)sztaki.hu: SimpeleSAMLphp NIIF ldap séma mapping lapot átneveztem SimpleSAMLphp NIIF ldap séma mapping névre

A simpleSAMLphp különböző attribútum mappinget használ az attribúmnevek átfordításaihoz. A href ldap sémához még nincs, ezt a két file tartalmazza az oid - name oda-vissza mapping-et. Az attributemap könyvtárban van a helyük. A config.php authproc szabályai között kell felvenni őket, amikor szükség van rá.

config/config.php

...
'authproc.sp' => array(
...
11 => array(
'class' => 'core:AttributeMap', 'oid-href'
),
...
),
...

attributemap/href-oid.php

<?php

/**
* Hungarian Research and Education Federation AttributeSchema representation
* source: https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif
* @author: Szabó Gyula, aai.sztaki.hu <gyufi@sztaki.hu>
*
*/

$attributemap = array(
'niifPersonCityOfBirth' => 'urn:oid:1.3.6.1.4.1.11914.0.1.155',
'niifPersonDateOfBirth' => 'urn:oid:1.3.6.1.4.1.11914.0.1.152',
'niifPersonActivityStatus' => 'urn:oid:1.3.6.1.4.1.11914.0.1.153',
'niifPersonJoinDate' => 'urn:oid:1.3.6.1.4.1.11914.0.1.169',
'niifPersonOrgID' => 'urn:oid:1.3.6.1.4.1.11914.0.1.154',
'niifCertificateSubjectDN' => 'urn:oid:1.3.6.1.4.1.11914.0.1.151',
'niifEduPersonFacultyDN' => 'urn:oid:1.3.6.1.4.1.11914.0.1.161',
'niifPersonPosition' => 'urn:oid:1.3.6.1.4.1.11914.0.1.167',
'niifStatus' => 'urn:oid:1.3.6.1.4.1.11914.0.1.1',
'niifPersonIdentityNumber' => 'urn:oid:1.3.6.1.4.1.11914.0.1.158',
'niifTitle' => 'urn:oid:1.3.6.1.4.1.11914.0.1.2',
'niifCertificateSHA1Fingerprint' => 'urn:oid:1.3.6.1.4.1.11914.0.1.173',
'niifEduPersonAttendedCourse' => 'urn:oid:1.3.6.1.4.1.11914.0.1.164',
'niifEduPersonArchiveCourse' => 'urn:oid:1.3.6.1.4.1.11914.0.1.171',
'niifEduPersonHeldCourse' => 'urn:oid:1.3.6.1.4.1.11914.0.1.172',
'niifPrefix' => 'urn:oid:1.3.6.1.4.1.11914.0.1.0',
'niifPersonDegree' => 'urn:oid:1.3.6.1.4.1.11914.0.1.166',
'niifEduPersonFaculty' => 'urn:oid:1.3.6.1.4.1.11914.0.1.160',
'niifEduPersonMajor' => 'urn:oid:1.3.6.1.4.1.11914.0.1.162',
'niifPersonQuitDate' => 'urn:oid:1.3.6.1.4.1.11914.0.1.170',
'niifPersonMothersName' => 'urn:oid:1.3.6.1.4.1.11914.0.1.157',
'niifEduPersonAcademicYear' => 'urn:oid:1.3.6.1.4.1.11914.0.1.163',
'niifPersonCountyOfBirth' => 'urn:oid:1.3.6.1.4.1.11914.0.1.156',
'niifUniqueId' => 'urn:oid:1.3.6.1.4.1.11914.0.1.3',
'niifPersonPrefix' => 'urn:oid:1.3.6.1.4.1.11914.0.1.165',
'niifActiveMemberOf' => 'urn:oid:1.3.6.1.4.1.11914.0.1.168',
'niifPersonResidentalAddress' => 'urn:oid:1.3.6.1.4.1.11914.0.1.159',
'niifIDPrefix' => 'urn:oid:1.3.6.1.4.1.11914.0.1.100',
);
?>

/attributemap/oid-href.php

<?php

/**
* Hungarian Research and Education Federation AttributeSchema representation
* source: https://wiki.aai.niif.hu/images/3/35/99-niifschema.ldif
* @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',
);
?>

SimpeleSAMLphp NIIF ldap séma mapping

2010-09-27T12:28:15Z

Gyufi(AT)sztaki.hu: SimpeleSAMLphp NIIF ldap séma mapping lapot átneveztem SimpleSAMLphp NIIF ldap séma mapping névre

#ÁTIRÁNYÍTÁS [[SimpleSAMLphp NIIF ldap séma mapping]]

SimpleSAMLphp NIIF ldap séma mapping

2010-09-27T12:16:47Z

Gyufi(AT)sztaki.hu: Új oldal, tartalma: „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 - n…”

Szerkesztő:Gyufi(AT)sztaki.hu

2010-09-27T12:01:10Z

Gyufi(AT)sztaki.hu:

;2010. szeptember
: [[Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban]]
: [[simpeleSAMLphp NIIF ldap séma mapping]]

=Networkshop 2010.=

simpleSAMLphp, mint IdP a Sztakiban.

http://docs.google.com/present/view?id=dgxggrcj_105djxkgkdq

Szerkesztő:Gyufi(AT)sztaki.hu

2010-09-16T08:49:43Z

Gyufi(AT)sztaki.hu:

;2010. szeptember
: [[Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban]]

=Networkshop 2010.=

simpleSAMLphp, mint IdP a Sztakiban.

http://docs.google.com/present/view?id=dgxggrcj_105djxkgkdq

Fájl:HuntekaMintSPRendszerArchitektura.png

2010-09-16T08:46:51Z

Gyufi(AT)sztaki.hu:

Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban

2010-09-16T08:46:28Z

Gyufi(AT)sztaki.hu: /* Rendszer architektúra */

=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

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

[[Kép: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]

==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");

[[Kép: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.

LogoutFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.log4j.Logger;

/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {

/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);

public LogoutFilter() {
}

/**
* @see Filter#destroy()
*/
public void destroy() {
}

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}

/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}

web.xml

...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...

[[Kép:IdPinitSLO.png]]

=Rendszer architektúra=

[[Kép:HuntekaMintSPRendszerArchitektura.png]]

==OIOSAML.java, mint SP komponens==
(OIOSAML 2.0 Toolkit test results dokumentumból érdemes ide tenni vm.-t)
===Telepítés===

Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába

2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:

<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>

<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>

<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>

A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.

A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.

Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.

===Konfiguráció===

Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.

Telepítés után a következő módosításokat érdemes megtenni a fileban:

oiosaml-sp.assurancelevel=0

Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

oiosaml-sp.uri.home=../

Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html]

===Meta-adat kezelés===

A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.

Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.

Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.

===Discovery Service===
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.

Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.

Telepítése az oiosaml.java-discovery.*.war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery.* változók használhatóak.

A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található:
[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html]

===Metadata frissítés===

A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.

Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.

Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.

A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

Fájl:IdPinitSLO.png

2010-09-16T08:44:16Z

Gyufi(AT)sztaki.hu:

Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban

2010-09-16T08:43:51Z

Gyufi(AT)sztaki.hu: /* IdP által kezdeményezett SLO */

=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

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

[[Kép: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]

==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");

[[Kép: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.

LogoutFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.log4j.Logger;

/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {

/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);

public LogoutFilter() {
}

/**
* @see Filter#destroy()
*/
public void destroy() {
}

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}

/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}

web.xml

...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...

[[Kép:IdPinitSLO.png]]

=Rendszer architektúra=

==OIOSAML.java, mint SP komponens==
(OIOSAML 2.0 Toolkit test results dokumentumból érdemes ide tenni vm.-t)
===Telepítés===

Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába

2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:

<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>

<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>

<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>

A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.

A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.

Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.

===Konfiguráció===

Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.

Telepítés után a következő módosításokat érdemes megtenni a fileban:

oiosaml-sp.assurancelevel=0

Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

oiosaml-sp.uri.home=../

Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html]

===Meta-adat kezelés===

A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.

Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.

Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.

===Discovery Service===
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.

Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.

Telepítése az oiosaml.java-discovery.*.war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery.* változók használhatóak.

A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található:
[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html]

===Metadata frissítés===

A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.

Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.

Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.

A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

Fájl:SPinitSLO.png

2010-09-16T08:42:34Z

Gyufi(AT)sztaki.hu:

Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban

2010-09-16T08:42:16Z

Gyufi(AT)sztaki.hu: /* SP által kezdeményezett SLO */

=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

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

[[Kép: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]

==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");

[[Kép: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.

LogoutFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.log4j.Logger;

/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {

/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);

public LogoutFilter() {
}

/**
* @see Filter#destroy()
*/
public void destroy() {
}

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}

/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}

web.xml

...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...

=Rendszer architektúra=

==OIOSAML.java, mint SP komponens==
(OIOSAML 2.0 Toolkit test results dokumentumból érdemes ide tenni vm.-t)
===Telepítés===

Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába

2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:

<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>

<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>

<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>

A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.

A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.

Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.

===Konfiguráció===

Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.

Telepítés után a következő módosításokat érdemes megtenni a fileban:

oiosaml-sp.assurancelevel=0

Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

oiosaml-sp.uri.home=../

Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html]

===Meta-adat kezelés===

A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.

Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.

Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.

===Discovery Service===
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.

Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.

Telepítése az oiosaml.java-discovery.*.war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery.* változók használhatóak.

A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található:
[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html]

===Metadata frissítés===

A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.

Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.

Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.

A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban

2010-09-16T08:39:04Z

Gyufi(AT)sztaki.hu: /* Identitások összekapcsolása */

=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

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

[[Kép: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]

==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");

===IdP által kezdeményezett SLO===

Ha a Single Logout-ot a felhasználó egy másik alkalmazásnál kezdeményezte, és kérte, hogy valamennyi aktív alkalmazásból léptesse ki a rendszer, az IdP a könyvtári alkalmazásnak egy Logout Request-et küld a böngésző átirányításának segítségével. A kérésről a SAML SP-n kívül az alkalmazásnak is tudnia kell, hogy a felhasználó session-jén a kilépést érvényre juttassa. Ezt a SAML SP SLO endpoint-jai elé tett filter segítségével lehet a legegyszerűbben végrehajtani.

LogoutFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.log4j.Logger;

/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {

/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);

public LogoutFilter() {
}

/**
* @see Filter#destroy()
*/
public void destroy() {
}

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}

/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}

web.xml

...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...

=Rendszer architektúra=

==OIOSAML.java, mint SP komponens==
(OIOSAML 2.0 Toolkit test results dokumentumból érdemes ide tenni vm.-t)
===Telepítés===

Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába

2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:

<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>

<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>

<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>

A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.

A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.

Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.

===Konfiguráció===

Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.

Telepítés után a következő módosításokat érdemes megtenni a fileban:

oiosaml-sp.assurancelevel=0

Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

oiosaml-sp.uri.home=../

Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html]

===Meta-adat kezelés===

A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.

Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.

Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.

===Discovery Service===
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.

Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.

Telepítése az oiosaml.java-discovery.*.war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery.* változók használhatóak.

A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található:
[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html]

===Metadata frissítés===

A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.

Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.

Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.

A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

Fájl:Accountlinking.png

2010-09-16T08:38:34Z

Gyufi(AT)sztaki.hu:

Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban

2010-09-16T08:03:41Z

Gyufi(AT)sztaki.hu: /* Identitások összekapcsolása */

=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

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

[[Kép:accountlinking]]

Bejelentkezés során bármely eduid-vel azonosítja a felhasználót a szóbanforgó Home IdP, az alkalmazás kikeresi a megfelelő könyvtári alkalmazásbeli azonosítót, és a továbbiakban az alkalmazás ezt használja a munkamenet során.

==Beiratkozás==

Ha a felhasználó olyan azonosítóval jön a Home IdP-től, ami nincs egyetlen alkalmazás azonosítóhoz sem kapcsolva, a beiratkozás folyamatát kell végrehajtani.

A beiratkozás folyamán létre kell hozni az olvasó táblában az új olvasót, és a Home IdP-től kapott személyes adatokkal fel kell tölteni az olvasó rekordot.

A “Föderált azonosító” kapcsolótáblában létre kell hozni a könyvtári azonosítót és a föderált azonosítót összerendelő rekordot.

==Kiiratkozás==

Felhasználó kiiratását az OIOSAML.java nem támogatja, az azonosító lejáratásával lehet a felhasználó jogosultságait korlátozni. Tervezésnél meg kell fontolni, hogy egy-egy IdP által azonosított felhasználó beiratásánál mennyi az az idő, amíg az olvasót aktívnak szeretnénk tudni. Megvizsgálva néhány könyvtár Használati szabályzatát a megoldás megfelel az általános gyakorlatnak. A könyvtárak beiratkozáskor kiállított olvasójegyét bizonyos időre szóló érvényességgel (általában 1 év) állítják ki, ha az olvasó ennek elteltével nem hosszabbítja meg olvasójegye érvényességét, az lejár.

==Azonosítás és attribútumok átadása==

A LoginFilter által védett URL-re irányuló kéréskor a SAML Assertion és az általa hordozott attribútumok a dk.itst.oiosaml.sp.UserAssertion objektumból lekérdezhetőek. Ezen objektum csak a védett URL-eken érhető el a dk.itst.oiosaml.sp.UserAssertionHolder.get() metódus meghívásával.

Ha csak a login funkciót védjük SAML SP-vel, érdemes a user session-be átmenteni a szükséges attribútumokat, ha azokat más funkciókkal is el kell érni.

Attribútum mappingről igény szerint a fejlesztés során kell gondoskodnunk, az OIOSAML.java nem támogat ilyen funkciót.

Példa az eduPersonPrincipalName attribútum kinyeréséről:

UserAssertion ua = UserAssertionHolder.get();
String eppn = ua.getAttribute(“urn:oid:1.3.6.1.4.1.5923.1.1.1.6 ”);

A rendszerfejlesztéshez kapcsolódó dokumentáció az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/developers.html]

==Attribútumok frissítése==

Hogy a könyvtári rendszerben nyilvántartott olvasók adatai naprakészek legyenek, a Home IdP-től származó attribútumokat nem csak a beiratkozáskor, hanem a mindennapi használatkor is igénybe vehetjük.

Az IdP-től kapott attribútumokat a könyvtári alkalmazás ellenőrzi, és ha az adott attribútum még nem szerepel a nyilvántartásában, azt rögzíti.

Az alkalmazás saját szabály-rendszere döntheti el, hogy a meglévő értékeket lecseréli az Home IdP-től kapottal, vagy csak hozzáadja új értékként a már meglévőhöz.

==Kijelentkezés==

===SP által kezdeményezett SLO===

Az alkalmazásból történő kijelentkezést a session-változók törlésével kell megoldani, és biztosítani kell a Single Logout folyamat elindítását. Az OIOSAML.java esetében ezt a saml/Logout URL-re történő redirect-tel lehet kezdeményezni.

HttpSession session = req.getSession(false);
res.sendRedirect("saml/Logout");

===IdP által kezdeményezett SLO===

Ha a Single Logout-ot a felhasználó egy másik alkalmazásnál kezdeményezte, és kérte, hogy valamennyi aktív alkalmazásból léptesse ki a rendszer, az IdP a könyvtári alkalmazásnak egy Logout Request-et küld a böngésző átirányításának segítségével. A kérésről a SAML SP-n kívül az alkalmazásnak is tudnia kell, hogy a felhasználó session-jén a kilépést érvényre juttassa. Ezt a SAML SP SLO endpoint-jai elé tett filter segítségével lehet a legegyszerűbben végrehajtani.

LogoutFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.log4j.Logger;

/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {

/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);

public LogoutFilter() {
}

/**
* @see Filter#destroy()
*/
public void destroy() {
}

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}

/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}

web.xml

...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...

=Rendszer architektúra=

==OIOSAML.java, mint SP komponens==
(OIOSAML 2.0 Toolkit test results dokumentumból érdemes ide tenni vm.-t)
===Telepítés===

Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába

2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:

<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>

<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>

<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>

A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.

A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.

Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.

===Konfiguráció===

Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.

Telepítés után a következő módosításokat érdemes megtenni a fileban:

oiosaml-sp.assurancelevel=0

Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

oiosaml-sp.uri.home=../

Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html]

===Meta-adat kezelés===

A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.

Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.

Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.

===Discovery Service===
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.

Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.

Telepítése az oiosaml.java-discovery.*.war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery.* változók használhatóak.

A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található:
[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html]

===Metadata frissítés===

A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.

Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.

Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.

A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban

2010-09-16T08:03:27Z

Gyufi(AT)sztaki.hu: /* Identitások összekapcsolása */

=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

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

[Kép:accountlinking]

Bejelentkezés során bármely eduid-vel azonosítja a felhasználót a szóbanforgó Home IdP, az alkalmazás kikeresi a megfelelő könyvtári alkalmazásbeli azonosítót, és a továbbiakban az alkalmazás ezt használja a munkamenet során.

==Beiratkozás==

Ha a felhasználó olyan azonosítóval jön a Home IdP-től, ami nincs egyetlen alkalmazás azonosítóhoz sem kapcsolva, a beiratkozás folyamatát kell végrehajtani.

A beiratkozás folyamán létre kell hozni az olvasó táblában az új olvasót, és a Home IdP-től kapott személyes adatokkal fel kell tölteni az olvasó rekordot.

A “Föderált azonosító” kapcsolótáblában létre kell hozni a könyvtári azonosítót és a föderált azonosítót összerendelő rekordot.

==Kiiratkozás==

Felhasználó kiiratását az OIOSAML.java nem támogatja, az azonosító lejáratásával lehet a felhasználó jogosultságait korlátozni. Tervezésnél meg kell fontolni, hogy egy-egy IdP által azonosított felhasználó beiratásánál mennyi az az idő, amíg az olvasót aktívnak szeretnénk tudni. Megvizsgálva néhány könyvtár Használati szabályzatát a megoldás megfelel az általános gyakorlatnak. A könyvtárak beiratkozáskor kiállított olvasójegyét bizonyos időre szóló érvényességgel (általában 1 év) állítják ki, ha az olvasó ennek elteltével nem hosszabbítja meg olvasójegye érvényességét, az lejár.

==Azonosítás és attribútumok átadása==

A LoginFilter által védett URL-re irányuló kéréskor a SAML Assertion és az általa hordozott attribútumok a dk.itst.oiosaml.sp.UserAssertion objektumból lekérdezhetőek. Ezen objektum csak a védett URL-eken érhető el a dk.itst.oiosaml.sp.UserAssertionHolder.get() metódus meghívásával.

Ha csak a login funkciót védjük SAML SP-vel, érdemes a user session-be átmenteni a szükséges attribútumokat, ha azokat más funkciókkal is el kell érni.

Attribútum mappingről igény szerint a fejlesztés során kell gondoskodnunk, az OIOSAML.java nem támogat ilyen funkciót.

Példa az eduPersonPrincipalName attribútum kinyeréséről:

UserAssertion ua = UserAssertionHolder.get();
String eppn = ua.getAttribute(“urn:oid:1.3.6.1.4.1.5923.1.1.1.6 ”);

A rendszerfejlesztéshez kapcsolódó dokumentáció az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/developers.html]

==Attribútumok frissítése==

Hogy a könyvtári rendszerben nyilvántartott olvasók adatai naprakészek legyenek, a Home IdP-től származó attribútumokat nem csak a beiratkozáskor, hanem a mindennapi használatkor is igénybe vehetjük.

Az IdP-től kapott attribútumokat a könyvtári alkalmazás ellenőrzi, és ha az adott attribútum még nem szerepel a nyilvántartásában, azt rögzíti.

Az alkalmazás saját szabály-rendszere döntheti el, hogy a meglévő értékeket lecseréli az Home IdP-től kapottal, vagy csak hozzáadja új értékként a már meglévőhöz.

==Kijelentkezés==

===SP által kezdeményezett SLO===

Az alkalmazásból történő kijelentkezést a session-változók törlésével kell megoldani, és biztosítani kell a Single Logout folyamat elindítását. Az OIOSAML.java esetében ezt a saml/Logout URL-re történő redirect-tel lehet kezdeményezni.

HttpSession session = req.getSession(false);
res.sendRedirect("saml/Logout");

===IdP által kezdeményezett SLO===

Ha a Single Logout-ot a felhasználó egy másik alkalmazásnál kezdeményezte, és kérte, hogy valamennyi aktív alkalmazásból léptesse ki a rendszer, az IdP a könyvtári alkalmazásnak egy Logout Request-et küld a böngésző átirányításának segítségével. A kérésről a SAML SP-n kívül az alkalmazásnak is tudnia kell, hogy a felhasználó session-jén a kilépést érvényre juttassa. Ezt a SAML SP SLO endpoint-jai elé tett filter segítségével lehet a legegyszerűbben végrehajtani.

LogoutFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.log4j.Logger;

/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {

/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);

public LogoutFilter() {
}

/**
* @see Filter#destroy()
*/
public void destroy() {
}

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}

/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}

web.xml

...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...

=Rendszer architektúra=

==OIOSAML.java, mint SP komponens==
(OIOSAML 2.0 Toolkit test results dokumentumból érdemes ide tenni vm.-t)
===Telepítés===

Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába

2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:

<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>

<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>

<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>

A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.

A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.

Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.

===Konfiguráció===

Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.

Telepítés után a következő módosításokat érdemes megtenni a fileban:

oiosaml-sp.assurancelevel=0

Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

oiosaml-sp.uri.home=../

Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html]

===Meta-adat kezelés===

A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.

Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.

Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.

===Discovery Service===
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.

Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.

Telepítése az oiosaml.java-discovery.*.war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery.* változók használhatóak.

A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található:
[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html]

===Metadata frissítés===

A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.

Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.

Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.

A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban

2010-09-16T07:50:02Z

Gyufi(AT)sztaki.hu: /* IdP által kezdeményezett SLO */

=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

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.

Bejelentkezés során bármely eduid-vel azonosítja a felhasználót a szóbanforgó Home IdP, az alkalmazás kikeresi a megfelelő könyvtári alkalmazásbeli azonosítót, és a továbbiakban az alkalmazás ezt használja a munkamenet során.

==Beiratkozás==

Ha a felhasználó olyan azonosítóval jön a Home IdP-től, ami nincs egyetlen alkalmazás azonosítóhoz sem kapcsolva, a beiratkozás folyamatát kell végrehajtani.

A beiratkozás folyamán létre kell hozni az olvasó táblában az új olvasót, és a Home IdP-től kapott személyes adatokkal fel kell tölteni az olvasó rekordot.

A “Föderált azonosító” kapcsolótáblában létre kell hozni a könyvtári azonosítót és a föderált azonosítót összerendelő rekordot.

==Kiiratkozás==

Felhasználó kiiratását az OIOSAML.java nem támogatja, az azonosító lejáratásával lehet a felhasználó jogosultságait korlátozni. Tervezésnél meg kell fontolni, hogy egy-egy IdP által azonosított felhasználó beiratásánál mennyi az az idő, amíg az olvasót aktívnak szeretnénk tudni. Megvizsgálva néhány könyvtár Használati szabályzatát a megoldás megfelel az általános gyakorlatnak. A könyvtárak beiratkozáskor kiállított olvasójegyét bizonyos időre szóló érvényességgel (általában 1 év) állítják ki, ha az olvasó ennek elteltével nem hosszabbítja meg olvasójegye érvényességét, az lejár.

==Azonosítás és attribútumok átadása==

A LoginFilter által védett URL-re irányuló kéréskor a SAML Assertion és az általa hordozott attribútumok a dk.itst.oiosaml.sp.UserAssertion objektumból lekérdezhetőek. Ezen objektum csak a védett URL-eken érhető el a dk.itst.oiosaml.sp.UserAssertionHolder.get() metódus meghívásával.

Ha csak a login funkciót védjük SAML SP-vel, érdemes a user session-be átmenteni a szükséges attribútumokat, ha azokat más funkciókkal is el kell érni.

Attribútum mappingről igény szerint a fejlesztés során kell gondoskodnunk, az OIOSAML.java nem támogat ilyen funkciót.

Példa az eduPersonPrincipalName attribútum kinyeréséről:

UserAssertion ua = UserAssertionHolder.get();
String eppn = ua.getAttribute(“urn:oid:1.3.6.1.4.1.5923.1.1.1.6 ”);

A rendszerfejlesztéshez kapcsolódó dokumentáció az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/developers.html]

==Attribútumok frissítése==

Hogy a könyvtári rendszerben nyilvántartott olvasók adatai naprakészek legyenek, a Home IdP-től származó attribútumokat nem csak a beiratkozáskor, hanem a mindennapi használatkor is igénybe vehetjük.

Az IdP-től kapott attribútumokat a könyvtári alkalmazás ellenőrzi, és ha az adott attribútum még nem szerepel a nyilvántartásában, azt rögzíti.

Az alkalmazás saját szabály-rendszere döntheti el, hogy a meglévő értékeket lecseréli az Home IdP-től kapottal, vagy csak hozzáadja új értékként a már meglévőhöz.

==Kijelentkezés==

===SP által kezdeményezett SLO===

Az alkalmazásból történő kijelentkezést a session-változók törlésével kell megoldani, és biztosítani kell a Single Logout folyamat elindítását. Az OIOSAML.java esetében ezt a saml/Logout URL-re történő redirect-tel lehet kezdeményezni.

HttpSession session = req.getSession(false);
res.sendRedirect("saml/Logout");

===IdP által kezdeményezett SLO===

Ha a Single Logout-ot a felhasználó egy másik alkalmazásnál kezdeményezte, és kérte, hogy valamennyi aktív alkalmazásból léptesse ki a rendszer, az IdP a könyvtári alkalmazásnak egy Logout Request-et küld a böngésző átirányításának segítségével. A kérésről a SAML SP-n kívül az alkalmazásnak is tudnia kell, hogy a felhasználó session-jén a kilépést érvényre juttassa. Ezt a SAML SP SLO endpoint-jai elé tett filter segítségével lehet a legegyszerűbben végrehajtani.

LogoutFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.log4j.Logger;

/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {

/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);

public LogoutFilter() {
}

/**
* @see Filter#destroy()
*/
public void destroy() {
}

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}

/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}

web.xml

...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...

=Rendszer architektúra=

==OIOSAML.java, mint SP komponens==
(OIOSAML 2.0 Toolkit test results dokumentumból érdemes ide tenni vm.-t)
===Telepítés===

Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába

2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:

<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>

<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>

<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>

A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.

A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.

Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.

===Konfiguráció===

Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.

Telepítés után a következő módosításokat érdemes megtenni a fileban:

oiosaml-sp.assurancelevel=0

Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

oiosaml-sp.uri.home=../

Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html]

===Meta-adat kezelés===

A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.

Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.

Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.

===Discovery Service===
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.

Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.

Telepítése az oiosaml.java-discovery.*.war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery.* változók használhatóak.

A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található:
[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html]

===Metadata frissítés===

A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.

Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.

Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.

A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban

2010-09-16T07:34:42Z

Gyufi(AT)sztaki.hu: /* huntéka, mint SP */

=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

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.

Bejelentkezés során bármely eduid-vel azonosítja a felhasználót a szóbanforgó Home IdP, az alkalmazás kikeresi a megfelelő könyvtári alkalmazásbeli azonosítót, és a továbbiakban az alkalmazás ezt használja a munkamenet során.

==Beiratkozás==

Ha a felhasználó olyan azonosítóval jön a Home IdP-től, ami nincs egyetlen alkalmazás azonosítóhoz sem kapcsolva, a beiratkozás folyamatát kell végrehajtani.

A beiratkozás folyamán létre kell hozni az olvasó táblában az új olvasót, és a Home IdP-től kapott személyes adatokkal fel kell tölteni az olvasó rekordot.

A “Föderált azonosító” kapcsolótáblában létre kell hozni a könyvtári azonosítót és a föderált azonosítót összerendelő rekordot.

==Kiiratkozás==

Felhasználó kiiratását az OIOSAML.java nem támogatja, az azonosító lejáratásával lehet a felhasználó jogosultságait korlátozni. Tervezésnél meg kell fontolni, hogy egy-egy IdP által azonosított felhasználó beiratásánál mennyi az az idő, amíg az olvasót aktívnak szeretnénk tudni. Megvizsgálva néhány könyvtár Használati szabályzatát a megoldás megfelel az általános gyakorlatnak. A könyvtárak beiratkozáskor kiállított olvasójegyét bizonyos időre szóló érvényességgel (általában 1 év) állítják ki, ha az olvasó ennek elteltével nem hosszabbítja meg olvasójegye érvényességét, az lejár.

==Azonosítás és attribútumok átadása==

A LoginFilter által védett URL-re irányuló kéréskor a SAML Assertion és az általa hordozott attribútumok a dk.itst.oiosaml.sp.UserAssertion objektumból lekérdezhetőek. Ezen objektum csak a védett URL-eken érhető el a dk.itst.oiosaml.sp.UserAssertionHolder.get() metódus meghívásával.

Ha csak a login funkciót védjük SAML SP-vel, érdemes a user session-be átmenteni a szükséges attribútumokat, ha azokat más funkciókkal is el kell érni.

Attribútum mappingről igény szerint a fejlesztés során kell gondoskodnunk, az OIOSAML.java nem támogat ilyen funkciót.

Példa az eduPersonPrincipalName attribútum kinyeréséről:

UserAssertion ua = UserAssertionHolder.get();
String eppn = ua.getAttribute(“urn:oid:1.3.6.1.4.1.5923.1.1.1.6 ”);

A rendszerfejlesztéshez kapcsolódó dokumentáció az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/developers.html]

==Attribútumok frissítése==

Hogy a könyvtári rendszerben nyilvántartott olvasók adatai naprakészek legyenek, a Home IdP-től származó attribútumokat nem csak a beiratkozáskor, hanem a mindennapi használatkor is igénybe vehetjük.

Az IdP-től kapott attribútumokat a könyvtári alkalmazás ellenőrzi, és ha az adott attribútum még nem szerepel a nyilvántartásában, azt rögzíti.

Az alkalmazás saját szabály-rendszere döntheti el, hogy a meglévő értékeket lecseréli az Home IdP-től kapottal, vagy csak hozzáadja új értékként a már meglévőhöz.

==Kijelentkezés==

===SP által kezdeményezett SLO===

Az alkalmazásból történő kijelentkezést a session-változók törlésével kell megoldani, és biztosítani kell a Single Logout folyamat elindítását. Az OIOSAML.java esetében ezt a saml/Logout URL-re történő redirect-tel lehet kezdeményezni.

HttpSession session = req.getSession(false);
res.sendRedirect("saml/Logout");

===IdP által kezdeményezett SLO===

Ha a Single Logout-ot a felhasználó egy másik alkalmazásnál kezdeményezte, és kérte, hogy valamennyi aktív alkalmazásból léptesse ki a rendszer, az IdP a könyvtári alkalmazásnak egy Logout Request-et küld a böngésző átirányításának segítségével. A kérésről a SAML SP-n kívül az alkalmazásnak is tudnia kell, hogy a felhasználó session-jén a kilépést érvényre juttassa. Ezt a SAML SP SLO endpoint-jai elé tett filter segítségével lehet a legegyszerűbben végrehajtani.

LogoutFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.log4j.Logger;

/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {

/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);

public LogoutFilter() {
}

/**
* @see Filter#destroy()
*/
public void destroy() {
}

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}

/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}

web.xml

...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...

=Rendszer architektúra=

==OIOSAML.java, mint SP komponens==
(OIOSAML 2.0 Toolkit test results dokumentumból érdemes ide tenni vm.-t)
===Telepítés===

Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába

2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:

<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>

<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>

<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>

A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.

A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.

Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.

===Konfiguráció===

Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.

Telepítés után a következő módosításokat érdemes megtenni a fileban:

oiosaml-sp.assurancelevel=0

Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

oiosaml-sp.uri.home=../

Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:

[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html]

===Meta-adat kezelés===

A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.

Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.

Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.

===Discovery Service===
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.

Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.

Telepítése az oiosaml.java-discovery.*.war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery.* változók használhatóak.

A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található:
[https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html]

===Metadata frissítés===

A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.

Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.

Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.

A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban

2010-09-16T07:20:49Z

Gyufi(AT)sztaki.hu: Új oldal, tartalma: „=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…”

=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

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.
Bejelentkezés során bármely eduid-vel azonosítja a felhasználót a szóbanforgó Home IdP, az alkalmazás kikeresi a megfelelő könyvtári alkalmazásbeli azonosítót, és a továbbiakban az alkalmazás ezt használja a munkamenet során.
Beiratkozás
Ha a felhasználó olyan azonosítóval jön a Home IdP-től, ami nincs egyetlen alkalmazás azonosítóhoz sem kapcsolva, a beiratkozás folyamatát kell végrehajtani.
A beiratkozás folyamán létre kell hozni az olvasó táblában az új olvasót, és a Home IdP-től kapott személyes adatokkal fel kell tölteni az olvasó rekordot.
A “Föderált azonosító” kapcsolótáblában létre kell hozni a könyvtári azonosítót és a föderált azonosítót összerendelő rekordot.
Kiiratkozás
Felhasználó kiiratását az OIOSAML.java nem támogatja, az azonosító lejáratásával lehet a felhasználó jogosultságait korlátozni. Tervezésnél meg kell fontolni, hogy egy-egy IdP által azonosított felhasználó beiratásánál mennyi az az idő, amíg az olvasót aktívnak szeretnénk tudni. Megvizsgálva néhány könyvtár Használati szabályzatát a megoldás megfelel az általános gyakorlatnak. A könyvtárak beiratkozáskor kiállított olvasójegyét bizonyos időre szóló érvényességgel (általában 1 év) állítják ki, ha az olvasó ennek elteltével nem hosszabbítja meg olvasójegye érvényességét, az lejár.
Azonosítás és attribútumok átadása
A LoginFilter által védett URL-re irányuló kéréskor a SAML Assertion és az általa hordozott attribútumok a dk.itst.oiosaml.sp.UserAssertion objektumból lekérdezhetőek. Ezen objektum csak a védett URL-eken érhető el a dk.itst.oiosaml.sp.UserAssertionHolder.get() metódus meghívásával.
Ha csak a login funkciót védjük SAML SP-vel, érdemes a user session-be átmenteni a szükséges attribútumokat, ha azokat más funkciókkal is el kell érni.
Attribútum mappingről igény szerint a fejlesztés során kell gondoskodnunk, az OIOSAML.java nem támogat ilyen funkciót.
Példa az eduPersonPrincipalName attribútum kinyeréséről:

UserAssertion ua = UserAssertionHolder.get();
String eppn = ua.getAttribute(“urn:oid:1.3.6.1.4.1.5923.1.1.1.6 ”);

A rendszerfejlesztéshez kapcsolódó dokumentáció az alábbi URL-en található:
https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/developers.html
Attribútumok frissítése
Hogy a könyvtári rendszerben nyilvántartott olvasók adatai naprakészek legyenek, a Home IdP-től származó attribútumokat nem csak a beiratkozáskor, hanem a mindennapi használatkor is igénybe vehetjük.
Az IdP-től kapott attribútumokat a könyvtári alkalmazás ellenőrzi, és ha az adott attribútum még nem szerepel a nyilvántartásában, azt rögzíti.
Az alkalmazás saját szabály-rendszere döntheti el, hogy a meglévő értékeket lecseréli az Home IdP-től kapottal, vagy csak hozzáadja új értékként a már meglévőhöz.
Kijelentkezés
SP által kezdeményezett SLO
Az alkalmazásból történő kijelentkezést a session-változók törlésével kell megoldani, és biztosítani kell a Single Logout folyamat elindítását. Az OIOSAML.java esetében ezt a saml/Logout URL-re történő redirect-tel lehet kezdeményezni.

HttpSession session = req.getSession(false);
res.sendRedirect("saml/Logout");

IdP által kezdeményezett SLO
Ha a Single Logout-ot a felhasználó egy másik alkalmazásnál kezdeményezte, és kérte, hogy valamennyi aktív alkalmazásból léptesse ki a rendszer, az IdP a könyvtári alkalmazásnak egy Logout Request-et küld a böngésző átirányításának segítségével. A kérésről a SAML SP-n kívül az alkalmazásnak is tudnia kell, hogy a felhasználó session-jén a kilépést érvényre juttassa. Ezt a SAML SP SLO endpoint-jai elé tett filter segítségével lehet a legegyszerűbben végrehajtani.

LogoutFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.log4j.Logger;

/**
* Servlet Filter implementation class LogoutFilter
*/
public class LogoutFilter implements Filter {

/**
* Default constructor.
*/
private static final Logger log = Logger.getLogger(LogoutFilter.class);

public LogoutFilter() {
}

/**
* @see Filter#destroy()
*/
public void destroy() {
}

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
log.debug("Enter into LoginFilter");
HttpServletRequest servletRequest = ((HttpServletRequest) request);
HttpSession session = servletRequest.getSession(false);
if (session != null){
log.debug("Remove application related session attributes.");
session.removeAttribute("aai_auth");
}
}

/**
* @see Filter#init(FilterConfig)
*/
public void init(FilterConfig fConfig) throws ServletException {
}
}

web.xml

...
<filter>
<filter-name>LogoutFilter</filter-name>
<filter-class>LogoutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LogoutFilter</filter-name>
<url-pattern>/saml/LogoutServiceHTTPRedirect</url-pattern>
<url-pattern>/saml/LogoutServiceHTTPRedirectResponse</url-pattern>
</filter-mapping>
...

Rendszer architektúra

OIOSAML.java, mint SP komponens
(OIOSAML 2.0 Toolkit test results dokumentumból érdemes ide tenni vm.-t)
Telepítés
Az oiosaml.java letöltése után a következő lépésekkel telepíthetjük alkalmazásunkhoz az oiosaml.java SP komponenst:

1. Másoljuk a lib/* fileokat a könyvtári alkalamzás WEB-INF/lib könyvtárába
2. Egészítsük ki az alkalmazás web.xml leírófile-ját a következőkkel:

<context-param>
<param-name>oiosaml-j.home</param-name>
<param-value>/path/to/oiosaml.home</param-value>
</context-param>

<servlet>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<servlet-class>dk.itst.oiosaml.sp.service.DispatcherServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>SAMLDispatcherServlet</servlet-name>
<url-pattern>/saml/*</url-pattern>
</servlet-mapping>

<filter>
<filter-name>LoginFilter</filter-name>
<filter-class>dk.itst.oiosaml.sp.service.SPFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LoginFilter</filter-name>
<url-pattern>/protected/*</url-pattern>
</filter-mapping>

A SAMLDispatcherServlet servlet végzi el a SAML-lal kapcsolatos kéréseket, ajánlott a /saml/* URL alá definiálni.
A LoginFilter filter által védett URL-lek (példánkban /protected/*) csak SAML-os azonosítással érhetőek el, ezen URL-ek alatt érhetők el különböző objektumokban TODO a SAML Assertion-ben átadott attribútumértékek.
Telepítés után a az OIOSAML.java ellenőrzi konfigurációját, és ha a rendszer nincs helyesen konfigurálva, elindul az autoconfig folyamat, ahol a rendszert a webes felületről konfigurálhatjuk. A konfigurációs folyamat végén az SP aláírt meta-adata letölthető.
Konfiguráció
Az oiosaml.java konfigurációja az oiosaml-sp.properties file-ban található.
Telepítés után a következő módosításokat érdemes megtenni a fileban:

oiosaml-sp.assurancelevel=0

Az elfogadott azonosítási szintet állíthatjuk itt be. Mivel a föderációban ilyet egyelőre nem használunk, és egyes IdP-k nem támogatják (simpleSAMLphp) ezt az attribútumot, állítsuk 0-ra.

oiosaml-sp.uri.home=../

Az alkalmazásunk kezdő lapja. SLO után ide irányítódik át a felhasználó böngészője.

A konfigurációs beállítások teljes dokumentációja az alábbi URL-en található:
https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/configuration.html
Meta-adat kezelés
A SAML SP komponens működéséhez elengedhetetlen, hogy a vele bizalmi szövetségben lévő IdP-k meta-adatait ismerje.
Az OIOSAML.java meta-adatformátumának a legfőbb jellemzője, hogy az egyes entitásokat egyenként külön file-ban kell eltárolni. Az szóban forgó file-okat a metadata/IdP alkönyvtárba kell helyezni XML formátumban, a név-konvenció csak annyit követel meg, hogy .xml-re végződjön a file neve.
Fontos tudni, hogy az OIOSAML.java csak induláskor tölti be a meta-adatokat, így ha azokat változtatjuk, az alkalmazást újra kell indítani, hogy a változtatások érvényre jussanak.
Discovery Service
Ha az SP több IdP-vel is bizalmi szövetséget alkot, szükség van Discovery Service-re is, hogy a felhasználó eldönthesse, melyik IdP-nél kívánja magát azonosítani.
Az OIOSAML.java tartalmaz egy discovery service servlet-et, ami az IdP metadatáiból állít össze egy weboldalt, ahol a felhasználó kiválaszthatja a saját IdP-jét.
Telepítése az oiosaml.java-discovery.*.war file egyszerű deploy-olásával történik, beállításra az oiosaml-sp.properties file oiosaml-sp.discovery.* változók használhatóak.

A discovery service-hez kapcsolódó dokumentáció az alábbi URL-en található:
https://svn.softwareborsen.dk/oiosaml.java/sp/trunk/docs/discovery.html
Metadata frissítés
A meta-adatok frissítése kapcsán meg kell oldani a HREF letölthető teljes meta-adatának entitásonként külön file-ba történő szétvágását.
Ezt a feladatot a mdsigner-j-cli-2.0-rc2-jar-with-dependencies.jar nevű program végzi el.
Működéséhez szükséges a metadata aláíró root certificate, ezzel lehet ellenőrizni a metadata hitelességét.
A programot célszerű rendszeresen, pl. naponta futtatni, egy külön folyamatban leválogatni a releváns IdP-ket, ellenőrizni a módosulásokat, módosulás esetén frissíteni a SAML SP metadata könyvtárát és újraindítani a webalkalmazást.

Szerkesztő:Gyufi(AT)sztaki.hu

2010-09-16T07:15:16Z

Gyufi(AT)sztaki.hu:

=[[Szövetségi alapon történő felhasználó azonosítás Huntéka könyvtári alkalmazásokban]]=

=Networkshop 2010.=

simpleSAMLphp, mint IdP a Sztakiban.

http://docs.google.com/present/view?id=dgxggrcj_105djxkgkdq

Szerkesztő:Gyufi(AT)sztaki.hu

2010-04-09T09:14:32Z

Gyufi(AT)sztaki.hu: Új oldal, tartalma: „Networkshop 2010. simpleSAMLphp, mint IdP a Sztakiban. http://docs.google.com/present/view?id=dgxggrcj_105djxkgkdq”

Networkshop 2010.

simpleSAMLphp, mint IdP a Sztakiban.

http://docs.google.com/present/view?id=dgxggrcj_105djxkgkdq

Attribútum feloldás

2009-10-01T09:15:17Z

Gyufi(AT)sztaki.hu: /* JNDIDirectoryDataConnector */

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 [[ShibIdPARP | Attribute Release Policy]]-ban engedélyezve van. Természetesen fel nem oldott attribútumokat nem lehet átadni.

Az attribútum feloldást az [[ShibIdPConfig | IdP konfiguráció]] <code>IdPConfig</code> elemének <code>resolverConfig</code> attribútumában megadott XML állományban konfigurálhatjuk. Ez általában a '''<code>resolver.xml</code>''' vagy '''<code>resolver.ldap.xml</code>''' névre hallgat
== Működő példa konfiguráció ==
<source lang="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,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>

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

</AttributeResolver>
</source>
== 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 [[Assertion | assertionbe]] tenni.
== Adatok kinyerése (DataConnector) ==
Minden adatforrás rendelkezik egy ''id'' mezővel, amelynek az összes adatforrásra nézve egyedinek kell lennie.
=== JNDIDirectoryDataConnector ===
Ennek segítségével állíthatjuk be a JNDI LDAP kapcsolat paramétereit. Ezen az interfészen keresztül tetszőleges LDAP v3 interfészt biztosító adatforrás lekérdezhető.

Példa:
<source lang="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>
</source>

; Példa beállítások magyarázata (részletes beállítási lehetőségekkel kapcsolatban lásd a [https://spaces.internet2.edu/display/SHIB/JNDIDataConnector Shibboleth Wiki vonatkozó részét]!)
* ''<code>Search@filter</code>'': 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 '''&''' jelet '''&amp;'''-vel kell eszképelni.
* ''<code>Search/Controls@searchScope</code>'': az LDAP lekérdezés scope-ja. Lehetséges értékek:
** ONELEVEL_SCOPE
** OBJECT_SCOPE (base)
** SUBTREE_SCOPE
* ''<code>java.naming.provider.url</code> property'': LDAP URL, amely a search base DN-jét is tartalmazza
* ''<code>java.naming.provider.protocol</code> 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]]
* ''<code>java.naming.security.principal</code> property'': az a DN, amellyel a Shibboleth alkalmazás bind-ol az LDAP szerverhez.
* ''<code>java.naming.security.credentials</code> 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.
<source lang="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>
</source>

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

A <code>JDBCDataConnector</code> részletes paraméterezhetőségéről lásd a [https://spaces.internet2.edu/display/SHIB/JDBCDataConnector Shibboleth wiki vonatkozó részét]!

=== StaticDataConnector ===
Ennek segítségével rendelhetünk statikus adatokat a felhasználókhoz. Legtöbbször akkor használjuk, ha az IdP-nél történt azonosítás tényéből attribútumokat akarunk származtatni.
<source lang="xml">
<StaticDataConnector id="staticOrgDN">
<Attribute name="eduPersonOrgDN">
<Value>o=niifi,o=niif,c=hu</Value>
</Attribute>
</StaticDataConnector>
</source>

Egy <code>StaticDataConnector</code> egyszerre több attribútumot is tud szolgáltatni, ill. egy attribútumnak több értéke is lehet. Bővebben lásd a [https://spaces.internet2.edu/display/SHIB/StaticDataConnector Shibboleth wiki vonatkozó részét]!

== Attribútumok előkészítése (AttributeDefinition) ==
Az attribútum definíciók arra valók, hogy az adatforrásból származó értéket az átvitelt biztosító SAML szabványnak, illetve az attribútumot fogadó SP-nek megfelelő formátumba konvertálják. Ezért minden attribútum definíciónál meg lehet adni függőséget, amelyből az attribútum értéke származik. A függőségnek két fajtája van:
* '''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]]-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 <code>valami@valahol</code> formátumú), akkor az attribútum scope-ja a <code>smartScope</code> lesz, ellenkező esetben a scope értéke a "@ utáni rész" lesz (pl.: <code>valahol</code>).
:: (Leegyszerűsítve) egy [[Assertion]]-ben egy attribútum így adható meg: attribútum név + scope + érték(ek)
* ''allowEmpty'': ez a boolean paraméter adja meg, hogy az üres érték elfogadható-e. Alapértelmezett értéke <code>false</code>, azaz ha nincs érték, akkor az [[Assertion]]-be nem kerül bele az attribútum. Ha <code>true</code>, 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:
# Ha meg van adva a ''sourceName'', akkor az adat konnektortól ezt az attribútumot kapja meg
# 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
# 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 <code>urn:mace:dir:attribute-def:cn</code> attribútumban küldi el a másik félnek.
<source lang="xml">
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
</source>

'''Példa 2.''': a ''directory'' nevű adat konnektortól lekérdezi a ''displayName'' attribútumot, majd ennek értékét az <code>urn:mace:dir:attribute-def:cn</code> (!) attribútumban küldi el a másik félnek.
<source lang="xml">
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn" sourceName="displayName">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
</source>

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

Részletes leírást lásd a [https://spaces.internet2.edu/display/SHIB/SimpleAttributeDefinition Shibboleth wiki vonatkozó részében]!

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

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

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

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

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

Példa: <code>/usr/local/shibboleth-idp/bin/resolvertest --resolverxml=file:///etc/shibboleth-idp/resolver.ldap.xml --user=bajnokk</code>
<source lang="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: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-instance"
AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<AttributeValue Scope="niif.hu">bajnokk</AttributeValue>
</Attribute>
</source>

== Forrás ==
* https://spaces.internet2.edu/display/SHIB/NewIdPAttribute
* https://spaces.internet2.edu/display/SHIB/IdPAttributeConfig

[[Kategória: Shibboleth IdP]]
[[Kategória: Shibboleth IdP konfiguráció]]

Attribútum feloldás

2009-10-01T09:14:42Z

Gyufi(AT)sztaki.hu: /* JNDIDirectoryDataConnector */

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 [[ShibIdPARP | Attribute Release Policy]]-ban engedélyezve van. Természetesen fel nem oldott attribútumokat nem lehet átadni.

Az attribútum feloldást az [[ShibIdPConfig | IdP konfiguráció]] <code>IdPConfig</code> elemének <code>resolverConfig</code> attribútumában megadott XML állományban konfigurálhatjuk. Ez általában a '''<code>resolver.xml</code>''' vagy '''<code>resolver.ldap.xml</code>''' névre hallgat
== Működő példa konfiguráció ==
<source lang="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,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>

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

</AttributeResolver>
</source>
== 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 [[Assertion | assertionbe]] tenni.
== Adatok kinyerése (DataConnector) ==
Minden adatforrás rendelkezik egy ''id'' mezővel, amelynek az összes adatforrásra nézve egyedinek kell lennie.
=== JNDIDirectoryDataConnector ===
Ennek segítségével állíthatjuk be a JNDI LDAP kapcsolat paramétereit. Ezen az interfészen keresztül tetszőleges LDAP v3 interfészt biztosító adatforrás lekérdezhető.

Példa:
<source lang="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>
</source>

; Példa beállítások magyarázata (részletes beállítási lehetőségekkel kapcsolatban lásd a [https://spaces.internet2.edu/display/SHIB/JNDIDataConnector Shibboleth Wiki vonatkozó részét]!)
* ''<code>Search@filter</code>'': 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 '''&''' jelet '''&'''-vel kell eszképelni.
* ''<code>Search/Controls@searchScope</code>'': az LDAP lekérdezés scope-ja. Lehetséges értékek:
** ONELEVEL_SCOPE
** OBJECT_SCOPE (base)
** SUBTREE_SCOPE
* ''<code>java.naming.provider.url</code> property'': LDAP URL, amely a search base DN-jét is tartalmazza
* ''<code>java.naming.provider.protocol</code> 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]]
* ''<code>java.naming.security.principal</code> property'': az a DN, amellyel a Shibboleth alkalmazás bind-ol az LDAP szerverhez.
* ''<code>java.naming.security.credentials</code> 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.
<source lang="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>
</source>

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

A <code>JDBCDataConnector</code> részletes paraméterezhetőségéről lásd a [https://spaces.internet2.edu/display/SHIB/JDBCDataConnector Shibboleth wiki vonatkozó részét]!

=== StaticDataConnector ===
Ennek segítségével rendelhetünk statikus adatokat a felhasználókhoz. Legtöbbször akkor használjuk, ha az IdP-nél történt azonosítás tényéből attribútumokat akarunk származtatni.
<source lang="xml">
<StaticDataConnector id="staticOrgDN">
<Attribute name="eduPersonOrgDN">
<Value>o=niifi,o=niif,c=hu</Value>
</Attribute>
</StaticDataConnector>
</source>

Egy <code>StaticDataConnector</code> egyszerre több attribútumot is tud szolgáltatni, ill. egy attribútumnak több értéke is lehet. Bővebben lásd a [https://spaces.internet2.edu/display/SHIB/StaticDataConnector Shibboleth wiki vonatkozó részét]!

== Attribútumok előkészítése (AttributeDefinition) ==
Az attribútum definíciók arra valók, hogy az adatforrásból származó értéket az átvitelt biztosító SAML szabványnak, illetve az attribútumot fogadó SP-nek megfelelő formátumba konvertálják. Ezért minden attribútum definíciónál meg lehet adni függőséget, amelyből az attribútum értéke származik. A függőségnek két fajtája van:
* '''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]]-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 <code>valami@valahol</code> formátumú), akkor az attribútum scope-ja a <code>smartScope</code> lesz, ellenkező esetben a scope értéke a "@ utáni rész" lesz (pl.: <code>valahol</code>).
:: (Leegyszerűsítve) egy [[Assertion]]-ben egy attribútum így adható meg: attribútum név + scope + érték(ek)
* ''allowEmpty'': ez a boolean paraméter adja meg, hogy az üres érték elfogadható-e. Alapértelmezett értéke <code>false</code>, azaz ha nincs érték, akkor az [[Assertion]]-be nem kerül bele az attribútum. Ha <code>true</code>, 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:
# Ha meg van adva a ''sourceName'', akkor az adat konnektortól ezt az attribútumot kapja meg
# 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
# 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 <code>urn:mace:dir:attribute-def:cn</code> attribútumban küldi el a másik félnek.
<source lang="xml">
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
</source>

'''Példa 2.''': a ''directory'' nevű adat konnektortól lekérdezi a ''displayName'' attribútumot, majd ennek értékét az <code>urn:mace:dir:attribute-def:cn</code> (!) attribútumban küldi el a másik félnek.
<source lang="xml">
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn" sourceName="displayName">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
</source>

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

Részletes leírást lásd a [https://spaces.internet2.edu/display/SHIB/SimpleAttributeDefinition Shibboleth wiki vonatkozó részében]!

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

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

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

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

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

Példa: <code>/usr/local/shibboleth-idp/bin/resolvertest --resolverxml=file:///etc/shibboleth-idp/resolver.ldap.xml --user=bajnokk</code>
<source lang="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: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-instance"
AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName"
AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<AttributeValue Scope="niif.hu">bajnokk</AttributeValue>
</Attribute>
</source>

== Forrás ==
* https://spaces.internet2.edu/display/SHIB/NewIdPAttribute
* https://spaces.internet2.edu/display/SHIB/IdPAttributeConfig

[[Kategória: Shibboleth IdP]]
[[Kategória: Shibboleth IdP konfiguráció]]

Metadata

2009-07-09T07:20:54Z

Gyufi(AT)sztaki.hu: /* simpleSAMLphp */

Ahhoz, hogy a [[Föderáció|föderációban]] résztvevő entitások biztonságosan tudjanak kommunikálni egymással, szükség van egy metaadat állományra. Ez a metaadat állomány szinte mindig humán felügyelettel jön létre, mivel a szervezetek közötti bizalmi kapcsolat technikai leképzésének ez az elsődleges eleme. (Másodlagos leképzésnek nevezhetjük az attribútum policy IdP és SP oldali megvalósítását.)

== SAML 2.0 metaadatok ==
Pontos szabvány: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

A metadata állomány az alábbi fontosabb információkat tartalmazza
* Érvényesség, aláírás
* [[Föderáció#Szerepek | Identity Providerek]]
* [[Attribute Authority | Attribute authorityk]]
* [[Föderáció#Szerepek | Service Providerek]]
* 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]] egyetlen entitásként kezelhető.

<source lang="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>

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

==== Egy SP-hez tartozó metadata ====
<source lang="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>
</source>

== 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, <code>Scope</code> 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 <code>eduPersonPrincipalName</code> 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. <code>bajnokk</code>)
* az intézmény azonosítójából, a scope-ból (pl. <code>niif.hu</code>)

Ha a metadatában használjuk a <code>Scope</code> 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 <code>eduPersonScopedAffiliation</code>.
=== Metadata eszközök ===
* [[Metadatatool]]
* [[Siterefresh]]
=== 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.

{{ATTENTION|Ugyanaz az '''<code>entityId</code>''' (más néven [[providerId]]) nem szerepelhet többször! Az '''<code>entityId</code>'''-knek az összes használt metadata állományra nézve egyedinek kell lennie. }}

=== Metadata állományok frissítése ===
A metadata állományok központi helyről való letöltésére a [[Siterefresh]] és a [[Metadatatool]] eszközök valók.

Az átszerkesztett/új metadata állományt mind az IdP, mind az SP automatikusan beolvassa, újraindítás nem szükséges.

== Nem SAML 2.0 metaadatokat használó alkalmazások ==
=== simpleSAMLphp ===

Az újabb verziók már támogatják az XML formátumú metaadatokat, de az [[SimpleSAMLphp|SSP]] moduljai szeretik még mindig a flatfile formátumot használni. Van egy ''metarefresh'' nevű modul, ami képes webről leszedni a metaadatokat, ellenőrizni az aláírást, és flatfile formátumú metaadatokat generálni. Fontos momentum, hogy figyelembe veszi a ''<RequestedAttribute>'' elementet, ezáltal megoldható az IdP-k attribútum kiadási szabályzatának automatikus frissítése is.

--[[Szerkesztő:Gyufi(AT)sztaki.hu|gyufi]] 2009. július 9., 07:20 (UTC)
{{TODO}}

=== Switch WAYF ===
{{TODO}}

[[Kategória: AAI általános]]
[[Kategória: Csonkok]]

MTA Sztaki IdP

2008-02-25T12:48:57Z

Gyufi(AT)sztaki.hu:

{{FederationMember
|name=MTA SZTAKI
|techContact=Szabó Gyula, sys-admin@sztaki.hu
|numOfUsers=400
|numOfStudents=0
|numOfEmployees=400
|numOfPartners=0
|numOfOther=20
|affiliationUsage=IdP-nk csak munkatársakat azonosít, így minden assertion '''eduPersonAffiliaton''' attribútuma '''employee''' értékkel van kiállítva.

|registrationStudent=Nem alkalmazható
|registrationEmployee=Ú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.

|registrationPartners=A SZTAKI külön IdP-ben tartja nyilván a különböző projektekben résztvevő partnereket (''SZTAKI Partners' IdP''), ez az IdP nem része a [[HREF]] föderációnak.
|removeStudent=Nem alkalmazható
|removeEmployee=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.
|removePartner=HREF föderáció szempontjából érdektelen információ
|logRetention=Havonta
|backend=LDAP
|authType=Apache
|passwordPolicy=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.
|attrOrigin=Ú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.
|availability=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.
}}

MTA Sztaki IdP

2008-02-21T12:51:54Z

Gyufi(AT)sztaki.hu:

{{FederationMember
|name=MTA SZTAKI
|techContact=Szabó Gyula, sys-admin@sztaki.hu
|numOfUsers=400
|numOfStudents=0
|numOfEmployees=400
|numOfPartners=0
|numOfOther=20
|affiliationUsage=

|registrationStudent=Nem alkalmazható
|registrationEmployee=Ú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.

|registrationPartners=A SZTAKI külön IdP-ben tartja nyilván a különböző projektekben résztvevő partnereket (''SZTAKI Partners' IdP''), ez az IdP nem része a [[HREF]] föderációnak.
|removeStudent=Nem alkalmazható
|removeEmployee=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.
|removePartner=HREF föderáció szempontjából érdektelen információ
|logRetention=Havonta
|backend=LDAP
|authType=Apache
|passwordPolicy=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.
|attrOrigin=Ú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.
|availability=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.
}}

Sablonvita:FederationMember

2008-02-12T19:35:42Z

Gyufi(AT)sztaki.hu:

Szerintünk mi hiányzik:

'''Technikai kapcsolattartó:''' név, email cím, aki az IdP működéséért felel

'''Rendelkezésreállás:''' (kiépítés és vállalt rendelkezésreállás)

'''Adattartalomért felelős kapcsolattartók adattípusok szerint:''' név, email cím, aki az adatok tartalmáért felel (HR, rendszergazdák, személy)

Ezt az utolsót nem tudjuk, hogyan kellene megoldani, egy kivonatot és egy URL-t a sablonba? A lényeg, hogy ha valaki kíváncsi arra, hogy az SP-nek átadott adat, - pl. telefonszám - hibás, akkor azért az adattartalomért ki a felelős. --[[User:Gyufi@sztaki.hu|Gyufi@sztaki.hu]] 2008. február 12., 14:22 (CET)
: Azt hiszem, túl bonyolult lenne az egyes adattartalmak felelőseinek elérhetőségeit kilistázni. Többet ér, ha az egyes attribútumok forrása, ill. a módosításra jogosultak fel vannak tüntetve. --[[User:Bajnokk@niif.hu|Bajnokk@niif.hu]] 2008. február 12., 16:34 (CET)

'''logo''', csak hogy pofás legyen a sablon. Van minden intézménynek logója, ezzel talán nem lehet baj.

--[[User:Gyufi@sztaki.hu|gyufi]] 2008. február 12., 20:35 (CET)

Sablonvita:FederationMember

2008-02-12T19:35:25Z

Gyufi(AT)sztaki.hu:

Szerintünk mi hiányzik:

'''Technikai kapcsolattartó:''' név, email cím, aki az IdP működéséért felel

'''Rendelkezésreállás:''' (kiépítés és vállalt rendelkezésreállás)

'''Adattartalomért felelős kapcsolattartók adattípusok szerint:''' név, email cím, aki az adatok tartalmáért felel (HR, rendszergazdák, személy)

Ezt az utolsót nem tudjuk, hogyan kellene megoldani, egy kivonatot és egy URL-t a sablonba? A lényeg, hogy ha valaki kíváncsi arra, hogy az SP-nek átadott adat, - pl. telefonszám - hibás, akkor azért az adattartalomért ki a felelős. --[[User:Gyufi@sztaki.hu|Gyufi@sztaki.hu]] 2008. február 12., 14:22 (CET)
: Azt hiszem, túl bonyolult lenne az egyes adattartalmak felelőseinek elérhetőségeit kilistázni. Többet ér, ha az egyes attribútumok forrása, ill. a módosításra jogosultak fel vannak tüntetve. --[[User:Bajnokk@niif.hu|Bajnokk@niif.hu]] 2008. február 12., 16:34 (CET)

'''logo'', csak hogy pofás legyen a sablon. Van minden intézménynek logója, ezzel talán nem lehet baj.

--[[User:Gyufi@sztaki.hu|gyufi]] 2008. február 12., 20:35 (CET)

Sablonvita:FederationMember

2008-02-12T13:22:12Z

Gyufi(AT)sztaki.hu: Új oldal, tartalma: „Szerintünk mi hiányzik: '''Technikai kapcsolattartó:''' név, email cím, aki az IdP működéséért felel '''Rendelkezésreállás:''' (kiépítés és vállalt ren...”