Muutama kuukausi sitten otin käyttöön OpenID Connect -palvelimen hallitakseni satojen sisäisten sovelluksiemme pääsyä. Omasta kehityksestämme, pienemmässä mittakaavassa kätevästi, olemme siirtyneet yleisesti hyväksyttyyn standardiin. Pääsy keskuspalvelun kautta yksinkertaistaa huomattavasti yksitoikkoista toimintaa, alentaa valtuuksien toteutuskustannuksia, mahdollistaa monien valmiiden ratkaisujen löytämisen, eikä aivojasi raahaa uusia kehitettäessä. Tässä artikkelissa puhun tästä siirrosta ja töyssyistä, jotka onnistuimme täyttämään.
Kauan sitten... Kuinka kaikki alkoi
Muutama vuosi sitten, kun sisäisiä sovelluksia oli liikaa manuaaliseen ohjaukseen, kirjoitimme sovelluksen pääsyn hallintaan yrityksen sisällä. Se oli yksinkertainen Rails-sovellus, joka liittyi tietokantaan, jossa oli tietoja työntekijöistä ja jossa konfiguroitiin pääsy erilaisiin toimintoihin. Samalla otimme esille ensimmäisen SSO:n, joka perustui tokenien varmentamiseen asiakkaan ja valtuutuspalvelimen puolelta, token välitettiin salatussa muodossa useilla parametreilla ja varmennettiin valtuutuspalvelimella. Tämä ei ollut kätevin vaihtoehto, koska jokaisen sisäisen sovelluksen piti kuvata huomattava logiikkakerros ja työntekijätietokannat olivat täysin synkronoituja valtuutuspalvelimen kanssa.
Jonkin ajan kuluttua päätimme yksinkertaistaa keskitetyn valtuutuksen tehtävää. SSO siirrettiin tasapainottajalle. OpenRestyn avulla Luaan lisättiin malli, joka tarkisti tunnukset, tiesi mihin sovellukseen pyyntö oli menossa ja pystyi tarkistamaan, onko siellä pääsy. Tämä lähestymistapa yksinkertaisti huomattavasti sisäisten sovellusten pääsyn hallintaa - jokaisen sovelluksen koodissa ei enää tarvinnut kuvata lisälogiikkaa. Tämän seurauksena sulkimme liikenteen ulkoisesti, eikä sovellus itse tiennyt valtuutuksesta mitään.
Yksi ongelma jäi kuitenkin ratkaisematta. Entä sovellukset, jotka tarvitsevat tietoja työntekijöistä? Valtuutuspalvelulle oli mahdollista kirjoittaa API, mutta silloin joudut lisäämään lisälogiikkaa jokaiselle tällaiselle sovellukselle. Lisäksi halusimme päästä eroon riippuvuudesta yhdestä itse kirjoitetusta sovelluksestamme, joka on suunnattu tulevaisuudessa käännettäväksi avoimeen lähdekoodiin, sisäisellä valtuutuspalvelimellamme. Puhumme siitä joku toinen kerta. Ratkaisu molempiin ongelmiin oli OAuth.
yhteisiin standardeihin
OAuth on ymmärrettävä, yleisesti hyväksytty valtuutusstandardi, mutta koska pelkkä sen toiminnallisuus ei riitä, alettiin heti pohtia OpenID Connectia (OIDC). OIDC itsessään on avoimen todennusstandardin kolmas toteutus, joka on virrannut lisäosaan OAuth 2.0 -protokollan (avoin valtuutusprotokolla) kautta. Tämä ratkaisu sulkee loppukäyttäjää koskevien tietojen puutteen ongelman ja mahdollistaa myös valtuutuksen toimittajan vaihtamisen.
Emme kuitenkaan valinneet tiettyä palveluntarjoajaa ja päätimme lisätä integroinnin OIDC:n kanssa olemassa olevaan valtuutuspalvelimeemme. Päätöstä kannatti se, että OIDC on erittäin joustava loppukäyttäjien valtuuksien suhteen. Siten oli mahdollista ottaa käyttöön OIDC-tuki nykyiselle valtuutuspalvelimellesi.
Meidän tapamme toteuttaa oma OIDC-palvelin
1) Toi tiedot haluttuun muotoon
OIDC:n integroimiseksi on tarpeen saattaa nykyiset käyttäjätiedot standardin ymmärtämään muotoon. OIDC:ssä tätä kutsutaan väitteiksi. Vaatimukset ovat pohjimmiltaan viimeisiä kenttiä käyttäjätietokannassa (nimi, sähköpostiosoite, puhelinnumero jne.). Olemassa , ja kaikki, mikä ei sisälly tähän luetteloon, katsotaan mukautetuksi. Siksi ensimmäinen asia, johon sinun on kiinnitettävä huomiota, jos haluat valita olemassa olevan OIDC-palveluntarjoajan, on mahdollisuus mukauttaa uusia merkkejä kätevästi.
Tunnusmerkkien ryhmä on yhdistetty seuraavaan osajoukkoon - Soveltamisala. Valtuutuksen aikana ei pyydetä pääsyä tiettyihin brändeihin, vaan laajuuksiin, vaikka joitain piirin merkkejä ei tarvittaisikaan.
2) Toteutti tarvittavat apurahat
Seuraava osa OIDC-integraatiota on valtuutustyyppien, ns. apurahojen, valinta ja toteutus. Valitun sovelluksen ja valtuutuspalvelimen välinen vuorovaikutuksen jatkoskenaario riippuu valitusta luvasta. Esimerkki oikean apurahan valinnasta on alla olevassa kuvassa.
Ensimmäisessä hakemuksessamme käytimme yleisintä apurahaa, valtuutuskoodia. Sen ero muihin on, että se on kolmivaiheinen, ts. on lisätestauksessa. Ensin käyttäjä pyytää valtuutuslupaa, vastaanottaa tunnuksen - Valtuutuskoodi, sitten tällä tunnuksella, ikään kuin matkalipun kanssa, pyytää pääsytunnusta. Kaikki tämän valtuutuskomentosarjan tärkeimmät vuorovaikutukset perustuvat uudelleenohjauksiin sovelluksen ja valtuutuspalvelimen välillä. Voit lukea lisää tästä apurahasta .
OAuth noudattaa periaatetta, että valtuutuksen jälkeen hankittujen käyttöoikeustunnusten tulee olla väliaikaisia ja vaihtua mielellään keskimäärin 10 minuutin välein. Valtuutuskoodi-apuraha on kolmivaiheinen vahvistus uudelleenohjauksilla, 10 minuutin välein tällaisen askeleen kääntäminen ei suoraan sanottuna ole miellyttävin tehtävä silmille. Tämän ongelman ratkaisemiseksi on olemassa toinen apuraha - Refresh Token, jota käytimme myös maassamme. Täällä kaikki on helpompaa. Varmennettaessa toisesta luvasta pääkäyttötunnuksen lisäksi myönnetään toinen - Refresh Token, jota voi käyttää vain kerran ja sen käyttöikä on yleensä paljon pidempi. Tämän päivitystunnuksen avulla, kun pääkäyttötunnuksen TTL (Time to Live) päättyy, uuden käyttöoikeustunnuksen pyyntö tulee toisen luvan päätepisteeseen. Käytetty Refresh Token nollataan välittömästi. Tämä tarkistus on kaksivaiheinen ja voidaan suorittaa taustalla, käyttäjälle huomaamattomasti.
3) Määritä mukautetut tiedonantomuodot
Kun valitut apurahat on toteutettu, valtuutus toimii, kannattaa mainita tiedon hankkiminen loppukäyttäjästä. OIDC:llä on tätä varten erillinen päätepiste, josta voit pyytää käyttäjätietoja nykyisellä käyttötunnuksellasi ja jos ne ovat ajan tasalla. Ja jos käyttäjän tiedot eivät muutu niin usein ja joudut seuraamaan nykyisiä useita kertoja, voit tulla sellaiseen ratkaisuun kuin JWT-tokenit. Standardi tukee myös näitä tokeneita. Itse JWT-tunnus koostuu kolmesta osasta: otsikko (tiedot tunnuksesta), hyötykuorma (kaikki tarvittavat tiedot) ja allekirjoitus (allekirjoitus, palvelin allekirjoittaa tunnuksen ja voit myöhemmin tarkistaa sen allekirjoituksen lähteen).
OIDC-toteutuksessa JWT-tunnusta kutsutaan nimellä id_token. Sitä voidaan pyytää normaalin käyttöoikeustunnuksen kanssa, ja jäljellä on vain vahvistaa allekirjoitus. Valtuutuspalvelimella on tätä varten erillinen päätepiste, jossa on joukko julkisia avaimia muodossa . Ja tästä puhuttaessa on syytä mainita, että on olemassa toinen päätepiste, joka perustuu standardiin kuvastaa OIDC-palvelimen nykyistä kokoonpanoa. Se sisältää kaikki päätepisteiden osoitteet (mukaan lukien allekirjoittamiseen käytetyn julkisen avainrenkaan osoitteen), tuetut tuotemerkit ja laajuudet, käytetyt salausalgoritmit, tuetut avustukset jne.
Esimerkiksi Googlessa:
{
"issuer": "https://accounts.google.com",
"authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
"device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
"revocation_endpoint": "https://oauth2.googleapis.com/revoke",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
"response_types_supported": [
"code",
"token",
"id_token",
"code token",
"code id_token",
"token id_token",
"code token id_token",
"none"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"scopes_supported": [
"openid",
"email",
"profile"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"client_secret_basic"
],
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"family_name",
"given_name",
"iat",
"iss",
"locale",
"name",
"picture",
"sub"
],
"code_challenge_methods_supported": [
"plain",
"S256"
],
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}Siten käyttämällä id_tokenia voit siirtää kaikki tarvittavat tunnusmerkit tunnuksen hyötykuormaan etkä ota yhteyttä valtuutuspalvelimeen joka kerta pyytääksesi käyttäjätietoja. Tämän lähestymistavan haittana on, että palvelimen käyttäjätietojen muutos ei tule heti, vaan uuden käyttöoikeustunnuksen mukana.
Toteutuksen tulokset
Joten kun otettiin käyttöön oma OIDC-palvelin ja määritettiin yhteydet siihen sovelluspuolella, ratkaisimme käyttäjiä koskevien tietojen siirron ongelman.
Koska OIDC on avoin standardi, meillä on mahdollisuus valita olemassa oleva toimittaja tai palvelintoteutus. Kokeilimme Keycloakia, joka osoittautui erittäin käteväksi konfiguroida, kun sovelluspuolen yhteyskonfiguraatiot on tehty ja muutettu, se on valmis käyttöön. Sovelluspuolella ei jää muuta kuin muuttaa yhteysasetuksia.
Puhutaan olemassa olevista ratkaisuista
Organisaatiossamme ensimmäisenä OIDC-palvelimena kokosimme oman toteutuksen, jota täydennettiin tarpeen mukaan. Muiden valmiiden ratkaisujen yksityiskohtaisen tarkastelun jälkeen voimme sanoa, että tämä on kiistanalainen asia. Oman palvelimen käyttöönottopäätöksen puolesta palveluntarjoajat olivat huolissaan tarvittavien toimintojen puuttumisesta sekä vanhan järjestelmän olemassaolosta, jossa oli erilaisia mukautettuja valtuutuksia joillekin palveluille ja melko paljon. tietoja työntekijöistä oli jo tallennettu. Valmiissa toteutuksissa on kuitenkin integroinnin mukavuutta. Esimerkiksi Keycloakilla on oma käyttäjähallintajärjestelmä, johon tiedot tallennetaan suoraan, eikä käyttäjien ohittaminen siellä ole vaikeaa. Tätä varten Keycloakilla on API, jonka avulla voit suorittaa kaikki tarvittavat siirtotoiminnot.
Toinen esimerkki sertifioidusta, mielenkiintoisesta toteutuksesta on mielestäni Ory Hydra. Se on mielenkiintoinen, koska se koostuu eri komponenteista. Integrointia varten sinun on linkitettävä käyttäjähallintapalvelusi heidän valtuutuspalveluun ja laajennettava sitä tarvittaessa.
Keycloak ja Ory Hydra eivät ole ainoita valmiita ratkaisuja. On parasta valita OpenID Foundationin sertifioima toteutus. Näillä ratkaisuilla on yleensä OpenID-sertifiointimerkki.
Älä myöskään unohda olemassa olevia maksullisia palveluntarjoajia, jos et halua pitää OIDC-palvelintasi. Nykyään on monia hyviä vaihtoehtoja.
Mitä seuraavaksi
Lähitulevaisuudessa aiomme sulkea liikenteen sisäisiltä palveluilta toisella tavalla. Aiomme siirtää nykyisen kertakirjautumisen tasapainottimessa OpenRestyllä OAuth-pohjaiseen välityspalvelimeen. Täällä on jo monia valmiita ratkaisuja, esim.
Lisäaineita
– hyvä palvelu JWT-tunnusten validoimiseen
- luettelo sertifioiduista OIDC-toteutuksista
Lähde: will.com