Missä tahansa suuressa yrityksessä, eikä X5 Retail Group ole poikkeus, sen kehittyessä käyttäjälupaa vaativien projektien määrä kasvaa. Ajan myötä käyttäjien saumaton siirtyminen sovelluksesta toiseen on tarpeen, minkä jälkeen on käytettävä yhtä SSO-palvelinta (Single-Sing-On). Mutta entä jos identiteetin tarjoajia, kuten AD tai muita, joilla ei ole lisämääritteitä, käytetään jo useissa projekteissa. Järjestelmäluokka, jota kutsutaan "tunnistusvälittäjiksi", tulee apuun. Toimivimmat ovat sen edustajat, kuten Keycloak, Gravitee Accessin hallinta jne. Useimmiten käyttötapaukset voivat olla erilaisia: konevuorovaikutus, käyttäjien osallistuminen jne. Ratkaisun tulee tukea joustavaa ja skaalautuvaa toiminnallisuutta, joka voi yhdistää kaikki vaatimukset yhteen, ja tällaisia ratkaisuja yrityksellämme on nyt indikaatiovälittäjä - Keycloak.
Keycloak on RedHatin ylläpitämä avoimen lähdekoodin identiteetti- ja kulunvalvontatuote. Se on pohjana yrityksen tuotteille SSO - RH-SSO:lla.
Peruskäsitteet
Ennen kuin alat käsitellä ratkaisuja ja lähestymistapoja, sinun tulee päättää prosessien ehdoista ja järjestyksestä:
tunnistaminen on menettely kohteen tunnistamiseksi hänen tunnisteestaan (toisin sanoen tämä on nimen, kirjautumistunnuksen tai numeron määritelmä).
todennus - tämä on todennusmenettely (käyttäjä tarkistetaan salasanalla, kirje tarkistetaan sähköisellä allekirjoituksella jne.)
Lupa - tämä on pääsyn tarjoaminen resurssiin (esimerkiksi sähköpostiin).
Identity Broker -avaimenperä
Avaimenperä on avoimen lähdekoodin identiteetin ja pääsynhallintaratkaisu, joka on suunniteltu käytettäväksi IS:ssä, jossa voidaan käyttää mikropalveluarkkitehtuurimalleja.
Keycloak tarjoaa ominaisuuksia, kuten kertakirjautumisen (SSO), välitetyn identiteetin ja sosiaalisen kirjautumisen, käyttäjien liittämisen, asiakassovittimet, hallintakonsolin ja tilinhallintakonsolin.
Keycloakin tukemat perustoiminnot:
- Kertakirjautuminen ja kertakirjautuminen selainsovelluksille.
- OpenID/OAuth 2.0/SAML-tuki.
- Identity Brokering - todennus ulkoisten OpenID Connect- tai SAML-identiteetin tarjoajien avulla.
- Social Login - Google, GitHub, Facebook, Twitter tuki käyttäjän tunnistamiseen.
- Käyttäjien yhdistäminen - käyttäjien synkronointi LDAP- ja Active Directory -palvelimista ja muista identiteetin tarjoajista.
- Kerberos-silta - Kerberos-palvelimen käyttäminen automaattiseen käyttäjän todentamiseen.
- Hallintakonsoli – asetusten ja ratkaisuvaihtoehtojen yhtenäiseen hallintaan verkon kautta.
- Tilinhallintakonsoli - käyttäjäprofiilin itsehallintaan.
- Ratkaisun räätälöinti yrityksen yritysidentiteettiin perustuen.
- 2FA-todennus – TOTP/HOTP-tuki Google Authenticatorin tai FreeOTP:n avulla.
- Kirjautumisreitit - käyttäjän itserekisteröityminen, salasanan palautus ja palautus ja muut ovat mahdollisia.
- Istuntojen hallinta – järjestelmänvalvojat voivat hallita käyttäjien istuntoja yhdestä pisteestä.
- Token Mappers - sitovat käyttäjäattribuutit, roolit ja muut vaaditut attribuutit tunnuksiin.
- Joustava käytäntöjen hallinta toimialueella, sovelluksissa ja käyttäjissä.
- CORS-tuki – Asiakassovittimissa on sisäänrakennettu CORS-tuki.
- Palveluntarjoajan rajapinnat (SPI) – Suuri määrä SPI:itä, joiden avulla voit mukauttaa palvelimen eri puolia: todennusvirtoja, identiteetin tarjoajia, protokollakartoitusta ja paljon muuta.
- Asiakassovittimet JavaScript-sovelluksiin, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Tuki työskentelyyn eri sovellusten kanssa, jotka tukevat OpenID Connect Relying Party -kirjastoa tai SAML 2.0 Service Provider -kirjastoa.
- Laajennettavissa lisäosien avulla.
CI / CD-prosesseissa sekä Keycloakin hallintaprosessien automatisoinnissa voidaan käyttää REST API / JAVA API:ta. Dokumentaatio on saatavilla sähköisesti:
REST API
Java API
Yritystunnuksen tarjoajat (paikan päällä)
Mahdollisuus todentaa käyttäjiä käyttäjien yhdistämispalvelujen kautta.
Pass-through-todennusta voidaan myös käyttää - jos käyttäjät todentavat Kerberos-työasemilla (LDAP tai AD), heidät voidaan todentaa automaattisesti Keycloakille ilman, että heidän tarvitsee syöttää käyttäjätunnusta ja salasanaa uudelleen.
Käyttäjien todentamiseen ja edelleen valtuutukseen on mahdollista käyttää relaatiotietokantajärjestelmää, joka soveltuu parhaiten kehitysympäristöihin, koska se ei vaadi pitkiä asetuksia ja integrointeja projektin alkuvaiheessa. Oletuksena Keycloak käyttää sisäänrakennettua DBMS:ää asetusten ja käyttäjätietojen tallentamiseen.
Tuettujen DBMS-järjestelmien luettelo on laaja ja sisältää: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle ja muut. Tähän mennessä testatuimmat ovat Oracle 12C Release1 RAC ja Galera 3.12 -klusteri MariaDB 10.1.19:lle.
Identiteettitarjoajat - sosiaalinen kirjautuminen
On mahdollista käyttää kirjautumista sosiaalisista verkostoista. Aktivoi käyttäjien todennusmahdollisuus Keycloackin hallintakonsolin avulla. Sovelluskoodin muutoksia ei vaadita, ja tämä toiminto on saatavilla heti, ja se voidaan aktivoida missä tahansa projektin vaiheessa.
On mahdollista käyttää OpenID/SAML Identity -palveluntarjoajia käyttäjien todentamiseen.
Tyypillisiä valtuutusskenaarioita, joissa käytetään OAuth2:ta Keycloakissa
Valtuutuskoodin kulku - käytetään palvelinpuolen sovellusten kanssa. Yksi yleisimmistä käyttöoikeustyypeistä, koska se sopii hyvin palvelinsovelluksiin, joissa sovelluksen lähdekoodi ja asiakastiedot eivät ole ulkopuolisten saatavilla. Tässä tapauksessa prosessi perustuu uudelleenohjaukseen. Sovelluksen on kyettävä kommunikoimaan käyttäjäagentin (user-agent), kuten verkkoselaimen, kanssa, jotta se vastaanottaa käyttäjäagentin kautta uudelleenohjattuja API-valtuutuskoodeja.
implisiittinen virtaus - mobiili- tai verkkosovellusten käyttämä (käyttäjän laitteessa toimivat sovellukset).
Implisiittistä valtuutuslupatyyppiä käyttävät mobiili- ja verkkosovellukset, joissa asiakkaan luottamuksellisuutta ei voida taata. Implisiittinen lupatyyppi käyttää myös käyttäjäagentin uudelleenohjausta, jolloin käyttöoikeustunnus välitetään käyttäjäagentille myöhempää käyttöä varten sovelluksessa. Tämä asettaa tunnuksen käyttäjän ja muiden sovellusten saataville käyttäjän laitteessa. Tämä valtuutuslupatyyppi ei todenna sovelluksen aitoutta, ja prosessi itse perustuu uudelleenohjaus-URL-osoitteeseen (joka on aiemmin rekisteröity palveluun).
Implicit Flow ei tue pääsytunnuksen päivitystunnuksia.
Asiakkaan valtuustietojen myöntämisvirta — käytetään, kun sovellus käyttää API:ta. Tämän tyyppisiä valtuutusoikeuksia käytetään yleensä palvelinten välisiin vuorovaikutuksiin, jotka on suoritettava taustalla ilman välitöntä käyttäjän toimia. Asiakkaan valtuustietojen myöntämisvirta sallii verkkopalvelun (luottamuksellinen asiakas) käyttää omia valtuustietojaan sen sijaan, että se esiintyy käyttäjänä todennuksen yhteydessä, kun se soittaa toiseen verkkopalveluun. Korkeamman turvallisuustason saavuttamiseksi soittava palvelu voi käyttää varmennetta (jaetun salaisuuden sijaan) valtuustietona.
OAuth2-määritys on kuvattu kohdassa
JWT-tunnus ja sen edut
JWT (JSON Web Token) on avoin standardi (), joka määrittelee kompaktin ja itsenäisen tavan siirtää tietoja turvallisesti osapuolten välillä JSON-objektina.
Standardin mukaan token koostuu kolmesta base-64-muodossa olevasta osasta, jotka on erotettu pisteillä. Ensimmäistä osaa kutsutaan otsikoksi, joka sisältää tunnuksen tyypin ja hajautusalgoritmin nimen digitaalisen allekirjoituksen saamiseksi. Toinen osa tallentaa perustiedot (käyttäjä, attribuutit jne.). Kolmas osa on digitaalinen allekirjoitus.
. .
Älä koskaan tallenna tokenia tietokantaan. Koska kelvollinen tunnus vastaa salasanaa, tunnuksen tallentaminen on kuin salasanan tallentamista selkeänä tekstinä.
Käyttöoikeustunnus on tunnus, joka antaa omistajalleen pääsyn suojattuihin palvelinresursseihin. Sillä on yleensä lyhyt käyttöikä ja se voi sisältää lisätietoja, kuten tunnuksen pyytävän osapuolen IP-osoitteen.
Päivitä tunnus on tunnus, jonka avulla asiakkaat voivat pyytää uusia käyttöoikeuksia käyttöikänsä umpeuduttua. Nämä rahakkeet myönnetään yleensä pitkäksi ajaksi.
Mikropalveluarkkitehtuurissa käytön tärkeimmät edut:
- Mahdollisuus käyttää erilaisia sovelluksia ja palveluita kertatodennuksen avulla.
- Koska käyttäjäprofiilissa ei ole useita vaadittuja attribuutteja, on mahdollista rikastaa dataa, joka voidaan lisätä hyötykuormaan, mukaan lukien automaattinen ja lennossa.
- Tietoa aktiivisista istunnoista ei tarvitse tallentaa, palvelinsovelluksen tarvitsee vain vahvistaa allekirjoitus.
- Joustavampi kulunhallinta hyötykuorman lisämääritteillä.
- Token-allekirjoituksen käyttö otsikossa ja hyötykuormassa lisää koko ratkaisun turvallisuutta.
JWT-merkki - koostumus
Otsikko - Oletusarvoisesti otsikko sisältää vain tunnuksen tyypin ja salaukseen käytetyn algoritmin.
Tunnusmerkin tyyppi tallennetaan "typ"-avaimeen. 'type'-avain ohitetaan JWT:ssä. Jos "typ"-avain on olemassa, sen arvon on oltava JWT osoittamaan, että tämä objekti on JSON Web Token.
Toinen avain "alg" määrittelee algoritmin, jota käytetään tunnuksen salaamiseen. Sen pitäisi olla oletuksena HS256. Otsikko on koodattu base64:llä.
{ "alg": "HS256", "type": "JWT"}
hyötykuorma (sisältö) - hyötykuorma tallentaa kaikki tiedot, jotka on tarkistettava. Jokainen hyötykuorman avain tunnetaan nimellä "vaatimus". Voit esimerkiksi kirjoittaa hakemukseen vain kutsulla (suljettu promo). Kun haluamme kutsua jonkun osallistumaan, lähetämme hänelle kutsukirjeen. On tärkeää tarkistaa, että sähköpostiosoite kuuluu kutsun vastaanottajalle, joten sisällytämme tämän osoitteen hyötykuormaan, tätä varten tallennamme sen "email"-avaimeen
{ "sähköposti": "[sähköposti suojattu]"}
Hyötykuorman avaimet voivat olla mielivaltaisia. On kuitenkin muutama varattu:
- iss (myöntäjä) - Tunnistaa sovelluksen, josta tunnus lähetetään.
- sub (Aihe) - määrittää tunnuksen aiheen.
- aud (Yleisö) on joukko kirjainkoolla eroteltuja merkkijonoja tai URI:ita, joka on luettelo tämän tunnuksen vastaanottajista. Kun vastaanottava puoli vastaanottaa JWT:n annetulla avaimella, sen on tarkistettava itsensä läsnäolo vastaanottajissa - muuten huomioimatta tokenin.
- exp (Vanhentumisaika) - Ilmaisee, milloin token vanhenee. JWT-standardi edellyttää, että kaikki sen toteutukset hylkäävät vanhentuneet tunnukset. Exp-avaimen on oltava unix-muodossa oleva aikaleima.
- nbf (ei ennen) on unix-muodossa oleva aika, joka määrittää hetken, jolloin merkki tulee voimaan.
- iat (Issued At) – Tämä avain edustaa tunnuksen myöntämisaikaa, ja sitä voidaan käyttää JWT:n iän määrittämiseen. Iat-avaimen on oltava unix-muodossa oleva aikaleima.
- Jti (JWT ID) — merkkijono, joka määrittää tämän tunnuksen yksilöllisen tunnisteen, isot ja pienet kirjaimet.
On tärkeää ymmärtää, että hyötykuormaa ei lähetetä salatussa muodossa (vaikka tokeneita voidaan sisäkkäin ja silloin on mahdollista lähettää salattua dataa). Siksi se ei voi tallentaa salaisia tietoja. Kuten otsikko, hyötykuorma on base64-koodattu.
Allekirjoitus - Kun meillä on otsikko ja hyötykuorma, voimme laskea allekirjoituksen.
Base64-koodattu: otsikko ja hyötykuorma otetaan, ne yhdistetään merkkijonoksi pisteen kautta. Sitten tämä merkkijono ja salainen avain syötetään otsikossa määritettyyn salausalgoritmiin ("alg"-avain). Avain voi olla mikä tahansa merkkijono. Pidemmät merkkijonot ovat suosituimpia, koska niiden poimiminen kestää kauemmin.
{"alg":"RSA1_5","hyötykuorma":"A128CBC-HS256"}
Keycloak Failover Cluster -arkkitehtuurin rakentaminen
Käytettäessä yhtä klusteria kaikissa projekteissa, kertakirjautumisratkaisulle on korkeammat vaatimukset. Kun projektien määrä on pieni, nämä vaatimukset eivät ole niin havaittavissa kaikissa projekteissa, mutta käyttäjien ja integraatioiden lisääntyessä käytettävyyden ja suorituskyvyn vaatimukset kasvavat.
Yhden SSO-vian riskin lisääminen lisää vaatimuksia ratkaisuarkkitehtuurille ja redundanttien komponenttien menetelmille ja johtaa erittäin tiukkaan SLA:han. Tässä suhteessa useammin ratkaisujen kehitysvaiheessa tai toteutusvaiheessa projekteilla on oma ei-vikasietoinen infrastruktuuri. Kehityksen edetessä vaaditaan kehittämis- ja skaalautumismahdollisuuksia. Joustavinta on rakentaa vikasietoklusteri käyttämällä konttivirtualisointia tai hybridilähestymistapaa.
Aktiivinen/aktiivinen ja aktiivinen/passiivinen klusteritiloissa työskentely edellyttää tietojen johdonmukaisuutta relaatiotietokannassa - molemmat tietokantasolmut on replikoitava synkronisesti eri maantieteellisesti hajautettujen tietokeskusten välillä.
Yksinkertaisin esimerkki vikasietoisesta asennuksesta.
Mitä etuja yhden klusterin käytöstä on:
- Korkea käytettävyys ja suorituskyky.
- Toimintatilojen tuki: aktiivinen/aktiivinen, aktiivinen/passiivinen.
- Kyky skaalata dynaamisesti - kontin virtualisointia käytettäessä.
- Mahdollisuus keskitettyyn hallintaan ja seurantaan.
- Yhtenäinen lähestymistapa käyttäjien tunnistamiseen/autentikointiin/valtuutukseen projekteissa.
- Läpinäkyvämpi vuorovaikutus eri projektien välillä ilman käyttäjien osallistumista.
- Mahdollisuus käyttää JWT-tunnusta uudelleen erilaisissa projekteissa.
- Yksittäinen luottamuspiste.
- Nopeampi projektien käynnistäminen mikropalveluiden/konttivirtualisoinnin avulla (ei tarvitse nostaa ja määrittää lisäkomponentteja).
- Kaupallista tukea on mahdollista ostaa myyjältä.
Mitä pitää ottaa huomioon klusteria suunnitellessa
DBMS
Keycloak käyttää tietokannan hallintajärjestelmää tallentaakseen: alueet, asiakkaat, käyttäjät jne.
Laaja valikoima DBMS-järjestelmiä tuetaan: MS SQL, Oracle, MySQL, PostgreSQL. Keycloakin mukana tulee oma sisäänrakennettu relaatiotietokanta. Sitä suositellaan käytettäväksi kuormittamattomissa ympäristöissä - kuten kehitysympäristöissä.
Aktiivinen/aktiivinen ja aktiivinen/passiivinen klusteritiloissa työskentely edellyttää tietojen johdonmukaisuutta relaatiotietokannassa, ja molemmat tietokantaklusterisolmut replikoidaan synkronisesti tietokeskusten välillä.
Hajautettu välimuisti (Infinspan)
Jotta klusteri toimisi oikein, seuraavien välimuistityyppien lisäsynkronointi vaaditaan JBoss-tietoruudukon avulla:
Todennusistunnot - käytetään tietojen tallentamiseen tietyn käyttäjän todentamisen yhteydessä. Tämän välimuistin pyynnöt sisältävät yleensä vain selaimen ja Keycloak-palvelimen, eivät sovellusta.
Toimintotunnuksia käytetään skenaarioissa, joissa käyttäjän on vahvistettava toiminto asynkronisesti (sähköpostitse). Esimerkiksi salasanan unohtamisen aikana actionTokens Infinispan -välimuistia käytetään pitämään kirjaa metatiedot liittyvistä jo käytettyjen toimintotunnisteista, joten niitä ei voi käyttää uudelleen.
Pysyvien tietojen välimuisti ja mitätöiminen - käytetään pysyvien tietojen välimuistiin, jotta vältetään tarpeettomat kyselyt tietokantaan. Kun mikä tahansa Keycloak-palvelin päivittää tiedot, kaikkien muiden Keycloak-palvelimien on tiedettävä siitä kaikissa palvelinkeskuksissa.
Work - Käytetään vain virheellisten viestien lähettämiseen klusterin solmujen ja datakeskusten välillä.
Käyttäjäistunnot - käytetään tallentamaan tietoja käyttäjäistunnoista, jotka ovat voimassa käyttäjän selainistunnon ajan. Välimuistin tulee käsitellä HTTP-pyynnöt loppukäyttäjältä ja sovellukselta.
Raaka voimasuojaus - käytetään tietojen seurantaan epäonnistuneista kirjautumisista.
Kuormituksen tasapainoittaminen
Kuormantasaaja on yksi näppäintakki, ja sen on tuettava tarttuvia istuntoja.
Sovelluspalvelimet
Niitä käytetään ohjaamaan komponenttien keskinäistä vuorovaikutusta, ja ne voidaan virtualisoida tai säilöä käyttämällä olemassa olevia automaatiotyökaluja ja infrastruktuurin automaatiotyökalujen dynaamista skaalausta. Yleisimmät käyttöönottoskenaariot OpenShiftissä, Kubernatesissa, Rancherissa.
Tämä päättää ensimmäisen osan - teoreettisen. Seuraavassa artikkelisarjassa analysoidaan esimerkkejä integraatioista eri identiteetintarjoajien kanssa ja esimerkkejä asetuksista.
Lähde: will.com