2017-11-15T21:11:52Z

Bajnokk(AT)niif.hu: létrehozás

'''config/config.php''':

<source lang="php">
'metadata.sources' => array(
array('type' => 'flatfile'),
array('type' => 'flatfile','directory' => 'metadata/metarefresh'),
array('type' => 'mdx', 'server' => 'https://mdx.eduid.hu', 'cachedir' => '/var/simplesamlphp/mdx-cache', 'cachelength' => 7200),
),
</source>

'''config/config-metarefresh''':

<source lang="php">
<?php

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

'''config/module_cron.php''':
<source lang="php">
<?php
/*
* Configuration for the Cron module.
*/

$config = array (

'key' => 'eztajelszotcsereldle',
'allowed_tags' => array('daily', 'hourly', 'frequent'),
'debug_message' => TRUE,
'sendemail' => FALSE,

);
</source>

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

Szerkesztő:Bajnokk(AT)niif.hu

2017-11-15T21:01:11Z

Bajnokk(AT)niif.hu:

MDX

2017-11-15T20:54:48Z

Bajnokk(AT)niif.hu: /* SimpleSAMLphp */

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). Az MDX kiszolgáló az alábbi szabvány szerint tudja visszaadni egy-egy entitás metaadatát: <code>http://mdx.eduid.hu/entities/{urlencoded}$entityID</code>, pl: <code>http://mdx.eduid.hu/entities/https%3A%2F%2Fdev.aai.niif.hu%2Fshibboleth</code>

== Dinamikus metadata kiszolgálás a HREF-ben ==
Az MDX kiszolgáló a '''http://mdx.eduid.hu''' alatt szolgáltat, és a ''href'' és az ''edugain'' metadata halmazokat tartalmazza.

Mindkét kiszolgáló ugyanazzal a kulccsal írja alá a lekért metaadat-állományt.
* A tanúsítvány letölthető innen: http://metadata.eduid.hu/current/mdx-test-signer-2015.crt
* 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> .

=== Fontos tudnivaló Discovery Service használattal kapcsolatban ===
Lévén az MDX-et használó SP-knél nem áll rendelkezésre folyamatosan az összes potenciális IdP listája, így a beépített Discovery Service-ek nem működnek. Ha MDX-et használunk, akkor valamilyen külső Discvery Service-t kell használnunk. A HREF-ben a https://discovery.eduid.hu a központi Discovery Service.

Emellett maga az MDX kiszolgáló is biztosít Discovery Service felületet, ehhez akár Shibboleth SP-nél, akár simpleSAMLphp SP-nél a konfigurációban az alábbi URL-t kell megadni, mint Discovery Service: https://mdx.eduid.hu/role/idp.ds . Ez a Discovery Service tartalmazza a hazai eduID-ben, valamint az eduGAIN-ben levő összes IdP-t. (És, ellentétben a hagyományos https://discovery.eduid.hu/edugain szolgáltatással, ez tartlamazza a magyar VHO-t is VHO IdP néven.)

== MDX használata kliens oldalon ==
=== SimpleSAMLphp ===

Az 1.14-es kiadástól kezdve a SimpleSAMLphp tartalmazza az dinamikus metadata lekérdezés funkciót, amely mind IdP, mind SP szerepben egységes módon használható. A config/config.php állományban metadata.sources szekcióban kell elhelyezni az alábbi blokkot:

<source lang="php">
'metadata.sources' => array(
array(
'type' => 'mdx',
'server' => 'http://mdx.eduid.hu',
'cachedir' => '/var/simplesamlphp/mdx-cache', //opcionális, de ajánlott
'cachelength' => 86400, //opcionális,
'validateFingerprint' => '91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43' //opcionális
)
),
</source>

=== Shibboleth SP ===

* Le kell tölteni a /etc/shibboleth alá az aláíró tanúsítványát innen: http://metadata.eduid.hu/current/mdx-test-signer-2015.crt
* Az alábbi blokkot be kell szúrni a <code>/etc/shibboleth/shibboleth2.xml</code> fájlba

<source lang="xml">
<MetadataProvider type="Dynamic" ignoreTransport="true">
<Subst>http://mdx.eduid.hu/entities/$entityID</Subst>
<MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
</MetadataProvider>
</source>

=== Shibboleth IdPv3 ===

* Le kell tölteni a <code>${idp.home}/credentials/</code> alá az aláíró tanúsítványát innen: http://metadata.eduid.hu/current/mdx-test-signer-2015.crt
* A <code>conf/metadata-providers.xml</code> fájlt kell szerkeszteni az alábbi módon:
<source lang="xml">

<MetadataProvider
xmlns="urn:mace:shibboleth:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd"
id="dynamicMDQ" xsi:type="DynamicHTTPMetadataProvider">


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


<MetadataFilter xsi:type="SignatureValidation" requireSignedMetadata="true"
certificateFile="${idp.home}/credentials/mdx-signer.crt" />


<MetadataQueryProtocol>http://mdx.eduid.hu/</MetadataQueryProtocol>
</MetadataProvider>

</source>

MDX

2017-11-15T20:50:38Z

Bajnokk(AT)niif.hu: /* MDX kiszolgálás a HREF-ben */

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). Az MDX kiszolgáló az alábbi szabvány szerint tudja visszaadni egy-egy entitás metaadatát: <code>http://mdx.eduid.hu/entities/{urlencoded}$entityID</code>, pl: <code>http://mdx.eduid.hu/entities/https%3A%2F%2Fdev.aai.niif.hu%2Fshibboleth</code>

== Dinamikus metadata kiszolgálás a HREF-ben ==
Az MDX kiszolgáló a '''http://mdx.eduid.hu''' alatt szolgáltat, és a ''href'' és az ''edugain'' metadata halmazokat tartalmazza.

Mindkét kiszolgáló ugyanazzal a kulccsal írja alá a lekért metaadat-állományt.
* A tanúsítvány letölthető innen: http://metadata.eduid.hu/current/mdx-test-signer-2015.crt
* 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> .

=== Fontos tudnivaló Discovery Service használattal kapcsolatban ===
Lévén az MDX-et használó SP-knél nem áll rendelkezésre folyamatosan az összes potenciális IdP listája, így a beépített Discovery Service-ek nem működnek. Ha MDX-et használunk, akkor valamilyen külső Discvery Service-t kell használnunk. A HREF-ben a https://discovery.eduid.hu a központi Discovery Service.

Emellett maga az MDX kiszolgáló is biztosít Discovery Service felületet, ehhez akár Shibboleth SP-nél, akár simpleSAMLphp SP-nél a konfigurációban az alábbi URL-t kell megadni, mint Discovery Service: https://mdx.eduid.hu/role/idp.ds . Ez a Discovery Service tartalmazza a hazai eduID-ben, valamint az eduGAIN-ben levő összes IdP-t. (És, ellentétben a hagyományos https://discovery.eduid.hu/edugain szolgáltatással, ez tartlamazza a magyar VHO-t is VHO IdP néven.)

== MDX használata kliens oldalon ==
=== SimpleSAMLphp ===

Az 1.14-es kiadású SimpleSAMLphp-ban lesz benne, mint kiadásban, de a legfrissebb, githubról letölthető változatban már benne van. Ezt kell használnunk, ha szeretnénk, hogy az üzemeltetett SimpleSAMLphp-nk MDX-es metadataforrásból dolgozzon.config/config.php metadatás részében kell elvégezni a beállításokat az alábbi módon:

<source lang="php">
'metadata.sources' => array(
array(
'type' => 'mdx',
'server' => 'http://mdx.eduid.hu',
'cachedir' => '/var/simplesamlphp/mdx-cache', //opcionális, de ajánlott
'cachelength' => 86400, //opcionális,
'validateFingerprint' => '91:81:AD:2B:F1:C1:4E:47:93:A2:9D:49:34:B7:77:62:4F:2F:98:43' //opcionális
)
),
</source>

=== Shibboleth SP ===

* Le kell tölteni a /etc/shibboleth alá az aláíró tanúsítványát innen: http://metadata.eduid.hu/current/mdx-test-signer-2015.crt
* Az alábbi blokkot be kell szúrni a <code>/etc/shibboleth/shibboleth2.xml</code> fájlba

<source lang="xml">
<MetadataProvider type="Dynamic" ignoreTransport="true">
<Subst>http://mdx.eduid.hu/entities/$entityID</Subst>
<MetadataFilter type="Signature" certificate="mdx-test-signer-2015.crt"/>
</MetadataProvider>
</source>

=== Shibboleth IdPv3 ===

* Le kell tölteni a <code>${idp.home}/credentials/</code> alá az aláíró tanúsítványát innen: http://metadata.eduid.hu/current/mdx-test-signer-2015.crt
* A <code>conf/metadata-providers.xml</code> fájlt kell szerkeszteni az alábbi módon:
<source lang="xml">

<MetadataProvider
xmlns="urn:mace:shibboleth:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd"
id="dynamicMDQ" xsi:type="DynamicHTTPMetadataProvider">


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


<MetadataFilter xsi:type="SignatureValidation" requireSignedMetadata="true"
certificateFile="${idp.home}/credentials/mdx-signer.crt" />


<MetadataQueryProtocol>http://mdx.eduid.hu/</MetadataQueryProtocol>
</MetadataProvider>

</source>

JoiningEduGAIN

2017-10-30T13:35:52Z

Bajnokk(AT)niif.hu: /* SP csatlakozása az eduGAIN-hez */ a csatlakozás self-service

== Metaadatok ==
Az eduGAIN csatlakozáshoz a csatlakozó entitásnak - akár IdP, akár SP - ismernie kell az eduGAIN-ben résztvevő többi entitást. Ezt vagy a hagyományos módszerrel, az eduGAIN aláírt metaadatainak betöltésével lehet elérni, vagy az igény szerinti metaadat-kiszolgáló (MDX) használatával.
=== Hagyományos XML állomány ===
Töltse be és rendszeresen frissítse az általunk aláírt eduGAIN metadatát: http://metadata.eduid.hu/current/edugain.xml. Az aláírókulcs megegyezik a többi metadata setet aláíró kulccsal (https://metadata.eduid.hu/href-metadata-signer-2011.crt). Félreértések elkerülése végett a magyar entitások az újra aláírt eduGAIN metaadatok között nem szerepelnek, hogy ne legyen duplikáció.

Ennél a módszernél fel kell készülni arra, hogy a metaadat-frissítés hosszadalmas, több percet igénylő folyamat lehet. Néhány jellemző probléma:
* Shibboleth SP el- vagy újraindításakor több percen keresztül <code>ListenerException</code> hiba jelentkezik.
* SimpleSAMLphp esetén a ''metarefresh'' kifut a rendelkezésre álló memóriából, vagy tovább fut, mint a <code>max_execution_timeout</code> vagy a webszerver beállításai ezt lehetővé tennék.
=== Igény szerinti metaadat kiszolgálás ===
Ebben az esetben a metaadatokat csak akkor töltjük le, ha éppen szükség van rájuk. Részletes leírás itt: [[MDX]].

Ennek a módszernek előnye, hogy sokkal kevesebb erőforrást igényel a szerveren. Az alapértelmezés szerinti gyorstárazási idő is jóval rövidebb, mint a hagyományos esetben, így a változások valamivel hamarabb érvényre jutnak.
=== Egyidejű használat ===
Mind a Shibboleth, mind a SimpleSAMLphp lehetővé teszi, hogy a hagyományos fájl-alapú és az MDX alapú metaadat forrásokat egyidőben használjuk. Például:
* helyi statikus metaadat-állományokat használunk,
* a magyar entitásokat hagyományos módon, az eduGAIN-es entitásokat MDX-szel akarjuk letölteni.

Ilyen esetben az MDX metaadat-forrást célszerű utolsó helyre tenni a sorban. Ekkor az metaadat-kérés csak akkor hajtódik végre, ha az entitás egyik statikus forrásban sem található meg.

== IdP csatlakozása az eduGAIN-hez ==
Az IdP-nek értelmeznie kell SP-k attribútum-igényeit. Erre '''erősen ajánlott''' az EntityCategory alapú attribútum kiadást használni, kiegészítve a metadata-alapú (RequestedAttributes) attribútum kiadási mechanizmussal.
* ''SimpleSAMLphp'': a javasolt megoldásról [[SSP_EntityCategories| bővebben erre]].
* ''Shibboleth'': natívan ismeri mindkét attribútumkiadási mechanizmust:
** https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeInMetadata
** https://wiki.shibboleth.net/confluence/display/IDP30/EntityAttributeExactMatchConfiguration

A metaadatok, illetve az attribútum-kiadás megfelelő konfigurációja '''után''' az IdP csatlakozását az IdP technikai kapcsolattartója kezdeményezi a föderációs adminfelületen (https://rr.eduid.hu), ügyelve arra, hogy az entitáshoz beállított logó is https-en keresztüli url-en legyen elérhető, ill. rögzítésre kerüljenek a különböző leíró dokumentumok angol nyelvű változataira mutató url-ek is.

== SP csatlakozása az eduGAIN-hez ==
A metaadatok megfelelő konfigurációja '''után''' az SP adminisztrátora a Resource Registry-ben állíthatja be, hogy az SP az eduGAIN-ben publikálásra kerüljön.

A Discovery felület integrációjával kapcsolatban lásd az [[MDX# Fontos tudnivaló Discovery Service használattal kapcsolatban | MDX leírás vonatkozó részét]]!
=== Entitás kategóriák ===
Amennyiben nemzetközi együttműködésben vesz részt az SP, az entitás kategóriák használatával megkönnyíthetjük, hogy az IdP-k az igényelt attribútumokat kiadják.

Az entitás kategóriák beállítását az SP kapcsolattartója az info@eduid.hu címen kezdeményezheti.
==== Research & Scholarship ====
Amennyiben a szolgáltatás a kutatást vagy az oktatást támogatja, beállítható a ''Research & Scholarship'' entitás kategória. Részletes szabályok: https://refeds.org/category/research-and-scholarship

==== GÉANT Data Protection Code of Conduct ====
Az entitás kategória részletes szabályai itt találhatóak: https://wiki.edugain.org/Recipe_for_a_Service_Provider . Fontos kiemelni, hogy ez a kategória az entitás metaadatainak részletes kitöltését (https://rr.eduid.hu) igényli, valamint egy olyan angol nyelvű adatvédelmi szabályzat meglétét, amely hivatkozik a http://www.geant.net/uri/dataprotection-code-of-conduct/v1 dokumentumra.

[[Category: AAI]]
[[Category: EduGAIN]]
[[Category: HOWTO]]

Scope

2017-10-18T15:15:34Z

Bajnokk(AT)niif.hu: pontosítás

A scope egy intézményhez tartozó '''DNS domain''', amely az intézmény birtokában van vagy rendelkezésére áll. Javasolt, de nem kötelező a scope értékét ténylegesen is a DNS-be bejegyezni.
: <small>Azaz használható a ''hallgato.intezmeny.hu'' scope-ként akkor is, ha ez a név nem feloldható a DNS-ből, feltéve, hogy az ''intezmeny.hu'' létezik és az intézményhez tartozik.</small>

A [[HREFGlossary#HREF Föderáció|HREF Föderációhoz]] történő csatlakozáskor a csatlakozó [[HREFGlossary#Azonosító Szervezet|Azonosító Szervezetnek]] kötelező megadnia legalább egy scope-ot.

A megadott scope-ok megjelennek a [[HREFMetadataSpec|metadatában]], ez alapján az SP-k ellenőrizhetik, hogy az IdP jogosult-e bizonyos attribútum-értékeket kiadni. Az [[HREFAttributeSpec|attribútum specifikáció]] az alábbi scope-ot használó attribútumokat használja:
* [[HREFAttributeSpec#eduPersonPrincipalName|eduPersonPrincipalName]]
* [[HREFAttributeSpec#eduPersonScopedAffiliation|eduPersonScopedAffiliation]]
----
Célszerű, hogy a felhasználókhoz tartozó scope lehetőleg ne változzon meg. Amennyiben mégis meg kellene változtatni, [[Intézmény átnevezés|itt találhatók hasznos információk a domain név változtatásával kapcsolatban]].

Vita:AAIGettingStarted

2017-10-11T07:26:04Z

Bajnokk(AT)niif.hu: elavult információk mozgatása a Vitalapra

# Először az szükséges, hogy nagyjából megértsd, miért használunk '''Autentikációs és Autorizációs Infrastruktúrákat''', egyátalán, mit is jelent ez a manapság divatos fogalom. Jelenleg a bevezető jellegű [[Publikációk | publikációkból]] lehet talán legjobban megérteni ezt. Nagyon fontos tisztában lenni azzal, hogy mit jelent a [[Föderáció]] fogalma.
# Ezek után jó, ha tisztában vagy a [[Shibboleth]] szoftverben használt eljárásokkal (profile-okkal). <small>(Sajnos, amíg a [[Shibboleth]] lap csak csonk, addig leginkább az [[Publikációk | előadásokból]] érdemes tájékozódni.)</small>
# Következő lépésként [[Shibboleth IdP]]-t érdemes telepíteni és konfigurálni. Kipróbálni jelenleg csak a [http://testshib.org Testshib.org] webhellyel lehet automatikusan, de előbb-utóbb lesz ilyen szolgáltatás az NIIF-ben is.
# Ha rákaptál a Single Sign-on "ízére", érdemes nekifogni a [[Shibboleth SP]] telepítésnek is.
# Ha a teszt alkalmazások (mint például a [[Shibenv]]) működnek (és az [[ShibIdPARP | attribútumok átadásával]] sincs probléma, akkor érdemes nekiállni az éles alkalmazások Shibboleth-esítésének.

AAIGettingStarted

2017-10-11T07:25:54Z

Bajnokk(AT)niif.hu: elavult információk mozgatása a Vitalapra

[[Kategória: AAI]]

Intézmény átnevezés

2017-10-09T16:21:07Z

Bajnokk(AT)niif.hu: /* entityID */ Az adatbázis-szolgáltatókat is érinti

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.

További probléma az entityID megváltoztatásával, hogy a kereskedelmi adatbázis-szolgáltatók jellemzően kézzel tartják karban azt a listát, hogy mely intézmények számára elérhető a szolgáltatás, és az entityID változtatása miatt az intézményünk kikerülhet ezekből a listákból.

=== [[Scope]] ===
Az eduPersonPrincipalName és az eduPersonScopedAffiliation használja a [[Scope|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]]

AA Testing

2017-09-15T19:36:55Z

Bajnokk(AT)niif.hu: /* Source */ Add argument for AA cert, remove redundancy

The following shell script uses ''curl'' to query a SAML2 Attribute Authority.

You need a valid principal (eduPersonPrincipalName) and the X.509 credentials of an existing Service Provider to use this script.

== Source ==

<source lang="bash">

#!/bin/bash

basedir=$(dirname $0)

# URL of the Attribute Authority
AA_URI="https://hexaa.eduid.hu:8443/simplesaml/module.php/aa/attributeserver.php"

# Testing principal (subject)
Principal="bajnokk@niif.hu"

# HEXAA cert
AACert="$basedir/keys/hexaa.eduid.hu-aa.crt"

# EntityID and credentials of the SP on behalf of which
# the request is made
ReqSP="https://sp.hexaa.eduid.hu/test"
ReqCert="$basedir/keys/test.sp.hexaa.eduid.hu-fed.crt"
ReqKey="$basedir/keys/test.sp.hexaa.eduid.hu-fed.key"

usage () {
cat <<EOS
Usage: $0 [options]

Options:
-a uri Attribute Authority URI. Defaults to '$AA_URI'
-C certfile Attribute Authority metadata certificate in PEM format. Defaults to '$AACert'.
-p principal Testing principal (user name / subject). Defaults to '$Principal'.
-s entity EntityID of the SP on behalf of which the request is made. Defaults to '$ReqSP'
-k keyfile Key file in PEM format containing the key of the SP used for the request. Defaults to '$ReqKey'
-c certfile Cert file in PEM format containing the certificate of the SP used for the request. Defaults to '$ReqCert'
EOS
exit 3
}

# Get command line arguments
while getopts "a:p:s:k:c:h" opt; do
case $opt in
a)
AA_URI=$OPTARG
;;
C)
AACert=$OPTARG
;;
p)
Principal=$OPTARG
;;
s)
ReqSP=$OPTARG
;;
k)
ReqKey=$OPTARG
;;
c)
ReqCert=$OPTARG
;;
h)
usage
;;
\?)
usage
;;
esac
done

DATE=$(date --utc +%FT%TZ)
ReqID=$(hexdump -n 16 -e '4/4 "%08x" 1 "\n"' /dev/urandom)

read -r -d '' REQ_XML <<EOS
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<samlp:AttributeQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_$ReqID" IssueInstant="$DATE" Version="2.0">
<saml:Issuer>$ReqSP</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">$Principal</saml:NameID>
</saml:Subject>
</samlp:AttributeQuery>
</S:Body>
</S:Envelope>
EOS

#debug echo "$REQ_XML"

echo "$REQ_XML" | \
curl --silent --show-error --cacert $AACert --cert $ReqCert --key $ReqKey \
--header "Content-Type: text/xml;charset=UTF-8" --data @- $AA_URI
</source>

== Validation of response ==
Signature validation:
xmlsec1 --verify --id-attr:ID "urn:oasis:names:tc:SAML:2.0:protocol:Response" --trusted-pem $aacert $response 2>/dev/null

Content validation:
xmllint --xpath "//*[local-name()='Attribute'][@Name='$attribute']/*[local-name()='AttributeValue']/text()" $response
[[Category: HOWTO]]

AA Testing

2017-09-15T18:54:36Z

Bajnokk(AT)niif.hu: validation

The following shell script uses ''curl'' to query a SAML2 Attribute Authority.

You need a valid principal (eduPersonPrincipalName) and the X.509 credentials of an existing Service Provider to use this script.

== Source ==

<source lang="bash">
#!/bin/bash

basedir=$(dirname $0)

# URL of the Attribute Authority
AA_URI="https://hexaa.eduid.hu:8443/simplesaml/module.php/aa/attributeserver.php"

# Testing principal (subject)
Principal="bajnokk@niif.hu"

# HEXAA cert
AACert="$basedir/keys/hexaa.eduid.hu-aa.crt"

# EntityID and credentials of the SP on behalf of which
# the request is made
ReqSP="https://sp.hexaa.eduid.hu/test"
ReqCert="$basedir/keys/test.sp.hexaa.eduid.hu-fed.crt"
ReqKey="$basedir/keys/test.sp.hexaa.eduid.hu-fed.key"

usage () {
cat <<EOS
Usage: $0 [options]

Options:
-a uri Attribute Authority URI. Defaults to 'https://hexaa.eduid.hu:8443/simplesaml/module.php/aa/attributeserver.php'
-p principal Testing principal (user name / subject). Defaults to 'bajnokk@niif.hu'.
-s entity EntityID of the SP on behalf of which the request is made. Defaults to 'https://sp.hexaa.eduid.hu/test'
-k keyfile Key file in PEM format containing the key of the SP used for the request. Defaults to 'keys/test.sp.hexaa.eduid.hu-fed.key'
-c certfile Cert file in PEM format containing the certificate of the SP used for the request. Defaults to 'keys/test.sp.hexaa.eduid.hu-fed.crt'
EOS
exit 3
}

# Get command line arguments
while getopts "a:p:s:k:c:h" opt; do
case $opt in
a)
AA_URI=$OPTARG
;;
p)
Principal=$OPTARG
;;
s)
ReqSP=$OPTARG
;;
k)
ReqKey=$OPTARG
;;
c)
ReqCert=$OPTARG
;;
h)
usage
;;
\?)
usage
;;
esac
done

DATE=$(date --utc +%FT%TZ)
ReqID=$(hexdump -n 16 -e '4/4 "%08x" 1 "\n"' /dev/urandom)

read -r -d '' REQ_XML <<EOS
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<samlp:AttributeQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_$ReqID" IssueInstant="$DATE" Version="2.0">
<saml:Issuer>$ReqSP</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">$Principal</saml:NameID>
</saml:Subject>
</samlp:AttributeQuery>
</S:Body>
</S:Envelope>
EOS

#debug echo "$REQ_XML"

echo "$REQ_XML" | \
curl --silent --show-error --cacert $AACert --cert $ReqCert --key $ReqKey \
--header "Content-Type: text/xml;charset=UTF-8" --data @- $AA_URI

</source>

== Validation of response ==
Signature validation:
xmlsec1 --verify --id-attr:ID "urn:oasis:names:tc:SAML:2.0:protocol:Response" --trusted-pem $aacert $response 2>/dev/null

Content validation:
xmllint --xpath "//*[local-name()='Attribute'][@Name='$attribute']/*[local-name()='AttributeValue']/text()" $response
[[Category: HOWTO]]

AA Testing

2017-09-15T18:47:38Z

Bajnokk(AT)niif.hu: getopt version of the script

The following shell script uses ''curl'' to query a SAML2 Attribute Authority.

You need a valid principal (eduPersonPrincipalName) and the X.509 credentials of an existing Service Provider to use this script.

----

<source lang="bash">
#!/bin/bash

basedir=$(dirname $0)

# URL of the Attribute Authority
AA_URI="https://hexaa.eduid.hu:8443/simplesaml/module.php/aa/attributeserver.php"

# Testing principal (subject)
Principal="bajnokk@niif.hu"

# HEXAA cert
AACert="$basedir/keys/hexaa.eduid.hu-aa.crt"

# EntityID and credentials of the SP on behalf of which
# the request is made
ReqSP="https://sp.hexaa.eduid.hu/test"
ReqCert="$basedir/keys/test.sp.hexaa.eduid.hu-fed.crt"
ReqKey="$basedir/keys/test.sp.hexaa.eduid.hu-fed.key"

usage () {
cat <<EOS
Usage: $0 [options]

Options:
-a uri Attribute Authority URI. Defaults to 'https://hexaa.eduid.hu:8443/simplesaml/module.php/aa/attributeserver.php'
-p principal Testing principal (user name / subject). Defaults to 'bajnokk@niif.hu'.
-s entity EntityID of the SP on behalf of which the request is made. Defaults to 'https://sp.hexaa.eduid.hu/test'
-k keyfile Key file in PEM format containing the key of the SP used for the request. Defaults to 'keys/test.sp.hexaa.eduid.hu-fed.key'
-c certfile Cert file in PEM format containing the certificate of the SP used for the request. Defaults to 'keys/test.sp.hexaa.eduid.hu-fed.crt'
EOS
exit 3
}

# Get command line arguments
while getopts "a:p:s:k:c:h" opt; do
case $opt in
a)
AA_URI=$OPTARG
;;
p)
Principal=$OPTARG
;;
s)
ReqSP=$OPTARG
;;
k)
ReqKey=$OPTARG
;;
c)
ReqCert=$OPTARG
;;
h)
usage
;;
\?)
usage
;;
esac
done

DATE=$(date --utc +%FT%TZ)
ReqID=$(hexdump -n 16 -e '4/4 "%08x" 1 "\n"' /dev/urandom)

read -r -d '' REQ_XML <<EOS
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<samlp:AttributeQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_$ReqID" IssueInstant="$DATE" Version="2.0">
<saml:Issuer>$ReqSP</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">$Principal</saml:NameID>
</saml:Subject>
</samlp:AttributeQuery>
</S:Body>
</S:Envelope>
EOS

#debug echo "$REQ_XML"

echo "$REQ_XML" | \
curl --silent --show-error --cacert $AACert --cert $ReqCert --key $ReqKey \
--header "Content-Type: text/xml;charset=UTF-8" --data @- $AA_URI

</source>
[[Category: HOWTO]]

TCS ServerCert

2017-09-13T11:13:34Z

Bajnokk(AT)niif.hu: /* Self-signed */ 2-pass variant to avoid CA:TRUE

== Usage ==
With this script, you can generate a certificate request that you can submit manually to Terena TCS service. It's possible to include multiple SubjectAltName -s in the request, such as <code>aai.niif.hu</code> and <code>www.aai.niif.hu</code>.

This script creates the following files in your current working directory:
* <code>hostname.you.provided.first.org.key</code> (private key)
* <code>hostname.you.provided.first.org.csr</code> (certificate request)

== Program code ==
<source lang="perl">
#!/usr/bin/perl -w

print "Please enter the fqdn's of the hosts one at a line\n";
print "Press Ctrl-D when done or Ctrl-C to cancel\n";

my $h;
my @hosts;

while ($h=<STDIN>) {
chomp ($h);
#XXX sanity check
push @hosts,$h;
}

my $tmpfile=`mktemp`;
chomp $tmpfile;

my $defaulthost=$hosts[0];
my @opensslReqCmd=("openssl","req","-new","-nodes","-config","$tmpfile","-out","$defaulthost.csr");

#for re-key, you'd use:
#if (-r "$defaulthost.key") {
#push @opensslReqCmd,("-key","$defaulthost.key");
#}

my @opensslVerifyCmd=("openssl","req","-text","-in","$defaulthost.csr");

&mkConfig($tmpfile,@hosts);

umask 0077;
system @opensslReqCmd;
system @opensslVerifyCmd;

unlink $tmpfile;

sub mkConfig(@) {
my $out=shift;
my @hosts=@_;
my $defaulthost=$hosts[0];

open (CONF,">$out") or die "$!";

print CONF <<EOS;
[ req ]
default_bits = 2048
default_keyfile = $defaulthost.key
default_days = 1095 # 3x365 days
default_md = sha256
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[ req_distinguished_name ]
CN = $defaulthost

[ v3_req ]
subjectAltName = \@alt_names

[alt_names]
EOS

for (my $i=1; $i<=$#hosts+1; $i++) {
print CONF "DNS." . $i . " = " . $hosts[$i-1] . "\n";
}
close CONF;
}

</source>

== Apache config ==
This is how you can instruct Apache to use the new cert
SSLCertificateFile /path/to/your/pki/hostname.you.provided.first.crt
SSLCertificateKeyFile /path/to/your/pki/hostname.you.provided.first.key
SSLCertificateChainFile /path/to/your/pki/hostname.you.provided.first-chain.crt

== Self-signed ==
It's not recommended to use CA-signed certificates with your IdPs or SPs. It has no benefits and has some drawbacks (ie. some older versions of mod_ssl refuse to work with expired SP certs).

Instead, you should generate a self-signed certificate with the following commands (please adjust the subject):
export host=your.host.name
openssl req -new -newkey rsa:2048 -subj "/C=HU/O=NIIF/OU=AAI/CN=$host" -days 10000 -nodes \
-keyout $host-fed.key -out $host-fed.csr
openssl x509 -in $host-fed.csr -out $host-fed.crt -req -signkey $host-fed.key

[[Category: TCS]]
[[Category: English]]

AAI

2017-09-12T14:25:45Z

Bajnokk(AT)niif.hu: /* Kiegészítő tudnivalók */

=== Meghatározások ===

* [[Föderáció]]
* [[Pont-pont bizalmi kapcsolati modell]]
* [[Metadata]]
* [[Föderációs modellek]]
* [[WAYF | Home Location Service]]
* [[Shibboleth]]
* [[AAIGettingStarted | Hogy kezdjem?]]

===Föderációs alapinfrastruktúrák (IdP-k, SP-k)===
Tapasztalatok alapján IdP esetén egyszerűsége miatt talán jobb választás a simpleSAMLphp, SP esetén Shibboleth ill. simpleSAMLphp egyaránt megfelelő választás /etc/ssl/certs/adminmail.sulinet.hu.crtmind beállítási, mind üzemeltetési szempontból.
* Shibboleth IdP: [[Shib3IdpInstall|Telepítés, beállítás]], [[Shibboleth3 IdP|Egyéb leírások]], [[Shibboleth2 IdP|Shibboleth 2 IdP leírások]]
* Shibboleth SP: [[ShibSP_QuickStart|Kezdőlépések]], [[Shibboleth2 SP|Egyéb leírások]]
* simpleSAMLphp IdP és SP: [[SSP_QuickStart|Kezdőlépések]]
* [[IdP_whichone|Melyik IdP-t válasszam?]]
* Ha nem értek hozzá, jó választás lehet a [https://samlidp.io samlidp.io - SAML Identity Provider as a Service]

===HREF/eduID föderációhoz kapcsolódó tudnivalók===
* [[HREFContract]]: A föderációhoz kapcsolódó dokumentációk gyűjtőlapja
* [[HREFAttributeSpec]]: A föderációban használható attribútumok specifikációja
* [[HREFMetadataSpec]]: A föderációban használt metadata specifikációja
* [[Resource_Registry]]: A föderáció adminisztrációs felületének leírása
* [[JoiningEduGAIN]]: Tudnivalók az eduGAIN csatlakozással kapcsolatban
* [[MDX]]: Igény szerinti metaadat-kiszolgálás

===További föderációs megoldások===
* [[Shibboleth2 DiscoveryService]]: Shibboleth 2.0 SAML-kompatibilis Discovery Service
* [[OpenSSO]]: Nehézsúlyú Java hozzáférés-szabályozást és federációt megvalósító rendszer
* [[OpenID]]: Széles körben támogatott, de nem SAML-alapú federációt megvalósító rendszer
* [[GoogleAuth]]: Google, mint [[OpenID]] szabványú IdP
* [[mod_mellon]]: SP megoldás apache modulban. A SAML2 motort a [http://lasso.entrouvert.org Lasso] valósítja meg. [http://docs.feide.no/fs-0050]
* [[oiosaml.java]]: Java SP megoldás, amit a Dán állam is használ. [http://www.softwareborsen.dk/projekter/softwarecenter/brugerstyring/oio-saml-java]
* [[UApprove]]: Shibboleth 2.1.x IdP-hez illeszthető "consent-modul" beállításának leírása
* [[Shibboleth troubleshooting]]: Shibboleth hibaelhárítás

===Kiegészítő tudnivalók===
* [[Alkalmazások illesztése]]: Néhány alkalmazás Shibboleth-illesztésének leírása
* [[Interoperabilitás mátrix]]: Shibboleth, OpenSSO, simpleSAMLphp együttműködési mátrix
* [[Eszközök]]: Hasznos eszközök föderációk üzemeltetéséhez, használatához
* [[Intézmény átnevezés]]: megfontolandó szempontok
* [[FedCerts | Tanúsítványok a föderációban]]
* [[HEXAATest | Test HEXAA (or any SAML AA) from command line]]
* [[EduIDTest | Hogyan teszteljünk eduID IdP-t vagy SP-t?]]
* [[Publikációk]]

[[Kategória: Összefoglaló lapok]]