'n Paar maande gelede het ek 'n OpenID Connect-bediener geïmplementeer om toegang vir honderde van ons interne toepassings te bestuur. Van ons eie ontwikkelings, gerieflik op 'n kleiner skaal, het ons na 'n algemeen aanvaarde standaard beweeg. Toegang deur die sentrale diens vergemaklik eentonige bedrywighede aansienlik, verminder die koste van die implementering van magtigings, stel jou in staat om baie klaargemaakte oplossings te vind en nie jou brein te raas wanneer jy nuwes ontwikkel nie. In hierdie artikel sal ek praat oor hierdie oorgang en die bulte wat ons daarin geslaag het om te vul.
Lank gelede... Hoe dit alles begin het
'n Paar jaar gelede, toe daar te veel interne toepassings vir handbeheer was, het ons 'n aansoek geskryf om toegang binne die maatskappy te beheer. Dit was 'n eenvoudige Rails-toepassing wat aan 'n databasis gekoppel is met inligting oor werknemers, waar toegang tot verskeie funksionaliteit opgestel is. Terselfdertyd het ons die eerste SSO opgewek, wat gebaseer was op die verifikasie van tokens vanaf die kant van die kliënt en die magtigingsbediener, die token is in geënkripteerde vorm met verskeie parameters oorgedra en op die magtigingsbediener geverifieer. Dit was nie die gerieflikste opsie nie, aangesien elke interne toepassing 'n aansienlike laag logika moes beskryf, en die werknemerdatabasisse was heeltemal gesinchroniseer met die magtigingsbediener.
Na 'n ruk het ons besluit om die taak van gesentraliseerde magtiging te vereenvoudig. SSO is na die balanseerder oorgeplaas. Met die hulp van OpenResty is 'n sjabloon by Lua gevoeg wat tokens nagegaan het, geweet het na watter toepassing die versoek gaan, en kon kyk of daar toegang daar is. Hierdie benadering het die taak om toegang tot interne toepassings te beheer aansienlik vereenvoudig - in die kode van elke toepassing was dit nie meer nodig om bykomende logika te beskryf nie. As gevolg hiervan het ons die verkeer ekstern gesluit, en die toepassing self het niks van magtiging geweet nie.
Een probleem het egter onopgelos gebly. Wat van toepassings wat inligting oor werknemers benodig? Dit was moontlik om 'n API vir die magtigingsdiens te skryf, maar dan sou jy bykomende logika vir elke sodanige toepassing moes byvoeg. Boonop wou ons ontslae raak van die afhanklikheid van een van ons selfgeskrewe toepassings, wat later in OpenSource vertaal sou word, op ons interne magtigingsbediener. Ons sal 'n ander keer daaroor praat. OAuth het die oplossing vir beide probleme geword.
aan gemeenskaplike standaarde
OAuth is 'n verstaanbare, algemeen aanvaarde magtigingstandaard, maar aangesien slegs die funksionaliteit daarvan nie genoeg is nie, het hulle dadelik begin om OpenID Connect (OIDC) te oorweeg. OIDC self is die derde implementering van die oop verifikasiestandaard, wat in 'n byvoeging oor die OAuth 2.0-protokol ('n oop magtigingsprotokol) gevloei het. Hierdie oplossing sluit die probleem van die gebrek aan data oor die eindgebruiker toe, en maak dit ook moontlik om die magtigingsverskaffer te verander.
Ons het egter nie 'n spesifieke verskaffer gekies nie en het besluit om integrasie met OIDC vir ons bestaande magtigingsbediener by te voeg. Ten gunste van hierdie besluit was die feit dat OIDC baie buigsaam is in terme van eindgebruikersmagtiging. Dit was dus moontlik om OIDC-ondersteuning op u huidige magtigingsbediener te implementeer.
Ons manier om ons eie OIDC-bediener te implementeer
1) Het die data na die verlangde vorm gebring
Om OIDC te integreer, is dit nodig om die huidige gebruikerdata in 'n vorm te bring wat verstaanbaar is deur die standaard. In OIDC word dit Eise genoem. Eise is in wese finale velde in die gebruikersdatabasis (naam, e-pos, telefoon, ens.). Bestaan , en alles wat nie in hierdie lys ingesluit is nie, word as pasgemaak beskou. Daarom is die eerste punt waaraan u aandag moet skenk as u 'n bestaande OIDC-verskaffer wil kies, die moontlikheid van gerieflike aanpassing van nuwe handelsmerke.
Die groep kenmerke word in die volgende subset gekombineer - Omvang. Tydens magtiging word toegang nie tot spesifieke handelsmerke versoek nie, maar tot bestekke, selfs al is sommige van die handelsmerke uit die omvang nie nodig nie.
2) Die nodige toelaes geïmplementeer
Die volgende deel van OIDC-integrasie is die keuse en implementering van magtigingstipes, die sogenaamde toekennings. Die verdere scenario van interaksie tussen die geselekteerde toepassing en die magtigingsbediener sal afhang van die geselekteerde toekenning. 'n Voorbeeldskema vir die keuse van die regte toekenning word in die figuur hieronder getoon.
Vir ons eerste aansoek het ons die mees algemene toekenning, die Magtigingskode, gebruik. Die verskil daarvan met ander is dat dit 'n driestap is, d.w.s. ondergaan addisionele toetsing. Eerstens, die gebruiker rig 'n versoek vir magtiging toestemming, ontvang 'n teken - Magtiging Kode, dan met hierdie teken, asof met 'n kaartjie vir reis, versoek 'n toegangsteken. Al die hoofinteraksie van hierdie magtigingskrip is gebaseer op herleidings tussen die toepassing en die magtigingbediener. Jy kan meer lees oor hierdie toekenning .
OAuth hou by die konsep dat toegangstekens wat na magtiging verkry word, tydelik moet wees en moet verander, verkieslik elke 10 minute gemiddeld. Die magtigingskode-toekenning is 'n driestap-verifikasie deur middel van herleidings, elke 10 minute om so 'n stap te verander, eerlikwaar, is nie die aangenaamste taak vir die oë nie. Om hierdie probleem op te los, is daar nog 'n toekenning - Refresh Token, wat ons ook in ons land gebruik het. Alles is makliker hier. Tydens verifikasie vanaf 'n ander toekenning, bykomend tot die hooftoegangstoken, word 'n ander een uitgereik - Refresh Token, wat slegs een keer gebruik kan word en sy leeftyd is gewoonlik baie langer. Met hierdie Refresh Token, wanneer die TTL (Time to Live) van die hooftoegangstoken eindig, sal die versoek vir 'n nuwe toegangtoken by die eindpunt van 'n ander toekenning kom. Die gebruikte Refresh Token word onmiddellik na nul teruggestel. Hierdie kontrole is twee-stap en kan in die agtergrond uitgevoer word, onmerkbaar vir die gebruiker.
3) Stel pasgemaakte data-uitvoerformate op
Nadat die geselekteerde toekennings geïmplementeer is, werk magtiging, dit is die moeite werd om te noem om data oor die eindgebruiker te kry. OIDC het 'n aparte eindpunt hiervoor, waar jy gebruikersdata kan aanvra met jou huidige toegangtoken en of dit op datum is. En as die gebruiker se data nie so gereeld verander nie, en jy moet die huidige baie keer volg, kan jy by so 'n oplossing soos JWT-tokens kom. Hierdie tokens word ook deur die standaard ondersteun. Die JWT-token self bestaan uit drie dele: kopskrif (inligting oor die teken), loonvrag (enige nodige data) en handtekening (handtekening, die teken word deur die bediener onderteken en jy kan later die bron van sy handtekening nagaan).
In die OIDC-implementering word die JWT-token id_token genoem. Dit kan aangevra word saam met 'n normale toegangsteken en al wat oorbly is om die handtekening te verifieer. Die magtigingsbediener het 'n aparte eindpunt hiervoor met 'n klomp publieke sleutels in die formaat . En om hiervan te praat, is dit die moeite werd om te noem dat daar 'n ander eindpunt is, wat gebaseer is op die standaard weerspieël die huidige konfigurasie van die OIDC-bediener. Dit bevat alle eindpuntadresse (insluitend die adres van die publieke sleutelring wat vir ondertekening gebruik word), ondersteunde handelsmerke en omvang, gebruikte enkripsiealgoritmes, ondersteunde toekennings, ens.
Byvoorbeeld op Google:
{
"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"
]
}Met id_token kan u dus al die nodige kenmerke na die loonvrag van die teken oordra en nie elke keer die magtigingsbediener kontak om gebruikersdata aan te vra nie. Die nadeel van hierdie benadering is dat die verandering in gebruikersdata vanaf die bediener nie onmiddellik kom nie, maar saam met 'n nuwe toegangsteken.
Implementering resultate
Dus, nadat ons ons eie OIDC-bediener geïmplementeer het en verbindings daarmee aan die toepassingskant gekonfigureer het, het ons die probleem opgelos om inligting oor gebruikers oor te dra.
Aangesien OIDC 'n oop standaard is, het ons die opsie om 'n bestaande verskaffer of bedienerimplementering te kies. Ons het Keycloak probeer, wat blykbaar baie gerieflik was om te konfigureer, nadat die verbindingskonfigurasies aan die toepassingskant opgestel en verander het, is dit gereed om te gaan. Aan die toepassingskant is al wat oorbly om die verbindingkonfigurasies te verander.
Praat oor bestaande oplossings
Binne ons organisasie, as die eerste OIDC-bediener, het ons ons eie implementering saamgestel, wat aangevul is soos nodig. Na 'n gedetailleerde oorsig van ander klaargemaakte oplossings, kan ons sê dat dit 'n betwiste punt is. Ten gunste van die besluit om hul eie bediener te implementeer, was daar kommer aan die kant van verskaffers in die afwesigheid van die nodige funksionaliteit, sowel as die teenwoordigheid van 'n ou stelsel waarin daar verskillende pasgemaakte magtigings vir sommige dienste was en nogal baie van data oor werknemers is reeds gestoor. In gereedgemaakte implementerings is daar egter geriewe vir integrasie. Keycloak het byvoorbeeld sy eie gebruikersbestuurstelsel en data word direk daarin gestoor, en dit sal nie moeilik wees om jou gebruikers daar verby te steek nie. Om dit te doen, het Keycloak 'n API wat jou sal toelaat om al die nodige oordragaksies volledig uit te voer.
Nog 'n voorbeeld van 'n gesertifiseerde, interessante, na my mening, implementering is Ory Hydra. Dit is interessant omdat dit uit verskillende komponente bestaan. Om te integreer, sal jy jou gebruikerbestuurdiens aan hul magtigingsdiens moet koppel en uitbrei soos nodig.
Keycloak en Ory Hydra is nie die enigste van die rak oplossings nie. Dit is die beste om 'n implementering te kies wat deur die OpenID-stigting gesertifiseer is. Hierdie oplossings het gewoonlik 'n OpenID-sertifiseringskenteken.
Moet ook nie van bestaande betaalde verskaffers vergeet as jy nie jou OIDC-bediener wil behou nie. Vandag is daar baie goeie opsies.
Wat is volgende?
In die nabye toekoms gaan ons verkeer na interne dienste op 'n ander manier toemaak. Ons beplan om ons huidige SSO op die balanseerder met OpenResty oor te dra na 'n instaanbediener gebaseer op OAuth. Daar is reeds baie klaargemaakte oplossings hier, byvoorbeeld:
Bykomende materiaal
- goeie diens vir die validering van JWT-tokens
- lys van gesertifiseerde OIDC implementerings
Bron: will.com