Kako osigurati mikroservise na AWS pomoću Cognito, API Gateway i Lambda

Programiranje

Rukovanje autorizacijom je bolno. Ali većina aplikacija mora provjeriti autentičnost korisnika i kontrolirati kojim resursima mogu pristupiti. Mikroservisi, iako rastu u popularnosti, mogu dodati složenost. Morate osigurati i radnje korisnika i interakciju između usluga.

AWS nudi nekoliko izvrsnih gradivnih elemenata za arhitekturu mikro usluga. Ali poput namještaja iz IKEA-e, i sami morate sastaviti dijelove. Uz to upute nisu baš dobre.

Izgradit ćemo jednostavnu aplikaciju i konfigurirati AWS za autentifikaciju korisnika i osiguravanje mikro usluge.

TL; DR (za nestrpljive)

Radna demonstracija: //auth-api-demo.firebaseapp.com/ (korisnik: demouserlozinka:demoPASS123)

GitHub Repo : //github.com/csepulv/auth-api-demo

Osnovni slučaj upotrebe / pretpostavka: Postoje dvije skupine resursa - a) oni kojima je potreban autentificirani korisnik i b) oni koji ne trebaju .

Koristit ćemo

  • AWS Lambda, API Gateway i Cognito
  • Claudia.js (za izgradnju našeg API-ja)
  • Reagirajte (za našeg web klijenta)

Za one koji čitaju do kraja, tu su neke dobrote.

Sad, za detalje.

Konceptualni model primjene

Demo aplikacija implementira sljedeći model.

  • Korisnik se prijavi u aplikaciju i dobije token za provjeru autentičnosti
  • AWS koristi ovaj token za provjeru identiteta i autorizaciju zahtjeva korisnika za zaštićenim resursima
  • App Gateway stvara virtualni iskop između korisnika i resursa aplikacije

AWS usluge

Ako ste novi u AWS-u, postoji službeni portal AWS Getting Started. Također, Udemy ima besplatan tečaj, AWS Essentials.

Trebat će vam pristup AWS računu. Možete se prijaviti za besplatni nivo AWS-a.

AWS Lambda

Iako je EC2 jedna od najpopularnijih AWS opcija, mislim da je Lambda prikladnija za mikroservise. EC2 primjerci su virtualni strojevi. Odgovorni ste za sve, od operativnog sustava do sav softver koji pokreće. Lambda je funkcija kao model usluge. Ne postoji spremanje ili postavljanje poslužitelja; napišete svoju uslužnu logiku.

Za više informacija pogledajte dokumente AWS Lambda.

Ali tu je bora s Lambdasom. Korisnik aplikacije ne može ih izravno doseći. Lambdama trebaju okidači koji pozivaju Lambda funkciju. To može biti poruka u redu ili, u našem slučaju, zahtjev API pristupnika.

AWS API pristupnik

API pristupnik osigurava iskorak oko vaših aplikacijskih usluga. Može prijaviti aktivnost korisnika, provjeriti autentičnost zahtjeva i provesti pravila korištenja (poput ograničenja brzine). (Dobra referenca su AWS API Gateway dokumenti.)

AWS Cognito

AWS Cognito usluga je upravljanja korisnicima, provjere autentičnosti i kontrole pristupa. Nažalost, sve značajke i konfiguracija mogu ponekad zbuniti. (Kao da su sigurnost i provjera autentičnosti ikad jednostavni.?) Usredotočit ćemo se na osnovne elemente Cognita radi osiguranja našeg API-ja.

Postavljanje programa i okruženja

Recept za našu demo aplikaciju je:

  1. U AWS Cognito stvorite korisnički bazen (s klijentskom aplikacijom) i federated Identity Pool.
  2. U AWS API Gatewayu izradite plan korištenja i API ključ
  3. Koristeći Claudia JS, izradite i implementirajte jednostavni API zasnovan na AWS Lambda.
  4. Ažurirajte ulogu AWS IAM-a kako biste autoriziranim korisnicima odobrili pristup zaštićenim API metodama
  5. Izradite aplikaciju za jednu stranicu (SPA) pomoću create-react-app. Koristit će AWS Cognito i čini potpisane (i ovjerene) API zahtjeve

Detaljno postavljanje AWS-a nalazi se u aws-setup.mddemo GitHub repo-u. Istaknut ćemo aspekte postavljanja i objasniti kako stvari funkcioniraju.

AWS Cognito

Korisnički bazen, klijentska aplikacija i ime domene

Stvorit ćemo korisnički skup s zadanim postavkama. Pojedinosti i snimke zaslona:

  • Korisnički bazen
  • Prijava klijenta
  • Naziv domene

Udruženi identitet

Možda je malo zbunjujuće da nam trebaju i Korisnički fond i Federirani Identity Pool. Ashan Fernando ima prilično dobro objašnjenje u ovom postu. Jednostavno rečeno,

  • Korisnički skupovi pružaju korisniku pristup aplikaciji. Ovo je poput usluga poput Auth0.
  • Savezne Identitet bazen pruža pristup AWS resursa.

Kombinacijom dva spremišta, naša aplikacija može provjeriti autentičnost korisnika, a AWS će dodijeliti privremene vjerodajnice. Te vjerodajnice omogućuju korisniku pristup AWS resursima. Uloga IAM-a, konfigurirana u spremištu identiteta, određuje privilegije za privremene vjerodajnice.

Detaljna postavka Federated Identity Pool je ovdje.

AWS API pristupnik

Predlažem da izradite plan korištenja za naš API. Iako to nije uvjet, dobra je praksa jer troškovi AWS-a mogu "pobjeći" ako niste oprezni. Izradit ćemo plan korištenja , imenovati api-auth-demoi postaviti brzinu gasa i praska te dnevnu kvotu za API pozive. Također ćemo stvoriti API ključ, koji će aplikacija web klijenta koristiti. (Potpuni detalji o postavljanju nalaze se ovdje.)

Završili smo glavninu našeg postavljanja AWS-a. Sada ćemo napisati svoje Lambda funkcije, a zatim izraditi našu web aplikaciju React.

AWS Lambda i Claudia JS

Naše Lambda funkcije napisat ćemo pomoću Node.js. Claudia.js će implementirati naše Lambda-e i konfigurirati API pristupnik. (Kao napomenu, Serverless framework pruža sličnu funkcionalnost.)

Za naš primjer potreban nam je samo jednostavni API. Stvorit ćemo dvije API metode (tj. Vrlo jednostavne mikro usluge): jednu za ovjerene korisnike i jednu za goste.

Upotrijebit ćemo Claudia API Builder, koji omogućuje mapiranje više ruta na jednu lambda. Mehanizam usmjeravanja sličan je usmjeravanju u okvirima kao što je Express.js.

 const ApiBuilder = require("claudia-api-builder"); const api = new ApiBuilder(); api.get("/no-auth",request => { return {message: "Open for All!"}; }, { apiKeyRequired: true } ); api.get("/require-auth", request => { return {message: "You're past the velvet rope!"}; }, { apiKeyRequired: true, authorizationType: "AWS_IAM" } ); module.exports = api; view rawapi.js hosted with ❤ by GitHub

Upotrijebit ćemo naredbenu liniju Claudia.js za postavljanje API-ja na AWS.

claudia create --region us-west-2 --api-module api --name auth-api-demo

NAPOMENA: Sve promjene na sustavu api.jsmorat će se ponovno primijeniti. Koristiticlaudia update...

API ključevi i aut

U api.js, {apiKeyRequired: true}označava da API zahtjevi zahtijevaju API ključ. {authorizationType: 'AWS_IAM'}konfigurira API pristupnik za autorizaciju pomoću AWS IAM-a. Temeljni mehanizam provjere autentičnosti nije očit. AWS dokumenti ocrtavaju pristup, ali sažetak je:

  • kada se korisnik prijavi, Cognito će izdati tokene za privremene vjerodajnice (dobivene putem STS-a).
  • za zaštićene resurse, aplikacija mora potpisati zahtjeve koristeći ove vjerodajnice
  • AWS dekodira i provjerava potpis
  • ako je potpis valjan, API pristupnik upućuje zahtjev

Dostupne su i druge metode autorizacije. U dokumentima Claudia.js opisano je kako odrediti druge metode. (Odgovarajući AWS dokumenti su ovdje.)

Uloge AWS IAM-a za ovjerene korisnike

Moramo urediti privilegije za IAM uloge za ovjerene korisnike. Moramo dopustiti pozivanje metode API Gateway koju smo stvorili.

Treba nam ARN API pristupnika. Idite na konzolu API Gateway i pronađite resurs / metodu API Gatewaya.

  • Kopirajte ARN
  • Idite na IAM konzolu i pronađite Autentificiranu ulogu stvorenu tijekom postavljanja Cognito Federated Identity Pool
  • dodajte Inline pravila kao u nastavku
  • U pravilu navedite kopirani ARN za resurs API Gateway.

Ovlašteni korisnici sada se mogu pozivati ​​na naše zaštićene API metode.

Kontrola pristupa usluzi usluzi

Postavljanje Cognita omogućit će korisniku da pozove API metodu. No, ova metoda je okidač za Lambda funkciju. Lambda funkcija izvršava se u kontekstu različite IAM uloge. To više nije izravni zahtjev korisnika, već AWS usluga za uslugu interakcije. IAM uloge pružaju kontrolu pristupa za ovu interakciju.

Claudia.JS kreirala je IAM ulogu za Lambda funkciju. (Ovu ulogu također možete ručno stvoriti i putem --roleparametra odrediti njezin identifikator Claudia.JS . Pojedinosti su ovdje.)

Ako našoj Lambda funkciji treba pristup drugim AWS resursima, morat ćemo ažurirati Lambdinu ulogu IAM-a i pružiti ove privilegije. Na primjer, ovo bi mogla biti RDS baza podataka.

AWS je uvijek koristio IAM za konfiguriranje usluge za uslugu kontrole pristupa. To je dobro razvijen i dobro dokumentiran model. Vjerojatno će to biti vaš primarni mehanizam za kontrolu pristupa između mikro usluga (unutar AWS-a). Možda postoje slučajevi kada ga trebate povećati ili zamijeniti, ali ja bih započeo s IAM-om.

Sada možemo izraditi web aplikaciju za naše korisnike.

Reagirajte na web aplikaciji

Izradit ću React web stranicu s jednom stranicom (SPA). Aplikacija Vue.js ili Angular također bi radila. Za klijentsku aplikaciju postoje dvije važne komponente: AWS Amplify i aws4modul.

AWS Amplify omogućuje jednostavnu integraciju s AWS Cognito. aws4je popularna knjižnica za potpisivanje AWS zahtjeva pomoću AWS zahtjeva za potpisima verzija 4. AWS je koristio potpisane zahtjeve za zaštićene resurse (tj. ovlaštene korisničke zahtjeve).

Vraćajući se web-klijentu, koristit ćemo create-react-app. Neću iznositi korake jer su dobro dokumentirani na create-react-apppočetnoj stranici, a postoje i brojni mrežni vodiči. (Čak sam ih nekoliko napisao.)

Za provjeru autentičnosti moramo izvršiti neko upravljanje državom. Primjer aplikacije ne koristi nikakav okvir, ali u stvarnoj aplikaciji predložio bih Mobx (ili Redux.)

U demo aplikaciji auth-store.jsupravlja stanjem provjere autentičnosti korisnika. To se sastoji od korisničkog stanja provjere autentičnosti i vjerodajnica. Ovi su navikli

  • generiraju različite komponente i stilove za autentificiranog i gostujućeg korisnika
  • potpisati zahtjeve za zaštićene API metode

Iako AWS Amplify upravlja većim dijelom integracije AWS Cognito, još moramo obaviti neki posao.

Utvrđivanje stanja autorizacije iz AWS Amplify

Dokumentacija AWS Amplify-a dobra je u nekim područjima, a u drugima nedostaje. Predlažem da pročitate odjeljak Autentifikacija u dokumentaciji Amplify. Ovo opisuje Authkomponentu koja komunicira s Cognitom.

Međutim, još uvijek postoje neki aspekti kojima se dokumentacija jasno ne bavi. AWS Amplify ne olakšava prepoznavanje stanja provjere autentičnosti. (Rasprava o ovoj složenosti je ovdje.) Amplify se konfigurira asinkrono, bez povratnog poziva. Ali postoji aws-amplifyklasa koja vam može pomoći.

HubKlase u aws-amplifymodulu ponaša kao događaj odašiljač. Stalo nam je do dva događaja: configuredi cognitoHostedUI.

Nakon što AWS Amplify konfigurira Authkomponentu, ona emitira configureddogađaj. Naša se aplikacija tada može raspitati o trenutnom statusu provjere autentičnosti korisnika. To je korisno kada se naša aplikacija, primjerice, učitava.

Tijekom korištenja aplikacije moramo znati mijenja li se stanje provjere autentičnosti. Tu je sign-indogađaj, ali to nije događaj želimo, kao i naš demo program koristi OAuth i Cognito Hosted UI. sign-inDogađaj koristi se u posebnoj prijavu u / na zaslonu ili kada koristite ugrađeni pojačati reagirati UI. Za OAuth, Amplify otprema cognitoHostedUIdogađaj nakon završenog tijeka prijave na OAuth.

Potpisivanje zahtjeva

Trenutni korisnik imat će vjerodajnice koje je izdao AWS Cognito. Sadrže pristupni ID , tajni ključ i ključ sesije . Ti su dostupni pozivom Auth.currentCredentials()u aws-amplify. Za API metode koje je odobrio IAM, morate potpisati zahtjev pomoću potpisa AWS V4 zahtjeva. Srećom, aws4modul rješava složenost generiranja tih potpisa.

U api-client.js,

 import aws4 from "aws4"; const apiHost = process.env.REACT_APP_API_HOST; const apiKey = process.env.REACT_APP_API_KEY; const region = process.env.REACT_APP_REGION; export async function authenticatedCall(authStore) { const opts = { method: "GET", service: "execute-api", region: region, path: "/latest/require-auth", host: apiHost, headers: { "x-api-key": apiKey }, url: `//${apiHost}/latest/require-auth` }; const credentials = await authStore.getCredentials(); const { accessKeyId, secretAccessKey, sessionToken } = credentials; const request = aws4.sign(opts, { accessKeyId, secretAccessKey, sessionToken }); delete request.headers.Host; const response = await fetch(opts.url, { headers: request.headers }); if (response.ok) { return await response.json(); } else return { message: response.statusText }; } export async function noAuthCall(authStore) { const response = await fetch(`//${apiHost}/latest/no-auth`, { headers: { "x-api-key": apiKey } }); return await response.json(); } view rawapi-client.js hosted with ❤ by GitHub

Demo

Napokon možemo pokrenuti npm starti pokrenuti aplikaciju! Kad prvi put stignemo u aplikaciju, gost smo (neautorizirani korisnik). Također možete otići na //auth-api-demo.firebaseapp.com/ da biste ga isprobali.

Možemo pristupiti nezaštićenim metodama.

Ali ako pokušamo pristupiti zaštićenom resursu, on neće uspjeti.

Ali ako se prijavimo, možemo pristupiti zaštićenim resursima.

Kliknite Prijavi se i koristite demousers lozinkom za demoPASS123.

Sada možemo kliknuti Req. Authgumb za pristup zaštićenom API načinu.

Joj! Morali smo konfigurirati više usluga i probaviti puno informacija. Ali sada imamo aplikaciju koja je model za provjeru autentičnosti mikro usluga na AWS-u.

Što sad?

Pristup ovog članka je "all-in" na AWS-u. Ovo je bio namjerni izbor da se pokaže kako se različiti AWS dijelovi uklapaju u rješavanje zajedničke potrebe, naime aut. U ovom članku postoje alternative metodama, a ovdje ih navodim nekoliko.

A za one koji su ostali uz mene do kraja, imam neke poklone za rastanak.

  • U demo repo-u postoji skripta za automatizaciju postavljanja AWS-a. Njegov README sadrži detalje za njegovo pokretanje.
  • resources-cheatsheet.md ima posebne poveznice za relevantnu AWS, Claudia.js itd. dokumentaciju.

Hvala na čitanju!