En qualsevol gran empresa, i X5 Retail Group no és una excepció, a mesura que es desenvolupa, augmenta el nombre de projectes que requereixen autorització d'usuaris. Amb el pas del temps, es requereix una transició perfecta dels usuaris d'una aplicació a una altra i, aleshores, cal utilitzar un únic servidor Single-Sing-On (SSO). Però què passa quan els proveïdors d'identitat com AD o altres que no tenen atributs addicionals ja s'utilitzen en diversos projectes. Una classe de sistemes anomenats "agents d'identificació" vindrà al rescat. Els més funcionals són els seus representants, com Keycloak, Gravitee Access management, etc. Molt sovint, els casos d'ús poden ser diferents: interacció amb la màquina, participació dels usuaris, etc. La solució ha de suportar una funcionalitat flexible i escalable que pugui combinar tots els requisits en un, i aquestes solucions, la nostra empresa ara té un corredor d'indicacions: Keycloak.
Keycloak és un producte de control d'accés i identitat de codi obert mantingut per RedHat. És la base dels productes de l'empresa que utilitzen SSO - RH-SSO.
Conceptes bàsics
Abans de començar a tractar solucions i enfocaments, hauríeu de decidir en termes i seqüència de processos:
Identificació és un procediment per reconèixer un subjecte pel seu identificador (és a dir, aquesta és la definició d'un nom, inici de sessió o número).
Autenticació - Es tracta d'un procediment d'autenticació (l'usuari es verifica amb una contrasenya, la carta es verifica amb una signatura electrònica, etc.)
Autorització - és la prestació d'accés a un recurs (per exemple, al correu electrònic).
Keycloak del corredor d'identitat
mantell de claus és una solució de gestió d'accés i identitat de codi obert dissenyada per utilitzar-se en SI on es poden utilitzar patrons d'arquitectura de microserveis.
Keycloak ofereix funcions com ara l'inici de sessió únic (SSO), la identitat intermediada i l'inici de sessió social, la federació d'usuaris, els adaptadors de client, la consola d'administració i la consola de gestió de comptes.
Funcionalitat bàsica compatible amb Keycloak:
- Inici de sessió únic i tancament de sessió únic per a aplicacions del navegador.
- Suport per a OpenID/OAuth 2.0/SAML.
- Intermediació d'identitats: autenticació mitjançant proveïdors d'identitat SAML o OpenID Connect externs.
- Inici de sessió social: suport de Google, GitHub, Facebook, Twitter per a la identificació d'usuaris.
- Federació d'usuaris: sincronització d'usuaris dels servidors LDAP i Active Directory i altres proveïdors d'identitat.
- Pont Kerberos: utilitzant un servidor Kerberos per a l'autenticació automàtica dels usuaris.
- Consola d'administració: per a la gestió unificada de la configuració i les opcions de solució a través del web.
- Consola de gestió de comptes: per a l'autogestió del perfil d'usuari.
- Personalització de la solució en funció de la identitat corporativa de l'empresa.
- Autenticació 2FA: suport TOTP/HOTP mitjançant Google Authenticator o FreeOTP.
- Fluxos d'inici de sessió: són possibles l'autoregistre de l'usuari, la recuperació i el restabliment de la contrasenya, entre d'altres.
- Gestió de sessions: els administradors poden gestionar les sessions d'usuari des d'un únic punt.
- Token Mappers: vincula els atributs d'usuari, els rols i altres atributs necessaris als fitxes.
- Gestió flexible de polítiques a l'àmbit, l'aplicació i els usuaris.
- Suport CORS: els adaptadors de client tenen suport CORS integrat.
- Interfícies de proveïdors de serveis (SPI): un gran nombre d'SPI que us permeten personalitzar diversos aspectes del servidor: fluxos d'autenticació, proveïdors d'identitat, mapes de protocols i molt més.
- Adaptadors de client per a aplicacions JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Suport per treballar amb diverses aplicacions que admeten la biblioteca OpenID Connect Relying Party o SAML 2.0 Service Provider Library.
- Ampliable mitjançant complements.
Per als processos CI / CD, així com per l'automatització dels processos de gestió a Keycloak, es pot utilitzar l'API REST / API JAVA. La documentació està disponible electrònicament:
REST API
API JAVA
Proveïdors d'identitat empresarial (on-premise)
Capacitat d'autenticar usuaris mitjançant els serveis de la Federació d'Usuaris.
També es pot utilitzar l'autenticació de pas: si els usuaris s'autentiquen en estacions de treball amb Kerberos (LDAP o AD), es poden autenticar automàticament a Keycloak sense haver d'introduir el seu nom d'usuari i contrasenya de nou.
Per a l'autenticació i l'autorització posterior dels usuaris, és possible utilitzar un SGBD relacional, que és més aplicable als entorns de desenvolupament, ja que no implica configuracions i integracions llargues en les primeres etapes dels projectes. Per defecte, Keycloak utilitza un SGBD integrat per emmagatzemar la configuració i les dades d'usuari.
La llista de SGBD compatibles és extensa i inclou: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle i altres. Els més provats fins ara són Oracle 12C Release1 RAC i el clúster Galera 3.12 per a MariaDB 10.1.19.
Proveïdors d'identitat - inici de sessió social
És possible utilitzar un inici de sessió des de les xarxes socials. Per activar la capacitat d'autenticar usuaris, utilitzeu la consola d'administració Keycloack. No calen canvis en el codi de l'aplicació i aquesta funcionalitat està disponible de manera immediata i es pot activar en qualsevol etapa del projecte.
És possible utilitzar proveïdors d'identitat OpenID/SAML per a l'autenticació d'usuaris.
Escenaris d'autorització típics amb OAuth2 a Keycloak
Flux de codi d'autorització - S'utilitza amb aplicacions del costat del servidor. Un dels tipus més comuns de permís d'autorització perquè és molt adequat per a aplicacions de servidor on el codi font de l'aplicació i les dades del client no estan disponibles per a persones alienes. El procés en aquest cas es basa en la redirecció. L'aplicació ha de poder comunicar-se amb un agent d'usuari (agent d'usuari), com ara un navegador web, per rebre codis d'autorització de l'API redirigits a través de l'agent d'usuari.
flux implícit - utilitzat per aplicacions mòbils o web (aplicacions que s'executen al dispositiu de l'usuari).
El tipus de permís d'autorització implícita l'utilitzen aplicacions mòbils i web on no es pot garantir la confidencialitat del client. El tipus de permís implícit també utilitza la redirecció de l'agent d'usuari, de manera que el testimoni d'accés es passa a l'agent d'usuari per a un ús posterior a l'aplicació. Això fa que el testimoni estigui disponible per a l'usuari i altres aplicacions al dispositiu de l'usuari. Aquest tipus de permís d'autorització no autentica la identitat de l'aplicació i el procés en si es basa en una URL de redirecció (registrada prèviament al servei).
Implicit Flow no admet testimonis d'actualització de testimonis d'accés.
Flux de concessió de credencials del client — s'utilitzen quan l'aplicació accedeix a l'API. Aquest tipus de permís d'autorització s'utilitza normalment per a les interaccions de servidor a servidor que s'han de realitzar en segon pla sense la interacció immediata de l'usuari. El flux de concessió de credencials de client permet que un servei web (client confidencial) utilitzi les seves pròpies credencials en lloc de suplantar la identitat d'un usuari per autenticar-se quan truca a un altre servei web. Per a un nivell de seguretat més alt, és possible que el servei de trucades utilitzi un certificat (en lloc d'un secret compartit) com a credencial.
L'especificació OAuth2 es descriu a
Token JWT i els seus avantatges
JWT (JSON Web Token) és un estàndard obert () que defineix una forma compacta i autònoma de transferir informació de manera segura entre parts com a objecte JSON.
Segons l'estàndard, el testimoni consta de tres parts en format base-64, separades per punts. La primera part s'anomena capçalera, que conté el tipus de testimoni i el nom de l'algorisme hash per obtenir una signatura digital. La segona part emmagatzema la informació bàsica (usuari, atributs, etc.). La tercera part és la signatura digital.
. .
No emmagatzemeu mai cap testimoni a la vostra base de dades. Com que un testimoni vàlid és equivalent a una contrasenya, emmagatzemar el testimoni és com emmagatzemar la contrasenya en text clar.
Fitxa d'accés és un testimoni que concedeix al seu propietari accés als recursos segurs del servidor. Normalment té una vida útil curta i pot portar informació addicional, com ara l'adreça IP de la part que sol·licita el testimoni.
Token d'actualització és un testimoni que permet als clients sol·licitar nous testimonis d'accés després d'haver expirat la seva vida útil. Aquestes fitxes solen emetre's durant un llarg període de temps.
Els principals avantatges d'utilitzar en arquitectura de microservei:
- Possibilitat d'accedir a diverses aplicacions i serveis mitjançant l'autenticació única.
- En absència d'una sèrie d'atributs obligatoris al perfil d'usuari, és possible enriquir amb dades que es poden afegir a la càrrega útil, incloses les automatitzades i sobre la marxa.
- No cal emmagatzemar informació sobre les sessions actives, l'aplicació del servidor només necessita verificar la signatura.
- Control d'accés més flexible mitjançant atributs addicionals a la càrrega útil.
- L'ús d'una signatura de testimoni per a la capçalera i la càrrega útil augmenta la seguretat de la solució en conjunt.
Fitxa JWT - composició
Títol - per defecte, la capçalera només conté el tipus de testimoni i l'algorisme utilitzat per al xifratge.
El tipus de testimoni s'emmagatzema a la clau "typ". La clau "tipus" s'ignora al JWT. Si la clau "typ" està present, el seu valor ha de ser JWT per indicar que aquest objecte és un testimoni web JSON.
La segona clau "alg" defineix l'algorisme utilitzat per xifrar el testimoni. S'hauria d'establir a HS256 per defecte. La capçalera està codificada en base64.
{ "alg": "HS256", "type": "JWT"}
càrrega útil (contingut) - la càrrega útil emmagatzema qualsevol informació que cal comprovar. Cada clau de la càrrega útil es coneix com a "reclamació". Per exemple, només podeu entrar a l'aplicació per invitació (promoció tancada). Quan volem convidar algú a participar, li enviem una carta d'invitació. És important comprovar que l'adreça de correu electrònic pertany a la persona que accepta la invitació, així que inclourem aquesta adreça a la càrrega útil, per a això la desem a la clau "email"
{ "email": "[protegit per correu electrònic]"}
Les claus de la càrrega útil poden ser arbitràries. No obstant això, hi ha alguns reservats:
- iss (Emissor): identifica l'aplicació des de la qual s'envia el testimoni.
- sub (Subjecte): defineix el subjecte del testimoni.
- aud (Audiència) és una matriu de cadenes o URI que distingeixen entre majúscules i minúscules que és una llista dels destinataris d'aquest testimoni. Quan el costat receptor rep un JWT amb la clau donada, ha de comprovar la presència d'ell mateix als destinataris; en cas contrari, ignora el testimoni.
- exp (Temps d'expiració): indica quan caduca el testimoni. L'estàndard JWT requereix que totes les seves implementacions rebutgin els testimonis caducats. La clau exp ha de ser una marca de temps en format Unix.
- nbf (Not Before) és un temps en format Unix que determina el moment en què el testimoni esdevé vàlid.
- iat (emès a): aquesta clau representa l'hora en què es va emetre el testimoni i es pot utilitzar per determinar l'edat del JWT. La clau iat ha de ser una marca de temps en format Unix.
- Jti (ID JWT): una cadena que defineix l'identificador únic d'aquest testimoni, distingeix entre majúscules i minúscules.
És important entendre que la càrrega útil no es transmet en forma xifrada (tot i que els testimonis es poden imbricar i llavors és possible transmetre dades xifrades). Per tant, no pot emmagatzemar cap informació secreta. Igual que la capçalera, la càrrega útil està codificada en base64.
Signatura - quan tenim un títol i una càrrega útil, podem calcular la signatura.
Codificada en Base64: es prenen la capçalera i la càrrega útil, es combinen en una cadena mitjançant un punt. Aleshores, aquesta cadena i la clau secreta s'introdueixen a l'algorisme de xifratge especificat a la capçalera (clau "alg"). La clau pot ser qualsevol cadena. Les cordes més llargues seran més preferides, ja que trigaran més a agafar-se.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Creació d'una arquitectura de clúster de failover Keycloak
Quan s'utilitza un únic clúster per a tots els projectes, hi ha més requisits per a una solució SSO. Quan el nombre de projectes és petit, aquests requisits no són tan notables per a tots els projectes, però, amb un augment del nombre d'usuaris i integracions, els requisits de disponibilitat i rendiment augmenten.
Augmentar el risc d'error de SSO únic augmenta els requisits per a l'arquitectura de la solució i els mètodes utilitzats per als components redundants i condueix a un SLA molt ajustat. En aquest sentit, més sovint durant el desenvolupament o les primeres etapes d'implementació de solucions, els projectes tenen la seva pròpia infraestructura no tolerant a errors. A mesura que avança el desenvolupament, cal establir oportunitats de desenvolupament i escala. És més flexible crear un clúster de failover mitjançant la virtualització de contenidors o un enfocament híbrid.
Per treballar en els modes de clúster actiu/actiu i actiu/passiu, cal garantir la coherència de les dades en una base de dades relacional: tots dos nodes de bases de dades s'han de replicar de manera sincrònica entre diferents centres de dades geodistribuïts.
L'exemple més senzill d'una instal·lació tolerant a errors.
Quins són els avantatges d'utilitzar un únic clúster:
- Alta disponibilitat i rendiment.
- Suport per a modes de funcionament: actiu / actiu, actiu / passiu.
- Capacitat d'escalar dinàmicament quan s'utilitza la virtualització de contenidors.
- Possibilitat de gestió i seguiment centralitzats.
- Enfocament unificat per a la identificació/autenticació/autorització d'usuaris en projectes.
- Interacció més transparent entre diferents projectes sense la implicació dels usuaris.
- La capacitat de reutilitzar el testimoni JWT en diversos projectes.
- Punt únic de confiança.
- Llançament més ràpid de projectes mitjançant microserveis/virtualització de contenidors (sense necessitat d'aixecar i configurar components addicionals).
- És possible comprar suport comercial del venedor.
Què cal cercar a l'hora de planificar un clúster
SGBD
Keycloak utilitza un sistema de gestió de bases de dades per emmagatzemar: regnes, clients, usuaris, etc.
S'admet una àmplia gamma de DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak ve amb la seva pròpia base de dades relacional integrada. Es recomana utilitzar-lo per a entorns no carregats, com ara entorns de desenvolupament.
Per treballar en els modes de clúster actiu/actiu i actiu/passiu, cal que les dades siguin coherents en una base de dades relacional i els dos nodes del clúster de bases de dades es repliquen de manera sincrònica entre els centres de dades.
Memòria cau distribuïda (Infinspan)
Perquè el clúster funcioni correctament, cal una sincronització addicional dels següents tipus de memòria cau mitjançant JBoss Data Grid:
Sessions d'autenticació: s'utilitzen per desar dades quan s'autentica un usuari específic. Les sol·licituds d'aquesta memòria cau normalment només inclouen el navegador i el servidor Keycloak, no l'aplicació.
Els testimonis d'acció s'utilitzen per a escenaris en què l'usuari necessita confirmar una acció de manera asíncrona (via correu electrònic). Per exemple, durant un flux d'oblit contrasenyes, la memòria cau d'actionTokens Infinispan s'utilitza per fer un seguiment de les metadades sobre fitxes d'acció associats que ja s'han utilitzat, de manera que no es poden reutilitzar.
Emmagatzematge a la memòria cau i invalidació de dades persistents: s'utilitza per a la memòria cau dades persistents per evitar consultes innecessàries a la base de dades. Quan qualsevol servidor Keycloak actualitza les dades, tots els altres servidors Keycloak de tots els centres de dades han de saber-ho.
Treball: només s'utilitza per enviar missatges no vàlids entre nodes de clúster i centres de dades.
Sessions d'usuari: s'utilitzen per emmagatzemar dades sobre sessions d'usuari que són vàlides durant la sessió del navegador de l'usuari. La memòria cau ha de processar les sol·licituds HTTP de l'usuari final i de l'aplicació.
Protecció de força bruta: s'utilitza per fer un seguiment de les dades sobre inicis de sessió fallits.
Equilibri de càrrega
L'equilibrador de càrrega és l'únic punt d'entrada per a la clausura i ha de suportar sessions enganxades.
Servidors d'aplicacions
S'utilitzen per controlar la interacció dels components entre si i es poden virtualitzar o contenidor mitjançant les eines d'automatització existents i l'escala dinàmica d'eines d'automatització d'infraestructura. Els escenaris de desplegament més habituals a OpenShift, Kubernates, Rancher.
Això conclou la primera part, la teòrica. A la següent sèrie d'articles, s'analitzaran exemples d'integracions amb diversos proveïdors d'identitat i exemples de configuració.
Font: www.habr.com