In elk groot bedrijf, en X5 Retail Group is daarop geen uitzondering, neemt naarmate de ontwikkeling vordert het aantal projecten waarvoor gebruikersautorisatie nodig is toe. Na verloop van tijd is een naadloze overgang van gebruikers van de ene applicatie naar de andere vereist en dan is er behoefte aan het gebruik van één enkele Single-Sing-On (SSO)-server. Maar wat te doen als identiteitsproviders zoals AD of anderen die geen extra attributen hebben, al in verschillende projecten worden gebruikt. Een klasse systemen die ‘identiteitsmakelaars’ worden genoemd, zullen te hulp komen. De meest functionele zijn de vertegenwoordigers ervan, zoals Keycloak, Gravitee Access management, enz. Meestal kunnen gebruiksscenario's verschillend zijn: machine-interactie, gebruikersparticipatie, enz. De oplossing moet flexibele en schaalbare functionaliteit ondersteunen die alle vereisten in één kan combineren, en zo'n oplossing Ons bedrijf heeft nu een indicatiemakelaar – Keycloak.
Keycloak is een open source identiteits- en toegangscontroleproduct dat wordt onderhouden door RedHat. Het is de basis voor de producten van het bedrijf die SSO gebruiken - RH-SSO.
Basisbegrippen
Voordat u oplossingen en benaderingen begint te begrijpen, moet u de termen en volgorde van processen definiëren:
identificatie is een procedure om een subject te herkennen aan zijn identifier (met andere woorden, dit is het bepalen van een naam, login of nummer).
authenticatie - dit is een authenticatieprocedure (de gebruiker wordt gecontroleerd met een wachtwoord, de brief wordt gecontroleerd met een elektronische handtekening, enz.)
Machtiging – biedt toegang tot een bron (bijvoorbeeld e-mail).
Keycloak identiteitsmakelaar
Sleutelmantel is een open source identiteits- en toegangsbeheeroplossing ontworpen voor gebruik in IS waar microservice-architectuurpatronen kunnen worden gebruikt.
Keycloak biedt functies zoals Single Sign-On (SSO), Brokered Identity en Social Login, Gebruikersfederatie, Client Adapters, Admin Console en Account Management Console.
Basisfunctionaliteit ondersteund in Keycloak:
- Eenmalige aanmelding en eenmalige aanmelding voor browsertoepassingen.
- OpenID/OAuth 2.0/SAML-ondersteuning.
- Identity Brokering - authenticatie met behulp van externe OpenID Connect- of SAML-identiteitsproviders.
- Sociale login - Google, GitHub, Facebook, Twitter-ondersteuning voor gebruikersidentificatie.
- Gebruikersfederatie – synchronisatie van gebruikers van LDAP- en Active Directory-servers en andere identiteitsproviders.
- Kerberos-bridge – gebruik van een Kerberos-server voor automatische gebruikersauthenticatie.
- Admin Console - voor uniform beheer van instellingen en oplossingsparameters via internet.
- Accountbeheerconsole – voor onafhankelijk gebruikersprofielbeheer.
- Maatwerk van de oplossing op basis van de huisstijl van het bedrijf.
- 2FA-authenticatie – TOTP/HOTP-ondersteuning met behulp van Google Authenticator of FreeOTP.
- Inlogstromen – zelfregistratie van gebruikers, wachtwoordherstel en reset, en andere zijn mogelijk.
- Sessiebeheer - beheerders kunnen gebruikerssessies vanaf één punt beheren.
- Token Mappers - binden gebruikerskenmerken, rollen en andere vereiste kenmerken aan tokens.
- Flexibel beleidsbeheer voor alle domeinen, applicaties en gebruikers.
- CORS-ondersteuning – Clientadapters hebben native CORS-ondersteuning.
- Service Provider Interfaces (SPI) - Een groot aantal SPI's waarmee u verschillende aspecten van de server kunt aanpassen: authenticatiestromen, identiteitsproviders, protocoltoewijzing en meer.
- Clientadapters voor JavaScript-applicaties, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Ondersteuning voor het werken met verschillende applicaties die de OpenID Connect Relying Party-bibliotheek of SAML 2.0 Service Provider Library ondersteunen.
- Uitbreidbaar met plug-ins.
Voor CI/CD-processen, maar ook voor de automatisering van beheerprocessen in Keycloak, kan de REST API/JAVA API worden gebruikt. Documentatie is beschikbaar in elektronische vorm:
REST API
JAVA-API
Enterprise Identity-providers (on-premise)
Mogelijkheid om gebruikers te authenticeren via gebruikersfederatieservices.
Pass-through-authenticatie kan ook worden gebruikt: als gebruikers zich authenticeren op werkstations met Kerberos (LDAP of AD), kunnen ze automatisch worden geauthenticeerd bij Keycloak zonder dat ze hun gebruikersnaam en wachtwoord opnieuw hoeven in te voeren.
Voor authenticatie en verdere autorisatie van gebruikers is het mogelijk om een relationeel DBMS te gebruiken, wat het meest geschikt is voor ontwikkelomgevingen, omdat dit geen langdurige instellingen en integraties in de vroege stadia van projecten met zich meebrengt. Standaard gebruikt Keycloak een ingebouwd DBMS om instellingen en gebruikersgegevens op te slaan.
De lijst met ondersteunde DBMS'en is uitgebreid en omvat: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle en anderen. De meest geteste op dit moment zijn Oracle 12C Release1 RAC en Galera 3.12 cluster voor MariaDB 10.1.19.
Identiteitsproviders - sociale login
Het is mogelijk om een login van sociale netwerken te gebruiken. Om de mogelijkheid om gebruikers te authenticeren in te schakelen, gebruikt u de Keycloack-beheerdersconsole. Er zijn geen wijzigingen aan de applicatiecode vereist en deze functionaliteit is out-of-the-box beschikbaar en kan in elke fase van het project worden geactiveerd.
Om gebruikers te authenticeren is het mogelijk om OpenID/SAML Identity providers te gebruiken.
Typische autorisatiescenario's met OAuth2 in Keycloak
Autorisatiecodestroom — gebruikt met server-side applicaties. Een van de meest voorkomende vormen van autorisatie omdat het zeer geschikt is voor server-side applicaties waarbij de broncode en clientgegevens van de applicatie niet toegankelijk zijn voor anderen. Het proces is in dit geval gebaseerd op omleiding. De applicatie moet kunnen communiceren met een user-agent (user-agent), zoals een webbrowser, om API-autorisatiecodes te ontvangen die via de user-agent worden doorgestuurd.
impliciete stroom — gebruikt door mobiele of webapplicaties (applicaties die op het apparaat van de gebruiker draaien).
Het impliciete autorisatietoestemmingstype wordt gebruikt door mobiele en webapplicaties waarbij de privacy van klanten niet kan worden gegarandeerd. Het impliciete machtigingstype maakt ook gebruik van omleiding van gebruikersagenten, waarbij het toegangstoken wordt doorgegeven aan de gebruikersagent voor later gebruik in de toepassing. Hierdoor wordt het token beschikbaar voor de gebruiker en andere applicaties op het apparaat van de gebruiker. Dit type autorisatietoestemming verifieert de identiteit van de applicatie niet en het proces zelf is afhankelijk van de omleidings-URL (eerder geregistreerd bij de service).
Implicit Flow ondersteunt geen vernieuwingstokens voor toegangstokens.
Klantreferenties verlenen stroom — worden gebruikt wanneer de applicatie toegang krijgt tot de API. Dit type autorisatietoestemming wordt doorgaans gebruikt voor server-naar-server-interacties die op de achtergrond moeten worden uitgevoerd zonder onmiddellijke gebruikersinteractie. Met de toekenningsstroom voor clientreferenties kan een webservice (vertrouwelijke client) zijn eigen referenties gebruiken in plaats van zich voor te doen als een gebruiker om zich te verifiëren bij het aanroepen van een andere webservice. Voor een hoger beveiligingsniveau is het mogelijk dat de bellende dienst een certificaat (in plaats van een gedeeld geheim) als referentie gebruikt.
De OAuth2-specificatie wordt beschreven in
JWT-token en zijn voordelen
JWT (JSON Web Token) is een open standaard () dat een compacte en op zichzelf staande manier definieert om informatie veilig tussen partijen over te dragen als een JSON-object.
Volgens de standaard bestaat het token uit drie delen in base-64-formaat, gescheiden door punten. Het eerste deel wordt de header genoemd en bevat het type token en de naam van het hash-algoritme voor het verkrijgen van een digitale handtekening. Het tweede deel slaat de basisinformatie op (gebruiker, attributen, enz.). Het derde deel is de digitale handtekening.
. .
Bewaar nooit een token in uw database. Omdat een geldig token gelijk is aan een wachtwoord, is het opslaan van het token hetzelfde als het opslaan van het wachtwoord in gewone tekst.
Toegangstoken is een token dat de eigenaar toegang geeft tot beschermde serverbronnen. Het heeft doorgaans een korte levensduur en kan aanvullende informatie bevatten, zoals het IP-adres van de partij die het token aanvraagt.
Token vernieuwen is een token waarmee klanten nieuwe toegangstokens kunnen aanvragen nadat hun levensduur is verstreken. Deze tokens worden doorgaans voor een langere periode uitgegeven.
De belangrijkste voordelen van het gebruik van een microservice-architectuur:
- Mogelijkheid om toegang te krijgen tot verschillende applicaties en diensten via eenmalige authenticatie.
- Als een aantal vereiste attributen in het gebruikersprofiel ontbreken, is het mogelijk om deze te verrijken met gegevens die aan de payload kunnen worden toegevoegd, ook automatisch en on-the-fly.
- Het is niet nodig om informatie over actieve sessies op te slaan; de serverapplicatie hoeft alleen de handtekening te verifiëren.
- Flexibelere toegangscontrole door extra attributen in de payload.
- Het gebruik van een tokenhandtekening voor de header en payload verhoogt de beveiliging van de algehele oplossing.
JWT-token - samenstelling
Titel — standaard bevat de header alleen het tokentype en het algoritme dat voor de codering wordt gebruikt.
Het type token wordt opgeslagen in de "typ" -sleutel. De 'type'-sleutel wordt genegeerd in de JWT. Als de sleutel "typ" aanwezig is, moet de waarde JWT zijn om aan te geven dat dit object een JSON-webtoken is.
De tweede sleutel "alg" specificeert het algoritme dat wordt gebruikt om het token te coderen. Standaard moet dit worden ingesteld op HS256. De header is gecodeerd in base64.
{ "alg": "HS256", "typ": "JWT"}
lading (inhoud) - de payload slaat alle informatie op die moet worden gecontroleerd. Elke sleutel in de payload staat bekend als een "claim". U kunt bijvoorbeeld alleen op uitnodiging deelnemen aan de aanvraag (gesloten promo). Als we iemand willen uitnodigen om deel te nemen, sturen we hem een uitnodigingsbrief. Het is belangrijk om te controleren of het e-mailadres van de persoon is die de uitnodiging accepteert, daarom nemen we dit adres op in de payload, hiervoor slaan we het op in de sleutel "e-mail"
{ "e-mail": "[e-mail beveiligd]" }
Sleutels in de payload kunnen willekeurig zijn. Er zijn echter een paar voorbehouden:
- iss (Issuer) - Identificeert de toepassing van waaruit het token wordt verzonden.
- sub (Onderwerp) - definieert het onderwerp van het token.
- aud (Audience) is een reeks hoofdlettergevoelige tekenreeksen of URI's die een lijst vormen met de ontvangers van dit token. Wanneer de ontvangende partij een JWT met de gegeven sleutel ontvangt, moet deze controleren of hijzelf aanwezig is bij de ontvangers - anders negeert hij het token.
- exp (Vervaltijd) - Geeft aan wanneer het token verloopt. De JWT-standaard vereist dat al zijn implementaties verlopen tokens afwijzen. De exp-sleutel moet een tijdstempel in Unix-indeling zijn.
- nbf (Not Before) is een tijdstip in unix-formaat dat het moment bepaalt waarop het token geldig wordt.
- iat (Issued At) - Deze sleutel vertegenwoordigt het tijdstip waarop het token is uitgegeven en kan worden gebruikt om de leeftijd van de JWT te bepalen. De iat-sleutel moet een tijdstempel in Unix-formaat zijn.
- Jti (JWT ID) — een tekenreeks die de unieke identificatie van dit token definieert, hoofdlettergevoelig.
Het is belangrijk om te begrijpen dat de payload niet versleuteld wordt verzonden (hoewel tokens kunnen worden genest en het dan mogelijk is om versleutelde gegevens te verzenden). Daarom kunt u er geen geheime informatie in opslaan. Net als de header is de payload base64-gecodeerd.
Handtekening - als we een titel en lading hebben, kunnen we de handtekening berekenen.
De header en payload gecodeerd in base64 worden genomen en gecombineerd tot een lijn, gescheiden door een punt. Deze string en de geheime sleutel worden vervolgens ingevoerd in het coderingsalgoritme dat is gespecificeerd in de header (sleutel “alg”). De sleutel kan elke string zijn. Langere snaren verdienen de meeste voorkeur, omdat ze meer tijd nodig hebben om te selecteren.
{"alg 'RSA1_5', 'payload': A128CBC-HS256"}
Het bouwen van een Keycloak Failover Cluster-architectuur
Bij het gebruik van één cluster voor alle projecten worden er hogere eisen gesteld aan een SSO-oplossing. Wanneer het aantal projecten klein is, zijn deze eisen niet voor alle projecten zo merkbaar, maar met een toename van het aantal gebruikers en integraties nemen de eisen aan beschikbaarheid en prestaties toe.
Het vergroten van het risico op een enkele SSO-storing verhoogt de eisen aan de oplossingsarchitectuur en de methoden die worden gebruikt voor redundante componenten en leidt tot een zeer krappe SLA. In dit opzicht hebben projecten tijdens de ontwikkeling of de vroege stadia van de implementatie van oplossingen vaker hun eigen niet-fouttolerante infrastructuur. Naarmate de ontwikkeling vordert, is het nodig om mogelijkheden voor ontwikkeling en schaalvergroting vast te leggen. Het is het meest flexibel om een failovercluster te bouwen met behulp van containervirtualisatie of een hybride aanpak.
Om in de Active/Active- en Active/Passive-clustermodi te kunnen werken, is het noodzakelijk om de gegevensconsistentie in de relationele database te garanderen - beide databaseknooppunten moeten synchroon worden gerepliceerd tussen verschillende geogedistribueerde datacenters.
Het eenvoudigste voorbeeld van een fouttolerante installatie.
Wat zijn de voordelen van het gebruik van één cluster:
- Hoge beschikbaarheid en prestaties.
- Ondersteuning voor bedrijfsmodi: Actief / Actief, Actief / Passief.
- Mogelijkheid tot dynamisch schalen - bij gebruik van containervirtualisatie.
- Mogelijkheid tot gecentraliseerd beheer en monitoring.
- Een uniforme aanpak voor het identificeren/authenticeren/autoriseren van gebruikers in projecten.
- Transparantere interactie tussen verschillende projecten zonder gebruikersinteractie.
- De mogelijkheid om het JWT-token in verschillende projecten te hergebruiken.
- Eén vertrouwenspunt.
- Snellere lancering van projecten met behulp van microservices/containervirtualisatie (geen noodzaak om extra componenten op te heffen en te configureren).
- Het is mogelijk om commerciële ondersteuning bij de leverancier aan te schaffen.
Waar u op moet letten bij het plannen van een cluster
DBMS
Keycloak gebruikt een databasebeheersysteem voor het opslaan van: realms, clients, gebruikers, enz.
Er wordt een breed scala aan DBMS'en ondersteund: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak wordt geleverd met een eigen ingebouwde relationele database. Aanbevolen voor gebruik in lichte omgevingen, zoals ontwikkelomgevingen.
Om in de Active/Active- en Active/Passive-clustermodi te kunnen werken, is gegevensconsistentie in een relationele database vereist, en worden beide databaseclusterknooppunten synchroon gerepliceerd tussen datacenters.
Gedistribueerde cache (Infinspan)
Om het cluster correct te laten werken, is aanvullende synchronisatie van de volgende cachetypen met behulp van JBoss Data Grid vereist:
Authenticatiesessies - gebruikt om gegevens op te slaan bij het authenticeren van een specifieke gebruiker. Verzoeken uit deze cache omvatten doorgaans alleen de browser en de Keycloak-server, niet de applicatie.
Actietokens worden gebruikt voor scenario's waarbij de gebruiker een actie asynchroon (via e-mail) moet bevestigen. Tijdens een wachtwoordvergetenstroom wordt de actionTokens Infinispan-cache bijvoorbeeld gebruikt om metagegevens bij te houden over gekoppelde actietokens die al zijn gebruikt, zodat deze niet opnieuw kunnen worden gebruikt.
Caching en ongeldigverklaring van persistente gegevens – gebruikt om persistente gegevens in de cache op te slaan om onnodige zoekopdrachten naar de database te voorkomen. Wanneer een Keycloak-server gegevens bijwerkt, moeten alle andere Keycloak-servers in alle datacenters hiervan op de hoogte zijn.
Werk - Wordt alleen gebruikt om ongeldige berichten te verzenden tussen clusterknooppunten en datacenters.
Gebruikerssessies - gebruikt om gebruikerssessiegegevens op te slaan die geldig zijn voor de duur van de browsersessie van de gebruiker. De cache moet HTTP-verzoeken van de eindgebruiker en applicatie afhandelen.
Brute force-beveiliging - gebruikt om gegevens over mislukte aanmeldingen bij te houden.
Loadbalancing
De load balancer is het enige toegangspunt tot keycloak en moet sticky-sessies ondersteunen.
Applicatieservers
Ze worden gebruikt om de interactie van componenten met elkaar te controleren en kunnen worden gevirtualiseerd of gecontaineriseerd met behulp van bestaande automatiseringstools en dynamische schaalvergroting van tools voor infrastructuurautomatisering. De meest voorkomende implementatiescenario's zijn OpenShift, Kubernates, Rancher.
Hiermee is het eerste deel – het theoretische deel – afgerond. In de volgende serie artikelen worden voorbeelden van integraties met verschillende identiteitsproviders en voorbeelden van instellingen geanalyseerd.
Bron: www.habr.com