In elke grote onderneming, en X5 Retail Group is daar geen uitzondering op, neemt naarmate de ontwikkeling vordert het aantal projecten toe waarvoor gebruikersauthenticatie vereist is. Na verloop van tijd is er een naadloze overgang van gebruikers van de ene applicatie naar de andere nodig, en dan ontstaat de noodzaak voor het gebruik van een enkele server voor Single-Sign-On (SSO). Maar wat te doen wanneer identiteitsproviders zoals AD of andere, die geen extra attributen hebben, reeds in verschillende projecten worden gebruikt? De oplossingen hiervoor zijn systemen die 'identiteitsbrokers' worden genoemd. De meest functionele vertegenwoordigers hiervan zijn zoals Keycloak, Gravitee Access management en anderen. De gebruikscenario's kunnen heel divers zijn: machine-interactie, deelname van gebruikers, enz. De oplossing moet flexibele en schaalbare functionaliteit ondersteunen die alle eisen in één oplossing kan verenigen, en die oplossing in ons bedrijf is momenteel de identiteitsbroker – Keycloak.
Keycloak is een open-source product dat bedoeld is voor identificatie en toegangsbeheer en wordt ondersteund door het bedrijf RedHat. Het vormt de basis voor de producten van het bedrijf die SSO gebruiken – RH-SSO.
Belangrijke begrippen
Voordat we beginnen met het begrijpen van oplossingen en benaderingen, moeten we de termen en de volgorde van processen vaststellen:
Identificatie — dit is de procedure voor het herkennen van een subject aan de hand van zijn identificatie (eenvoudiger gezegd, dit is het bepalen van de naam, het inloggen of het nummer).
Authenticatie – dit is de procedure voor authenticatie (de gebruiker wordt gecontroleerd via een wachtwoord, een e-mail wordt gecontroleerd met een digitale handtekening, enz.).
Autorisatie – dit is het verlenen van toegang tot een bepaalde bron (bijvoorbeeld tot e-mail).
Identiteitsbroker Keycloak
Keycloak — dit is een oplossing voor identiteits- en toegangsbeheer met een open-source karakter, bedoeld voor gebruik in informatiesystemen waar microservices-architectuurpatronen kunnen worden toegepast.
Keycloak biedt functies zoals single sign-on (SSO), broker-identificatie en sociale inlog, federatie van gebruikers, clientadaptors, een beheerdersconsole en een console voor het beheren van accounts.
Basisfunctionaliteit die door Keycloak wordt ondersteund:
- Single-Sign On en Single-Sign Out voor browserapplicaties.
- Ondersteuning voor OpenID/OAuth 2.0/SAML.
- Identiteitsbroker - authenticatie via externe OpenID Connect of SAML-identiteitsproviders.
- Social Login - ondersteuning voor Google, GitHub, Facebook, Twitter voor gebruikersidentificatie.
- Gebruikersfederatie - synchronisatie van gebruikers vanuit LDAP en Active Directory-servers en andere identiteitsproviders.
- Kerberos-brug - gebruik van een Kerberos-server voor automatische authenticatie van gebruikers.
- Admin Console - voor centraal beheer van instellingen en parameters van de oplossing via het web.
- Account Management Console - voor zelfstandig beheer van gebruikersprofielen.
- Aanpassing van de oplossing op basis van de huisstijl van het bedrijf.
- 2FA-authenticatie - ondersteuning voor TOTP/HOTP met Google Authenticator of FreeOTP.
- Login flows - gebruikers kunnen zich zelf registreren, hun wachtwoord herstellen en resetten, en meer.
- Sessiebeheer - beheerders kunnen gebruikerssessies vanuit één punt beheren.
- Token Mappers - toewijzing van gebruikersattributen, rollen en andere vereiste attributen aan tokens.
- Flexibel beheer van beleidsregels via realm, applicatie en gebruikers.
- CORS-ondersteuning - client-adapters hebben ingebouwde ondersteuning voor CORS.
- Service Provider Interfaces (SPI) - een groot aantal SPI's waarmee verschillende aspecten van de serverconfiguratie zijn in te stellen: authenticatiestromen, identiteitsproviders, protocolmapping en meer.
- Client-adapters voor JavaScript-toepassingen, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Ondersteuning voor werken met verschillende applicaties die de OpenID Connect Relying Party-bibliotheek of SAML 2.0 Service Provider-bibliotheek ondersteunen.
- Mogelijkheid tot uitbreiding met behulp van plugins.
Voor CI/CD-processen en automatisering van beheertaken in Keycloak kan een REST API/JAVA API worden gebruikt. Documentatie is beschikbaar in digitale vorm:
REST API
JAVA API
Enterprise niveau identiteitsproviders (On-Premise)
Mogelijkheid tot authenticatie van gebruikers via User Federation-services.
Ook kan doorlopende authenticatie worden gebruikt - als gebruikers zich authentiseren op werkstations met Kerberos (LDAP of AD), kunnen ze automatisch worden geauthentiseerd in Keycloak zonder opnieuw hun gebruikersnaam en wachtwoord in te voeren.
Voor authenticatie en verdere autorisatie van gebruikers kan een relationele DBMS worden gebruikt, wat vooral van toepassing is op ontwikkelomgevingen, aangezien het geen langdurige configuraties en integraties vereist in de vroege stadia van projecten. Standaard gebruikt Keycloak een ingebouwde DBMS voor het opslaan van instellingen en gebruikersgegevens.
De lijst met ondersteunde DBMS's is uitgebreid en omvat: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle en anderen. De meest geteste zijn momenteel Oracle 12C Release 1 RAC en Galera 3.12-cluster voor MariaDB 10.1.19.
Identiteitsproviders — sociale login
Het is mogelijk om in te loggen via sociale netwerken. Om de mogelijkheid te activeren om gebruikers te authentiseren, wordt de Keycloak-beheerconsole gebruikt. Wijzigingen in de code van applicaties zijn niet nodig en deze functionaliteit is 'out of the box' beschikbaar en kan op elke fase van de projectuitvoering worden geactiveerd.
Voor de authenticatie van gebruikers kunnen OpenID/SAML-identiteitsproviders worden gebruikt.
Typische autorisatiescenario's met OAuth2 in Keycloak
Authorization Code Flow — wordt gebruikt met server-toepassingen (server-side applications). Een van de meest voorkomende type autorisatie, omdat het goed werkt voor serverapplicaties waarin de broncode en clientgegevens niet toegankelijk zijn voor derden. Het proces is in dit geval gebaseerd op omleiding (redirection). De applicatie moet kunnen communiceren met een gebruikersagent (user-agent), zoals een webbrowser — autorisatiecodes moeten die via de gebruikersagent worden omgeleid krijgen.
Implicit Flow — wordt gebruikt door mobiele of webapplicaties (toepassingen die op het apparaat van de gebruiker draaien).
De impliciete autorisatie heeft toepassing in mobiele en webapplicaties waar de privacy van de klant niet gegarandeerd kan worden. Bij deze autorisatietype wordt de gebruiker omgeleid en wordt het toegangstoken aan de gebruiker verstrekt voor verder gebruik in de applicatie. Dit maakt het token toegankelijk voor de gebruiker en andere applicaties op het apparaat. Bij dit autorisatietype wordt er geen authenticatie van de applicatie uitgevoerd; het proces vertrouwt op de eerder geregistreerde omleidings-URL in de service.
De Implicit Flow ondersteunt geen refresh tokens voor toegangstokens.
Client Credentials Grant Flow — wordt gebruikt wanneer een applicatie toegang tot de API nodig heeft. Dit autorisatietype wordt meestal gebruikt voor server-server interacties die op de achtergrond moeten plaatsvinden zonder directe interactie met de gebruiker. De client credentials grant flow stelt een webservice (vertrouwelijke client) in staat zijn eigen referenties te gebruiken in plaats van de identiteit van de gebruiker bij authenticatie wanneer een andere webservice wordt aangeroepen. Voor een hoger beveiligingsniveau kan de aanroepende service een certificaat (in plaats van een gedeeld geheim) gebruiken als referentie.
De OAuth2-specificatie is beschreven in
JWT-token en zijn voordelen
JWT (JSON Web Token) is een open standaard (), die een compacte en autonome manier definieert voor de veilige overdracht van informatie tussen partijen in de vorm van 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, waarin het type token en de naam van het hash-algoritme voor de digitale handtekening is opgenomen. Het tweede deel bevat de hoofdinformatie (gebruiker, attributen, enz.). Het derde deel is de digitale handtekening.
..
Bewaar het token nooit in uw database. Want een geldig token is gelijk aan een wachtwoord; het opslaan van een token is hetzelfde als het opslaan van een wachtwoord in platte tekst.
Toegangstoken — is a token that provides its owner access to protected server resources. It usually has a short lifespan and may carry additional information, such as the IP address of the requesting party.
Refresh-token — is a token that allows clients to request new access tokens after their lifetime has expired. These tokens are generally issued for a longer period.
The main advantages of using it in a microservices architecture:
- The ability to access various applications and services through a one-time authentication.
- If certain required attributes are missing in user profiles, it is possible to enhance data, which can be added to the payload, including automatically and 'on the fly'.
- There is no need to store information about active sessions; the server application only needs to verify the signature.
- More flexible access management through additional attributes in the payload.
- Using the token signature for the header and payload increases the overall security of the solution.
JWT token — composition
De header — by default, the header contains only the type of token and the algorithm used for encryption.
The type of token is stored in the 'typ' key. The 'typ' key is ignored in JWT. If the 'typ' key is present, its value must be JWT to indicate that this object is a JSON Web Token.
The second key 'alg' defines the algorithm used for encrypting the token. By default, it should be set to HS256. The header is encoded in base64.
{ "alg": "HS256", "typ": "JWT"}
Payload (contents) — the payload contains any information that needs to be verified. Each key in the payload is known as a 'claim'. For example, one can only log into the application by invitation (closed promo). When we want to invite someone to participate, we send them an invitation email. It is important to verify that the email address belongs to the person accepting the invitation, so we will include this address in the payload, saving it under the 'e-mail' key.
{ "email": "example@x5.ru" }
Keys in the payload can be arbitrary. However, there are several reserved ones:
- iss (Issuer) — defines the application from which the token is sent.
- sub (Onderwerp) — bepaalt het onderwerp van het token.
- aud (Doelgroep) – een array van hoofdlettergevoelige strings of URI's, die een lijst zijn van ontvangers van dit token. Wanneer de ontvangende partij een JWT met deze sleutel ontvangt, moet ze controleren of zij zich in de ontvangers bevindt – anders moet het token worden genegeerd.
- exp (Verlooptijd) — geeft aan wanneer het token verloopt. De standaard JWT vereist dat in al zijn implementaties tokens met een verlopen tijd worden afgewezen. De exp-sleutel moet een tijdstempel in unix-formaat zijn.
- nbf (Niet Voor) — dit is de tijd in unix-formaat die het moment bepaalt waarop het token geldig wordt.
- iat (Uitgegeven Op) — deze sleutel vertegenwoordigt de tijd 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 string die een unieke identificatie van dit token definieert, rekening houdend met hoofdlettergebruik.
Het is belangrijk te begrijpen dat de payload niet in versleutelde vorm wordt doorgegeven (hoewel tokens genest kunnen zijn en dan versleutelde gegevens kunnen doorgeven). Daarom kan er geen gevoelige informatie in worden opgeslagen. Net als de koptekst wordt de payload gecodeerd in base64.
Handtekening — wanneer we de koptekst en payload hebben, kunnen we de handtekening berekenen.
De in base64 gecodeerde koptekst en payload worden samengevoegd in een string door een punt. Vervolgens wordt deze string samen met de geheime sleutel ingevoerd in het encryptie-algoritme dat in de koptekst is opgegeven (sleutel 'alg'). De sleutel kan een willekeurige string zijn. Langere strings zijn het meest wenselijk, omdat er meer tijd nodig is voor brute force-aanvallen.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Opbouw van de architectuur van een hoog beschikbare Keycloak-cluster
Bij het gebruik van een enkele cluster voor alle projecten zijn er hogere eisen aan de oplossing voor SSO. Wanneer het aantal projecten klein is, zijn deze eisen niet zo voelbaar voor alle projecten, maar naarmate het aantal gebruikers en integraties toeneemt, stijgen de eisen aan beschikbaarheid en prestaties.
Het verhogen van de risico's van een enkele SSO verhoogt de eisen aan de architectuur van de oplossing en de gebruikte methoden voor het back-uppen van componenten, wat leidt tot een zeer strikte SLA. Daarom hebben projecten in de ontwikkelingsfase of vroege implementatie vaak hun eigen niet-failover infrastructuur. Naarmate de ontwikkeling vordert, moet er ruimte zijn voor groei en schaalbaarheid. Het is het meest flexibel om een failover-cluster op te bouwen met behulp van containervirtualisatie of een hybride benadering.
Om in Active/Active en Active/Passive cluster-modus te kunnen werken, moet er consistentie van gegevens in de relationele database worden gegarandeerd - beide knooppunten van de database moeten synchroon worden gerepliceerd tussen verschillende geografisch verspreide datacenters.
Het eenvoudigste voorbeeld van een failover-installatie.
Wat zijn de voordelen van het gebruik van een enkele cluster:
- Hoge beschikbaarheid en prestaties.
- Ondersteuning voor werkmodi: Active/Active, Active/Passive.
- Mogelijkheid voor dynamische schaalvergroting - bij gebruik van containervirtualisatie.
- Mogelijkheid voor centraal beheer en monitoring.
- Een uniforme benadering voor identificatie/authenticatie/autorisatie van gebruikers in projecten.
- Transparanter contact tussen verschillende projecten zonder de betrokkenheid van gebruikers.
- Mogelijkheid tot hergebruik van JWT-token in verschillende projecten.
- Een enkel vertrouwenspunt.
- Snellere projectstart met gebruik van microservices/containervirtualisatie (er is geen opzet en configuratie van extra componenten vereist).
- Het is mogelijk om commerciële ondersteuning van de leverancier te verkrijgen.
Waar moet je op letten bij het plannen van een cluster
DBMS
Keycloak gebruikt een databasebeheersysteem (DBMS) voor het opslaan van: realms, clients, users, en dergelijke.
Een breed scala aan DBMS's wordt ondersteund: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak wordt geleverd met een eigen ingebouwde relationele database. Het wordt aangeraden te gebruiken voor niet-belaste omgevingen, zoals ontwikkelomgevingen.
Om in Active/Active en Active/Passive cluster-modus te kunnen werken, moet er consistentie van gegevens in de relationele database worden gegarandeerd, en beide knooppunten van de cluster-database worden synchroon gerepliceerd tussen datacenters.
Gedistrubueerde cache (Infinspan)
Voor de correcte werking van het cluster is extra synchronisatie van de volgende types cache vereist met gebruik van JBoss Data Grid:
Authenticatie-sessies — gebruikt om gegevens op te slaan tijdens de authenticatie van een specifieke gebruiker. Verzoeken vanuit deze cache omvatten doorgaans alleen de browser en de Keycloak-server, en niet de applicatie.
Actie-tokens — worden gebruikt voor scenario's waarin een gebruiker een actie asynchroon moet bevestigen (via e-mail). Bijvoorbeeld, tijdens de vergeten-wachtwoord workflow wordt de actieTokens Infinispan cache gebruikt om metadata over gerelateerde actiemarkers die al zijn gebruikt bij te houden, zodat deze niet opnieuw kunnen worden gebruikt.
Caching en invalidatie van persistente gegevens – wordt gebruikt voor het cachen van persistente gegevens om onnodige verzoeken aan de database te vermijden. Wanneer een Keycloak-server gegevens bijwerkt, moeten alle andere Keycloak-servers in alle datacenters hiervan op de hoogte zijn.
Werk — wordt alleen gebruikt voor het verzenden van berichten over ongeldig verklaren tussen clusterknopen en datacenters.
Gebruikersexplotaties — worden gebruikt om gegevens over gebruikersexplotaties op te slaan, die geldig zijn gedurende de browser-sessie van de gebruiker. De cache moet HTTP-verzoeken van eindgebruikers en applicaties verwerken.
Brute force bescherming — wordt gebruikt om gegevens bij te houden over mislukte inlogpogingen.
Lastenverdeling
De load balancer is het enige toegangspunt tot Keycloak en moet sticky sessions ondersteunen.
Applicatie-servers
Worden gebruikt om de interactie tussen componenten te beheren en kunnen worden gevirtualiseerd of gecontaineriseerd met behulp van bestaande automatiseringstools en dynamische schaalbaarheid van infrastructuurautomatisering. De meest voorkomende implementatiescenario's zijn in OpenShift, Kubernetes, Rancher.
Hiermee is het eerste deel – het theoretische – voltooid. In de volgende reeks artikelen worden voorbeelden van integraties met verschillende identiteitsproviders en configuratievoorbeelden behandeld.
Bron: habr.com
