Rövid útmutató a Cloud Foundry UAA használatához

1. Áttekintés

A Cloud Foundry felhasználói fiók és hitelesítés (CF UAA) egy identitáskezelési és hitelesítési szolgáltatás. Pontosabban, ez egy OAuth 2.0 szolgáltató, amely hitelesítést és tokenek kiadását teszi lehetővé az ügyfélalkalmazások számára.

Ebben az oktatóanyagban bemutatjuk a CF UAA szerver beállításának alapjait. Ezután megvizsgáljuk, hogyan lehet felhasználni az Resource Server alkalmazások védelmére.

De előtte tisztázzuk az UAA szerepét az OAuth 2.0 engedélyezési keretrendszerben.

2. Cloud Foundry UAA és OAuth 2.0

Kezdjük azzal, hogy megértsük, hogyan viszonyul az UAA az OAuth 2.0 specifikációhoz.

Az OAuth 2.0 specifikáció négy résztvevőt határoz meg, amelyek kapcsolódhatnak egymáshoz: egy erőforrás-tulajdonos, egy erőforrás-kiszolgáló, egy ügyfél és egy hitelesítési kiszolgáló.

OAuth 2.0 szolgáltatóként az UAA a jogosultsági szerver. Ez azt jelenti, hogy elsődleges célja a hozzáférési tokenek kiadása ügyfél alkalmazásokhoz és ezeknek a tokeneknek az érvényesítése a erőforrás-kiszolgálós.

E résztvevők interakciójának engedélyezéséhez először be kell állítanunk egy UAA-kiszolgálót, majd további két alkalmazást kell végrehajtanunk: az egyiket kliensként, a másikat erőforrás-kiszolgálóként.

Használjuk a megerősítő kód támogatás folyamata az ügyféllel. És az erőforrás-kiszolgálóval a Bearer token hitelesítést fogjuk használni. A biztonságosabb és hatékonyabb kézfogás érdekében aláírt JWT-ket fogunk használni hozzáférési jeleinként.

3. UAA szerver beállítása

Első, telepítjük az UAA-t, és néhány demo adattal feltöltjük.

A telepítés után regisztrálunk egy nevű kliens alkalmazást webappclient. Ezután létrehozunk egy nevű felhasználót appuser két szereppel, erőforrás.olvasott és erőforrás.írja.

3.1. Telepítés

Az UAA egy Java webalkalmazás, amely bármilyen kompatibilis szervlet-tárolóban futtatható. Ebben az oktatóanyagban a Tomcat programot fogjuk használni.

Menjünk előre és töltse le az UAA háborút, és helyezze el a Tomcatunkba telepítés:

wget -O $ CATALINA_HOME / webapps / uaa.war \ //search.maven.org/remotecontent?filepath=org/cloudfoundry/identity/cloudfoundry-identity-uaa/4.27.0/cloudfoundry-identity-uaa-4.27.0. háború

Mielőtt azonban elindítanánk, konfigurálnunk kell az adatforrását és a JWS kulcspárját.

3.2. Szükséges konfiguráció

Alapértelmezés szerint az UAA a konfigurációt olvassa le uaa.yml osztályúton. De mivel most töltöttük le a háború fájlt, jobb lesz, ha az UAA-nak egyéni helyet adunk meg a fájlrendszerünkön.

Ezt megtehetjük a UAA_CONFIG_PATH ingatlan:

exportálás UAA_CONFIG_PATH = ~ / .uaa

Alternatív megoldásként beállíthatjuk CLOUD_FOUNDRY_CONFIG_PATH. Vagy megadhatunk egy távoli helyet a UAA_CONFIG_URL.

Ezután átmásolhatjuk az UAA szükséges konfigurációját a konfigurációs útvonalunkra:

wget -qO- //raw.githubusercontent.com/cloudfoundry/uaa/4.27.0/uaa/src/main/resources/required_configuration.yml \> $ UAA_CONFIG_PATH / uaa.yml

Vegye figyelembe, hogy az utolsó három sort töröljük, mert egy pillanat múlva cserélni fogjuk őket.

3.3. Az adatforrás konfigurálása

Tehát állítsuk be az adatforrást, ahol az UAA információkat tárol az ügyfelekről.

A bemutató céljára a HSQLDB-t fogjuk használni:

export SPRING_PROFILES = "alapértelmezett, hsqldb"

Természetesen, mivel ez egy Spring Boot alkalmazás, ezt itt is megadhatnánk uaa.yml mint a tavasz.profilok ingatlan.

3.4. A JWS kulcspár konfigurálása

Mivel JWT-t használunk, Az UAA-nak magánkulccsal kell rendelkeznie az UAA által kiadott minden JWT aláírásához.

Az OpenSSL ezt egyszerűsíti:

openssl genrsa -out signingkey.pem 2048 openssl rsa -in signingkey.pem -pubout -out authenticationkey.pem

A hitelesítési szerver megteszi jel a JWT a privát kulccsal, valamint az ügyfél és az erőforrás-kiszolgálónk igazolja azt az aláírást a nyilvános kulccsal.

Exportálni fogjuk őket JWT_TOKEN_SIGNING_KEY és JWT_TOKEN_VERIFICATION_KEY:

exportálás JWT_TOKEN_SIGNING_KEY = $ (macska signingkey.pem) exportálás JWT_TOKEN_VERIFICATION_KEY = $ (macska ellenőrzési kulcs.pem) 

Ezeket megint megadhatnánk uaa.yml a jwt.token.signing kulcs és jwt.token.ellenőrző kulcs tulajdonságait.

3.5. Az UAA beindítása

Végül kezdjük a dolgokat:

$ CATALINA_HOME / bin / catalina.sh fut

Ezen a ponton rendelkezünk kell egy működő UAA szerverrel, amely elérhető a következő címen: // localhost: 8080 / uaa.

Ha megyünk // localhost: 8080 / uaa / info, akkor látunk néhány alapvető indítási információt

3.6. Az UAA parancssori kliens telepítése

A CF UAA parancssori kliens az UAA adminisztrációjának fő eszköze, de a használatához először telepítenünk kell a Rubyt:

sudo apt install rubygems gem install cf-uaac

Ezután konfigurálhatjuk uaac hogy rámutassunk az UAA futó példányára:

uaac target // localhost: 8080 / uaa

Ne feledje, hogy ha nem akarunk parancssori klienst használni, akkor természetesen használhatjuk az UAA HTTP kliensét is.

3.7. Ügyfelek és felhasználók feltöltése az UAAC használatával

Most, hogy megvan uaac telepítve, töltsük fel az UAA-t néhány demo adattal. Legalább szükségünk lesz: A ügyfél, a felhasználó, és erőforrás.olvasott és erőforrás.írja csoportok.

Tehát bármilyen adminisztráció elvégzéséhez magunknak kell hitelesítenünk. Kiválasztjuk az UAA-val együtt szállított alapértelmezett adminisztrátort, amely jogosult más ügyfelek, felhasználók és csoportok létrehozására:

uaac token kliens get admin -s adminsecret

(Természetesen, mindenképpen meg kell változtatnunk ezt a fiókot - az oauth-clients.xml fájlon keresztül - szállítás előtt!)

Alapvetően ezt a parancsot olvashatjuk: „Adj egy jelképes, felhasználásával ügyfél hitelesítő adatok a admin és a secret of adminsecret“.

Ha minden jól megy, akkor megjelenik egy sikerüzenet:

A tokent sikeresen lehívta az ügyfél hitelesítő adataival.

A token tárolva van uaac’S állapota.

Most úgy működik, mint admin, regisztrálhatunk egy nevű klienst webappclient val vel kliens hozzáadása:

uaac kliens adjon hozzá webappclient -s webappclientsecret \ --name WebAppClient \ --scope resource.read, resource.write, openid, profile, email, address, phone \ --authorized_grant_types authority_code, refresh_token, client_credentials, password \ --authorities uaa. erőforrás \ --redirect_uri // localhost: 8081 / login / oauth2 / code / uaa

És regisztrálhatunk egy nevű felhasználót is appuser val vel felhasználó hozzáadása:

uaac user add appuser -p appusersecret --emails [e-mail védett]

Ezután két csoportot adunk hozzá - erőforrás.olvasott és erőforrás.írja - a csoport hozzáadása:

uaac group add resource.read uaac group add resource.write

És végül hozzárendeljük ezeket a csoportokat appuser val vel tag hozzá:

uaac tag add resource.read appuser uaac tag add resource.write appuser

Phew! Tehát, amit eddig tettünk:

  • Telepített és konfigurált UAA
  • Telepítve uaac
  • Hozzáadott egy demo klienst, felhasználókat és csoportokat

Tehát ne feledjük ezeket az információkat, és ugorjunk a következő lépésre.

4. OAuth 2.0 kliens

Ebben a részben, a Spring Boot használatával létrehozunk egy OAuth 2.0 kliens alkalmazást.

4.1. Alkalmazás beállítása

Kezdjük azzal, hogy elérjük a Spring Initializr alkalmazást, és létrehozunk egy Spring Boot webalkalmazást. Csak azt választjuk Web és OAuth2 kliens alkatrészek:

 org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-oauth2-client 

Ebben a példában a Spring Boot 2.1.3 verzióját használtuk.

Következő, regisztrálnunk kell ügyfelünket, webappügyfél.

Egyszerűen meg kell adnunk az alkalmazásnak a Ügyfélazonosító, ügyfél-titok, és az UAA-k kibocsátó-uri. Meghatározzuk azokat az OAuth 2.0 hatóköröket is, amelyeket ez az ügyfél meg akar adni a felhasználónak:

#registration spring.security.oauth2.client.registration.uaa.client-id = webappclient spring.security.oauth2.client.registration.uaa.client-secret = webappclientsecret spring.security.oauth2.client.registration.uaa.scope = resource.read, resource.write, openid, profile #provider spring.security.oauth2.client.provider.uaa.issuer-uri = // localhost: 8080 / uaa / oauth / token

Ezekkel a tulajdonságokkal kapcsolatos további információkért tekintse meg a regisztráció és a szolgáltató bab Java dokumentumait.

És mivel már a 8080-as portot használjuk az UAA számára, futtassuk ezt a 8081-et:

szerver.port = 8081

4.2. Belépés

Most, ha hozzáférünk a /Belépés elérési utat, rendelkeznünk kell az összes regisztrált ügyfél listájával. Esetünkben csak egy regisztrált ügyfélünk van:

A linkre kattintva átirányítunk az UAA bejelentkezési oldalra:

Itt jelentkezzünk be appuser / appusersecret.

Az űrlap elküldésével át kell irányítanunk egy jóváhagyási űrlapra, ahol a felhasználó engedélyezheti vagy megtagadhatja az ügyfelünkhöz való hozzáférést:

Ezután a felhasználó megadhatja, hogy mely jogosultságokat akarja. Céljainkra mindent kiválogatunk erőforrás kivételével: ír.

Bármit is ellenőriz a felhasználó, az a létrejövő hozzáférési token hatóköre lesz.

Ennek bizonyítására átmásolhatjuk az index elérési útján látható tokent, // localhost: 8081, és dekódolja a JWT hibakeresővel. A jóváhagyási oldalon látnunk kell az ellenőrzött hatóköröket:

{"jti": "f228d8d7486942089ff7b892c796d3ac", "sub": "0e6101d8-d14b-49c5-8c33-fc12d8d1cc7d", "hatókör": ["resource.read", "openid", "profile"], "client_id": " webappclient "// további követelések}

Amint ügyfélalkalmazásunk megkapja ezt a tokent, hitelesíteni tudja a felhasználót, és hozzáférhetnek az alkalmazáshoz.

Most, egy olyan alkalmazás, amely nem mutat adatokat, nem túl hasznos, ezért a következő lépés az erőforrás-kiszolgáló felállítása lesz - amely rendelkezik a felhasználó adataival - és csatlakoztassa hozzá az ügyfelet.

Az elkészült erőforrás-kiszolgáló két védett API-val rendelkezik: az egyikhez a erőforrás.olvasott hatálya és egy másik, amely megköveteli erőforrás.írja.

Amit látni fogunk, az az az ügyfél az általunk megadott hatókörök felhasználásával felhívhatja a olvas API, de nem ír.

5. Erőforrás-kiszolgáló

Az erőforrás-kiszolgáló a felhasználó védett erőforrásait tárolja.

Ez hitelesíti az ügyfeleket a Engedélyezés fejléc és egy engedélyezési szerverrel konzultálva - esetünkben ez az UAA.

5.1. Alkalmazás beállítása

Az erőforrás-kiszolgálónk létrehozásához a Spring Initializr programot ismét használjuk a Spring Boot webalkalmazás előállításához. Ezúttal a Web és OAuth2 erőforrás-kiszolgáló alkatrészek:

 org.springframework.boot spring-boot-starter-oauth2-resource-server org.springframework.boot spring-boot-starter-web 

A kliens alkalmazáshoz hasonlóan a Spring Boot 2.1.3 verzióját is használjuk.

A következő lépés a futó CF UAA helyének megjelölése a alkalmazás.tulajdonságok fájl:

spring.security.oauth2.resourceserver.jwt.issuer-uri = // localhost: 8080 / uaa / oauth / token

Természetesen válasszunk itt is új kikötőt. 8082 jól fog működni:

szerver.port = 8082

És ez az! Rendelkeznünk kell egy munkaerő-kiszolgálóval, és alapértelmezés szerint minden kéréshez érvényes hozzáférési token szükséges a Engedélyezés fejléc.

5.2. Resource Server API-k védelme

Ezután tegyünk fel néhány végpontot, amelyet érdemes megvédeni.

Hozzáadunk egy RestController két végponttal, az egyik a felhasználókkal engedélyezett erőforrás.olvasott hatókörrel, a másik pedig a felhasználókkal resource.write hatókör:

@GetMapping ("/ read") public String read (Principal megbízó) {return "Hello write:" + megbízó.getName (); } @GetMapping ("/ write") public String write (Principal megbízó) {return "Hello write:" + megbízó.getName (); }

Következő, felülírjuk az alapértelmezett Spring Boot konfigurációt a két erőforrás védelme érdekében:

Az @EnableWebSecurity nyilvános osztály, az OAuth2ResourceServerSecurityConfiguration kiterjeszti a WebSecurityConfigurerAdapter {@Orride védett érvénytelen konfigurációját (HttpSecurity http) a (z) {http.authorizeRequests () .antMatchers ("/ read / **") kivételt dobja. write / ** "). hasAuthority (" SCOPE_resource.write ") .anyRequest (). hitelesített () .és () .oauth2ResourceServer (). jwt (); }}

Ne feledje, hogy a hozzáférési tokenben szereplő hatókörök előtaggal vannak ellátva HATÁLY_ amikor lefordítják őket a tavaszi biztonsághoz Engedélyezett.

5.3. Védett erőforrás igénylése ügyféltől

Az Ügyfél alkalmazásból a két védett erőforrást hívjuk meg RestTemplate. A kérelem benyújtása előtt lekérjük a hozzáférési tokent a kontextusból, és hozzáadjuk a Engedélyezés fejléc:

private String callResourceServer (OAuth2AuthenticationToken authenticationToken, String url) {OAuth2AuthorizedClient oAuth2AuthorizedClient = this.authorizedClientService. loadAuthorizedClient (authenticationToken.getAuthorizedClientRegistrationId (), authenticationToken.getName ()); OAuth2AccessToken oAuth2AccessToken = oAuth2AuthorizedClient.getAccessToken (); HttpHeaders fejlécek = new HttpHeaders (); fejlécek.add ("Engedélyezés", "Viselő" + oAuth2AccessToken.getTokenValue ()); // erőforrás-végpont visszahívási válasza; }

Ne feledje azonban, hogy ha használjuk, akkor eltávolíthatjuk ezt a kazántáblát Web Ügyfél ahelyett RestTemplate.

Ezután két hívást adunk az erőforrás-kiszolgáló végpontjaihoz:

@GetMapping ("/ read") public String read (OAuth2AuthenticationToken authenticationToken) {String url = remoteResourceServer + "/ read"; return callResourceServer (authenticationToken, url); } @GetMapping ("/ write") public String write (OAuth2AuthenticationToken authenticationToken) {String url = remoteResourceServer + "/ write"; return callResourceServer (authenticationToken, url); }

A várakozásoknak megfelelően a / hívásaolvas Az API sikeres lesz, de a /ír egy. A 403 HTTP állapot azt közli velünk, hogy a felhasználó nem jogosult.

6. Következtetés

Ebben a cikkben az OAuth 2.0 rövid áttekintésével kezdtük, mivel ez az UAA, az OAuth 2.0 Authorization Server alapja. Ezután úgy konfiguráltuk, hogy hozzáférési tokeneket bocsásson ki egy ügyfél számára, és biztonságot nyújtson egy erőforrás-kiszolgáló alkalmazás számára.

A példák teljes forráskódja elérhető a Github oldalon.


$config[zx-auto] not found$config[zx-overlay] not found