Egyéb

Auto-generated book for Egyéb

NeptunLdapSyncImpl

Áttekintés

A Neptun - LDAP szinkronizáció egy lehetséges implementációja az NIIF Intézet által fejlesztett PHP szkript. Ezen szkript a - lehetőségekhez képest - kellően általánosan kezeli az intézményi szinkronizációs igényeket, ezért önmagában, intézményi testreszabás nélkül, nem használható.

A szkript fejlesztés alatt levő verziója elérhető a GIT Repositoryból. A forráskód tartalmazza a keretrendszert, illetve intézményi példakódokat, melyek a BME által felvetett szinkronizációs igények alapján készültek el.

!!! danger "Figyelem"

Ez a szkript jelenleg is fejlesztés alatt áll, a felhasználása során előkerülő hibákért, esetleges adatvesztésért az NIIF Intézet semmilyen felelősséget nem vállal.

Követelmények

A szkript futtatásának követelményei:

Alapvető célok

A fejlesztés során elsősorban a következő kritériumokat tartottuk szem előtt:

Nem célunk az összes intézmény összes egyedi igényét figyelembe venni, viszont ezen intézményi fejlesztéseknek helyet biztosítunk a központi forrásfában, így az intézmények egymás implementációit - szükség esetén - átvehetik.

Részletes(ebb) leírás

A szinkronizáció művelete alapvetően két különböző szintre bomlik:

A keretrendszer mindkét fenti réteghez biztosít ősosztályokat, azonban az implementáció az intézményi réteghez tartozik. Általános esetben minden webszolgáltatás operációhoz külön szinkronizációs metódus tartozik, azonban az implementáció nagy része közös, ezt a keretrendszer képes elfedni (a SyncManager ősosztályban).

LDAP bejegyzések leképezése

A szinkronizációs keretrendszer egy LDAP bejegyzéshez egy ún. Entry objektumot rendel, melynek mezői az LDAP attribútumokkal közeli rokonságot mutatnak.

Minden szinkronizációs metódus eredménye egy (vagy jópár) XML struktúra, melyek általában egy LDAP bejegyzéshez tartoznak. Például a személyes adatokat szolgáltató operáció válaszában jól elkülöníthetőek az egyes felhasználókhoz tartozó adatok.

A szinkronizációt nagyban egyszerűsíti ez a feltevés, így az egyes LDAP bejegyzéseket elég ezekkel az XML struktúrákkal szinkronizálni, egy leképezést kell tehát biztosítani az LDAP attribútumok és az XML struktúra között.

Tegyük fel, hogy van egy XML struktúránk, amit szeretnénk egy LDAP bejegyzésre leképezni:

 <Szemely>
  <Kod>XYZ123</Kod> <!-- pl. NEPTUN-kód -->
  <Vezeteknev>Gipsz</Vezeteknev>
  <Keresztnev>Natália</Keresztnev>
  <Email>gipsz@somewhere</Email>
  <Email>gipsz.nati@somewhere</Email>
  <Lakcim>
   <Irsz>0000</Irsz>
   <Varos>Pest-Buda</Varos>
   <Cim>Alma tér 2</Cim>
  </Lakcim>
  <Telefon>+36-1 123-1234</Telefon>
  <!-- tovabbi elemek -->
 </Szemely>

Az ehhez tartozó LDAP bejegyzés pedig legyen a következő:

dn: niifPersonOrgId=XYZ123,ou=people,o=BME,c=hu
objectClass: niifPerson
objectClass: person
niifPersonOrgId: XYZ123
givenName: Natália
givenName;en: Natalia
sn: Gipsz
sn;en: Gipsz
cn: Gipsz Natália
cn;en: Natalia Gipsz
mail: gipsz@somewhere
mail: gipsz.nati@somewhere
postalAddress: 0000 Pest-Buda, Alma tér 2
telephoneNumber: +3611231234

Az XML->LDAP leképezésnek tehát a következőket kell megoldania:

A leképező objektum életciklusa

LDAP leképező objektum életciklusa

LDAP-ban létező bejegyzés esetén a következőképp alakul a leképező objektum életciklusa:

  1. azon mezők betöltése, melyek az LDAP bejegyzés kereséséhez szükségesek
  2. LDAP keresés végrehajtása
  3. LDAP-ból az attribútumok betöltése az objektum megfelelő mezőibe
  4. életciklus metódus meghívása (pl. generált mezők számítása)
  5. az XML-ből a mezők frissítése
  6. életciklus metódus meghívása (pl. generált mezők számítása)
  7. megváltozott mezők keresése
  8. életciklus metódus meghívása (mentés előtti teendők végrehajtása)
  9. írás az LDAP-ba

A leképező objektum konfigurációja

A leképező objektum mezői tehát megfeleltethetőek mind az LDAP attribútumoknak, mind az XML struktúra egyes részeinek. Ezt a két megfeleltetést a mezőknél egy dokumentációs blokkban kell megtenni:

class SzemelyEntry extends BaseEntry {
 /**
  * @LDAP sn
  * @NEPTUN Szemely/VezetekNev
  */
 public $sn;
 /**
  * @LDAP mail
  * @NEPTUN Szemely/Email
  */
 public $mail;
 /**
  * @LDAP cn
  * @NEPTUN Szemely
  */
 public $cn;

 /* eletciklus metodusok, kotelezoen implementalando metodusok */
}

A fenti rövid példában a vezetéknév illetve az email cím leképzése látható.

XML kezelés

A keretrendszer egy XPath-hoz hasonlító, egyszerűsített útvonal-kifejezés kiértékelését képes elvégezni. Ebben a kifejezésben csak XML elementek szerepehetnek, / karakterrel elválasztva.

A bejegyzéshez tartozó XML-ben előfordulhatnak olyan elemek, melyek több értéket hordoznak (a fenti példában ilyen az Email elem, de például lehet több lakcímből, telefonszámból, ...). Az XML feldolgozása során ezeket a mezőket transzparensen kell kezelni, tehát a feldolgozás során minden egyes csomópontnál a többszörös illeszkedés összes ágának bejárása szükséges. Ezt a rekurzív bejárást a keretrendszer biztosítja.

Szelektív felülírás

Az LDAP attribútumok közül néhány esetén felmerülhet, hogy az adott attribútum ne kerüljön felülírásra a szinkronizáció során. Erre a keretrendszer kezdetleges lehetőséget biztosít, a következő három írási szemantika definiálásával:

A felülírási szemantikát az attribútumnál a @WRITE direktívával lehet jelezni.

Részletes dokumentáció

A részletes API dokumentáció a projekt forrásfából a phpDocumentor eszközzel generálható a docs/ könyvtárba:

phpdoc -c phpdoc
x-www-browser docs/index.html

Futtatás, tesztelés

Parancssoros paraméterek

A szinkronizáció a test.php szkript meghívásával indítható. Ez a parancssoros szkript a következő paramétereket fogadja:

Inkrementális szinkronizáció

A példaimplementáció alapértelmezetten (a --teljes kapcsoló hiánya esetén) az utolsó futtatás óta módosult rekordokat kérdezi le a Neptun webszolgáltatástól. Az egyes szinkronizációs modulok külön futtatásával elérhető, hogy bizonyos adatok (például a státuszok) gyakrabban frissüljenek, más adatok (például a hallgatott tárgyak) ritkábban.

Az utolsó futtatás időpontja tehát szinkronizációs metódusonként kerül tárolásra.

Szelektív feltöltés

A --neptulist paraméter használatával a szinkronizáció korlátozható bizonyos neptun kódokra. Ez a futtatási mód akkor lehet előnyös, ha például egy (néhány) felhasználó adatait kell csak szinkronizálni. Például elképzelhető egy olyan webes felület, ahol a felhasználók ellenőrizhetik a címtárban tárolt adataikat, illetve bizonyos esetekben kérhetik adataik frissítését. Ez a megoldás nagyban csökkentheti az adminisztrációs költségeket, hiszen a Neptunban elvégzett módosítások áttöltését maga a felhasználó kérheti.

Konfiguráció

A szinkronizáció konfigurációt a config.php -ben lehet módosítani. Ebben a fájlban kell beállítani az LDAP szerver elérhetőségét és a jelszavakat, a logolás szintjét, a szinkronizációs metódusok nevét, illetve az ideiglenes fájlokat tároló könyvtárat.

GoogleAuth SAML

SimpleSAMLphp proxy-t használva, a Google workspace fiókot is beköthetjük az eduID federációba.

  1. Felügyeleti konzolon: "Alkalmazások" => "Webes és mobilalkalmazások" => "Alkalmazás hozzáadaása" => "Egyéni SAML alkalmazás hozzáadása"

  2. "Alkalmazásnév": eduID, majd "Tovább"

  3. "Metadataadatok letöltése", majd "Tovább"

  4. "ACS URL": simplesamlphp belépési URL-ét másoljuk be (pl https://_domain_/simplesaml/module.php/saml/sp/saml2-acs.php/google-workspace ), "Entitásazonosító" mezőbe az előző oldalról a "Entitásazonosító" értékét (pl: https://accounts.google.com/o/saml2?idpid=123456), Névazonosító formátuma: "EMAIL", Névazonosító: "PRIMARY EMAIL"

  5. Attribútumok oldalon az alábbi attribútumokat és értékeket vegyük fel:

     "First name": "urn:oid:2.5.4.42"
 "Last name": "urn:oid:2.5.4.4"
 "Primary email": "urn:oid:0.9.2342.19200300.100.1.3"

    Majd befejezés

  6. "Felhasználói hozzáférés" résznél aktiváljuk a szolgáltatást a "BEKAPCSOLVA mindenki számára" opcióval

  7. A simpleSAMLphp metadata konvertálója ( https://idpurl/simplesaml/admin/metadata-converter.php ) segítségével alakítsuk át a letöltött XML-t és az eredményt mentsük el a "metadata/saml20-idp-remote.php" fájlba.

  8. config/authsources.php fájlban a "default-sp" => "entityID" -nél értéknél adjuk meg az "Entitásazonosító" értéket

  9. metadata/saml20-idp-hosted.php fájlban: "'auth' => 'google-workspace'"

Regulation

Szabályozás, NHH

Hírközlési szolgáltatások osztályozása

EU keret szabályozás

Zárt célú hálózatok

TT201805

Távoli elérés

Tagok Tanácsa (délelőtt)

eduID Workshop (délután)

Föderációs dokumentumok módosítása

Műszaki dokumentumok

Szószedet

A módosítások elsősorban megfogalmazási pontosítások. Új elemként jelenik meg az "EduID" fogalom meghatározás, amely a teljes föderációt jelenti a HREF föderáció szinonimájaként. Pontosításra kerültek azok a mesterségesen generált (a gyakorlatban nem használt) fogalmak, amelyek megkülönböztetik azt, hogy az IdP illetve az SP intézmény, vagy infrastrukturális- vagy szoftverkomponens értelemben értendők-e.

Módosításokat tartalmazó változat: https://eduid.hu/wp-content/uploads/2018/05/HREFGlossary-201805-tracked.odt

IdP műszaki előírások

A módosítások elsősorban megfogalmazási pontosítások. Az ajánlott attribútumok közé bekerült az 'sn' és a 'givenName', a kötelező attribútumok közül kikerült a 'schacHomeOrganizationType'. Engedélyezettek lettek a 2048 bites RSA kulcsoknál magasabb kriptográfiai védelmet nyújtó egyéb kulcsok is. Pontosításra kerültek a domain használati szabályok. A teszt felhasználók alkalmazásának körét pontosítottuk.

Módosításokat tartalmazó változat: https://eduid.hu/wp-content/uploads/2018/05/HREFRequirementsIdP2-201805-tracked.odt

SP műszaki előírások

Az RSA kulcsokról szóló pont az IdP-nél megadott módon változott. Elvárás a nyilvánosan elérhető adatkezelési dokumentum.

Módosításokat tartalmazó változat: https://eduid.hu/wp-content/uploads/2018/05/HREFRequirementsSP2-201805-tracked.odt

Föderációs Operátor szolgáltatások

Jelentősebb változtatások történtek a dokumentumon.

Kikerültek belőle a "Kiegészítő szolgáltatások", amelyek a gyakorlatban sohasem működtek valódi szolgáltatásként. A Föderációs Operátor ügyfélszolgálata - a tényeknek megfelelően - best effort-jelleggel működik, e-mailes megkeresésekre válaszol.

Bekerült új szolgáltatásként a Dinamikus metadata szolgáltatás (MDX) és az Autorizációs szolgáltatás (HEXAA).

Módosításokat tartalmazó változat: https://eduid.hu/wp-content/uploads/2018/05/FedOpServices-hu-201805-tracked.odt

Policy

A Szószedetben, ill. más dokumentumokban történt változások átvezetése történt. Érdemi módosítás, hogy bármely oktatással foglalkozó intézmény tag lehet, illetve az, hogy az adatkezelési szabályzatnak nyilvánosnak kell lennie.

Módosításokat tartalmazó változat: https://eduid.hu/wp-content/uploads/2018/05/HREFPolicy12-201805-tracked.odt

Metadata Specifikáció

Teljesen új dokumentumstruktúra készült. Meghatározza a metadata előállítási folyamatát, a használatuk módját, pontosítja az eduGAIN szerepét, illetve információkat tartalmaz a metadata hitelességét és aktualitását garantáló infrastruktúráról.

Új változat: https://eduid.hu/wp-content/uploads/2018/05/HREFMetadataSpec2.odt

Attribútum Specifikáció

Jelentős szerkezeti változások, ám tartalmilag csak nagyon kevés dolog módosult. A legtöbb esetben a meglévő, nemzetközi használatban levő sémadokumentumra hivatkozunk, a specifikáció csak az eltérő (szigorúbb) értelmezésű attribútumokkal foglalkozik (pl. az eduPersonPrincipalName újra nem kiosztható, stb). Fontos, hogy az eduGAIN-ben lévő többi intézményre az eduID megkötései nem vonatkoznak, így ha egy eduGAIN-be publikált SP használni kívánja az attribútumokat, akkor kizárólag a sémákban meghatározott dolgokat feltételezheti!

A dokumentumból kikerült több olyan attribútum, amelyet ismereteink szerint nem használnak a föderációs tagok.

Új változat: https://eduid.hu/wp-content/uploads/2018/05/HREFAttributeSpec2-201805-tracked.odt

Szerződés

A szerződés szövegén csak kisebb változtatások történtek (pl. NIIF Intézet -> KIFÜ). Az új szerződésekből kikerültek a cirkalmas felmondási feltételek. A régi szerződések nem változtak.

Lényeges változás, hogy az egyoldalú Csatlakozási Nyilatkozat kikerült a konstrukcióból.

Hub.eduid.hu

Az o365.eduid.hu címen működő szolgáltatás utódja.

Célja: eduID-val rendelkező végfelhasználók számára biztosít automatikus felhasználó létrehozást és licensz kiosztást felhős szolgáltatásokban (jelenleg Microsoft licenszek kiosztása)

Microsoft integráció

Microsoft Graph API-n keresztül létrehozza a felhasználót és affiliation (student, staff, member) alapján hozzárendeli csoportokhoz. A csoporthoz hozzá lehet rendelni licenszeket, illetve jogosultságokat, amit automatikusan megörököl a felhasználó

Az o365.eduid.hu címen működő szolgáltatás utódja.

Célja: eduID-val rendelkező végfelhasználók számára biztosít automatikus felhasználó létrehozást és licensz kiosztást felhős szolgáltatásokban (jelenleg Microsoft licenszek kiosztása)

Szükséges beállítások Microsoft oldalról

  1. Készítsünk egy Office 365 tenant-ot, ha még nincs: https://learn.microsoft.com/hu-hu/microsoft-365/education/deploy/create-your-office-365-tenant

  2. A https://portal.azure.com oldalon bejelentkezve, hozzunk létre 1-1 biztonsági csoportot a tanulók és a dolgozók részére. Jegyezzük fel a csoportok objektumazonosítóját

  3. Ahhoz, hogy a hub.eduid.hu szolgáltatás kezelni tudja a létrehozott tenant-ot, regisztráljunk egy új alkalmazást: https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/CreateApplicationBlade (ajánlott név: hub.eduid.hu) Mentsük el a generált "Alkalmazás (ügyfél) azonosítója" értéket

  4. Az alkalmazáshoz készítsünk egy új titkos ügyfélkódot, majd a generálás végén mentsünk el a titkos ügyfélkód "Érték" mező értékét. bélyegkép

  5. A létrehozott alkalmazáshoz állítsuk be a szükséges jogosultságokat:

    bélyegkép

    • User.ReadWrite.All
    • Group.ReadWrite.All
    • Directory.ReadWrite.All
    • GroupMember.ReadWrite.All
    • MailboxSettings.Read
    • MailboxSettings.ReadWrite

    "Rendszergazda jogosultság megadása..." gombbal fogadjuk el az új beállításokat

  6. A SAML login bekapcsolásának egyelőre sajnos nincs webes beállítási lehetősége, a Microsoft-tól sem kaptunk ezügyben iránymutatást, ezért ezt PowerShell-en keresztül kell megtenni.

Figyelem! Ha bekapcsoljuk a domain-ra a SAML alapú (Federated) bejelentkezést, akkor már csak azon keresztül lehet bejelentkezni az adott domainre, nincs lehetőség, vegyeshasználatra! Csak akkor hatjsuk végre a beállítást, ha rendben megtörtént a hub.eduid.hu és Microsoft közötti kapcsolat és megfelelően létrejöttek a felhasználók!

Indítsunk egy PowerShell-t, majd adjuk ki a Connect-MsolService parancsot (ha nincs még feltelepítve, akkor a Install-Module MSOnline paranccsal lehet). Jelentkezzünk be adminisztrátori fiókunkkal.

jobbra

Állítsuk be az alábbi változókat:

 $dom = _domain amire engedélyezzük a Federációs bejelentkezést_
 $BrandName = _intézmény neve_
 $LogOffUrl = _IdP kijelentkezési URL-je_
 $ecpUrl = _IdP bejelentkezési URL-je_
 $MyURI = _IdP entity ID-ja_
 $MySigningCert = _IdP selfsigned tanúsítványa_
 $Protocol = "SAMLP"

Példa:

 $dom = "kifu.gov.hu"
 $BrandName = "Kormányzati Informatikai Fejlesztési Ügynökség"
 $LogOffUrl = "<https://idp.niif.hu/simplesaml/saml2/idp/SingleLogoutService.php>"
 $ecpUrl = "<https://idp.niif.hu/simplesaml/saml2/idp/SSOService.php>"
 $MyURI = "<https://idp.niif.hu/shibboleth>"
 $MySigningCert = "MIID3zCCAsegAwIBAgI......XEhu3Otgo="
 $Protocol = "SAMLP"

Majd futtassuk le:

 Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $BrandName -Authentication Federated -PassiveLogOnUri $ecpUrl -ActiveLogOnUri $ecpUrl -SigningCertificate $MySigningCert -IssuerUri $MyURI -LogOffUri $LogOffUrl -PreferredAuthenticationProtocol $Protocol

Ha nem ad vissza semmilyen hibaüzenetet, akkor az office.com -ra való bejelentkezéssel tudjuk tesztelni. Miután beírtuk az e-mail címet a bejelentkező ablakban, akkor át fog irányítani a böngésző az IdP-nkre.

Bejelentkezési mód visszaállítása:

 Set-MsolDomainAuthentication -DomainName $dom -Authentication Managed

Szükséges beállítások IdP oldalon

A korábbiakhoz képest nincs változás. Leírása: O365_SAML

Regisztrációja hub.eduid.hu szolgáltatásba

Az alábbi paramétereket kell megküldeni az ügyfélszolgálati e-mail címünkre (info@eduid.hu):

Jelszavakat, bizalmas információkat érdemes egyszer használatos linken keresztül küldeni, pl a https://pwpush.einfra.hu/ szolgáltatáson

Niifgk

NIIF gatekeeper hálózat

A gatekeeper a H.323 hálózatok fontos építőeleme, amely a következő feladatokat látja el:

Ahhoz, hogy a gatekeeper szolgáltatásait egy H.323 végberendezéssel (pl. videokonferencia berendezés, NetMeeting, GnomeMeeting, stb.) igénybe tudjuk venni, a végberendezésnek regisztrálnia kell a gatekeeperben. A gatekeeper nyilvántartja a regisztrált végpontokat és kezeli az általuk kezdeményezett hívásokat.

Minden gatekeeperhez tartozik egy ún. zóna, amely egy egyedi hívószám előtaggal (prefix) rendelkezik. Például a 100-as zónában lévő végberendezés hívószáma: 00361001020 (ahol a 1020 egy lehetséges végpont azonosítója a 100-as zónán belül). Egy adott zónán belül lévő végpontok hívásainak irányításáról illetve a fent felsorolt egyéb szolgáltatások biztosításáért a zóna gatekeepere felel.

Az NIIF videokonferencia szolgáltatás zónái

Az alábbi ábrán az NIIF videokonferencia szolgáltatást alkotó Gatekeepereket ábrázoltuk ill. a hozzájuk tartozó zónákat. Jelöltük továbbá a hívószám előtagokat, amelyek alapján a hívás irányítás működik.

Az felsőoktatási és kutatási videókonferencia hálózatot alkotó zónák

HU zóna

Gatekeeper: HU-GK

Domain név: hu-gk.vvc.niif.hu

Prefix: 0036 (ill. 06)

Funkció: belföldi intézmények gatekeepereinek összekapcsolása, nemzetközi H.323 kapcsolat biztosítása. A HU-GK kizárólag gatekeeperek közötti hívás irányítással foglalkozik, végpontok regisztrációja nem lehetséges.

(Megjegyzés: a 0036 előhívő helyett a 06-ot is használhatjuk belföldi hívás kezdeményezése esetén).

NIIF zóna

Gatekeeper: NIIF-GK

Domain név: niif-gk.vvc.niif.hu

Prefix: 0036100 (ill. 06100)

Funkció: gatekeeper szolgáltatás olyan belföldi intézmények számára, akik nem rendelkeznek gatekeeperrel. Az NIIF-GK további feladata az NIIF MCU (Multipoint Control Unit) videokonferencia szerver bekapcsolása a szolgáltatásba.

Free zóna

Gatekeeper: FZ-GK

Domain név: fz-gk.vvc.niif.hu

Prefix: 0036900 (ill. 06900)

Funkció: bárki számára szabadon hozzáférhető gatekeeper szolgáltatás, amely használható tetszőleges H.323 kompatibilis végberendezés segítségével (pl. Microsoft NetMeeting, GnomeMeeting). Az FZ-GK-hoz csatlakozó felhasználók szabadon használhatják az NIIF videokonferencia szolgáltatásait (beföldi ill. nemzetközi GDS hívások).

Global Dialling Scheme

A GDS (Global Dialing Scheme) egy nemzetközi hívószám-kiosztás, amely több mint 100 zónát foglal magában kb. 30 országból. A GDS lehetővé teszi külföldi kutatóintézetek és egyetemek nemzetközi telefonszám alapján való elérhetőségét (pl. 0049, Németország).

IDMIntezmenyiIgenyek

Intézmények identitásmenedzsment igényei

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

Ez a bejegyzés az intézményi igények összegyűjtésére szolgál, kérlek segíts, és vidd fel az általad fontosnak tartott problémákat! Az általad felvitt / szerkesztett pontok végére kérlek jegyezd fel intézményed nevét, hogy mindenki átláthassa ezt a lapot!

Neptun szinkronizáció

LDAP igények

level0509

Kedves Partnerünk!

A KIFÜ webhosting környezetét rövidesen frissíteni fogjuk. Az ebből eredő legfontosabb változás, hogy a 2019-ben hivatalosan már nem támogatott 5.6-os verziójú PHP helyett a továbbiakban a 7.0-ás verzió lesz elérhető.

Nyilvántartásunk szerint Ön az alábbi oldal üzemeltetője:

<az ön weboldala>

Arra kérjük, hogy tesztelje le weboldalát a megújított környezetben, és esetleges észrevételeit ezen levélre válaszolva juttassa el hozzánk. A tesztelésre használható cím:

http://<az ön weboldala>:81 vagy

https://<az ön weboldala>:444

Teszteléskor vegye figyelembe, hogy amennyiben az oldala abszolút hivatkozásokat vagy átirányításokat használ, előfordulhat, hogy egyes erőforrásokat a hagyományos környezetből használ annak ellenére, hogy a lekérést Ön a tesztcímmel indította. Erre utalhat például, ha valamely oldal betöltése után már nem szerepel a tesztcímre jellemző portszám (:81 illetve :444) a böngészője címsorában.

Előfordulhat továbbá, hogy egy szigorú munkakelyi tűzfal vagy proxy megakadályozza Önt az alternatív portok elérésében. Ebben az esetben kérjen segítséget rendszergazdájától.

Amennyiben 2019-06-09-ig nem kapunk választ Öntől erre a levélre, úgy tekintjük, hogy oldala készen áll a korszerűsített kiszolgálói környezetben történő használatra.

Üdvözlettel: Webhosting csapat KIFÜ

PWS upgrade

Tisztelt Partnerünk!

Webhosting szolgáltatásunk frissítésének befejező lépéseként 2019. augusztus 5-én 18 és 19 óra között átállítjuk kiszolgálóinkat a PHP 7.0 verzióját használó környezetre. Az átállással kapcsolatban korábban küldött tájékoztató leveleinket az alábbiakban olvashatják.

Üdvözlettel: KIFÜ Webhosting

  1. A 2019. május 9-én kiküldött tájékoztató levél
  2. A 2019. június 12-én kiküldött tájékoztató levél

A 2019. augusztus 5-én 18 és 19 óra között tervezett karbantartást elhalasztottuk 12-ére.

Java Keystore import

Sajnos egy meglevő privát kulcsot és tanúsítványt nem lehet olyan könnyen (keytool segítségével) Java Keystore-ba importálni. A művelet folyamata a Shibboleth Wikiben található leírás alapján:

Xmltooling Log4cpp patch

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

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

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

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

Hivatalos kapcsolattartás

  1. A kapcsolattartás a href-admin@listserv.niif.hu levelezőlistán keresztül történik.
  2. A Tagok Adminisztratív Kapcsolattartóinak kötelező feliratkozniuk a kapcsolattartásra szolgáló levelezőlistára.
  3. Feliratkozhat a kapcsolattartásra szolgáló listára
    • Tagok részéről tetszőleges személy (vita esetén a Tag Adminisztratív Kapcsolattartója dönt a listatagságról)
    • Partnerek részéről tetszőleges személy (vita esetén a Partner Adminisztratív Kapcsolattartója dönt a listatagságról)

Tagok Tanácsa ülés

A Tagok Tanácsának ülése a Tagok képviselőinek személyes találkozója.

Résztvevők

  1. A Tagok Tanácsának ülése nyilvános.
  2. A Tagok Tanácsának ülésein a Tagok és Partnerek részéről megjelentek felszólalhatnak
  3. A Tagok Tanácsának döntéseivel kapcsolatban a Tagok Adminisztratív Kapcsolattartói, ill. távollétük esetén írásbeli meghatalmazásukkal rendelkezők szavazhatnak.

Meghirdetés

  1. A Tagok Tanácsa ülését kezdeményezheti:
    • a Föderációs Operátor,
    • 5 Tag,
    • a Tagok 20%-a.
  2. A Tagok Tanácsának időpontját és helyszínét a kezdeményező köteles legkevesebb 10 munkanappal az időpont előtt meghirdetni.

Határozatképesség

A Tagok Tanácsa ülés határozatképes, ha részt vesz rajta a Tagok 20%-ának képviselője

Emlékeztető, határozatok

  1. A Tagok Tanácsa ülésről emlékeztető készül, amelyet az ülést követő 3 munkanapon belül meg kell osztani a kapcsolattartásra szolgáló levelezőlistán.
  2. A Tagok Tanácsa határozatait a Föderációs Operátor online elérhetővé teszi a föderáció hivatalos dokumentumtárában (jelenleg: http://eduid.hu/dokumentumok).
  3. Indokolt esetben a határozatok angol nyelven is publikálásra kerülnek.

Döntéshozatal

Döntéshozatal formái

Döntéshozatal módja

Tagok Tanácsának tiltakozása hiányában három (3)munkanap elteltét követően elfogadásra kerülő döntések:

Tagok Tanácsának tiltakozás hiányában tíz (10) munkanap elteltét követően elfogadásra kerülő döntések:

Tagok Tanácsának egyszerű szótöbbséggel meghozott döntése szükséges:

Tagok Tanácsának minősített többségű döntése szükséges:

TT 2011-09

Tagok Tanácsának működési rendje

A Tagok Tanácsa folyamatosan alakítja ki a működési rendjét. A munka elkezdéséhez javasoljuk az alábbi elfogadását:

Föderációs dokumentumok módosítása

Műszaki dokumentumok

Műszaki követelmények

Az eredeti "HREF műszaki követelmények és elvárások" c. dokumentumban időnként keveredett az IdP/SP valamint az azt üzemeltető intézmény fogalma, valamint célszerűnek tűnt pontosabban megfogalmazható követelményeket megfogalmazni. Ezért az új műszaki követelményeket két dokumentum tartalmazza: IdP üzemeltetési szabályok, SP üzemeltetési szabályok. Ezeknek a követelményeket minden olyan új IdP-nek és SP-nek teljesítenie kell, amelyik a föderációs metaadatokba bekerül.

A címváltozás miatt módosítani kell a csatlakozási szándéknyilatkozat 2.1-es pontját, valamint a HREFPolicy-ban levő hivatkozásokat is.

Attribútum specifikáció

Lényeges változtatások:

Metadata specifikáció

Lényeges változtatás: PKI validációt nem támogatjuk, a metadataaláíró kulcsot csak explicit módon validáljuk. Ennek oka, hogy lényegesen egyszerűbb, kevesebb hibalehetőséggel és működési overhead-del jár.

Csatlakozási szerződés

A Nemzeti Információs Infrastruktúra Fejlesztési Programról szóló kormányrendelet megváltozott, így a csatlakozási szerződés 10.3 pontjában az "5/2011 (II.3.)" kormányrendeletnek kell szerepelnie. A változtatás nem érinti a már aláírt szerződéseket, azokat nem kell újra aláírni.

Felhatalmazás

A TT felhatalmazza a Föderációs Operátort, hogy a Föderációs Dokumentumokban az alábbi triviális változtatásokat a jövőben önállóan is elvégezheti:

A Föderációs Operátor köteles a dokumentumok érvényes verzióját a http://eduid.hu/dokumentumok oldalon közzétenni és a változásról értesíteni a Tagok Tanácsát. A dokumentumok keltezését és verziószámát minden módosítás esetén aktualizálni kell.

Szószedet

Apró változtatás: entitás szó meghatározása a szószedetben

Dokumentumok angol nyelvű változata

Lektorálás folyamatban...

Tag- és Partnerfelvételi eljárásrend

A Föderációs Operátor új Tag/Partner jelentkezésekor, valamint Tagok és Partnerek új IdP-jének ill. SP-jének elfogadásakor a HREFJoin dokumentumban meghatározott módon jár el.

eduGAIN

Az [http://edugain.org eduGAIN] nemzeti föderációk konföderációja. A Föderációs Operátor publikálja:

Az eduGAIN metadatába bekerülést az üzemeltető intézménynek kérvényeznie kell (opt-in). Az eduGAIN metadata a föderációs metaadatoktól külön állományban szerepel, így a föderációs résztvevők maguk dönthetnek arról, hogy megbíznak-e benne.

Az eduGAIN-hez csatlakozáshoz a Tagok Tanácsa úgy dönt, hogy

Metadata módosítás

Technikai változtatás

Jelenleg metadata a NIIF CA által aláírt tanúsítvánnyal van aláírva, ami lejárt. Ez nem okoz problémát az általunk ismert szoftvereknél, azonban nem kizárt, hogy újabb csatlakozóknál gondot fog okozni. Az aláíró tanúsítvány cseréje azonban az összes entitásnál beavatkozást igényel. (Beavatkozás hiányában a metadata nem frissül, sőt, újraindításnál a szoftver el sem indul!)

A kulcscsere tervezett időpontja: 2011. október 4., koordinálása a href-tech listán történik.

Adminisztratív változtatás

A metadatából el kell távolítani azokat az entitásokat, amelyek olyan intézményekhez tartoznak, akik nem írták alá a Csatlakozási Szerződést. Az eltávolítás ideje: 2011. november 15., előzőleg az intézményekkel a Föderációs Operátor egyeztet a fennálló esetleges akadályokról.

Egyéb döntések

Magyar Tudományos Akadémia csatlakozása

Az MTA alkalmazásaihoz (jelenleg Akadémiai Adattár; később MTMT és esetleg továbbiak) a felhasználók az MTA saját IdP-jén keresztül férhetnek hozzá, azonban ez az IdP képes arra, hogy eduID-n keresztül IS azonosítsa a felhasználókat; azaz a föderáció szempontjából SP-ként viselkedik. Azonban felmerült, hogy az Akadémia IdP-ként is csatlakozhasson a föderációhoz, annak ellenére, hogy várható, hogy a felhasználóinak nagy része rendelkezik identitással más eduID-s intézményekben is.

A TT hozzájárul ahhoz, hogy a Magyar Tudományos Akadémia Tagként csatlakozzon a föderációhoz, valamint az AAT rendszere mögött futó azonosítási rendszer SP-ként és IdP-ként is része legyen a föderációnak.

Felvetett egyéb témák

EARC

eduGAIN Attribute Release Check

Evaluation

Ranks (for each SP):

Additional points (A-C):

Penalty points (A-C):

Definitions

Swift

Ismertető

A C4E mellé kialakításra került egy úgynevezett Object Store, amely gyakorlatilag egy magas rendelkezésre állású, redundáns objektum tároló. A rendszer hátterében egy CEPH alapú tároló került kialakításra, amely két darab Rados Gateway-en keresztül kapcsolódik a C4E authentikációs komponenséhez (keystone). A rendszerbe integrálódás OpenStack Swift API használatával valósul meg, ezért látszólag Swift komponensként látható és vehető igénybe, azonban a háttérben egy CEPH rendszer felelős az adatok biztonságáért.

Hasznos linkek:

Igénylés

A C4E felhasználóinak lehetőségük van objektum tárolót igénybe venni a C4E szolgáltatás mellé. Alapértelmezetten minden projekthez 20GB méretű tárolót biztosítunk. Ettől eltérő igény teljesítéséhez nincs más teendő, mint a projekt igénylésénél feltüntetni az igényelni kívánt terület méretét.

Használatba vétel

A sikeres projekt igénylés után a szolgáltatás két féle módon vehető igénybe, amelyek részletezése a következő bekezdésekben látható.

C4E dashboard

A dashboard-ra történő bejelentkezés után, a képernyő bal oldalán található menüben az „Object Store” lehetőséget választva hozhatunk létre úgynevezett konténereket és jeleníthetjük meg azokat.

Object Store

Konténer létrehozásához válasszuk a konténer hozzáadása lehetőséget, majd a következő képen látható módon válasszunk egy tetszőleges nevet.

Create container

A megfelelő név kiválasztása után, a „Create” gombra kattintva a rendszer létrehozza a megfelelő paraméterekkel és az előzőleg igényelt méretű kvótákkal felparaméterezett konténert. Az elkészült konténerbe lehetőség van könyvtárak létrehozására és fájlok feltöltésére. Sajnos a rendszer nem támogatja az azonos container elnevezést külön projektekben, így előfordulhat, hogy a kívánt container név már foglalt lesz!

S3 API

OpenSSH Server on Debian 8

OpenSSH Server on Debian 8

Debian 8 does not ship with a version of OpenSSH that is compatible with Moonshot. To get Moonshot support for it, you must install a specific Moonshot-enabled version. The following instructions will guide you through the package building process.

All of the instructions below assume that you have root access, and will work as the root user (either directly or using sudo).

The instructions on this page will replace the system provided OpenSSH packages with the Moonshot enabled ones (don't worry, standard SSH things will still work!)

Following the instructions on this page will give you a Moonshot-enabled OpenSSH Server only.

System Preparation

Add the Moonshot libraries.

If you have not already done so, you first need to follow the instructions on how to install the Moonshot Libraries on Debian 7.

Prepare the building environment

Install the required packages.

apt-get install build-essential dpkg-dev fakeroot gnupg lintian patch patchutils strace unzip pbuilder debian-builder quilt \
 automake autoconf debhelper dh-make
apt-get source openssh
cd openssh-6.7p1
apt-get build-dep openssh

Building Instructions

Download the gssapi-generic.patch, then build the packages.

cd openssh-6.7p1
cp /tmp/gssapi-generic.patch debian/patches
echo "gssapi-generic.patch" >> debian/patches/series
debuild -us -uc

Installing Instructions

The new packages can be installed with dpkg.

dpkg -i ../openssh-server_6.7p1-X_<arch>.deb

Configuration Instructions

Once installed, the Moonshot-enabled OpenSSH server will still need a few quick tweaks in order to turn on the Moonshot support.

NeptunWebservicePPKE

###############################################################################
# Authentikáció a neptunhoz

sub check_neptun($$) {
    my $neptuncode = shift;
    my $neptunpass = shift;
    my $soap = SOAP::Lite->proxy('https://yourhost.example.org/LDAPServices/LDAPServices.svc');
    $soap->default_ns('http://niif.hu/neptunszinkron/OktatasiAdatok');
    $soap->on_action(sub { "http://niif.hu/neptunszinkron/OktatasiAdatok/OktatasiAdatokPortType/isNeptunTag" });

    my $som = $soap->call("isNeptunTag",
                           SOAP::Data->type('xml' =>
                           '<oLDAPLoginAdat><LoginNev xmlns="http://niif.hu/neptunszinkron/NeptunTag">'.$neptuncode.'</LoginNev>
<Jelszo xmlns="http://niif.hu/neptunszinkron/NeptunTag">'.$neptunpass.'</Jelszo></oLDAPLoginAdat>')
                     );
    telluseranddie( "Neptun hiba!", $som->fault->{ faultstring }) if ($som->fault);
    if($som->result->{"Tag"} eq 'true') {
      logit( "neptun check ok\n");
    }
    else {
      telluseranddie("Hibás neptunkód vagy jelszó!\n","neptun check is NOT ok");
    }
}

################################################################################
# Személyi adatok lekérdezése neptun kód alapján

sub getuser_data_szemelyi($) {
  my $neptuncode = shift;

  my $soap = SOAP::Lite->proxy('https://yourhost.example.org/LDAPSzemelyi/LDAPWCFSzemelyiAdatok.svc');
  $soap->default_ns('http://niif.hu/neptunszinkron/SzemelyiAdatok');
  $soap->on_action(sub { "SzemelyiAdatokByNeptunKodokSzinkronRequest" });

  my $som = $soap->call("SzemelyiAdatokByNeptunKodok",
                           SOAP::Data->name('NeptunKodok' =>
                           \SOAP::Data->name('kod' =>
                            \SOAP::Data->name('string' => $neptuncode)
                           )
                          )
  );
  die $som->fault->{ faultstring } if ($som->fault);
  return $som->result->{"Szemely"};
}
################################################################################
# Szervezei kapcsolódások neptun kód alapján

sub getuser_data_szervezetikapcsolat($) {
  my $neptuncode = shift;
  my $soap = SOAP::Lite->proxy('https://yourhost.example.org/LDAPServices/LDAPServices.svc');
  $soap->default_ns('http://niif.hu/neptunszinkron/OktatasiAdatok');
  $soap->on_action(sub { "http://niif.hu/neptunszinkron/OktatasiAdatok/OktatasiAdatokPortType/SzervezetiKapcsolatAdatok" });

  my $som = $soap->call("SzervezetiKapcsolatAdatok",
                           SOAP::Data->name('NeptunKodok' =>
                           \SOAP::Data->name('kod' =>
                            \SOAP::Data->name('string' => $neptuncode)
                           )
                          )
  );
  die $som->fault->{ faultstring } if ($som->fault);
  return $som->result->{"SzervezetiKapcsolatAdat"};
}

Joomla telepítés

A Joomla aktuális verzióját az alábbi link segítségével lehet letölteni: https://downloads.joomla.org/latest

A letöltött ZIP állományt tömörítsük ki a saját gépünkön. Miután a kitömörítettük a ZIP állományt a mappa tartalmát feltölthetjük a tárhelyünkre.

A PWS-en található tárhelyünkhöz a SFTP segítségével tudunk kapcsolódni.

Windows operációs rendszer esetén pl. :WinSCP - https://winscp.net/eng/download.php

Szükséges adatok:

SFTP host: ftp.pws.niif.hu

SFTP user: < felhasználói név >

SFTP password: < jelszó >

WinSCP - Munkamenet

A csatlakozás során fogadjuk el, a kiszolgáló kulcsának hozzáadását a gyorsítótárhoz.

Amennyiben sikeresen csatlakoztunk az alábbi mappa szerkezetet láthatjuk:

Könyvtárszerkezet

A korábban letöltött és kicsomagolt Joomla fájlokat másoljuk fel a www könyvtárba.

Miután feltöltésre kerültek a fájlok a domain név beírása után az alábbi oldalnak kell megjelennie: Joomla - Kezdőlap Joomla - A webhely üzemen kívül

Töltsük ki az adatokat, majd kattintsunk a Tovább gombra (Amennyiben a telepítést követően azt szeretnénk, hogy látogatók ne lássak az oldalt akkor a „A webhely üzemen kívült” állítsuk át igen-re).

A következő oldalon kell elvégezni a Joomla adatbázisának a beállításait: Joomla - adatbázis beállítás

Szükséges adatok:

MySQL user: < MySQL felhasználói név >

Adatbázis neve: < megegyezik a MySQL felhasználó névvel >

MySQL password: < MySQL jelszó >

MySQL host – Állomás neve: < MySQL host >

Az adatbázis típusánál a MySQLi-t válasszuk ki. Ha kitöltöttünk minden szükséges információt kattintsunk a Tovább gombra.

Joomla - Telepítés hiba

Amennyiben az alábbihoz hasonló hibaüzenetet kapunk akkor töröljük a tárhelyünkről a www mappában található installation mappából a hibaüzenetben említett fájlt, ezután próbáljuk újra az adatbázishoz való kapcsolódást (az adatbázist jelszót újra be kell írni). Ha sikeresen volt áttérünk az FTP beállításhoz. (Ha almappába rakjuk pl. www/joomla/ akkor ez a beállítási lehetőség nem jelenik meg.)

Joomla - FTP beállítás

Az FTP-réteg engedélyezése résznél kattintsunk a Nem részre.

(A PWS szolgáltatás keretében nem elérhető az FTP szolgáltatás)

Kattintsunk a Tovább gombra.

Most következik a "Véglegesítés"

Joomla - Véglegesítés 1 Joomla - Véglegesítés 2 Joomla - Véglegesítés 3 Joomla - Véglegesítés 4

Amennyiben a configuration.php esetén az látjuk, hogy NEM akkor ezt a fájlt nekünk kell majd manuálisan létrehozni.

Ha mindennel megvagyunk kattintsunk a Telepítés gombra.

Joomla - Telepítés megtörtént Joomla - configuration.php

A Megjegyzés részben találhatóak meg a configuration.php-hoz szükséges adatok. Hozzuk létre a fájlt, másoljuk bele a tartalmat majd mentsük el. Ha ezzel végeztünk akkor töltsük fel a www könyvtárba a fájlt.

Ezután töröljük az installation mappát manuálisan a www könyvtárból.

Az oldal használtra kész.

Hasznos link(ek):

A Joomla! tartalomkezelő rendszer magyar weboldala - https://joomlacms.hu/

Harica

Harica eduID intergráció

Az új Harica TCS szolgáltató lehetővé teszi az eduGAIN bejelentkezést "Institutional Login" gomb segítségével.

Harica bejelentkezés eduID-val nem műküdik

A HARICA rendszerében a felhasználói fiók létrehozása nem sikerül, mert az Identity Provider (IdP) nem biztosítja a szükséges attribútumokat a Service Provider (SP) részére. A hibaüzenet a következő:

"Your Identity Provider (IdP) does not provide HARICA with the appropriate info (attributes) for your account. Please contact your IdP to fix this issue."

A megoldáshoz szükséges attribútumok listája a következő:

Attribútum OID Kötelező
eduPersonTargetedID urn:oid:1.3.6.1.4.1.5923.1.1.1.10 Igen
givenName urn:oid:2.5.4.42 Igen
mail urn:oid:0.9.2342.19200300.100.1.3 Igen
surname urn:oid:2.5.4.4 Igen
displayName urn:oid:2.16.840.1.113730.3.1.241 Nem
eduPersonEntitlement urn:oid:1.3.6.1.4.1.5923.1.1.1.7 Nem
eduPersonOrgUnitDN urn:oid:1.3.6.1.4.1.5923.1.1.1.3 Nem
eduPersonPrimaryAffiliation urn:oid:1.3.6.1.4.1.5923.1.1.1.5 Nem

SSP 2.x Megoldás

Az attribútumok kezelésére a NIIF SimpleSAMLphp AttributeLimit modul került használatra. Az alábbi konfiguráció az authproc szekcióban biztosítja, hogy a szükséges attribútumok átadásra kerüljenek a HARICA SP-jeinek.

Konfiguráció

Az alábbi beállításokat add hozzá ahhoz a filehoz ahol az authproc történik, pl saml20-idp-hosted.php:

10 => [
    'class' => 'attributelimit:AttributeLimit',
    'https://www.harica.gr/simplesamlphp/module.php/saml/sp/metadata.php/pki-grnet-sp' => [
        'urn:oid:0.9.2342.19200300.100.1.3', // mail
        'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', // eduPersonPrincipalName
        'urn:oid:2.5.4.42', // givenName
        'urn:oid:2.5.4.4', // surname (sn)
        'urn:oid:2.16.840.1.113730.3.1.241', // displayName
        'urn:oid:1.3.6.1.4.1.25178.1.2.9', // schacHomeOrganization
        'urn:oid:1.3.6.1.4.1.5923.1.1.1.10', // eduPersonTargetedId
    ],
    'https://cm-stg.harica.gr/simplesamlphp/module.php/saml/sp/metadata.php/harica-cm-stg-sp' => [
        'urn:oid:0.9.2342.19200300.100.1.3', // mail
        'urn:oid:1.3.6.1.4.1.5923.1.1.1.6', // eduPersonPrincipalName
        'urn:oid:2.5.4.42', // givenName
        'urn:oid:2.5.4.4', // surname (sn)
        'urn:oid:2.16.840.1.113730.3.1.241', // displayName
        'urn:oid:1.3.6.1.4.1.25178.1.2.9', // schacHomeOrganization
        'urn:oid:1.3.6.1.4.1.5923.1.1.1.10', // eduPersonTargetedId
    ],
],

Magyarázat

  1. Az authproc szekcióban a attributelimit modul segítségével szabályozzuk, hogy mely attribútumok kerüljenek továbbításra az SP részére.

  2. Az egyes SP-khez tartozó attribútumokat külön definiáljuk az SP metaadat URL alapján.

  3. Az attribútumokat az OID alapján adjuk meg, például:

    • urn:oid:0.9.2342.19200300.100.1.3 a mail attribútumot jelenti.

Ellenőrzés

Jelentkezz be az IdP-n keresztül, és ellenőrizd, például saml tracer segítségével hogy átadásra kerülnek e a kötelező attribútumok.

Egyéb megoldás

Amennyiben az idp-nk nem simplesamlphp vagy nem szeretnénk az attributelimit modult használni, más módon kell az IdP-t konfigurálni a kötelező attribútumok kiadására.

RedHatJavaLinks

!!! info

A Shibboleth fejlesztők csak a Sun-féle JAVA virtuális gépet támogatják. RedHat/CentOS rendszereken az openjdk csomag mindenféle "alternatives" linket készít. Az alábbi scripttel átírhatjuk a linkeket a sunos Java csomag által adott binárisokra

#!/bin/bash

JAVA_HOME=/usr/java/default
priority=16635

alternatives \
        --install /usr/bin/java java $JAVA_HOME/bin/java $priority \
        --slave /usr/lib/jvm/jre jre $JAVA_HOME/jre \
  --slave /usr/bin/javaws javaws $JAVA_HOME/bin/javaws \
  --slave /usr/bin/keytool keytool $JAVA_HOME/bin/keytool \
  --slave /usr/bin/orbd orbd $JAVA_HOME/bin/orbd \
  --slave /usr/bin/pack200 pack200 $JAVA_HOME/bin/pack200 \
  --slave /usr/bin/policytool policytool $JAVA_HOME/bin/policytool \
  --slave /usr/bin/rmid rmid $JAVA_HOME/bin/rmid \
  --slave /usr/bin/rmiregistry rmiregistry $JAVA_HOME/bin/rmiregistry \
  --slave /usr/bin/servertool servertool $JAVA_HOME/bin/servertool \
  --slave /usr/bin/tnameserv tnameserv $JAVA_HOME/bin/tnameserv \
  --slave /usr/bin/unpack200 unpack200 $JAVA_HOME/bin/unpack200

alternatives \
  --install /usr/lib/jvm/jre-1.6.0 jre_1.6.0 $JAVA_HOME/jre $priority

alternatives \
  --install /usr/bin/javac javac $JAVA_HOME/bin/javac $priority \
  --slave /usr/lib/jvm/java java_sdk $JAVA_HOME \
  --slave /usr/bin/appletviewer appletviewer $JAVA_HOME/bin/appletviewer \
  --slave /usr/bin/apt apt $JAVA_HOME/bin/apt \
  --slave /usr/bin/extcheck extcheck $JAVA_HOME/bin/extcheck \
  --slave /usr/bin/jar jar $JAVA_HOME/bin/jar \
  --slave /usr/bin/jarsigner jarsigner $JAVA_HOME/bin/jarsigner \
  --slave /usr/bin/javadoc javadoc $JAVA_HOME/bin/javadoc \
  --slave /usr/bin/javah javah $JAVA_HOME/bin/javah \
  --slave /usr/bin/javap javap $JAVA_HOME/bin/javap \
  --slave /usr/bin/jconsole jconsole $JAVA_HOME/bin/jconsole \
  --slave /usr/bin/jdb jdb $JAVA_HOME/bin/jdb \
  --slave /usr/bin/jhat jhat $JAVA_HOME/bin/jhat \
  --slave /usr/bin/jinfo jinfo $JAVA_HOME/bin/jinfo \
  --slave /usr/bin/jmap jmap $JAVA_HOME/bin/jmap \
  --slave /usr/bin/jps jps $JAVA_HOME/bin/jps \
  --slave /usr/bin/jrunscript jrunscript $JAVA_HOME/bin/jrunscript \
  --slave /usr/bin/jsadebugd jsadebugd $JAVA_HOME/bin/jsadebugd \
  --slave /usr/bin/jstack jstack $JAVA_HOME/bin/jstack \
  --slave /usr/bin/jstat jstat $JAVA_HOME/bin/jstat \
  --slave /usr/bin/jstatd jstatd $JAVA_HOME/bin/jstatd \
  --slave /usr/bin/native2ascii native2ascii $JAVA_HOME/bin/native2ascii \
  --slave /usr/bin/rmic rmic $JAVA_HOME/bin/rmic \
  --slave /usr/bin/schemagen schemagen $JAVA_HOME/bin/schemagen \
  --slave /usr/bin/serialver serialver $JAVA_HOME/bin/serialver \
  --slave /usr/bin/wsgen wsgen $JAVA_HOME/bin/wsgen \
  --slave /usr/bin/wsimport wsimport $JAVA_HOME/bin/wsimport \
  --slave /usr/bin/xjc xjc $JAVA_HOME/bin/xjc

NeptunLdapSync

Az NIIF Intézet által fejlesztett szinkronizációs folyamat alkalmas arra, hogy Neptunban tárolt felhasználók (hallgatók, oktatók, dolgozók) adatait egy névtárba szinkronizálja. Természetesen lehetséges a névtárat más forrásokból is módosítani (pl. a dolgozói adatok sokhelyütt nem a Neptunban tárolódnak), ezzel a szinkronizációs program nem foglalkozik.

Az NIIF Intézet referencia implementációjának leírása itt található

Feltételezések

Felhasználó életciklusa

  1. Neptun felhasználói bejegyzés létrehozása (részletek nélkül)
  2. Felhasználói adatok szinkronizálása az LDAP-ba
  3. LDAP jelszó aktiválása
  4. Neptun adatok változásának szinkronizációja
    • személyi adatok
    • státusz adatok
    • szervezeti kapcsolódás adatai
    • oktatási adatok
  5. (opcionális) POSIX attribútumok generálása
  6. (opcionális) Elfelejtett LDAP jelszó újragenerálása Neptun autentikáció után
  7. Neptun státusz adatok alapján passzív / kilépett státuszba helyezés
  8. LDAP bejegyzés törlése

Részletek

Attribútum mapping

Azonosító adatok

Attribútum LDAP Attribútum Megjegyzés
Neptun kód niifPersonOrgID

Személyi adatok

Attribútum LDAP Attribútum Megjegyzés
Vezetéknév sn
Keresztnév givenName
Teljes név cn
Titulus title pl. Dr.
Telefonszám telephoneNumber, mobile, fax A mobiltelefonszámot érdemes külön LDAP attribútumban tárolni a többi telefonszámtól. Speciális konverziós logika szükséges lehet (például az elválasztó karakterek törlése).
E-mail cím mail

Státusz adatok

Attribútum LDAP Attribútum Megjegyzés
Hallgatói státusz eduPersonAffiliation={'student', 'member'} Ha van hozzá olyan képzés, aminek hallgatója
Oktatói státusz eduPersonAffiliation={'faculty', 'member'} Ha az elmúlt N évben volt kurzushoz kapcsolódása
Alkalmazotti státusz eduPersonAffiliation={'employee', 'staff', 'member'} Ha alkalmazott

Metaadatok

Attribútum LDAP Attribútum Megjegyzés
Bejegyzés archiválásának időpontja schacExpiryDate Azon időpont, amikor a bejegyzést az aktív felhasználók közül el kell távolítani, ezután semmilyen szolgáltatáshoz nem férhet hozzá
Egyéb státuszok schacUserStatus Pl. az intézményhez fűződő viszonya (meddig tart), bizonyos szolgáltatásokat meddig érhet el, stb

Szervezeti kapcsolódások

Attribútum LDAP Attribútum Megjegyzés
Kar niifEduPersonFaculty(DN) Képzés kar szabadszöveges megnevezése (kódja) - csak hallgatóknál
Szak niifEduPersonMajor Képzés szak szabadszöveges megnevezése - csak hallgatóknál
Egyéb szervezeti egység eduPersonOrgUnitDN Pl tanszék, intézet, kollégium

Oktatási adatok

Attribútum LDAP Attribútum Megjegyzés
Aktívan oktatott tárgyak listája niifEduPersonHeldCourse Azon tárgykódok listája, melynek az elmúlt 1 évben indult olyan kurzusa, amit az adott oktató tartott
Tárgyfelelős eduPersonEntitlement? Azon tárgykódok listája, melynek az oktató jelenleg tárgyfelelőse
Aktuális félévben hallgatott tárgyak listája niifEduPersonAttendedCourse
Valaha hallgatott tárgyak listája niifEduPersonArchiveCourse Aktuális félév tárgyai is

Jelszó beállító felület

Törlési folyamat

Státusz

Szinkronizáció

A Neptun és az LDAP közötti szinkronizációt az LDAP oldali szinkronizáló szkript indítja.

Neptun interfészek

A szinkronizálás a Neptun által biztosított XML Webszolgáltatáson keresztül valósul meg. A legtöbb művelet két paramétert fogad: időbélyeg illetve Neptun lista - mindkettő opcionális. Amennyiben az időbélyeg szerepel, csak a megadott időpont óta módosult rekordok kerülnek át. A Neptun lista megadása az adott bejegyzésekre szűkíti az eredményt.

Fontos, hogy pl. a személyi adatoknál az időbélyeg a Neptun-ban a teljes rekordra értelmezett, tehát nem csak a szinkronizálni kívánt adatok triggerelik a változását.

Implementációk

JRA5Attributes

When a Home Bridging Element releases local attributes to a Remote Bridging Element, some attribute transformation and attribute filtering should take place. Similarly, Remote BE has to filter out unnecessary/unwanted attributes and transform the remaining according to its federation's rules.

Conversion

Regardless of attribute representation of each federation (eg. Attribute Certificates or simple string values), users want to transport the information included in attribute values. The aim of attribute conversion is to let BE administrators be able to define rules for including and extracting information into/from attributes that can be handled by both federations.

It is worth noting that inside the two federations they can embed

It is possible that in some cases the information that needs to be transferred is hold by a tuple of attributes. Sometimes the number of attributes representing the same information can differ in each federation. In these cases simple translation of attribute names and values is not enough.

Information needed for conversion

Naturally, federations need to agree on the vocabulary when exchanging these kinds of information. It can be achieved in the following ways:

In the former case, conversion is independent of the relying party, all what BEs need to do is to convert to and from the common format. However, maintaining a central vocabulary is not always easy and is quite hard to make it flexible enough. It should be possible to allow federations to define custom interfaces for talking to specific peers.

eduGAIN Credential Conversion Service (eCCS)

Gabriel López et al. describe a common 'eduGAIN Credential Conversions Service'.

Summary

They propose a central (although technically distributable) service for carrying out attribute conversion to and from a common representation (eduGain Common Credentials, eCC). Conversion polices for converting local attributes to eCC and vice versa are included in the metadata. Attributes can be transferred between BEs in eCC representation and in 'source format' (in unconverted form). In both cases an RBE needs to invoke eCCS, which sends back attributes in the required format of the remote federation.

eCCS operates by utilizing custom SAML extensions called ConversionQuery and WrappedStatement as well as conversion policy sets (XACML) published in metadata.

Probably the most important thing in eCCS is to eliminate the NxN matrix problem (where N is the number of BEs), because of conversion policies published in MDS.

Comments

The Shibboleth Way

Shibboleth uses *AttributeDefinition elements to define conversion rules from data source (i.e. LDAP) attributes to "resolved" attributes. AttributeDefinitions can depend on DataConnectors or other AttributeDefinitions.

It can be used for attribute conversion in eduGAIN as well if we can define a DataConnector that can use attributes retrieved

Shibboleth2 has a number of built-in AttributeDefinitions:

Hooking into EduGAIN

It is still necessary to define an attribute vocabulary within a confederation, however it is technically easier to exchange additional attributes between relying parties. If 'EduGAIN' as a confederation can be one of the relying parties (and why not?), then the NxN matrix problem can be avoided, because only 'special' relying parties (peers) require additional configuration.

Open issues

Filtering

Both HBE and RBE need to filter the set of attributes released and accepted.

Shibboleth2 comes with a filtering code that is the same both for the attribute publisher and the consumer. Filtering rules may be based on (among others):

Tartalomszűrés

SuliX szűrés

Azon intézmények számára, akik jogosultak az OpenEDU programban való részvételre (Kik jogosultak?), a SuliX rendszer automatikusan, külön szoftver telepítése nélkül az intézmény teljes hálózata számára ingyenesen biztosítja a törvénynek való megfelelést. A SuliX szoftverekhez való hozzájutás az OpenEDU programon keresztül történik. Információk a csatlakozásról itt találhatók: http://sulix.hu/szolgaltatasok/openedu_program/csatlakozas

NIIFI IdP staging környezet

Ez az oldal a NIIFI IdP tesztkörnyezetét írja le. Amennyire lehetséges, ez a tesztkörnyezet megegyezik az éles IdP kiépítésével. A staging környezet célja, hogy az éles IdP-n végzett konfiguráció-változtatások tesztelése könnyen elvégezhető legyen.

Klaszter felépítése

A https://idptest.aai.niif.hu/idp/shibboleth entityID-jú IdP-t jelenleg egy kétgépes klaszter szolgálja ki:

Mindkét környezetben fut egy Terracotta L2 szerver, és egy Tomcat6, az aktuális IdP verzióval. A webkiszolgálást a papigw nevű környezet végzi (ide mutat az idptest DNS bejegyzése), a terhelést pedig a mod_proxy_balancer modullal, AJP protokollon osztja tovább a két IdP példánynak.

Az IdP-k a papigw környezetben futó MySQL példányt használják a perzisztens adatok tárolására, és az éles LDAP szerverhez csatlakoznak.

Az idptest-en uApprove is működik, azonban a terhelési tesztek alatt érdemes kikapcsolni, az ismert bugok miatti sorozatos JDBC hibák elkerülése végett.

Terhelési tesztek

Az idptest alkalmas terhelési tesztek futtatására is, amit az alábbi JMeter szkripttel végezhető. Ez a szkript a dev.aai.niif.hu SP-t használja az autentikációs kérés indítására, majd a shibtest user nevében belép az IdP-n (futtatás előtt érdemes a shibtest user jelszavát megadni :).

Hosszú ideig futtatott, sokszálú terhelés után a Terracotta L2 szervereket érdemes újraindítani, hogy ne fogyasszák feleslegesen a memóriát és a diszk területet.

OpenSSH Server on Ubuntu 14.04 LTS

Ubuntu 14.04 LTS (Trusty Tahr) does not ship with a version of OpenSSH that is compatible with Moonshot. To get Moonshot support for it, you must install a specific Moonshot-enabled version. The following instructions will guide you through the package building process.

All of the instructions below assume that you have root access, and will work as the root user (either directly or using sudo).

The instructions on this page will replace the system provided OpenSSH packages with the Moonshot enabled ones (don't worry, standard SSH things will still work!).

Following the instructions on this page will give you a Moonshot-enabled OpenSSH Server only.

System Preparation

Add the Moonshot libraries.

If you have not already done so, you first need to follow the instructions on OpenSSH Client how to install the Moonshot Libraries on Ubuntu 14.04 LTS.

Prepare the building environment

Install the required packages.

apt-get install build-essential dpkg-dev fakeroot gnupg lintian patch patchutils strace unzip pbuilder debian-builder quilt \
 automake autoconf debhelper dh-make
apt-get source openssh
cd openssh-6.6p1
apt-get build-dep openssh

Building and Installing Instructions

Download the gssapi-generic.patch, then build the packages. cd openssh-6.6p1 cp /tmp/gssapi-generic.patch debian/patches echo "gssapi-generic.patch" >> debian/patches/series debuild -us -uc

Installing Instructions

The new packages can be installed with dpkg.

dpkg -i ../openssh-server_6.6p1-X_<arch>.deb

Configuration Instructions

Once installed, the Moonshot-enabled OpenSSH server will still need a few quick tweaks in order to turn on the Moonshot support.

ErrorHomeURL

Hiba történt

Valószínűleg nem engedélyezted a cookie-k fogadását a böngésződben.

(A Shibboleth működéséhez szükség van erre.)

level0612

Tisztelt Partnerünk!

A webhosting szolgáltatásunk megújításának következő lépését kezdjük meg.

Így szeretnénk felhívni a figyelmét arra, hogy amennyiben CMS-t (Joomla, Drupal, Wordpress stb.) használ, a PHP 7.0 kompatibilitás teszteléséhez szükséges lehet az URL átirányítás kikapcsolása. Előfordulhat az is, hogy a site URL-hez fixen be van írva a portszám - ez esetben ezt törölni kell.

A tesztelhetőség érdekében a CMS-en belüli abszolút hivatkozásokat is át kell írni relatívra, különben előfordulhat, hogy azok még a PHP 5.6-os rendszerből kerülnek kiszolgálásra.

Az Ön oldalának tesztelése akkor teljes, ha a böngésző fejlesztői módjában a hálózat fülön az oldal URL-je kizárólag a 81-es, illetve 444-es porttal kiegészítve jelenik meg a domain oszlopban.

Üdvözlettel: KIFÜ Webhosting

WordPress telepítés

A WordPress aktuális magyar nyelvű verzióját az alábbi link segítségével lehet letölteni: https://hu.wordpress.org/latest-hu_HU.zip

A letöltött ZIP állományt tömörítsük ki a saját gépünkön. Miután a kitömörítettük a ZIP állományt a mappa tartalmát feltölthetjük a tárhelyünkre.

A PWS-en található tárhelyünkhöz a SFTP segítségével tudunk kapcsolódni. Windows operációs rendszer esetén pl. :WinSCP - https://winscp.net/eng/download.php

Szükséges adatok:

SFTP host: ftp.pws.niif.hu

SFTP user: < felhasználói név >

SFTP password: < jelszó >

WinSCP - Munkamenet

A csatlakozás során fogadjuk el, a kiszolgáló kulcsának hozzáadását a gyorsítótárhoz.

Amennyiben sikeresen csatlakoztunk az alábbi mappa szerkezetet láthatjuk:

Könyvtárszerkezet

A már korábban letöltött és kicsomagolt WordPress fájlokat másoljuk fel a www könyvtárba.

Miután feltöltésre kerültek a fájlok a domain név beírása után az alábbi oldalnak kell megjelennie:

WordPress - Kezdőlap

Kattintsunk a Rajta gombra.

Ezen az oldalon végezhető el a WordPress adatbázis beállítása: WordPress - adatbázis beállítás

Szükséges adatok:

MySQL user: < MySQL felhasználói név >

Adatbázis neve: < megegyezik a MySQL felhasználó névvel >

MySQL password: < MySQL jelszó >

MySQL host: < MySQL host >

A tábla előtaggal nem kell foglalkozni amennyiben más WordPress adatbázist nem használunk.

Ha a tovább lépés után azzal a hibával találkozunk, hogy „Sajnos a wp-config.php fájl nem írható” akkor a saját gépünkön hozzuk létre a wp-config.php fájlt majd a szövegdobozban látható tartalmat másoljuk a létrehozott fájlba, mentsük el.

Sajnos, a wp-config.php nem írható

Miután ezzel megvagyunk az elmentett fájlt másoljuk fel a www mappába. Ezt követően kattintsunk a Telepítő futtatása gombra.

Amennyiben felmásolásra került a fájl és sikeresen tudott kapcsolódni az adatbázishoz akkor az alábbi oldalt láthatjuk: WordPress - oldal beállítások

Itt adjuk meg az oldalunk nevét (pl. PWS WordPress teszt oldal), egy felhasználói nevet aki adminisztrátori jogosultsággal rendelkezhet. Jelszóként használhatjuk a WordPress által generált jelszót. Adjuk meg az email címet amelyre a rendszer üzenetet küldhet.

Miután elkészültünk kattintsunk a WordPress telepítése gombra.

Ezzel használatra kész a WordPress alapú oldalunk.

A rendszer egy Új WordPress honlap tárgyú emailt küld a korábban beállított email címre.

A levél tartalmazza az oldal elérhetőségét, a felhasználó nevet és a bejelentkezési címet. WordPress - Sikerült! Új WordPress honlap email

Hasznos linkek:

https://wphu.org/ - WordPress Magyarország

https://hu.wordpress.org/ - Magyar - WordPress

Java Keystore

A Java ún. keystore -ban tartja nyilván a privát és publikus kulcsokat és a tanúsítványokat. Egy-egy elemnek alias neve van, ezzel hivatkozhatunk rá.

A keystore a keytool nevű eszközzel adminisztrálható. Tetszőleges mennyiségű keystore-t használhatunk.

Trusted CA betöltése

Lásd: LDAP_kliens_SSL#Java

Létező kulcspár betöltése

Lásd: Java Keystore import

Új kulcs és tanúsítvány

Kulcs generálás

keytool -genkey -keystore mykeystore.jks -keysize 1024 -alias my_new_cert -keyalg RSA

!!! info

A nyavalyás [Metadatatool]() csak RSA kulcsokkal tud dolgozni. Ha nem adunk meg `-keyalg` opciót, akkor DSA kulcsot generál a `keytool`

Tanúsítvány igénylés

keytool -certreq -keystore mykeystore.jks -file my_certreq.csr -alias my_new_cert

Tanúsítvány betöltése

keytool -import -file my_new.cert -keystore mykeystore.jks -alias my_new_cert