547
szerkesztés
Módosítások
Új oldal, tartalma: „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 üzem…”
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.
==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===
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.
==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://examplefederation.org/DS">
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]] 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.xrt"/>
* 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
ShibUserHeaders On
ShibRequireSession On
</Location>
==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===
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.
==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://examplefederation.org/DS">
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]] 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.xrt"/>
* 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
ShibUserHeaders On
ShibRequireSession On
</Location>
