Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Programrendszerek Fejlesztése 14/8 1. Tartalom  Alkalmazásszerverek, alkalmazásszerverek felépítése  Java EE alkalmazások és modulok és kezelésük 

Hasonló előadás


Az előadások a következő témára: "Programrendszerek Fejlesztése 14/8 1. Tartalom  Alkalmazásszerverek, alkalmazásszerverek felépítése  Java EE alkalmazások és modulok és kezelésük "— Előadás másolata:

1 Programrendszerek Fejlesztése 14/8 1

2 Tartalom  Alkalmazásszerverek, alkalmazásszerverek felépítése  Java EE alkalmazások és modulok és kezelésük  Alkalmazásszerverek kezelése (monitoring, menedzsment)  Clustering, Jgroups  Alkalmazásszerverek biztonsága  Java Connector Architecture

3 Alkalmazásszerver Alkalmazásszerverek  Üzleti alkalmazások számára biztosítanak megfelelő infrastruktúrát – Middleware  Programozási modell különböző funkciókra (pl. perzisztencia-kezelés)  Szabványos és saját (gyártóspecifikus) API-k  Rendszerint a következő rétegek vannak:  Alkalmazás szerver  Kliens  Adatbázis  Gyakorlatilag futtató környezetként szolgál a rá feltelepített alkalmazások számára  Ahhoz, hogy az alkalmazásokat futtatni tudja, azoknak meg kell felelniük bizonyos formai feltételeknek Alkalmazás hardver, operációs rendszer, adatbázis, hálózat, … Alkalmazás

4 Alkalmazásszerverek  Java:  Ingyenes/szabad:  JBoss (RedHat)  Glassfish (Sun)  Geronimo (Apache)  JOnAS  Fizetős  WebSphere (IBM)  WebLogic (BEA)  OC4J (Oracle) .NET:  Microsoft IIS +.NET Framework

5 Architektúra – jellemző modulok  Perzisztenciakezelő:  Adatok hosszú távú tárolásához (pl. adatbázisba) biztosít szolgáltatásokat  Web konténer:  Web-alapú felhasználói felület számára biztosít futási környezetet  EJB konténer:  EJB-modulok (üzleti logika) számára biztosít futási környezetet  Java Messaging Services (JMS) kezelő:  Üzenetküldés (aszinkron kommunikáció) számára biztosít erőforrásokat és szolgáltatásokat  Message-driven beanek is ezt használják  Címtár (JNDI) kezelő:  Felhasználói és rendszerkomponensek név alapú elérésére biztosít lehetőséget a komponensek fizikai helyétől függetlenül  Tranzakciókezelő:  Üzleti tranzakciók kezeléséhez nyújt támogatást  Nemcsak az adatbázis-tranzakciók kezelését végzi (arra ott a perzisztenciakezelő), hanem az üzleti logika építőelemeinek (műveletek) tranzakcióba zárásáért és atomi kezeléséért felelős  Management interfész:  Az alkalmazásszerver egyes komponenseit (rendszer és felhasználói) lehet ezen keresztül vezérelni (beállítások és műveletek)  Sok alkalmazásszerver esetében van ehhez web-alapú kliens, ami integrálva van a szerverhez, de jellemzően más formában is elérhető (pl. JMX)  Újabban webszolgáltatás-kezelő:  Webszolgáltatások számára biztosít futási környezetet

6 Architektúra - JBoss  Mikrokernel alapú: van egy kicsi mag, mint platform, és az alkalmazásszerver összes szolgáltatása ezen keresztül kapcsolódik egymáshoz  JBoss esetén a mikrokernel a JMX-re (Java Management Extesion) épül  Előnyök:  JMX egy szabvány  Tetszőleges JMX-képes kliens alkalmazás felhasználható a modulok kezeléséhez (web alapú, grafikus vagy konzolos is létezik)  Minden modul ugyanúgy kezelhető (JMX-interfészen keresztül)  Nagyfokú modularitás:  felesleges modulok adott telepítés esetén eltávolíthatók  Az egyes modulok velük ekvivalens másikra cserélhetők (pl. perzisztencia: Hibernate  Toplink)

7 Architektúra - WebSphere

8 J2EE alkalmazások és modulok  Moduláris felépítésű üzleti alkalmazások, amelyek alkalmazásszerver-környezetben képesek üzemelni  J2EE modulok típusai:  Web modul (WAR): web-alapú felhasználói felületek számára (egyszerű háttérlogikával)  EJB modul (JAR): bonyolultabb üzleti logika számára  Alkalmazáskliens modul (JAR): nem web-alapú kliens alkalmazások számára  Erőforrás-adapter modul (RAR): nem J2EE-kompatibilis rendszerekkel való integráció számára  Enterprise alkalmazás (EAR): előző négy modultípus egységbe csomagolására

9 Modulok helye Web modul (WAR) EJB modul (JAR) Alkalmazáskliens modul (JAR) Enterprise alkalmazás (EAR) Erőforrás-adapter modul (RAR) ?

10 Alkalmazások és modulok telepítése  Elkészített modulok és alkalmazások adott formai követelményeknek megfelelően  Rendszerint van ún. hot-deploy könyvtár: ebbe bemásolva az elkészített modulokat, azokat az alkalmazásszerver automatikusan telepítni (beállítható időközönként vizsgálja a változásokat)  Rendszerint van lehetőség webes menedzsmentre, általában ezen keresztül is lehet modulokat telepíteni

11 Alkalmazások és modulok telepítése - JBoss  Szabvány J2EE modulok és alkalmazások telepíthetők  JBoss-os kiegészítő modulok is telepíthetők  Megfelelő szerver profilban lévő deploy könyvtár tartalmazza a telepített alkalmazásokat:  Becsomagolt (archív) modulok (.ear,.war,.jar fájlok)  Ún. exploded modulok (hasonló az előzőhöz, csak nincs egybecsomagolva, könyvtárként jelenik meg)  JMX interfészen keresztül is telepíthetők modulok

12 Alkalmazások és modulok telepítése - WebSphere  Webes vagy konzolos menedzsment eszközök használatával  Hot directory-ba való bemásolással:  Java EE csomagolás nélkül is telepíthetők alkalmazások (akár Java forrásfájl is telepíthető így)  A hiányzó dolgokat (telepítési leírók, stb.) az alkalmazásszerver automatikusan legenerálja,  Megfelelő fejlesztőeszköz használatával:  Pl. Rational Application Developer for WebSphere Software, Rational Application Developer Assembly and Deploy  Ezek jellemzően az alkalmazásfejlesztés életciklus nagyobb részét támogatják (tervezés, fejlesztés, tesztelés, telepítés, stb.)

13 Menedzsment  Java Management Extesions (JMX)  Standard API  Erőforrások kezelésére és monitorozására: alkalmazások, eszközök, szolgáltatások, JVM, stb.  Jellemző használat:  Alkalmazások konfigurációjának elemzésére és módosítására  Alkalmazások viselkedéséről statisztikai adatok gyűjtése, és elérhetővé tétele  Állapotváltozások és hibák esetén történő értesítésekre  Moduláris architektúra  rugalmasan bővíthető  Ún. MBean-ek testesítik meg a kezelhető erőforrásokat (szabvány interfésszel rendelkező osztályok)

14 Menedzsment - JBoss  JMX Console: web alapú kliens a JMX interfész használatához  Twiddle: parancssori eszköz a JMX interfész használatához  Lehetőségek:  Szolgáltatások, modulok állapota (indítási és leállítási lehetőség)  Statisztikák (kérések száma, gyorsítótárak, készletek állapota stb.)  Beállítások, finomhangolás  …  Fontos: JMX Console alkalmazást éles rendszeren tiltani kell, mert ehhez hozzáférve a JBosst futtató gépen tetszőleges parancs futtatható

15 Menedzsment - JBoss  Web Console: webes felület a JBoss fontosabb részeinek kezeléséhez  JMX Console-lal szemben menedzsment szempontjából logikailag csoportosítja az erőforrásokat  Lehetőséget biztosít az egyes értékek grafikonon történő nyomon követésére valamint pillanatképek készítésére

16 Menedzsment - WebSphere  A WebSphere egyik előnye a kiváló menedzsment lehetőség  Központilag több különálló szerver kezelhető:  Adminisztratív ügynök  Munkakezelő (Job manager): menedzsment feladatok (telepítés, elindítás, stb.) kezelésére  Centralizált telepítéskezelő: távoli szerverekre egy központi helyről lehet alkalmazásokat telepíteni  Alkalmazások csoportosíthatók, a csoportok egységesen kezelhetők  Scriptek készítésének támogatása parancssori eszközökkel  programozható menedzsment  JMX itt is használható

17 Clustering  Nagy teljesítményigényű vagy kritikus üzleti alkalmazások esetén alkalmazzák  Több alkalmazásszerver példány együttműködik a feladatok elvégzésére  Előnyök:  Ha a folyamatok részei párhuzamosíthatók, akkor az egyes részfolyamatok futhatnak párhuzamosan  a teljes folyamat gyorsabban végrehajtódik  Load balancing: mindig olyan szerver példány kapja a következő feladatot, amelyiknek a legkisebb a terhelése  Hibatűrés: Amennyiben egy szerver példány kiesik (hálózati vagy egyéb hiba esetén), a feladatát a többiek át tudják venni  J2EE szabvány szerint támogatja az alkalmazások clusterekre történő telepítését  A clustering tényleges megvalósítása gyártófüggő  Rendszerint van valamilyen előtétrendszer, ami a kéréseket szétosztja a rendelkezésre álló példányok között – egyes gyártók támogatják az automatikus elosztást  Probléma: munkamenet (session) hogyan kerüljön át az egyik példányról a másikra

18 JGroups  Megbízható multicast kommunikációra felhasználható Java osztálykönyvtár (licensz: LGPL)  Egymással kommunikáló csomópontokból csoportokat képez  A csoportok tetszőleges LAN-on vagy WAN-on kialakíthatók  Csoportok kialakítása dinamikusan (futásidőben) történik  Point-to-point és point-to-multipoint kommunikációt is támogat  Jellemzői:  Veszteségmentes adatátvitel minden címzettnek (elveszett üzenetek újraküldésével  Nagy üzenetek tördelése (küldő oldalon) és visszaállítása (fogadó oldalon)  Üzenetsorrend megtartása  Atomi műveletvégzés: vagy mindenki megkapja a teljes üzenetet vagy senki  Természetéből fakadóan képes clustering támogatására

19 JGroups  Többféle átviteli protokoll támogatása:  TCP  UDP  Tunnel  Többféle felderítési protokoll támogatása:  Ping  TCPGossip  TCPPing  Mping  Többféle hibadetektáló protokoll támogatása:  FD: szomszédoknak küldött heartbeat üzeneteket használ  FD_SOCK: TCP socketek gyűrűje, minden csomópont a szomszédjához kapcsolódik  VERIFY_SUSPECT: gyanús csomópontot megpróbálja „pingelni” (központi koordinátort használ)  Többféle megbízható kézbesítési protokoll támogatása:  Unicast: nyugta alapú (akkor szól, ha minden rendben van)  NAKACK: az üzenetek sorozatszámot kapnak, ha a sorozatban hiba keletkezik, újraküldést kér a fogadó (akkor szól, ha hiba van)

20 Clustering - JBoss  Beépített clusterkezelés  JBoss terminológia:  Partition: egy cluster  Node: egy JBoss példány  JGroups felhasználása a megbízható üzenetküldésre a clustereken belül a node-ok között  dinamikus felderítés és csatlakozás/kilépés  Csatornák használata:  JBoss cache által használt csatornák:  Web session replication  EJB3 stateful session bean replication  EJB3 entity caching  Általános célú clustering szolgáltatás:  HAPartition:  Más node-okkal való RPC lebonyolítására  Listenereket akaszthatunk rá, amiket adott események esetén értesít  Sok szolgáltatás magja ide köthető  Következmény:  Egy két JBoss példányból álló (alapértelmezett beállítások mellett futó) cluster gyakorlatilag négy cluster (mind a négyben kettő node szerepel), mivel a cluster csatornánként értendő

21 Clustering - JBoss  Alapértelmezetten az all nevű szerver profil tartalmaz clustering-támogatást (indítása: -c all parancssori argumentumokkal)  A deploy könyvtárban a cluster- service.xml fájlban találhatók a clustering beállítások  A clustereknek egyedi nevet kell adni, ha közös hálózaton vannak  Egy példány több clusternek is tagja lehet, de ez menedzsment szempontból ellenjavallott  HTTP session replication:  JBoss automatikusan kezeli az all szerver konfigurációban (a load balancingot nem!)  web.xml -ben distributable attribútumot be kell állítani ${jboss.partition.name:DefaultPartition} ${jboss.bind.address} False

22 Clustering - JBoss  Alkalmazások telepítése JBoss clusterbe farming szolgáltatás segítségével:  egyszerű deploy az all szerver konfiguráció farm könyvtárába  automatikusan települ az alkalmazás az összes clusterbeli példányra  Később becsatlakozó példányok a csatlakozáskor automatikusan telepítik az ilyen alkalmazásokat  Csak az archivált modulokat támogatja, az exploded típusúakat nem ... DefaultPartition 5000 farm/ Properties p = new Properties(); p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces"); p.put(Context.PROVIDER_URL, "localhost:1100"); // HA-JNDI port. return new InitialContext(p);

23 Clustering - JBoss  Állapottovábbítás:  HA-JNDI (high availability):  Teljes clusterre kiterjedő JNDI  Mellette minden példányban saját lokális JNDI  Az alkalmazásnak tudnia kell a HA-JNDI jelenlétéről: jndi.properties fájlba: java.naming.provier.url=server1:1100,server2:1100,server3:1100

24 Clustering - WebSphere  WebSphere esetén:  Cluster: olyan alkalmazásszerverek csoportja, amelyek azonos alkalmazásokat futtatnak és kezelhetők úgy, mint egyetlen alkalmazásszerver  Cluster member: egy WebSphere példány  A clusteren végzett telepítés, eltávolítás, frissítés (stb.) a cluster minden tagján végrehajtódik  Egy tag legfeljebb egyetlen clusterhez tartozhat  Vertikális (egy rendszeren belüli) és horizontális (több rendszeren keresztüli) és vegyes clustereket is támogat Vertikális cluster Horizontális cluster

25 Biztonság  Authentikáció:  folyamat, amely során megállapítjuk, hogy ki szeretne hozzáférni egy adott erőforráshoz  Valamilyen egyedi információt kell begyűjteni a hozzáférést kezdeményezőtől:  Tudás alapú: pl. felhasználónév és jelszó  Kulcs alapú: fizikai vagy titkosítási kulcsok  Biometrikus: pl. ujjlenyomat, retina, DNS, stb.  Authorizáció:  Folyamat, amelynek során ellenőrizzük, hogy egy adott felhasználó megfelelő jogosultságokkal rendelkezik-e a kért erőforráshoz való hozzáféréshez

26 26 PKI és társai  Kivonat (Hash)  Titkos kulcsú titkosítás (Symetric)  Nyilvános kulcsú titkosítás (Asymetric)  Digitális aláírás (Digital Siganture)  Digitlis tanúsítvány (Digital Certificate)  Tanúsítvány hatóság (Certificate Authority)

27 27 Kivonat  Tetszőleges bemenet  Pl.: 128 bites kimenet  A bemeneten egy kis változtatás is megváltoztatja a kimenete is  Nem visszafejthető

28 28 Szimmetrikus kulcsú titkosítás  Közös kulcs  Gyors  Kulcselosztás?

29 29 Aszimmetrikus kulcsú titkosítás  Nyilvános kulcs  Titkos kulcs  Lassú

30 30 Digitális aláírás

31 31 Digitális tanúsítvány

32 32 Tanúsítvány hatóság

33 33 Biztonsági megoldások

34 34 TLS (Tranport Layer Security)  Új réteg bevezetése:  Netscape SSL  Microsoft PCT  IETF TLS  Megbízhatóság, Adatvédelem, Azonosítás  Definiálja a csatorna paramétreinek egyeztetési módszerét  Viszony/Kapcsolat

35 35 TLS felosztása I.  TLS Handshake  Session identifier  Peer certificate  Compression method  Cipher spec  Master secret  Is resumable

36 36 TLS felosztása II.  TLS Record  Fragmentálás  Tömörítés  Tartalom védelem  Titkosítás

37 37 Kapcsolat felépítés 1. Hello üzenetcsere 2. Rejtjelezési paraméter csere 3. Bizonyítvány csere 4. Főkulcs 5. Adatcsere

38 SSO, E-SSO  Single sign-on (SSO)  Hozzáférés vezérlés  A felhasználó egyszer lép be  Az erőforrások hozzáférése ezután már transzparens számára  Problémák:  Sok webhely, sok jelszó (21 account/password)  A jelszó kezelés bonyolult  Ezért egy jelszavat használ mindenhova  Jelszó menedzselők  Mac-X, GNOME, KDE, Web Böngészők  Előnyei:  Idő megtakarítás  IT költség csökentés  Több szintű transzparens biztonság 38

39 Megoldások  SSO  Kerberos alapú  Okos kártya alapú  OTP token (one time password)  OpenSSO  Megosztott azonosítás, Föderatív azonosság  OpenID  Shibboleth  Információ kártyák  Liberty Allience  WS-Federation  Szabványok  SAML 39

40 SAML  Security Assertion Markup Language  Azonosítás, Jogosultság kezelés biztonsági tartományok között  Probléma:  Intranet megoldások  Web Böngésző SSO?  Részei  XML séma  XML aláírás  XML titkosítás  Elemei:  XML alapú állítások  Protokollok  Kötések  Profilok 40

41 SAML  Kifejezések  Azonosítás  Attribútum  Engedélyezés döntés eredmény (XAML inkább)  Pl.: X adta ki t időben S-re vonatkozóan amenniyben a C feltételek igazak  Protokol  Hogyan van a dróton átküldve  Legfontosabb:  Query  Authentication query  Attribute query  Authorization query  Kötés 41

42 SAML 42

43 OTP token  Cél: nehezebb legy a védett erőforráshoz jogosulatlanul hozzáférni  Folyamatosan változó jelszó  Típusai  Matematikai algoritmus mely az előző alapján gyártja a következőt (Leslie Lamport: hash lánc)  Idő szinkronizálás alapú (speciális hw, mobil, …)  Matematikai alapú de az újak az azonosító szerver véletlenszáma alapján generálódnak (SMS) 43

44 OpenID  Módszer arra, hogy egy azonosító egy felhasználó kezelésében van  Elosztott  A felhasználó tetszőleges OpenID szolgáltatót választhat  Szolgáltató váltásnál is megtarthatja az azonosítóját  Ajax segítségével az oldal elhagyása nélkül is azonosítható a felhasználó  Profil, … nem része a specifikációnak 44

45 OpenID  A protokol  A felhasználó megdja az azonsítóját az erőforráshoz  Az erőforrás felderíti az azonosító szervert és annak protokollját  Az erőforrás átirányítja a felhasználót az azonosító szerverhez  Az azonosító szerver azonosítja a felhasználót (az hogy hogyan az nincs megadva)  Az azonosító szerver visszairányítja a felhasználót az erőforráshoz az azonosítás eredményével  URL, Nonce, aláírás 45

46 Shibboleth  SAML alapú  Föderatív kapcsolatok felett azonosítás, jogosultság kezelés 46

47 47 MIT Athena project ( ) Funkciói (Fejek): Azonosítás (authentication) Hozzáférés vezérlés (access control) Naplózás (auditing) Felépítés: Kliens (Client) Szerver (Server) Jegy központ (KDC) Kerberos V5 (RFC 1510): Azonosítás Kerberos

48 48 Kerberos Működési Elv 1. A Kerberos azonosítás a szimmetrikus titkosításon alapul 2. Kulcs elosztás 3. Kerberosz jegy 4. A jegy kiosztása 5. Az egyed fő kulcs használatának korlátozása

49 49 A Kerberos azonosítás a szimmetrikus titkosításon alapul  D K (E K (M)) = M;  Hasonló megoldás van NTLM esetén is:  Ha a közös kulccsal van titkosítva akkor a másik fél hiteles  Titkosított Csomag:  Azonosító (authenticator) mindig mást kell titkositania  Közös titkos kulcs:  Viszony Kulcs (session key)  Kritikus elem:  Időbélyeg (Time Stamp) kisebb a kulönbség mint 5 perc, sorrend figyelés  Kölcsönös azonosítás:  A szerver is megteszi ugyanezt

50 50 Kulcs elosztás Hogyan osztjuk ki a kulcsokat (nem csak ) emberek, … Kerberos nélkül: n (n — 1)/2 kulcs (50,000 -> 1,500,000,000) Minden kliensen Kerberos : Három entitás: Két kommunikáló fél Közvetitő fél (Key Distribution Center - KDC) Minden egyed rendelkezik egy-egy KDC-vel közös kulccsal Az Egyed Mester Kulcsa (Master Key) (pl: a felh. Jelszavából, MD5 tárolás, létrehozáskor), hosszútávú kulcs Kerberos tartományok Windows 2000: Dcpromo -> kdc szolgáltatás (minden DC írható/olvasható KDC adatbázis) Azonosító szolgáltatás Jegy Kiadó Szolgáltatás Multimaster

51 51 Kerberos jegy  Biztonságos csatorna építhető ki a segítségével  Kereberos:  Azonosító Szolgáltatás (Authentication Service)  Jegykiosztó Szolgáltatás (Ticket-Granting Service)  Mindenki megbízik a KDC által legyártott viszonykulcsokban (nem csak a Master Key-ben)  A viszonykulcs minősége a Windows 2000 véletlen szám generátorától függ (Nem a felh. Jelszótól !!!)  A KDC-nek kellene a viszony kulcsokat kiosztani :  A közös kulccsal titkosítja (user, szerver) (Kerberos terminológia : jegy ticket))

52 52 Kulcs hierarchia  A biztonság növelése érdekében, a gyakran használt kulcsokat gyakrabban változtatják és erősebb kulcsokat generálnak (felh. jelszó):  A magasabb szintű kulcsok védik az alacsonyabb szintű kulcsokat  A magasabb szintű kulcsok hosszabb élettartamúak

53 53 Kulcs elosztás  Két megoldás lehetséges:  Mindkét fél a szervertől kapja meg:  Az erőforrás szervernek minden kulcsot tárolnia kellene  Szinkronizációs problémák  A szerver a kezdeményező félnek küldi el mindkét jegyet  Egyszerű azonosítás (elküldi a jegyet)  Gyors azonosítás (tárolhatja a jegyet)  Egyszerűbb terhelés elosztás (csak másik jegyet kell küldeni)  A kulcsok egy speciális memória területen tárlódnak és soha sem kerülnek ki a merevlemezre (klist.exe, kerbtray.exe ürítés )

54 54 Jegy biztosító jegyek (ticket-granting ticket )  Minden egyes viszony kulcs létrehozására a felhasználó mester kulcsát használtuk  Könnyebben visszafejthető szótáras támadással (L0phtcrack )  Az első azonosítás után egy TGT-t, és egy viszony kulcsot kap a felhasználó e jegy segítségével titkosítja az üzeneteket a KDC számára  A TGT újrahasznosítható az élettértartamán belül  A KDC nem tartja nyilván a TGT-ket  Gyorsabb megoldás mivel nem kell keresgélnie az adatbázisában

55 55 Kerberos működése 1. KRB_AS_REQ 2. KRB_AS_REP 3. KRB_TGS_REQ 4. KRB_TGS_REP 5. KRB_AP_REQ 6. KRB_AP_REP

56 56 Bejelentkezés egy Windows 2000 szerverbe Helyi bejelentkezés (Egy tartományos modell): DNS keresés (_kerberos, _kpasswd ) 3. KRB_AS_REQ 4. Az Azonosító Szolgáltatás azonosítja a felhasználót majd KRB_AS_REP üzenetet küld. 5. A helyi gép egy KRB_TGS_REQ üzenetet küld. 6. A kdc KRB_TGS_REP választ küld 7. A jegyet megvizsgálja az LSA

57 57 Jegy tulajdonságok  FORWARDABLE  A szerver szerzi be a jegyet  FORWARDED  PROXIABLE  Kliens szerzi be a jegyet  Tudni kell a háttérszerver adatait  PROXY  RENEWABLE  A viszony kulcsok cserélhetőek a jegy újragenerálása nélkül  Aktuális kulcs időtartam (tipikusan egy nap)  Teljes kulcs időtartam (néhány hét)  INITIAL

58 58 Hálózati bejelentkezés 1. KRB_TGS_REQ 2. KRB_TGS_REP 3. KRB_AP_REQ 4. KRB_AP_REP

59 59 Bejelentkezés más tartományba  A felhasználó vagy az erőforrás más tartományhoz tartozik (Alice Europe, Gép NA). 1. KRB_AS_REQ és KRB_AS_REP (Europe) 2. KRB_TGS_REQ, KRB_TGS_REP 1. KRB_TGS_REQ Europe 2. Hivatkozó jegy NA irányába (compaq.com, tartományközi jelszó) 3. DNS kdc keresés compaq.com- ban 4. Hivatkozó jegy NA-ra 5. KDC keresés NA-ban 6. TGS_REP az erőforrásra  Ez nem történik meg minden alkalommal (tárolás), a csomagok kicsik

60 60 Tartományok közötti kapcsolat  Tartományi megbízott fiókok  A tartomány közti azonosítást a speciális megbízó (principal) fiókot tárol a másik tartományról  Tartomány közti kulcsok (inter-realm key)  A kulcs a jelszóból származik mely megfelelő időközönként cserélődik  Valós megbízotti kapcsolat:  Közös titkos kulcs (dcpromo)  krbtgt fiók:  Az ő jelszava lesz a Master Key  A jelszó menetrend szerint váltakozik  Jelentős DC használat (principal, tartomány)

61 61 Azonosítás delegálása

62 62 Smart card belépés  PKINIT  CA használat  Menet:  PA-PK-AS-REQ  …

63 63 JAAS  Java Authentication and Authorization Service (JAAS) API  Felhasználó azonosítás (eddig csak kód alapú azonosítás volt)  Mit tud  Mivel rendelkezik  Kicsoda  Az azonosítás választható (alakítható)  Plugable Authentication Modules (PAM)  Engedélyezés:  Deklaratív  Progamból

64 64 PAM  SUN Solaris (Linux, …)  Szabványos azonosító környezet  Az aktuálisan használt eljárás használat, telepítés közben derül ki (administrator)  Login modulok  Válszthatóak  Könnyen bővíthetőek  Login konfigurációs fájl

65 65 Java 1.4 login modulok  com.sun.security.auth.module.NTLoginModule  com.sun.security.auth.module.NTSystem  com.sun.security.auth.module.JndiLoginModule  com.sun.security.auth.module.KeyStoreLoginModule  com.sun.security.auth.module.Krb5LoginModule  com.sun.security.auth.module.SolarisSystem  com.sun.security.auth.module.UnixLoginModule  com.sun.security.auth.module.UnixSystem

66 66 JAAS elemei  Login Context  Login.config  Login Module  Subject  Elemei:  Principal (PrincipalImpl)  Credential  Metódusai:  subject.getPrincipals()  subject.getPublicCredentials()  subject.getPrivateCredentials()  Access Controller  Permission objektum  Jaas.policy

67 67 JAAS példa // Example Java 2 Security Policy Entry grant Codebase "www.sun.com", Signedby "duke" { FilePermission "/cdrom/-", "read"; } // Example JAAS Security Policy Entry grant Codebase "www.sun.com", Signedby "duke", Principal com.sun.Principal "charlie" { FilePermission "/cdrom/charlie/-", "read"; } // Example login module configuration entry Login2 { sample.SampleLoginModule required; com.sun.security.auth.module.NTLoginModule sufficient; com.foo.SmartCard requisite debug=true; com.foo.Kerberos optional debug=true; }; import java.security.*; import javax.security.auth.*; //exts // Instantiate a login context LoginContext ctx = new LoginContext ("name", CallbackHandler); // Authenicate the subject ctx.login(); // Retrieve authenticated subject Subject sub = ctx.getSubject(); // Enforce Access Controls Subject.doAs(sub, action);

68 68 Példa

69 69 PrincipalImpl import java.io.Serializable; import java.security.Principal; public class PrincipalImpl implements Principal, Serializable { private String name; public PrincipalImpl(String n) {name = n;} public boolean equals(Object obj) { if (!(obj instanceof PrincipalImpl)) {return false;} PrincipalImpl pobj = (PrincipalImpl)obj; if (name.equals(pobj.getName())) {return true;}return false;} public String getName() {return name;} public int hashCode() {return name.hashCode();} public String toString() {return getName();} }

70 70 Login konfiguráció  A használt azonosítási eljárást nem a program írásakor döntjük el  Login.config  Djava.security.auth.login.config==login.config  == a rendszer fájlt lecseréli  LoginContext  required  optional  requisite  sufficient JAASExample { AlwaysLoginModule required; PasswordLoginModule optional; };

71 71 Login Context  Java osztály  Login végrehajtás  Subject visszaadás  Konstruktora:  LoginContext("JAASExample", newUsernamePasswordCallbackHandler())  Fontosabb metódusai:  login()  getSubject()  logout()

72 72 Callback handler  Feladata a megfelelő információ beszerzése  javax.security.auth.callback.CallbackHandler  Elemei:  NameCallback  PasswordCallback  TextInputCallback  TextOutputCallback  LanguageCallback  ChoiceCallback  ConfirmationCallback

73 73 import java.io.*; import java.security.*; import javax.security.auth.*; import javax.security.auth.callback.*; UsernamePasswordCallbackHandler implements CallbackHandler { public void handle(Callback[] callbacks) throws UnsupportedCallbackException, IOException { for(int i=0;i

74 74 Login Modul  LoginModule interfész  Két fázisú elfogadás (two phase commit)  Metódusai:  initialize( subject, callbackHandler, sharedState, options)  login()  commit()  abort()  logout()

75 75 public class AlwaysLoginModule implements LoginModule { private Subject subject;private Principal principal;private CallbackHandler callbackHandler; private String username;private boolean loginSuccess; public void initialize(Subject sub, CallbackHandler cbh, Map sharedState, Map options) {subject = sub;callbackHandler = cbh;loginSuccess = false;} public boolean login() throws LoginException { if (callbackHandler == null) {throw new LoginException( "No CallbackHandler defined");} Callback[] callbacks = new Callback[1]; callbacks[0] = new NameCallback("Username"); try {System.out.println( "\nAlwaysLoginModule Login" ); callbackHandler.handle(callbacks); username = ((NameCallback)callbacks[0]).getName(); } catch (IOException ioe) { throw new LoginException(ioe.toString()); } catch (UnsupportedCallbackException uce) { throw new LoginException(uce.toString());} loginSuccess = true; return true;} public boolean commit() throws LoginException { if (loginSuccess == false) { System.out.println( "Commit: AlwaysLoginModule FAIL" ); return false;} if (!(subject.getPrincipals().contains(principal))) { subject.getPrincipals().add(principal);} System.out.println( "Commit: AlwaysLoginModule SUCCESS" ); return true; }…

76 76 if (callbackHandler == null) {throw new LoginException("No CallbackHandler defined");} Callback[] callbacks = new Callback[2]; callbacks[0] = new NameCallback("Username"); callbacks[1] = new PasswordCallback("Password", false); try { callbackHandler.handle(callbacks); username = ((NameCallback)callbacks[0]).getName(); char[] temp = ((PasswordCallback)callbacks[1]).getPassword(); password = new char[temp.length]; System.arraycopy(temp, 0, password, 0, temp.length); ((PasswordCallback)callbacks[1]).clearPassword(); } catch (IOException ioe) {throw new LoginException(ioe.toString()); } catch (UnsupportedCallbackException uce) {throw new LoginException(uce.toString());} if ( "joeuser".equals(username)) { if ( password.length == 5 && password[0] == 'j' && password[1] == 'o' && password[2] == 'e' && password[3] == 'p' && password[4] == 'w' ) { loginSuccess = true; clearPassword(); return true; }} else {loginSuccess = false;username = null; clearPassword(); throw new FailedLoginException(); }

77 77 Hozzáférési környezet  Szálanként kezeljük a jogosultságot  A Subject kötése a környezethez:  Object doAs(Subject subject,PrivilegedAction action)  Object doAsPrivileged(Subject, PrivilegedAction action, AccessControlContext acc)  Deklaratív megoldás:  Object doAsPrivileged(Subject, PrivilegedAction action, null)

78 78 Program modell/ Deklaratív modell class PayrollAction implements PrivilegedAction { AccessControlContext context = AccessController.getContext(); Subject subject = Subject.getSubject(context ); if (subject == null ) {throw new AccessControlException("Denied");} Set principals = subject.getPrincipals(); Iterator iterator = principals.iterator(); while (iterator.hasNext()) { PrincipalImpl principal = (PrincipalImpl)iterator.next(); if (principal.getName().equals( "joeuser" )) {System.out.println("joeuser has Payroll access\n"); return new Integer(0);}}throw new AccessControlException("Denied"); } class PersonnelAction implements PrivilegedAction { public Object run() { AccessController.checkPermission(new PersonnelPermission("access")); System.out.println( "Subject has Personnel access\n"); return new Integer(0);}}

79 79 public class JAASExample { static LoginContext lc = null; public static void main( String[] args) { try { lc = new LoginContext("JAASExample",new UsernamePasswordCallbackHandler()); } catch (LoginException le) {System.out.println( "Login Context Creation Error" );System.exit(1);} try {lc.login();} catch (LoginException le) { System.exit(1); } try { Subject.doAs( lc.getSubject(), new PayrollAction() ); } catch (AccessControlException e) {System.out.println( "Payroll Access DENIED" ); } try { Subject.doAsPrivileged( lc.getSubject(), new PersonnelAction(), null ); } catch (AccessControlException e) { System.out.println( "Personnel Access DENIED" ); } try { lc.logout(); } catch (LoginException le) { System.out.println( "Logout FAILED" ); System.exit(1); } System.exit(0); } java -Djava.security.manager -Djava.security.auth.login.config==login.config -Djava.security.policy==jaas.policy JAASExample

80 Biztonság - WebSphere  Kerberos, Single Sign-On, biztonsági tanúsítványok támogatása  Több biztonsági tartomány kezelése, minden biztonsági tartomány a saját felhasználóival reldelkezik  Alkalmazási és adminisztrációs tartományok elkülöníthetők  Adminisztratív tevékenységek naplózása

81 Biztonság - WebSphere  Authentikáció:  Felhasználói adatbázis alapján történik:  Operációs rendszer felhasználói alapján  LDAP alapján  Egyéb (tetszőleges adatbázisból, de implementálni kell)  Sikeres authentikáció esetén egy igazolás (credential) kerül kiállításra  a továbbiakban ez használatos a hitelesített felhasználó ábrázolására  Átviteli protokollok:  EJB-erőforrások esetén: CSIv2  Webes erőforrások esetén: HTTP vagy HTTPS  WebSphere-ben használható authentikációs módszerek:  Lightweight Third Party Authentication (LTPA)  Kerberos  RSA token  Single Sign-on:  Egyszer kell authentikálni, utána minden alkalmazás annak az eredményét használja  Feltételek:  Minden az SSO-ban részt vevő szerver ugyanazt a felhasználói adatbázist használja  Minden az SSO-ban részt vevő szerver ugyanabban a DNS név alatt érhető el (cookie-k miatt)  Minden URL-ben domain neveket kell használni (szintén cookie-k miatt)  Webes alkalmazások esetén a webböngészőnek támogatnia kell a cookie-kat

82 Biztonság - WebSphere  Authorizáció:  Webes és Java EE authorizáció  Webszolgáltatás authorizáció  JMS és JACC authorizáció  Ha JACC szolgáltató meg van adva, akkor a WebSphere azt használja (a Java EE alkalmazás authorizációs döntései delegálva lesznek a szolgáltatóhoz)  Java biztonsági annotációk támogatása  Adminisztatív tevékenységek:  Alapértelmezett szerepkörök:  Monitor, Configurator, Operator, Administrator, ISC Admins, Deployer, Admin Security Manager, Auditor JACC (Java Authorization Contract for Containers) architektúra

83 Biztonság - WebSphere  Biztonságos kommunikáció:  SSL használata:  Titoktartás (privacy), integritás megőrzése és authentikáció céljából  Public Key Infrastructure (PKI) használata:  Tanúsítvány (certificate) alapú  Tanúsítványok visszavonásának lehetősége  Java Secure Sockets Extension (JSSE), mint implementáció

84 Biztonság - WebSphere  Biztonságos kommunikáció:  SSL használata:  Titoktartás (privacy), integritás megőrzése és authentikáció céljából  Tanúsítvány alapú  Public Key Infrastructure (PKI)  Java Secure Sockets Extension (JSSE), mint implementáció  Alkalmazások biztonsága:  Biztonsági szerepkörök használata (fejlesztésnél a pontos felhasználók még nem ismeretesek, de a rendszerben betöltött szerepek igen)  Telepítéskor rendelhetünk az egyes felhasználókhoz biztonsági szerepköröket  Deklaratív (a szabályok programkódon kívül vagy annotációval vannak megadva) és programozott (a szabályok programkóddal vannak megadva) biztonság

85 Biztonság - JBoss  Java EE alkalmazások biztonsága:  Deklaratív (XML alapú és annotált) és programozott biztonság  JAAS API használata:  Standard a Java biztonság terén  Authentikáció és authorizáció céljából használható  Biztonsági tartományok támogatása  Beépített authentikációs lehetőségek:  Jelszó alapú  LDAP alapú  Adazbázis (JDBC) alapú  Tanúsítvány alapú  Saját kiegészítések is készíthetők  SSL támogatása: JSSE felhasználásával  A szerver biztonsága érdekében egyes alapértelmezett szolgáltatásokat biztonságossá kell tenni:  JMX konzol: eltávolítható, vagy authentikációval látható el ( jmx- console.war )  Web konzol: authentikációval látható el ( management könyvtár)  HTTP invokerek: JMXInvokerServlet biztonságossá tételével ( http- invoker.sar )  JMX invoker: RMI/HTTP-re történő váltással ( jmx-invoker-adaptor- server.sar )

86 JCA  Lehetővé teszi a JEE komponensek és az EIS (vállalti információs rendszerek) együttműködését  Plug-in architektúra:  JEE szerverek között hordozható plug-inek  Erőforrás-adapter (RAR) modulok valósítják meg ezeket  Elosztott tranzakciókezelés: X/Open XA szabvány  Authentikáció támogatása: felhasználónév/jelszó, Kerberos  JSR-112 specifikálja

87 Erőforrás adapterek  Erőforrás-adapter modulok felelősek egy adott típusú EIS illesztéséért  Az erőforrás-adapter készítőinek alaposan ismerniük kell az illesztett EIS működését, a vele történő kommunikáció módját  Különböző ún. egyezmények vannak a különböző területekre:  Definiálják az alkalmazásszerver és az erőforrás-adapterek kapcsolatait  API: java osztályok és interfészek  Követelmények: mit kell teljesíteni az erőforrás-adapternek és mit az alkalmazásszervernek

88 Egyezmények  Kapcsolatkezelés (connection management):  Alkalmazás komponensek EIS-ekhez való kapcsolódásához, kapcsolatkészletek fenntartásához  Tranzakciókezelés (transaction management):  Tranzakciók kiterjesztése több erőforráskezelőn keresztül  EIS-ek erőforráskezelői által belsőleg kezelt tranzakciók támogatására is  Biztonságkezelés (security management):  Kapcsolatkezelési egyezmény kiterjesztése biztonságspecifikus részletekkel  Single sign-on támogatása  Életcikluskezelés (life cycle management):  Erőforrás-adapterek életciklusának kezelésére (indítás, leállítás, stb.)  Munkakezelés (work management):  Erőforrás-adapterek által végzett hosszabb ideig tartó munkák elvégzésének támogatása  Lehetővé teszi, hogy a szálkezelést ne az erőforrás-adaptereknek kelljen végezni, a szálak megfelelő készletezését  Tranzakcióbeáramlás-kezelés (transaction inflow management):  Lehetővé teszi, hogy az alkalmazásszerver részt vegyen egy külső (importált) tranzakcióban ACID tulajdonságok megtartásával  Üzenetbeáramlás-kezelés (message inflow management):  Aszinkron üzenetkézbesítésre  J2EE kompatibilis alkalmazásszerver esetén tetszőleges üzenetkézbesítő szolgáltatást illeszthetünk erőforrás- adapterrel (JMS, JAXM, stb.)

89 Common Client Interface  A JCA része  Olyan interfészek gyűjteménye, amelyek lehetővé teszik alkalmazáskomponens kliensek számára a különböző rendszerekhez való kapcsolódást  Távoli eljáráshívás alapú, a műveletek az EIS-eken futnak, a kliensek az eredményeket kapják vissza  Tekinthető úgy, mint a JDBC kiterjesztése olyan EIS-ek felé, amelyek nem relációs adatbázis-kezelők

90 Common Client Interface  Teljesen általánosított interfészek, amelyek lehetővé teszik a lehető legtöbb EIS-típushoz való kapcsolódást:  EIS-függő típusok nem szerepelnek  Metaadatok kezelésének támogatása  Intefészek:  Kapcsolat interfészek  Kölcsönhatás (interaction) interfészek  Metaadat interfészek  Szolgáltatás végpont üzenetfigyelő interfész  Kivétel (exception) interfészek

91 Common Client Interface  Record:  EIS művelethez szükséges adatszerkezet Java-beli megfelelője  Interface, aminek megvalósításával saját típusok hozhatók létre (rendszerint ezt fejlesztőeszközök tudják automatikusan generálni)  Létezhet olyan megvalósítása is, amely általános, a tényleges adattípust csak futási időben alakítja ki  ResultSet:  EIS által visszaadott táblázatos adatok reprezentálására  Hasonló a relációs adatbázisok által visszaadott táblázatos adatokhoz

92 A mai előadás tartalma  Alkalmazásszerverek, alkalmazásszerverek felépítése  Java EE alkalmazások és modulok és kezelésük  Alkalmazásszerverek kezelése (monitoring, menedzsment)  Clustering, Jgroups  Alkalmazásszerverek biztonsága  Java Connector Architecture

93 A következő előadás tartalma  Web Babok  Kontextusok  Kapcsolat az EJB-vel  Pageflow  Implementációk  Seam  ApacheShale 93


Letölteni ppt "Programrendszerek Fejlesztése 14/8 1. Tartalom  Alkalmazásszerverek, alkalmazásszerverek felépítése  Java EE alkalmazások és modulok és kezelésük "

Hasonló előadás


Google Hirdetések