OAuth 2.0 Spring Boot és Spring Security keretrendszerekkel

Használt technológiák: Spring Boot 2, Spring Security 5, Keycloak 9

A látogatottsági adatok alapján a legkedveltebbek a Spring Security-val foglalkozó posztjaim, ebből is kiemelkedik a JWT-vel foglalkozó JWT és Spring Security posztom. Ezért most arról fogok írni, hogy hogyan támogatja a Spring Security 5.x az OAuth 2.0 szabványt, mi is az az OAuth 2.0, valamint hogyan használható vállalati környezetben, miért érdemes ott is ebbe az irányba elmozdulni. Szó esik arról is, hogyan kell egy külön szervert beállítani a felhasználói adatok eltárolására és azonosításra/hitelesítésre/bejelentkezésre/autentikációra (authentication), erre a Keycloak nyílt forráskódú eszközt fogom használni (de mivel szabányos protokollok vannak, használhatnék más is). Valamint ehhez fogunk kapcsolódni egy Spring Boot alkalmazással, a Spring Security keretrendszer használatával.

Az OAuth egy nyílt szabány erőforrás-hozzáférés kezelésére, vagy ismertebb nevén authorizációra (authorization). Alapja, hogy elválik, hogy a felhasználó mit is akar igénybe venni, és az, hogy hol jelentkezik be. A legismertebb példa erre az, hogy mostanában ha igénybe akarunk venni egy online szolgáltatást, akkor nem feltétlen kell magunkat regisztrálnunk, hanem bejelentkezhetünk a Google vagy Facebook fiókunk használatával is. Ehhez az említett oldalon lehet bejelentkezni, ott megadni a jelszavunkat, majd folytathatjuk az online szolgáltatás oldalán a tevékenységünket. Nagy előnye, hogy egyrészt nem kell annyi jelszót megjegyeznünk, valamint az OAuth kialakítása miatt nem kell a jelszavunk megadni egy harmadik félnek.

Ha valaki most itt abbahagyná az olvasást, hogy az alkalmazásába nem akar sem Facebook, sem Google bejelentkezést, az is olvasson tovább. Ugyanis az OAuth szabvány használatával természetesen saját authorizációt is megvalósíthatunk, sőt, ez a javasolt mód. Ugyanis nagyon hamar eljuthatunk oda, hogy nem csak egy alkalmazást akarunk üzemeltetni, hanem kettőt, és nem szeretnénk, ha a felhasználóinknak több jelszót kelljen megjegyezniük. Ezt Single Sign-On-nak (SSO), egyszeri bejelentkezésnek nevezzük. És ez nem csak a felhasználóinknak jó, hanem a fejlesztőinknek is, hiszen ha kitaláljuk, hogy módosítani szeretnénk az autentikáción vagy authorizáción, például kétfaktoros autentikációt szeretnénk bevezetni, akkor elegendő egy helyen módosítani, nem kell módosítani a többi alkalmazáson. Erre jó példa, hogy a Google különböző szolgáltatásaiba sem kell külön bejelentkeznünk, mint pl. a GMail, YouTube vagy Maps.

Java Thread Dump

Mostanában úgy alakult, hogy egy webes alkalmazás belső működését kellett elemeznem. Ennek több oldalról is neki lehet ugrani, mint memóriahasználat, garbage collector működése, heap dump (JVM memóriájának tartalma), thread dump (futó szálak állapota), napló állományok, stb.

Vannak eszközök, amelyeknél nem kell feltétlen a JVM működésébe avatkoznunk, pl. naplófájl elemzésekor. Persze itt is előfordulhat olyan eset, hogy a naplózás szintjét állítanunk kell, ez történhet az alkalmazás újraindításával, de bizonyos megoldások engedik a naplózás szintjének futás szintű állítását (pl. Spring Boot Actuator /logger endpoint).

Vannak eszközök, melyekkel futó JVM-hez lehet csatlakozni, anélkül, hogy ezt erre felkészítettük volna. (Tipikusan az adott gépről, távoli hozzáféréshez biztos, hogy további konfiguráció szükséges.) Ilyen pl. a jstat a GC működésének és a memóriahasználat elemzésére, a jstack a thread dump lekéréséhez, valamint a jconsole mely egy komplex grafikus eszköz a JVM monitorozására. (Ez utóbbi használata már problémákba ütközhet, hiszen szerveren nem feltétlen van grafikus felület, a távoli hozzáférés meg további konfigurációkat igényel.)

Egyes eszközöket pedig már előre kell telepíteni és konfigurálni, hogy használni tudjuk.

Ez a poszt a thread dump készítéséről fog szólni, valamint annak elemzéséről, értelmezéséről. Szó esik hogy milyen eszközöket tudunk erre használni. A legtöbb poszt ezzel kapcsolatban arról szól, hogy lehet a hibásan programozott párhuzamosságból adódó deadlockokat, livelockokat kiszűrni, de én arra koncentrálok, hogy hogy lehet egyáltalán értelmezni a thread dumpot, hogy épp mit is csinál az alkalmazás.

Training360 Fejlesztői Meetup

A Training360 oktatóközpont, ahol jelenleg is oktatok, Nézz be a hype mögé címmel fejlesztői meetupot szervez 2019. október 17-én, csütörtökön 18:00-kor. Főbb témáink: microservices, tesztelés, Kotlin, blockchain, mobil fejlesztés, machine learning. Helyszín A Grund, 1082 Budapest, Nagytemplom utca 30.

A program:

  • Bevezető - Kardos Ádám
  • Integrációs tesztek nehézségei (Javaban) - Viczián István
  • Ezért érdekes a Kotlin nyelv egy termékmenedzser szemszögéből - Orosz Gábor
  • Elosztott főkönyvi technológiák összehasonlító elemzése - Szegő Dániel
  • Amire a Flutter büszke lehet (és amire nem) - Barta Tamás
  • Azure ML Data Engineering áttekintő - Józsa Tamás
  • Technológiák, amelyeket Microservicek-hez használunk - Arold Ádám

Ahogy a programból is látszik, az első előadást én fogom tartani az integrációs tesztelésről. Beszélni fogok a monolitikus és microservice architektúrális különbségeinek tesztelési vonzatairól, a tesztpiramisról, az integrációs tesztelés típusairól és céljairól, API-tesztelésről, komponens tesztelésről, E2E tesztelésről. Ki fogok térni olyan problémákra, mint stub és mock objektumok és szolgáltatások (in-process és out-process egyaránt), adatbázis megfelelő állapotba hozása, kapcsolódás több szolgáltatáshoz akár szinkron RESTful webszolgáltatásokkal, akár aszinkron kommunikációval (pl. sorok). Bár manapság divatos mindig a legmodernebb eszközökről beszélni, párhuzamosan ezer technológia, több eszköz és programozási nyelv használata, én azért próbálok a realitás talaján maradni, és olyan megoldásokat bemutatni, ami akár kötöttebb környezetben, kevesebb szakemberrel és ismerettel is megoldható.

A részvétel ingyenes, de regisztrációhoz kötött, amit a https://www.training360.com/meetup címen tehetsz meg.

A meetup elérhető a Meetup.com oldalon vagy van Facebook esemény is.

Meetup

JSF használata Spring Boottal

Tudom, a mai HTML/CSS/JavaScript világban a JSF, mint felületi technológia nem túl csábító, azonban bizonyos helyzetekben jó választásnak tűnhet. A JSF a Java EE szabvány része, minden alkalmazásszerver beépítetten támogatja. Komponens alapú fejlesztést tesz lehetővé, és MVC tervezési minta szerint épül fel. Java programozók pillanatokon belül használatba tudják venni, egy teljes másik stack megtanulása nélkül, és nagyon gyorsan lehet vele haladni. Persze ha nagyon egyéni képernyőket és komponenseket kell fejleszteni, máris előjön a gyengesége. Azt is lestem egy projektnél, hogy az admin felületeket, ahol nem kell a csicsa, JSF-ben készítették el, és csak a publikus oldalakon használtak valami modern JavaScript keretrendszert.

Bár a JSF a Java EE része, remekül integrálható Spring Frameworkkel, sőt Spring Boottal is. Bár a Spring Boot beépített JSF támogatást nem tartalmaz, létezik a JoinFaces projekt, mely remek startereket tartalmaz szinte az összes JSF implementációhoz (pl. Mojarra, PrimeFaces, stb.). Sőt Spring Security integrációt is tartalmaz.

Akit nem hoz lázba a JSF, annak is érdemes a posztot elolvasnia, mert szó esik majd a JSF néhány furi tulajdonságáról, a tesztelésről (, ami mostanában a szívügyem) és még Demeter törvényéről is.

A poszthoz természetesen a GitHubon működő példaprojekt érhető el.

Java Technology Roadmap

Manapság divatosak az un. roadmapek, térképek, melyek grafikusan ábrázolják, hogy miket kell megtanulni ahhoz, hogy egy területen otthonosan mozogj, hogyan kezdj neki a tanulásnak, hogy végül magas szinten meg tudd oldani a felmerülő problémákat.

Ezek közül a legismertebb a Web Developer Roadmap - 2019, mely még a Front-end Developer Handbook 2019 könyvben is helyet kapott.

Ez látva én is elhatároztam, hogy készítek egyet a Java Platform területén, mely több okból is hasznomra válhat:

  • Rendszerezem a meglévő szabványokat, technológiákat, eszközöket
  • Aki már járatos a témában, az is találhat rajta újdonságokat
  • Oktatás során többször kérdezik tőlem, hogyan érdemes nekiállni a Java tanulásnak, így kész válaszom lehet
  • Magam számára is ad egy eligazítást, hogy mivel érdemes foglalkozni, amiről esetleg hasznos lenne blog posztot írni, vagy tanfolyamot kidolgozni
  • Egy helyre összegyűjthetem a legjobb könyveket és referenciákat
  • Elindít egyfajta kommunikációt

A térkép megtalálható a GitHubon.

A felépítése a szokásos, felülről lefelé kell haladni. A fő ágon vannak a kötelező elemek, és erről ágaznak el az opcionális elemek. A témakörök sárgával vannak jelölve, a szabványok, technológiák és eszközök narancssárgával, a könyvek kékkel.

Lilával jelöltem azokat az elemeket, melyek hasonló problémákat oldanak meg, mint a narancssárgával jelöltek, én mégis a narancssárgák használatát javaslom. Vigyázat, ez nagyon szubjektív lehet, lehet, hogy bizonyos környezetekben pont a lila a megfelelő (vagy az egyetlen lehetséges) választás. A preferencia oka főleg a szélesebbkörű elterjedtség, aktívabb közösség, fejlődés, egyszerűség, tanulhatóság és tesztelhetőség. A térképen lévő egyik eszközzel sem lehet nagyon melléfogni, általában széleskörűen használt megoldások.

A térkép szándékosan nem tér ki a következő területekre: virtualizáció, cloud computing, big data, microservice. Ezek elegendő anyagot biztosítanak egy külön roadmap felrajzolásához.

A roadmap fejlesztése ezennel nem állt meg, folyamatosan szeretném bővíteni, magyarázni. Valamint szöveges leírásokat is tervezek készíteni a roadmapen lévő alterületekkel kapcsolatban. Ezekhez várok minden visszajelzést.

Bár a térkép magyar nyelven készült, egy idő után, amennyiben kicsit stabilizálódik, tervezem angol nyelvre is lefordítani.

Java Technology Roadmap