# 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](https://repo.niif.hu/gitweb/gitweb.cgi?p=neptun-ldap-script.git). 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:
* GNU/Linux platform (esetleg UNIX), Windows platformon a futás nem garantálható
* PHP (legalább 5.2-es verzió)
* a következő PHP modulok engedélyezése: LDAP, XML, CURL
## Alapvető célok
A fejlesztés során elsősorban a következő kritériumokat tartottuk szem előtt:
* egyszerű feladatokra egyszerű testreszabhatóság (például új LDAP attribútum felvétele)
* komolyabb feladatok, workflow-k API-szintű támogatása
* általános szinkronizációs keretrendszer, ami nem csak az előre megszabott Neptun interfészekkel képes együttműködni, hanem tetszőleges webszolgáltatás eredményét képes feldolgozni
* intézményi testreszabás lehetősége
* hatékony, memóriakorlátozott futás (a felhasznált memória mérete ne függjön a webszolgáltatás által adott rekordok számától)
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:
* az egyes webszolgáltatás-művelet paraméterezett meghívása, az eredmény rekordokra bontása (*szinkronizációs metódus*)
* a webszolgáltatás eredmény rekordjait (entry) LDAP bejegyzésekkel szinkronizálni (*bejegyzés leképezése*)
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:
```xml
XYZ123
Gipsz
Natália
gipsz@somewhere
gipsz.nati@somewhere
0000
Pest-Buda
Alma tér 2
+36-1 123-1234
```
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:
* egy létező LDAP bejegyzés megtalálása (pl Neptun-kód alapján)
* LDAP attribútum feltöltése egy XML elemben tárolt értékkel
* többértékűség támogatása (például több e-mail cím)
* attribútum érték konverzió (telefonszám, név angol változata)
* egy attribútum értékének több XML elemből történő összeállítása (lakcím, teljes név)
* LDAP bejegyzés módosítása
* új LDAP bejegyzés létrehozása
* objectClass-ok kezelése
* DN kezelése
### A 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
1. LDAP keresés végrehajtása
1. LDAP-ból az attribútumok betöltése az objektum megfelelő mezőibe
1. életciklus metódus meghívása (pl. generált mezők számítása)
1. az XML-ből a mezők frissítése
1. életciklus metódus meghívása (pl. generált mezők számítása)
1. megváltozott mezők keresése
1. életciklus metódus meghívása (mentés előtti teendők végrehajtása)
1. í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:
```php
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:
* egy attribútum mindig felülírásra kerül (ez az alapértelmezett, `always`)
* egy attribútum csak akkor kerül felülírásra, ha az LDAP-ban az attribútum még nem szerepelt (`if-empty`)
* egy attribútum csak akkor kerül írásra az XML-ből, ha a teljes bejegyzés létrehozása történik (`create-only`)
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](http://phpdoc.org) 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:
* `--help`: súgó megjelenítése
* `--teljes`: figyelmen kívül hagyja az utolsó szinkronizálás időpontját
* `--neptunlist`: soronként egy neptun kódot tartalmazó fájl
* `--szinkron`: vesszővel (nem szóközzel) elválasztott lista a szinkronizálandó típusokról
### 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 ), "Entitásazonosító" mezőbe az előző oldalról a "Entitásazonosító" értékét (pl: ), 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 ( ) 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
* [NHH VoIP Konzultáció](http://www.nhh.hu/index.php?id=hir&cid=3976&mid=1807&lang=hu)
* [NHH VoIP Konzultáció dokumentum](http://www.nhh.hu/dokumentum.php?cid=14590&letolt)
* [IP alapú beszédátviteli szolgáltatások Nyilvános meghallgatás dr. Bartolits István](http://www.nhh.hu/dokumentum.php?cid=17592&letolt)
* [A hazai számozási rendszer korszerűsítése EBSZ](http://www.nhh.hu/dokumentum.php?cid=19570&letolt)
## Hírközlési szolgáltatások osztályozása
* [osztályozási rendszer, tájékoztatók](http://www.nhh.hu/?id=hir&cid=1773&mid=1308&lang=hu)
## EU keret szabályozás
* [Európai Szabályozók Csoportjának 2007 decemberében kiadott ajánlása](http://erg.eu.int/doc/publications/erg_07_56rev2_cp_voip_final.pdf)
* [ERG(European Regulators Group) Documents](http://erg.eu.int/documents/docs/index_en.htm)
*[The treatment of Voice over Internet Protocol (VoIP) under the EU Regulatory Framework](http://ec.europa.eu/information_society/policy/ecomm/doc/info_centre/commiss_serv_doc/406_14_voip_consult_paper_v2_1.pdf)
* [Universal Service Directive](http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2002:108:0051:0077:EN:PDF)
* [Authorisation Directive](http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2002:108:0021:0032:EN:PDF)
* [Framework Directive](http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2002:108:0033:0050:EN:PDF)
## Zárt célú hálózatok
* [A HAZAI ZÁRTCÉLÚ HÁLÓZATOK SZEREPÉNEK ÁTALAKULÁSA AZ ELEKTRONIKUS KÖZIGAZGATÁSI SZOLGÁLTATÁSOK BEVEZETÉSE ÉS KITERJESZTÉSE FOLYAMATÁBAN](http://www.zmne.hu/hadmernok/archivum/2007/2/2007_2_pandi.html)
* [276/2006. (XII. 23.) Korm. rendelet a Közigazgatási és Elektronikus Közszolgáltatások Központi Hivatala létrehozásáról, feladatairól és hatásköréről](http://misc.meh.hu/letoltheto/276_2006.pdf)
# TT201805
## Távoli elérés
### Tagok Tanácsa (délelőtt)
* Kezdés: **2018. május 22. 10:00**
* Behívószám (tárgyalóteremből vagy Vidyo klienssel): **003655125804**
* Böngészőn keresztüli elérés: ****, konferencia név: **5804**
* Élő közvetítés (hozzászólás nem lehetséges):
### eduID Workshop (délután)
* Kezdés: **2018. május 22. 12:30**
* Behívószám (tárgyalóteremből vagy Vidyo klienssel): **003655127389**
* Böngészőn keresztüli elérés: ****, konferencia név: **7389**
* Élő közvetítés (hozzászólás nem lehetséges):
## 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:
#### 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:
#### 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:
#### 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:
#### 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:
#### 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:
#### 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:
### 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.
* [Tagi szerződés minta](https://eduid.hu/wp-content/uploads/2017/06/href-contract-member.odt)
* [Partner szerződés (magyar) minta](https://eduid.hu/wp-content/uploads/2017/06/partner-hu-hu.odt)
* [Partner szerződés (angol) minta](https://eduid.hu/wp-content/uploads/2017/11/href-contract-partner.odt)
# 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:
2. A 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: (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. 
5. A létrehozott alkalmazáshoz állítsuk be a szükséges jogosultságokat:
* 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.
Á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 = ""
$ecpUrl = ""
$MyURI = ""
$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](https://help.edu.hu/books/eduid-cloud365/page/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):
* teantID ("Bérlő azonosítója")
* domain nevek, ami alatt a felhasználókat létre kell hozni ("Egyéni tartománynevek"-nél felvett domain-ek, amiket kezelni kell)
* affiliation alapján melyik csoportokba helyezzük át a felhasználókat. Ehhez szükséges egy affiliation és groupID összerendelés (pl student-ek kerüljenek az XY csoportba)
* a létrehozott alkalmazáshoz tartozó "Alkalmazás (ügyfél) azonosítója" és a titkos ügyfélkód
* domain nevek, ami alatt a felhasználókat létre kell hozni
Jelszavakat, bizalmas információkat érdemes egyszer használatos linken keresztül küldeni, pl a 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:
* **Hívószám alapú hívás-irányítás:** telefonszám alapján képes a gatekeeper a hívott felet megtalálni. Hívni - bár a lehetőség természetesen megvan rá - nem IP cím vagy domain név alapján kell, hanem a szokványos telefonálásnál használt hívószámok segítségével (pl. 00361001234).
* **Hívás engedélyezés:** hívás kezdeményezése esetén a gatekeeper hivatott eldönteni, hogy a hívó fél jogosult-e a hívás kezdeményezésére illetve fogadására.
* **Hívás hitelesítés:** igény szerint hitelesítheti a hívó felet (pl. jelszó).
* **Sávszélesség limitálás:** hívások sávszélességének kontrollálása.
* **Számlázási információk szolgáltatása:** hívás rekordok (CDR) szolgáltatása.
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.
#### 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:
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://:81 vagy
https://: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](https://help.edu.hu/books/egyeb/page/level0509)
1. [A 2019. június 12-én kiküldött tájékoztató levél](https://help.edu.hu/books/egyeb/page/level0612)
*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](https://spaces.internet2.edu/display/SHIB/SPPKIConfig):
* PKCS8 struktúra készítése, amely tartalmazza a privát kulcsot
openssl pkcs8 -topk8 -in be.aai.niif.hu.key -nocrypt -outform DER -out be.aai.niif.hu.pkcs8
* El kell készíteni a tanúsítványhoz tartozó tanúsítvány láncot
cat ca-cert.pem be.aai.niif.hu.crt >cert-bundle.pem
* Létre kell hozni egy keystore-t. Ezt egy fake kulcs és tanúsítvány létrehozásával csináljuk.
/usr/java/latest/bin/keytool -genkey -keyalg RSA -alias "selfsigned" -keystore myKeystore.jks -validity 360 -storepass "secret"
* Töröljük a fake kulcsot, marad az üres keystore
/usr/java/latest/bin/keytool -delete -alias "selfsigned" -keystore myKeystore.jks -storepass "secret"
* A Shibboleth IdP **extkeytool** nevű eszközével betöltjük a pkcs8-ban levő kulcsot és a tanúsítványokat az üres keystore-ba. Ehhez persze be kell állítani az `IDP_HOME` változót.
export IDP_HOME=/usr/local/shibboleth-idp
/usr/local/shibboleth-idp/bin/extkeytool -importkey -keystore myKeystore.jks -alias be -storepass secret \
-keyfile be.aai.niif.hu.pkcs8 -certfile cert-bundle.pem -provider org.bouncycastle.jce.provider.BouncyCastleProvider
* Ha minden jól ment, akkor láthatjuk, hogy ott virít a kulcsunk a keystore-ban:
[~](bajnokk@dev)$ /usr/java/latest/bin/keytool -list -keystore myKeystore.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
be, Aug 31, 2007, PrivateKeyEntry,
Certificate fingerprint (MD5): 2B:D6:14:00:44:D7:9C:B8:F9:DC:52:CD:3D:E1:3F:FB
# Xmltooling Log4cpp patch
```cpp
--- xmltooling/soap/impl/SOAPClient.cpp.orig 2008-03-14 23:50:29.000000000 +0100
+++ xmltooling/soap/impl/SOAPClient.cpp 2008-04-25 13:14:29.000000000 +0200
@@ -89,8 +89,11 @@
XercesJanitor 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(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.
1. A Tagok Adminisztratív Kapcsolattartóinak kötelező feliratkozniuk a kapcsolattartásra szolgáló levelezőlistára.
1. 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.
1. A Tagok Tanácsának ülésein a Tagok és Partnerek részéről megjelentek **felszólalhatnak**
1. 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.
1. 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.
1. 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: ).
1. Indokolt esetben a határozatok angol nyelven is publikálásra kerülnek.
## Döntéshozatal
### Döntéshozatal formái
* **Tiltakozás hiányában meghozott döntés**: a Föderációs Operátor elektronikus úton eljuttatja a határozati javaslatot a Tagok Tanácsa tagjainak. Amennyiben a megadott határidőn belül a Tagok Tanácsának egyetlen szavazati joggal rendelkező tagja sem emel kifogást, a határozat elfogadásra kerül. Ellenkező esetben — amennyiben a Föderációs Operátor fenntartja a határozati javaslatot — Egyszerű szótöbbséggel döntenek
* **Egyszerű szótöbbség:** a Tagok Tanácsának tagjai vagy egy ülésen személyesen, vagy meghatározott módon elektronikus úton, vagy egyéb – a Tagok Tanácsa által előzetesen meghatározott módon – szavaznak a határozati javaslatról. A határozat elfogadásra kerül, ha a leadott szavazatok 50%-a +1 szavazat támogatja azt.
* **Minősített többség:** a Tagok Tanácsának tagjai vagy egy ülésen személyesen, vagy meghatározott módon elektronikus úton, vagy egyéb – a Tagok Tanácsa által előzetesen meghatározott módon – szavaznak a határozati javaslatról. A határozat elfogadásra kerül, ha az összes Tag 66%-a + 1 szavazat támogatja azt.
### 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:**
* új Tag vagy Partner felvétele a Föderációba;
* Tag vagy Partner új IdP-jének vagy SP-jének regisztrálása
**Tagok Tanácsának tiltakozás hiányában tíz (10) munkanap elteltét követően elfogadásra kerülő döntések:**
* a Műszaki Dokumentumokat érintő kisebb módosítások.
**Tagok Tanácsának egyszerű szótöbbséggel meghozott döntése szükséges:**
* Tagok Tanácsának saját eljárási szabályainak elfogadása, módosítása;
* Föderációs Szabályzat Műszaki Dokumentumainak jelentősebb módosításához, illetve bármely más dokumentum módosításához;
* a Föderációs Szabályzathoz kapcsolódó új dokumentum elfogadásához;
* Tagok ill. Partnerek vitás kérdéseivel kapcsolatos döntésekhez
**Tagok Tanácsának minősített többségű döntése szükséges:**
* a Döntéshozatal rendjének megváltoztatásához
* nemzetközi szervezetekhez és együttműködésekhez történő csatlakozásról szóló döntéshez.
* a Szolgáltatási díj bevezetéséhez, összegének megváltoztatásához;
* a Föderáció megszüntetéséhez.
# 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:
* [Tagok Tanácsának Működése](https://help.edu.hu/books/egyeb/page/tagok-tanacsanak-mukodese)
## 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](https://docs.google.com/document/d/1XkFqQx9npWVgftAU1b0cRoqiTNrhj9oqEWpMWaIJO6o/edit?hl=en_US), [SP üzemeltetési szabályok](https://docs.google.com/document/d/1QZWwFqHm4VNyIn6GdKnOzyA0Xdg2uYgwlAkJA1ffpM8/edit?hl=en_US). 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ó
* [Elfogadásra javasolt változat]()
* [Változások a publikált változathoz képest](https://help.edu.hu/books/aai/page/href-attributum-specifikacio)
Lényeges változtatások:
* Az attribútumok eredeti definícióját a sémák határozzák meg. Az Attribútum Specifikáció csak ezek föderáción belüli speciális értelmezését adja meg.
* Az edupersonPrincipalName és az edupersonTargetedId újra ki nem oszthatóságának megkövetelése
* scope pontosabb meghatározása
* eduPersonOrgUnitDN nem "recommended", hanem "optional"
#### Metadata specifikáció
* [Elfogadásra javasolt változat]()
* [Változások a publikált változathoz képest](https://help.edu.hu/books/aai/page/href-metadata-specifikacio)
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:
* jogszabályi hivatkozások aktualizálása
* hivatkozott anyagok hivatkozásának aktualizálása (pl. cím és elérhetőség módosítás)
* helyesírási és nyelvhelyességi hibák, elírások, valamint formázási hibák javítása
A Föderációs Operátor köteles a dokumentumok érvényes verzióját a 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](https://help.edu.hu/books/aai/page/hrefglossary)
### 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](https://help.edu.hu/books/aai/page/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 felé** a magyar eduID föderációból résztvenni kívánó entitásokat
* a **magyar eduID felé** az eduGAIN metaadatokat a már ismert aláírókulccsal aláírva. Az eduID-ben szereplő entitások az eduGAIN metadatában nem szerepelnek (mivel duplikáció lenne).
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
* elfogadja a [Metadata Registration Practice Statement](https://help.edu.hu/books/aai/page/hrefmetadataregistrationpracticestatement) (angol nyelvű) dokumentumot,
* felhatalmazza a Föderációs Operátort a csatlakozási nyilatkozat aláírására.
## 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):
* A: IdP sends all necessary information
* B: IdP sends minimal information
* C: IdP sends basic information while some required information is missing
* C: IdP sends eduPersonTargetedId with the wrong (legacy) syntax
* D: IdP sends superfluous personal information
* D: IdP sends some subset of the requested information, but not the basic information (see definition below)
* F: Incorrect value syntax (except for eptid above)
* F: R&S category support is indicated but its requirements are not satisfied
* F: No attributes received
**Additional points (A-C):**
* IdP R&S support is indicated
**Penalty points (A-C):**
* Redundant attributes are missing, but information is available
* IdP sends superfluous non-personal information (eptid, homeOrganizationType, etc)
## Definitions
* attribute: a non-empty SAML Attribute sent as a part of a SAML AttributeStatement
* information: either an attribute or a set of attributes for which a transformation or combination algorithm is available to produce data for an application (ie: e-mail, affiliation, name)
* requested information: the set of attributes or meta-attributes (such as a non-reassigned identifier or a name), that is requested by the SP by using SAML metadata, whether or not isRequired is flagged.
* all necessary information: set of released attributes that can provide all requested information
* minimal information = required information: If the tested SP has an entity category, where the minimal set is defined (such as R&S), the minimal information is the minimal set. Otherwise it is the set of attributes that can provide the subset of requested information, where isRequired is set in the SAML metadata.
* basic information: a set of attributes, including at least a persistent identifier represented by at least one of:
* eduPersonPrincipalName
* eduPersonTargetedId (either as a SAML NameID or an attribute)
* eduPersonUniqueId
* superfluous attribute: attribute that is sent by the IdP even though the information is not requested by the SP. Sending the same attribute in different NameFormats (such as URI and OID) does not count as superfluous information
* R&S requirements: according to the R&S specification, the following attributes must be provided by an R&S IdP:
* eduPersonPrincipalName
* mail
* displayName OR (givenName AND sn)
* redundant attributes: information that can be extracted from one or more attributes:
* schacHomeOrganization <= eduPersonScopedAffiliation / eduPersonPrincipalName
* eduPersonAffiliation <= eduPersonScopedAffiliation
* cn <= sn+givenName
* cn <= displayName
# 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.
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.
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](https://wiki.moonshot.ja.net/display/Moonshot/Install+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_.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.
* Configure the OpenSSH server to use Moonshot by editing /etc/ssh/sshd_config. Check the following lines are present and uncommented:
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPIStrictAcceptorCheck yes
* Now restart the OpenSSH server
systemctl restart ssh
* Configure the [OpenSSH Client](https://wiki.moonshot.ja.net/display/Moonshot/OpenSSH+Client).
# NeptunWebservicePPKE
```perl
###############################################################################
# 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' =>
''.$neptuncode.'
'.$neptunpass.'')
);
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:
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 -
**Szükséges adatok:**
**SFTP host:** ftp.pws.niif.hu
**SFTP user:** < felhasználói név >
**SFTP password:** < jelszó >
*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:
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:
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:
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.
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.)
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"
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.
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 -
# 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](https___github.com_NIIF_simplesamlphp-module-attributelimit.md) 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:
```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
```bash
#!/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ó](https://help.edu.hu/books/egyeb/page/neptunldapsyncimpl)
## Feltételezések
* A Neptun tartalmazza az SDA által kifejlesztett szinkronizációs webservice-t (ezt jelen pillanatban az SDA-tól kérni kell)
* A Neptun ezen kívül biztosít egy olyan webservice-t is, amely ellenőrizni tud egy neptunkódhoz tartozó jelszót (információink szerint ilyet néhány helyen biztosít az SDA)
* Létezik egy vagy több - az intézmény által fejlesztett vagy üzembe állított - webes adminisztrációs alkalmazás, ahol a felhasználók a Neptun jelszavuk birtokában tudnak maguk számára
* LDAP jelszót generálni (a neptunos jelszó **nem** szinkronizálódik az LDAP-ba)
* LDAP jelszót megváltoztatni
* LDAP azonosítót generálni (opcionális, az intézmény algoritmikusan generált azonosítókat is alkalmazhat)
* további LDAP attribútumokat generáltatni (pl. levelezéshez, Unix bejelentkezéshez stb.)
## Felhasználó életciklusa
1. Neptun felhasználói bejegyzés létrehozása (részletek nélkül)
1. Felhasználói adatok szinkronizálása az LDAP-ba
1. LDAP jelszó aktiválása
1. Neptun adatok változásának szinkronizációja
* személyi adatok
* státusz adatok
* szervezeti kapcsolódás adatai
* oktatási adatok
1. *(opcionális)* POSIX attribútumok generálása
1. *(opcionális)* Elfelejtett LDAP jelszó újragenerálása Neptun autentikáció után
1. Neptun státusz adatok alapján passzív / kilépett státuszba helyezés
1. 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.
* Szervezeti struktúra
* paraméterek: nincs
* visszatérés: szervezeti egységek fastruktúrája (egységenként: kód, szerv. egység neve, típusa)
* ritka szinkronizálás (félévente)
* Neptun kódok és státuszok
* paraméterek: opc. időbélyeg, opc. Neptun lista
* visszatérés: Neptun kód, hallgatói státusz, oktatói státusz, alkalmazotti státusz
* gyakori szinkronizálás (legalább naponta)
* Személyi adatok
* paraméterek: opc. időbélyeg, opc. Neptun lista
* visszatérés: Neptun kódhoz tartozó személyi adatok
* gyakori szinkronizálás (naponta)
* Szervezeti kapcsolódás
* paraméterek: opc. időbélyeg, opc. Neptun lista
* visszatérés: Neptun kódhoz tartozó szervezeti egységek kódja
* ritka szinkronizálás (félévente)
* Oktatási adatok
* paraméterek: Neptun lista
* visszatérés: minden megadott neptun kódhoz az összes oktatási adat (nem csak a változások)
* ritka szinkronizálás (szorgalmi időszakban hetente, tárgyjelentkezési időszak kezdetétől regisztrációs hét végéig nincs szinkronizálás)
## Implementációk
* [NIIF szinkronizáció implementáció (PHP)](https://help.edu.hu/books/egyeb/page/neptunldapsyncimpl)
* [Neptun webservice szinkronizációs próbálkozások a PPKE-n](https://help.edu.hu/books/egyeb/page/neptunwebserviceppke)
# 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
* the same information into different attribute-value pairs, eg. `fooFedHospitalWard: urn:foo:surgery` and `barFedAbteilung: urn:bar:Chirurgie` could carry the same information ("a medical institution has surgical ward"), while
* the same attribute-value pairs can carry different information, eg. `eduPersonAffiliation: student` could be used for higher educational students only in one federation but in the other this could mean everybody studying in education (from primary schools to PhD).
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:
* the confederation maintains a common vocabulary of allowed attribute values
* peers agree on attribute value interfaces (what Home sends and Remote accepts), independently of the confederation
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
* eCCS **MUST** be distributed and very close to the BE because of maintaining **privacy**. No central elements (outside the scope of the 2 federations) shall ever receive users' attributes.
* Representing every possible conversion scenarios in conversion policy might be quite difficult
* It would be quite hard if even possible to define custom 'common formats' between subsets of federations using the 'big' eduGAIN MDS. It would be necessary if some federations have different levels of cooperations requiring different attributes.
### The Shibboleth Way
Shibboleth uses `*AttributeDefinition` elements to define conversion rules from data source (i.e. LDAP) attributes to "resolved" attributes. `AttributeDefinition`s can depend on `DataConnector`s or other `AttributeDefinition`s.
It can be used for attribute conversion in eduGAIN as well if we can define a `DataConnector` that can use attributes retrieved
* from the IdP (at the HBE), or
* from the HBE (at RBE).
Shibboleth2 has a number of built-in `AttributeDefinition`s:
* [SimpleAttributeDefinition](https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverSimpleAttributeDefinition): pass through the retrieved value of the attribute
* [ScopedAttributeDefinition](https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScopedAttributeDefinition): append a scope to the attribute value
* [TemplateAttributeDefinition](https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverTemplateAttributeDefinition): sets value based on an arbitrary template of constant string and other attributes
* [MappedAttributeDefinition](https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverMappedAttributeDefinition): sets value according to conditions on (possibly other) attribute values
* [ScriptedAttributeDefinition](https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinition): execute a [JSR-223](https://scripting.dev.java.net/) (Java) script to determine the attribute value. This script gets the context information in `requestContext` variable.
* ... and some others ...
#### 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.
* TODO: does EduGAIN have the notion "relying party"?
#### Open issues
* Licencing issue (Shibboleth has Apache2 style licence)
* Amount of code needs to be included into eduGainBase is unknown. Worst case: whole Java Shibboleth library (`edu.internet2.middleware.shibboleth.common.*`)
## 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):
* requester/issuer
* attribute values
* authentication context
# 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?](http://sulix.hu/szolgaltatasok/openedu_program)), 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:
# 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 entityID-jú IdP-t jelenleg egy kétgépes klaszter szolgálja ki:
* papigw.aai.niif.hu virtuális környezet (london, debian squeeze)
* sandbox.aai.niif.hu virtuális gép (xen, debian lenny)
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](http://httpd.apache.org/docs/current/mod/mod_proxy_balancer.html) 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](https://admin.pws.niif.hu/redmine/attachments/33/idp-loadtest.jmx) [JMeter](http://jakarta.apache.org/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](https://wiki.moonshot.ja.net/display/Moonshot/OpenSSH+Client).
## 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_.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.
* Configure the OpenSSH server to use Moonshot by editing /etc/ssh/sshd_config. Check the following lines are present and uncommented:
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPIStrictAcceptorCheck yes
* Now restart the OpenSSH server
service ssh restart
* Configure the [OpenSSH Client](https://wiki.moonshot.ja.net/display/Moonshot/OpenSSH+Client).
# 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:
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 -
**Szükséges adatok:**
**SFTP host:** ftp.pws.niif.hu
**SFTP user:** < felhasználói név >
**SFTP password:** < jelszó >
*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:
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:
Kattintsunk a **Rajta** gombra.
Ezen az oldalon végezhető el a WordPress adatbázis beállítása:
**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.
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:
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.
 
**Hasznos linkek:**
- WordPress Magyarország
- 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](https://help.edu.hu/books/ldap/page/ldap-kliens-ssl)
## Létező kulcspár betöltése
Lásd: [Java Keystore import](https://help.edu.hu/books/egyeb/page/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