Opbygning af en grundlæggende UAA-sikret JHipster Microservice

1. Oversigt

I tidligere artikler har vi dækket det grundlæggende i JHipster, og hvordan man bruger det til at generere en mikroservicebaseret applikation.

I denne vejledning vi udforsker JHipsters brugerkonto og autorisationstjeneste - UAA for kort - og hvordan man bruger det til at sikre en fuldt udbygget JHispter-baseret mikroserviceapplikation. Endnu bedre, alt dette kan opnås uden at skrive en eneste linje kode!

2. UAA-kerneegenskaber

Et vigtigt træk ved de applikationer, vi har bygget i vores tidligere artikler, er, at brugerkonti var en integreret del af dem. Nu er det fint, når vi har en enkelt applikation, men hvad hvis vi vil dele brugerkonti mellem flere JHipster-genererede applikationer? Det er her, JHipsters UAA kommer ind.

JHipsters UAA er en mikroservice, der er bygget, implementeret og kørt uafhængigt af andre tjenester i vores applikation. Det fungerer som:

  • En OAuth2 autorisationsserver, baseret på Spring Boot's implementering
  • En Identity Management Server, der udsætter en CRUD API for en brugerkonto

JHipster UAA understøtter også typiske loginfunktioner som selvregistrering og "husk mig". Og selvfølgelig integreres det fuldt ud med andre JHipster-tjenester.

3. Opsætning af udviklingsmiljø

Før vi starter en udvikling, skal vi først være sikre på, at vores miljø har alle sine forudsætninger. Udover alle de værktøjer, der er beskrevet i vores Intro To JHipster-artikel, har vi brug for et kørende JHipster Registry. Ligesom et hurtigt resumé tillader registreringsdatabasetjenesten de forskellige tjenester, som vi opretter, for at finde og tale med hinanden.

Den fulde procedure til generering og kørsel af registreringsdatabasen er beskrevet i afsnit 4.1 i vores JHipster med en Microservice Architecture-artikel, så vi gentager det ikke her. Et Docker-billede er også tilgængeligt og kan bruges som et alternativ.

4. Generering af en ny JHipster UAA-service

Lad os generere vores UAA-tjeneste ved hjælp af kommandolinjeværktøjet JHipster:

$ mkdir uaa $ cd uaa $ jhipster 

Det første spørgsmål, vi skal besvare, er, hvilken type applikation vi vil generere. Brug piletasterne til at vælge "JHipster UAA (til mikroservice OAuth2-godkendelse)":

Dernæst bliver vi bedt om et par spørgsmål vedrørende specifikke detaljer vedrørende den genererede tjeneste, såsom applikationsnavn, serverport og serviceopdagelse:

For det meste er standardsvarene fine. Med hensyn til applikationens basisnavn, som påvirker mange af de genererede artefakter, vi har valgt “Uaa” (små bogstaver) - et fornuftigt navn. Vi kan lege med de andre værdier, hvis vi vil, men det ændrer ikke hovedfunktionerne i det genererede projekt.

Efter at have besvaret disse spørgsmål opretter JHipster alle projektfiler og installerer npm pakkeafhængigheder (som ikke virkelig bruges i dette tilfælde).

Vi kan nu bruge det lokale Maven-script til at opbygge og køre vores UAA-tjeneste:

$ ./mvnw ... build meddelelser udeladt 2018-10-14 14: 07: 17.995 INFO 18052 --- [restartedMain] com.baeldung.jhipster.uaa.UaaApp: ------------ ---------------------------------------------- Ansøgning 'uaa' løber! Adgangs-URL'er: Lokal: // localhost: 9999 / Ekstern: //192.168.99.1:9999/ Profil (er): [dev, swagger] ------------------- --------------------------------------- 2018-10-14 14: 07: 18.000 INFO 18052 --- [restartedMain] com.baeldung.jhipster.uaa.UaaApp: --------------------------------- ------------------------- Config Server: Forbundet til JHipster Registry konfigurationsserver! -------------------------------------------------- -------- 

Den vigtigste besked, man skal være opmærksom på her, er den, der siger, at UAA er forbundet til JHipster Registry. Denne meddelelse indikerer, at UAA var i stand til at registrere sig selv og vil være tilgængelig for opdagelse af andre mikrotjenester og gateways.

5. Test af UAA-tjenesten

Da den genererede UAA-tjeneste ikke har nogen brugergrænseflade i sig selv, skal vi bruge direkte API-opkald til at teste, om den fungerer som forventet.

Der er to funktioner, som vi skal sørge for, at de fungerer, før vi bruger det med andre dele eller vores system: OAuth2 token generation og konto hentning.

Lad os først få et nyt token fra vores UAAs OAuth-slutpunkt, ved hjælp af en simpel krølle kommando:

$ curl -X POST --data \ "brugernavn = bruger & adgangskode = bruger & grant_type = adgangskode & scope = openid" \ // web_app: [e-mailbeskyttet]: 9999 / oauth / token 

Her har vi brugt adgangskode flow ved hjælp af to par legitimationsoplysninger. I denne form for flow sender vi klientlegitimationsoplysninger ved hjælp af grundlæggende HTTP-godkendelse, som vi koder direkte i URL'en.

Slutbrugeroplysningerne sendes som en del af kroppen ved hjælp af standardparametre for brugernavn og adgangskode. Vi bruger også den navngivne brugerkonto "bruger", som er tilgængelig som standard i testprofilen.

Forudsat at vi har leveret alle detaljer korrekt, får vi et svar, der indeholder et adgangstoken og et opdateringstoken:

{"access_token": "eyJh ... (token udeladt)", "token_type": "bærer", "refresh_token": "eyJ ... (token udeladt)", "expires_in": 299, "scope": " openid "," iat ": 1539650162," jti ":" 8066ab12-6e5e-4330-82d5-f51df16cd70f "}

Det kan vi nu Brug den returnerede adgangstoken for at få oplysninger om den tilknyttede konto ved hjælp af konto ressource, som er tilgængelig i UAA-tjenesten:

$ curl -H "Autorisation: Bærer eyJh ... (adgangstoken udeladt)" \ // localhost: 9999 / api / account {"id": 4, "login": "user", "firstName": "User" , "lastName": "Bruger", "email": "[email protected]", "imageUrl": "", "enabled": true, "langKey": "da", "createdBy": "system", " createdDate ":" 2018-10-14T17: 07: 01.336Z "," lastModifiedBy ":" system "," lastModifiedDate ": null," autoriteter ": [" ROLE_USER "]} 

Bemærk, at vi skal udstede denne kommando, inden adgangstoken udløber. UAA-tjenesten udsteder som standard tokens, der er gyldige i fem minutter, hvilket er en fornuftig værdi for produktionen.

Vi kan nemt ændre gyldige tokens levetid ved at redigere ansøgning-.yml fil, der svarer til den profil, vi kører appen under, og indstiller uaa.web-client-configuration.access-token-validity-in-seconds nøgle. Indstillingsfilerne findes i src / main / resources / config katalog over vores UAA-projekt.

6. Generering af UAA-aktiveret gateway

Nu hvor vi er overbeviste om, at vores UAA-tjeneste og service-registreringsdatabasen fungerer, lad os oprette et økosystem, som disse kan interagere med. I slutningen har vi tilføjet:

  • En vinkelbaseret frontend
  • En mikroservice-back-end
  • En API-gateway, der fronter begge disse

Lad os faktisk begynde med gatewayen, da det vil være den service, der vil forhandle med UAA om godkendelse. Det vil være vært for vores front-end-applikation og rute API-anmodninger til andre mikrotjenester.

Endnu en gang bruger vi kommandolinjeværktøjet JHipster i en nyoprettet mappe:

$ mkdir gateway $ cd gateway $ jhipster

Som før er vi nødt til at besvare et par spørgsmål for at generere projektet. De vigtige er følgende:

  • Applikationstype: skal være "Microservices gateway"
  • Ansøgning navn: Vi bruger “gateway” denne gang
  • Service opdagelse: Vælg “JHipster registry”
  • Godkendelsestype:Vi skal vælge indstillingen "Godkendelse med JHipster UAA-server" her
  • UI Framework: Lad os vælge “Angular 6”

Når JHipster genererer alle dens artefakter, kan vi opbygge og køre gatewayen med det medfølgende Maven wrapper script:

$ ./mwnw ... mange meddelelser udeladt ---------------------------------------- ------------------ Ansøgning 'gateway' kører! Adgangs-URL'er: Lokal: // localhost: 8080 / Ekstern: //192.168.99.1:8080/ Profil (er): [dev, swagger] ------------------- --------------------------------------- 2018-10-15 23: 46: 43.011 INFO 21668 --- [genstartet hoved] c.baeldung.jhipster.gateway.GatewayApp: --------------------------------- ------------------------- Config Server: Forbundet til JHipster Registry konfigurationsserver! -------------------------------------------------- -------- 

Med ovenstående meddelelse kan vi få adgang til vores applikation ved at pege vores browser på // lokal vært: 8080, som skal vise den standardgenererede startside:

Lad os gå videre og logge ind på vores applikation ved at navigere til Konto> Login menupunkt. Vi bruger admin / admin som legitimationsoplysninger, som JHipster opretter automatisk som standard. Alt går godt, velkomstsiden viser en besked, der bekræfter en vellykket login:

Lad os sammenfatte, hvad der skete med at få os her: For det første sendte gatewayen vores legitimationsoplysninger til UAAs OAuth2-token-slutpunkt, som validerede dem og genererede et svar indeholdende en adgang og et opdateret JWT-token. Gatewayen tog derefter disse tokens og sendte dem tilbage til browseren som cookies.

Derefter kaldte den kantede frontend den / uaa / api / konto API, som igen gatewayen videresendes til UAA. I denne proces tager gatewayen cookien, der indeholder adgangstokenet, og bruger dens værdi til at føje en autorisationsoverskrift til anmodningen.

Hvis det er nødvendigt, kan vi se al denne strøm i detaljer ved at kontrollere både UAA og Gateway's logfiler. Vi kan også få fulde data på ledningsniveau ved at indstille org.apache.http.wire loggerniveau til DEBUG.

7. Generering af en UAA-aktiveret mikroservice

Nu hvor vores applikationsmiljø er i gang, er det tid til at tilføje en simpel mikroservice til det. Vi opretter en "tilbud" mikroservice, som afslører en komplet REST API, der giver os mulighed for at oprette, forespørge, ændre og slette et sæt aktiekurser. Hvert tilbud vil kun have tre egenskaber:

  • Citatets handelssymbol
  • Dens pris, og
  • Sidste handels tidsstempel

Lad os gå tilbage til vores terminal og bruge JHipsters kommandolinjeværktøj til at generere vores projekt:

$ mkdir citater $ cd citater $ jhipster 

Denne gang beder vi JHipster om at generere en Microservice applikation, som vi kalder "citater". Spørgsmålene svarer til dem, vi har besvaret før. Vi kan beholde standardindstillingerne for de fleste af dem, bortset fra disse tre:

  • Service Discovery: Vælg "JHipster Registry", da vi allerede bruger det i vores arkitektur
  • Sti til UAA-applikationen: Da vi holder alle projektmapper under samme mappe, vil dette være ../uaa (medmindre vi selvfølgelig har ændret det)
  • Godkendelsestype: Vælg “JHipster UAA-server”

Her er hvordan en typisk rækkefølge af svar vil se ud i vores tilfælde:

Når JHipster er færdig med at generere projektet, kan vi gå videre og bygge det:

$ mvnw ... mange, mange meddelelser udeladt ---------------------------------------- ------------------ Ansøgning 'citater' kører! Adgangs-URL'er: Lokal: // localhost: 8081 / Ekstern: //192.168.99.1:8081/ Profil (er): [dev, swagger] ------------------- --------------------------------------- 2018-10-19 00: 16: 05.581 INFO 16092 --- [restartedMain] com.baeldung.jhipster.quotes.QuotesApp: --------------------------------- ------------------------- Config Server: Forbundet til JHipster Registry konfigurationsserver! -------------------------------------------------- -------- ... flere meddelelser udeladt 

Meddelelsen "Forbundet til JHipster Registry-konfigurationsserveren!" er det, vi leder efter her. Dens tilstedeværelse fortæller os, at mikroservicen registrerede sig i registreringsdatabasen, og på grund af dette vil gatewayen være i stand til at dirigere anmodninger til vores "tilbud" -ressource og vise den på et flot brugergrænseflade, når vi først har oprettet det. Da vi bruger en mikroservicearkitektur, deler vi denne opgave i to dele:

  • Opret "tilbud" ressource back-end-tjenesten
  • Opret brugergrænsefladen "tilbud" i frontend (del af gateway-projektet)

7.1. Tilføjelse af citatressourcen

Først skal vi Sørg for, at tilbudet om mikroservice er stoppet - vi kan ramme CTRL-C i det samme konsolvindue, som vi tidligere brugte til at køre det.

Lad os nu tilføje en enhed til projektet ved hjælp af JHipsters værktøj. Denne gang bruger vi import-jdl kommando, som vil redde os fra den kedelige og fejlbehæftede proces med at levere alle detaljer individuelt. For yderligere information om JDL-formatet henvises til den fulde JDL-reference.

Næste, vi oprette en kaldet tekstfil citater.jh indeholder vores Citere enhedsdefinitionsammen med nogle kodegenereringsdirektiver:

enhed Citat {symbol Streng krævet unik, pris BigDecimal krævet, lastTrade ZonedDateTime krævet} dto Citat med mapstruct paginat Citat med pagineringstjeneste Citat med serviceImpl mikroservice Citat med citatfilter Citat clientRootFolder Citat med tilbud 

Det kan vi nu importer denne enhedsdefinition til vores projekt:

$ jhipster import-jdl citater.jh 

Bemærk: under importen vil JHipster klage over en konflikt, mens de anvender ændringer til master.xml fil. Vi kan sikkert vælge overskrive mulighed i dette tilfælde.

Vi kan nu oprette og køre vores mikroservice igen ved hjælp af mvnw. Når det er op, kan vi kontrollere, at gatewayen henter den nye rute, der har adgang til Gateway visning, tilgængelig fra Administration menu. Denne gang kan vi se, at der er en post til “/ Tilbud / **” rute, hvilkenviser, at backend er klar til brug af brugergrænsefladen.

7.2. Tilføjelse af Citat UI

Lad os endelig generere CRUD UI i gateway-projektet, som vi bruger til at få adgang til vores tilbud. Vi bruger den samme JDL-fil fra "citater" mikroserviceprojektet til at generere UI-komponenterne, og vi importerer den ved hjælp af JHipsters import-jdl kommando:

$ jhipster import-jdl ../jhipster-quotes/quotes.jh ... meddelelser udeladt? Overskrive webpack \ webpack.dev.js? y ... meddelelser udeladt Tillykke, JHipster-udførelsen er fuldført! 

Under importen vil JHipster bede et par gange om den handling, den skal tage med hensyn til modstridende filer. I vores tilfælde kan vi simpelthen overskrive eksisterende ressourcer, da vi ikke har foretaget nogen tilpasning.

Nu kan vi genstarte gatewayen og se, hvad vi har opnået. Lad os pege vores browser på gatewayen på // localhost: 8080og sørger for, at vi opdaterer dets indhold. Det Enheder menuen skal nu have en ny post til Citater ressource:

Ved at klikke på denne menupunkt vises Citater liste skærm:

Som forventet er noteringen tom - vi har endnu ikke tilføjet nogen tilbud! Lad os prøve at tilføje en ved at klikke på "Opret nyt tilbudsknap" øverst til højre på dette skærmbillede, som bringer os til formularen Opret / rediger:

Vi kan se, at den genererede form har alle forventede funktioner:

  • Nødvendige felter er markeret med en rød indikator, der bliver grøn, når den først er udfyldt
  • Dato / tid og numeriske felter bruger native komponenter til at hjælpe med dataindtastning
  • Vi kan annullere denne aktivitet, som efterlader data uændrede eller gemme vores nye eller ændrede enhed

Efter at have udfyldt denne formular og ramt Gemme, vi får vist resultaterne på noteringsskærmen. Vi kan nu se det nye Citater eksempeli datagitteret:

Som administrator har vi også adgang til API-menupunktet, der fører os til standard Swagger API Developer Portal. På dette skærmbillede kan vi vælge en af ​​de tilgængelige API'er, der skal udøves:

  • Standard: Gateway's egen API, der viser tilgængelige ruter
  • uaa: Konto- og bruger-API'er
  • citater: Citater API

8. Næste trin

Den applikation, vi hidtil har bygget, fungerer som forventet og giver et solidt grundlag for videreudvikling. Vi bliver helt sikkert også nødt til at skrive noget (eller en masse) brugerdefineret kode afhængigt af kompleksiteten af ​​vores krav. Nogle områder, der sandsynligvis har brug for noget arbejde, er:

  • Brugergrænseflade udseende og fornemmelse: Dette er normalt ret let på grund af den måde, front-end-applikationen er struktureret på - vi kan gå langt ved blot at rode med CSS og tilføje nogle billeder
  • Ændringer af brugerregister: Nogle organisationer har allerede en slags internt brugerlager (f.eks. Et LDAP-bibliotek) - dette vil kræve ændringer på UAA, men det pæne er, at vi kun behøver at ændre det en gang
  • Finer kornet tilladelse på enheder:Standardsikkerhedsmodellen, der bruges af den genererede enhedsback-end, har ikke nogen instans- og / eller feltniveau-sikkerhed - det er op til udvikleren at tilføje disse begrænsninger på det rette niveau (API eller service afhængigt af tilfældet)

Selv med disse bemærkninger kan brug af et værktøj som JHispter hjælpe meget, når man udvikler en ny applikation. Det vil medføre et solidt fundament og kan holde et godt niveau af konsistens i vores kodebase, når systemet - og udviklere - udvikler sig.

9. Konklusion

I denne artikel har vi vist, hvordan man bruger JHispter til at oprette en fungerende applikation baseret på en mikrotjenestearkitektur og JHipsters UAA-server. Vi opnåede det uden at skrive en enkelt linje med Java-kode, hvilket er ret imponerende.

Som sædvanlig er den fulde kode for projekterne præsenteret i denne artikel tilgængelig i vores GitHub-arkiv.


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