streamalism.org

1. Oversikt

Cloud Foundry User Account and Authentication (CF UAA) er en identitetsadministrasjons- og autorisasjonstjeneste. Mer presist, det er en OAuth 2.0-leverandør som tillater autentisering og utstedelse av tokens til klientapplikasjoner.

I denne opplæringen skal vi dekke det grunnleggende om å sette opp en CF UAA-server. Vi vil deretter se på hvordan du bruker den til å beskytte ressursserverapplikasjoner.

Men før, la oss avklare UAAs rolle i OAuth 2.0 autorisasjonsrammeverket.

2. Cloud Foundry UAA og OAuth 2.0

La oss starte med å forstå hvordan UAA forholder seg til OAuth 2.0-spesifikasjonen.

OAuth 2.0-spesifikasjonen definerer fire deltakere som kan koble til hverandre: en ressurseier, en ressursserver, en klient og en autorisasjonsserver.

Som en OAuth 2.0-leverandør spiller UAA rollen som autorisasjonsserver. Dette betyr det primære målet er å utstede tilgangstokener for klient applikasjoner og validere disse tokens for ressursservers.

For å tillate samspillet mellom disse deltakerne, må vi først sette opp en UAA-server og deretter implementere to applikasjoner til: en som klient og den andre som ressursserver.

Vi bruker Godkjennelseskoden tilskuddsflyt med klienten. Og vi bruker Bearer-token-autorisasjon med ressursserveren. For et mer sikkert og effektivt håndtrykk, bruker vi signerte JWT-er som tilgangstokener.

3. Sette opp en UAA-server

Først, vi installerer UAA og fyller den med noen demodata.

Når det er installert, registrerer vi et klientprogram som heter webappclient. Deretter oppretter vi en bruker som heter appuser med to roller, resource.read og resource.write.

3.1. Installasjon

UAA er et Java-webapplikasjon som kan kjøres i en hvilken som helst kompatibel servletcontainer. I denne opplæringen bruker vi Tomcat.

La oss gå videre og last ned UAA-krigen og legg den inn i Tomcat utplassering:

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. krig

Før vi starter den, må vi konfigurere datakilden og JWS-nøkkelparet.

3.2. Nødvendig konfigurasjon

UAA leser som standard konfigurasjon fra uaa.yml på klassestien. Men siden vi nettopp har lastet ned krig fil, vil det være bedre for oss å fortelle UAA et tilpasset sted på filsystemet vårt.

Vi kan gjøre dette ved å sette inn UAA_CONFIG_PATH eiendom:

eksporter UAA_CONFIG_PATH = ~ / .uaa

Alternativt kan vi stille CLOUD_FOUNDRY_CONFIG_PATH. Eller vi kan spesifisere en ekstern plassering med UAA_CONFIG_URL.

Deretter kan vi kopiere UAAs nødvendige konfigurasjon til vår konfigurasjonsbane:

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

Merk at vi sletter de tre siste linjene fordi vi skal erstatte dem om et øyeblikk.

3.3. Konfigurere datakilden

Så la oss konfigurere datakilden, der UAA skal lagre informasjon om klienter.

For formålet med denne opplæringen skal vi bruke HSQLDB:

eksporter SPRING_PROFILES = "standard, hsqldb"

Siden dette er en Spring Boot-applikasjon, kan vi selvfølgelig også spesifisere dette i uaa.yml som våren.profiler eiendom.

3.4. Konfigurere JWS-nøkkelparet

Siden vi bruker JWT, UAA må ha en privat nøkkel for å signere hver JWT som UAA utsteder.

OpenSSL gjør dette enkelt:

openssl genrsa -out-signeringsnøkkel.pem 2048 openssl rsa -in-signeringsnøkkel.pem -pubout -out verificationkey.pem

Autorisasjonsserveren vil skilt JWT med den private nøkkelen, og vår klient og ressursserver vil bekrefte den signaturen med den offentlige nøkkelen.

Vi eksporterer dem til JWT_TOKEN_SIGNING_KEY og JWT_TOKEN_VERIFICATION_KEY:

eksporter JWT_TOKEN_SIGNING_KEY = $ (kattesigneringsnøkkel.pem) eksporter JWT_TOKEN_VERIFICATION_KEY = $ (kattverifiseringsnøkkel.pem) 

Igjen, vi kunne spesifisere disse i uaa.yml via jwt.token.signing-key og jwt.token.verifiseringsnøkkel eiendommer.

3.5. Starter UAA

Til slutt, la oss starte ting:

$ CATALINA_HOME / bin / catalina.sh kjøre

På dette tidspunktet bør vi ha en fungerende UAA-server tilgjengelig på // localhost: 8080 / uaa.

Hvis vi går til // localhost: 8080 / uaa / info, så får vi se noen grunnleggende oppstartsinfo

3.6. Installere UAA Command Line Client

CF UAA Command-Line Client er hovedverktøyet for administrering av UAA, men for å bruke det, må vi først installere Ruby:

sudo apt installere rubygems perle installere cf-uaac

Deretter kan vi konfigurere uaac for å peke på vår løpende forekomst av UAA:

uaac mål // localhost: 8080 / uaa

Merk at hvis vi ikke vil bruke kommandolinjeklienten, kan vi selvfølgelig bruke UAAs HTTP-klient.

3.7. Befolke klienter og brukere som bruker UAAC

Nå som vi har gjort det uaac installert, la oss fylle UAA med noen demodata. I det minste trenger vi: A klient, a bruker, og resource.read og resource.write grupper.

Så for å utføre administrasjon, må vi autentisere oss selv. Vi velger standardadministratoren som leveres med UAA, som har tillatelse til å opprette andre klienter, brukere og grupper:

uaac token-klient får admin-adminsecret

(Selvfølgelig, vi må definitivt endre denne kontoen - via filen oauth-clients.xml - før forsendelse!)

I utgangspunktet kan vi lese denne kommandoen som: “Gi meg en token, ved hjelp av klient legitimasjon med client_id av admin og en secret av adminsecret“.

Hvis alt går bra, ser vi en suksessmelding:

Hentet token via tilskudd fra klienten.

Tokenet er lagret i uaac’S tilstand.

Nå fungerer som admin, kan vi registrere en klient som heter webappclient med klient legge til:

uaac-klient legger til webappclient -s webappclientsecret \ --navn WebAppClient \ --scope resource.read, resource.write, openid, profile, e-post, adresse, telefon \ --authorized_grant_types autorisasjonskode, refresh_token, client_credentials, passord \ --authorities uaa. ressurs \ --redirect_uri // localhost: 8081 / login / oauth2 / code / uaa

Og også, vi kan registrere en bruker som heter appuser med bruker legge til:

uaac bruker legge til appuser -p appusersecret --emails [email protected]

Deretter legger vi til to grupper - resource.read og resource.write - bruker med gruppe legge til:

uaac-gruppe legg til ressurs. les uaac-gruppe legg til resource.write

Og til slutt vil vi tilordne disse gruppene til appuser med medlem legge til:

uaac medlem legge til ressurs. lese appuser uaac medlem legge til resource.write appuser

Puh! Så det vi har gjort så langt er:

• Installert og konfigurert UAA
• Installert uaac
• Lagt til en demoklient, brukere og grupper

Så, la oss huske på disse delene av informasjon og hoppe til neste trinn.

4. OAuth 2.0-klient

I denne seksjonen, vi bruker Spring Boot til å lage et OAuth 2.0-klientprogram.

4.1. Programoppsett

La oss starte med å få tilgang til Spring Initializr og generere en Spring Boot-webapplikasjon. Vi velger bare Internett og OAuth2-klient komponenter:

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

I dette eksemplet har vi brukt versjon 2.1.3 av Spring Boot.

Neste, vi trenger å registrere vår klient, webappklient.

Ganske enkelt må vi gi appen den klient-ID, klienthemmelighet, og UAA utsteder-uri. Vi spesifiserer også OAuth 2.0-omfangene som denne klienten vil at brukeren skal gi den:

#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

For mer informasjon om disse egenskapene, kan vi se på Java-dokumentene for registrerings- og leverandørbønner.

Og siden vi allerede bruker port 8080 for UAA, la oss kjøre på 8081:

server.port = 8081

4.2. Logg Inn

Nå hvis vi får tilgang til /Logg Inn sti, bør vi ha en liste over alle registrerte kunder. I vårt tilfelle har vi bare en registrert klient:

Ved å klikke på lenken vil vi omdirigere oss til UAA-påloggingssiden:

Her, la oss logge inn med appuser / appusersecret.

Send inn skjemaet skal omdirigere oss til et godkjenningsskjema der brukeren kan autorisere eller nekte tilgang til klienten vår:

Brukeren kan da gi hvilke privilegier hun ønsker. For våre formål, vi velger alt unntatt ressurs: skriv.

Uansett hva brukeren sjekker, er omfanget av det resulterende tilgangstokenet.

For å bevise dette kan vi kopiere token som vises i indeksbanen, // lokal vert: 8081, og dekode den ved hjelp av JWT-feilsøkingsprogrammet. Vi bør se omfanget vi sjekket på godkjenningssiden:

{"jti": "f228d8d7486942089ff7b892c796d3ac", "sub": "0e6101d8-d14b-49c5-8c33-fc12d8d1cc7d", "scope": ["resource.read", "openid", "profile"], "client_id": " webappclient "// flere krav}

Når klientapplikasjonen vår mottar dette tokenet, kan det autentisere brukeren, og de får tilgang til appen.

Nå, en app som ikke viser noen data, er ikke veldig nyttig, så vårt neste trinn vil være å stå opp en ressursserver - som har brukerens data - og koble klienten til den.

Den fullførte ressursserveren vil ha to beskyttede API-er: en som krever resource.read omfang og et annet som krever resource.write.

Det vi får se er det klienten, ved hjelp av omfangene vi innvilget, vil kunne ringe lese API men ikke skrive.

5. Ressursserver

Ressursserveren er vert for brukerens beskyttede ressurser.

Det autentiserer klienter via Autorisasjon topptekst og i samråd med en autorisasjonsserver - i vårt tilfelle er det UAA.

5.1. Programoppsett

For å opprette ressursserveren vår, bruker vi Spring Initializr igjen til å generere en Spring Boot-webapplikasjon. Denne gangen velger vi Internett og OAuth2 ressursserver komponenter:

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

Som med klientapplikasjonen bruker vi versjon 2.1.3 av Spring Boot.

Det neste trinnet er å indikere plasseringen til den kjørende CF UAA i application.properties fil:

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

La oss selvfølgelig velge en ny havn også. 8082 vil fungere bra:

server.port = 8082

Og det er det! Vi bør ha en fungerende ressursserver, og som standard vil alle forespørsler kreve et gyldig tilgangstoken i Autorisasjon Overskrift.

5.2. Beskyttelse av ressursserver-APIer

Neste, la oss legge til noen sluttpunkter som er verdt å beskytte, skjønt.

Vi legger til en RestController med to endepunkter, ett godkjent for brukere som har resource.read omfang og det andre for brukere som har resource.write omfang:

@GetMapping ("/ read") offentlig Strenglesning (rektor) {retur "Hei skriv:" + principal.getName (); } @GetMapping ("/ skriv") offentlig Strengskriving (rektor) {retur "Hei skriv:" + principal.getName (); }

Neste, Vi overstyrer standard Spring Boot-konfigurasjon for å beskytte de to ressursene:

@EnableWebSecurity offentlig klasse OAuth2ResourceServerSecurityConfiguration utvider WebSecurityConfigurerAdapter {@Override beskyttet ugyldig konfigurasjon (HttpSecurity http) kaster Unntak {http.authorizeRequests () .antMatchers ("/ read / **"). HasAuthority ("SCOPE."). skriv / ** "). hasAuthority (" SCOPE_resource.write ") .anyRequest (). autentisert () .and () .oauth2ResourceServer (). jwt (); }}

Vær oppmerksom på at omfangene som er gitt i tilgangstokenet er foran OMFANG_ når de blir oversatt til en vårsikkerhet Gitt autoritet.

5.3. Be om en beskyttet ressurs fra en klient

Fra klientapplikasjonen vil vi kalle de to beskyttede ressursene ved hjelp av RestTemplate. Før du sender forespørselen, henter vi tilgangstokenet fra konteksten og legger det til Autorisasjon Overskrift:

private String callResourceServer (OAuth2AuthenticationToken authenticationToken, String url) {OAuth2AuthorizedClient oAuth2AuthorizedClient = this.authorizedClientService. loadAuthorizedClient (authenticationToken.getAuthorizedClientRegistrationId (), authenticationToken.getName ()); OAuth2AccessToken oAuth2AccessToken = oAuth2AuthorizedClient.getAccessToken (); HttpHeaders headers = nye HttpHeaders (); headers.add ("Authorization", "Bearer" + oAuth2AccessToken.getTokenValue ()); // svar på returressursens endepunkt; }

Vær imidlertid oppmerksom på at vi kan fjerne denne kjeleplaten hvis vi bruker den WebClient i stedet for RestTemplate.

Deretter legger vi til to anrop til ressursserverens endepunkter:

@GetMapping ("/ read") offentlig Strenglesning (OAuth2AuthenticationToken authenticationToken) {String url = remoteResourceServer + "/ read"; returner callResourceServer (authenticationToken, url); } @GetMapping ("/ skriv") offentlig strengskriving (OAuth2AuthenticationToken authenticationToken) {String url = remoteResourceServer + "/ skriv"; returner callResourceServer (authenticationToken, url); }

Som forventet, samtalen til /lese API vil lykkes, men ikke /skrive en. HTTP-status 403 forteller oss at brukeren ikke er autorisert.

6. Konklusjon

I denne artikkelen startet vi med en kort oversikt over OAuth 2.0, da det er grunnlaget for UAA, en OAuth 2.0 Authorization Server. Deretter konfigurerte vi den for å utstede tilgangstokener for en klient og sikre en ressursserverapplikasjon.

Den fulle kildekoden for eksemplene er tilgjengelig på Github.