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

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:

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/

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

Intézményi_üzemeltetésű_Sulinet_Eduroam_AP-k_konfigurációja

Az eduroam hálózat lehetőséget biztosít arra, hogy a Sulinet Dashboard felületen felvett felhasználók bármilyen, eduroam SSID-t használó intézményben internet-hozzáféréshez jussanak.

Ezzel kapcsolatban felmerültek igények, hogy bármilyen típusú, az intézmény által üzemeltetett eszközzel is megvalósítható legyen ezen hozzáférés. Ezen szolgáltatás igénybevételéhez egy olyan iskolai eduroam/eduID felhasználási szerződést kell kötni az intézménnyel, amelyben az intézmény vállalja, hogy az eduroam szabályai szerint működteti az AP-ket és erre vonatkozó szerződést köt a KIFÜ-vel.

Technikailag legtöbb vezeték nélküli eszközön megvalósítható az eduroam hálózat beállítása;

Eszköz beállításához szükséges paraméterek

Bármilyen vezeték nélkül eszköz, mely képes kezelni a WPA2 Enterprise protokollt, azon be lehet állítani az eduroam hálózatot az alábbiak szerint (egyelőre csak úgy működik, ha a vezeték nélküli eszköz a sulinetes router privát vagy védett szemensére van kötve):

Radius szerver IP: 195.111.98.15, 195.111.115.15

Radius szerver hitelesítéshez használt port (authentication port): 1812

Radius szerver naplózáshoz használt port (accouting port): 1813

Jelszó (shared secret): minden végpontnak egyedi shared secretje van, amit a Dashboardon olvashat

A WPA2 Enterprise protokoll általában az eszköz WIFI-vel foglalkozó menüjének a Wireless Security menüjében található meg.

A fentieken kívül ügyelni kell a következőkre:

Ha minden beállítás megtörtént és fogható az eduroam SSID a vezeték nélküli eszköz révén, akkor a Windows operációs rendszert használók tekintsék meg ezt a leírást a gyors csatlakozás érdekében.

SOHO eszköz beállításához szükséges paraméterek

A konfigurációs segédlet egy TP-LINK TL-WR1043ND V1 eszközön kerül bemutatásra a gyári szoftverrel.

OpenWRT telepítése a példakánt TP-LINK TL-WR1043ND v1 routerre

Konfiguráció Cisco AP-k esetén

Az alábbi konfiguráció egy Cisco AIR-SAP1602I-E-K9 típusú AP lényegi konfigurációja, mely segítséget nyújthat az intézmény által üzemeltetett eszköz beállításához.

	! Cisco típusú eszköz esetén a különféle hitelesítési-, authoricáiós- és logolási művelethez engedélyezni kell az AAA-t (Authentication, Authorization, Accounting)</br>
	aaa new-model</br>
	! RADIUS szerver csoportot kell létrehozni radius_eduroam néven (bármilyen név csoportnév megfelelő, viszont később tudni kell rá hivatkozni), melybe a lenti két szerver tartozik; konkrét szerver IP definiálása lejjebb  található</br>
	aaa group server radius radius_eduroam
	 server name radius2.eduroam
	 server name radius1.eduroam</br>
	! létre kell hozni egy AAA method-listet, ami a fenti Eduroam szerverekre hivatkozik</br>
	aaa authentication login eap_eduroam group radius_eduroam</br>
	! a lenti beállítással rögzítésre kerülnek a hitelesítés hibák (téves jelszó, téves felhasználói név használata)</br>
	aaa accounting send stop-record authentication failure
	aaa accounting update newinfo</br>
	! létre kell hozni egy accounting_eduroam nevű method-listet (szintén bármilyen más fantázianév megfelelő, viszont később tudni kell rá hivatkozni), ami a hálózati tevékenység logolását engedélyezi; ez szintén a radius-szerverekre  hivatkozik</br>
	aaa accounting network accounting_eduroam start-stop group radius_eduroam</br>
	! beállítjuk, hogy az AP több SSID-t is kezeljen és logoljon (amennyiben az intézménynek van saját SSID-ja az eduroam-on kívül)</br>
	dot11 mbssid
	dot11 syslog</br>
	! létre kell hozni az eduroam nevű SSID-t és úgy beállítani, hogy a RADIUS szervereket használja a hitelesítéshez</br>
	dot11 ssid eduroam
	   vlan 101
	   authentication open eap eap_eduroam
	   authentication network-eap eap_eduroam
	   authentication key-management wpa version 2
	   accounting accounting_eduroam
	   mbssid guest-mode</br>
	! attól függően, hogy az AP tudja-e a 802.11a-t, attól függően  Dot11Radio0 és/vagy Dot11Radio1 interfészeken is be kell állítani az eduroam vlan titkosítását és az SSID interfészhez történő  hozzárendelését</br>
	interface Dot11Radio0 és/vagy Dot11Radio1
	 encryption vlan 101 mode ciphers aes-ccm
	 ssid eduroam</br>
	! hozzá kell rendelni a BVI1 interfészt egy tetszőleges VLAN-hoz, aminek egyeznie kell a fenti dot11 ssid eduroam parancsban megadottakkal</br>
	interface Dot11Radio0.101
	 encapsulation dot1Q 101
	 no ip route-cache
	 bridge-group 1
	 bridge-group 1 subscriber-loop-control
	 bridge-group 1 spanning-disabled
	 bridge-group 1 block-unknown-source
	 no bridge-group 1 source-learning
	 no bridge-group 1 unicast-flooding</br>
	! az AP uplink interfészét is hozzá kell rendelni a BVI1 interfészhez</br>
	interface GigabitEthernet0
	 bridge-group 1
	 bridge-group 1 spanning-disabled
	 no bridge-group 1 source-learning</br>
	! IP adatokkal el kell látni a BVI1 interfészt; a lenti példában DHCP-n keresztül kapja meg a menedzseléshez szükséges IP címet, ami az ap1 kliens-azonosító miatt mindig ugyanaz lesz< br/>
	interface BVI1
	 ip dhcp client client-id ascii ap1
	 ip address dhcp
	 no ip route-cache</br>
	! meg kell adni egy interfészt, amit forrás-címként fog használni az eszköz a radius-szerverrel történő kommunikáláshoz, pl. Loopback0</br>
	ip radius source-interface Loopback0</br>
	! meg kell adni a legelső sorokban meghatározott radius-szerverek IP-jét, a kommunikációs portokat és a radius-szerver által használt jelszót titkosított formában</br>
	radius-server attribute 32 include-in-access-req format %h
	radius server radius1.eduroam
	 address ipv4 195.111.98.15 auth-port 1812 acct-port 1813
	 key 0 *egyedi_shared_secret_helye*
	radius server radius2.eduroam
	 address ipv4 195.111.115.15 auth-port 1812 acct-port 1813
	 key 0 *egyedi_shared_secret_helye*</br>
	! engedélyezzük az STP-t és az IP routolását a BVI1-hez rendelt interfészeken</br>
	bridge 1 protocol ieee
	bridge 1 route ip
	bridge irb

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

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

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