Single Sign-On (SSO) biedt het broodnodige gemak en intrinsieke beveiliging voor aanmeldingsactiviteiten voor applicaties. Gelukkig werkt SSO met elke web-app in uw Azure Active Directory, dus laten we eens kijken hoe we dit kunnen instellen.
Met SSO loggen uw gebruikers één keer in met één account en hebben ze toegang tot uw webapplicaties, SAAS, bedrijfsbronnen en domein-gekoppelde apparaten. Na het inloggen kunnen ze elke applicatie starten vanuit de Azure AD MyApps en/of Office 365 Portal. Beheerders kunnen gebruikersaccounts beheren en toegang tot applicaties toevoegen/verwijderen op basis van lidmaatschap.
Zonder SSO moeten uw gebruikers app-specifieke loggegevens onthouden en bij elk inloggen. Het personeel moet accounts voor elke toepassing bijwerken, maken en beheren. Gebruikers moeten de wachtwoorden onthouden en hun tijd besteden aan het inloggen.
Dus, het is niet moeilijk om te zien dat SSO een duidelijke winnaar is als het gaat om toegankelijkheid op internet. Maar het is niet alleen handig, het is ook veilig, dus laten we eens kijken naar OpenID Connect.
Wat is OpenID Connect?
Hoewel Security Assertion Markup Language de huidige primaire SSO-oplossing voor ondernemingen is, schakelen velen hun gebruik om verschillende redenen over op OpenID connect.
Hier zijn er enkele om er een paar te noemen:
- Werkt beter op mobiele apparaten
- Gebaseerd op OAuth 2, dus makkelijker voor ontwikkelaars
- Perfect voor niet-werknemers
- Eenvoudig te configureren en betaalbaar in onderhoud
- Industry Standard voor Azure Active Directory, Okta, Google G Suite, Auth0, OneLogin, etc.
OpenID Connect is native voor veel IDPS, namelijk de Azure AD, daarom zullen we gebruik maken van fit.
Zowel OIDC als SAML kunnen samen worden uitgevoerd. Dus als u uw externe en interne gebruikers moet scheiden en categoriseren, kan dat de oplossing zijn. Het is ook goed voor het scheiden van uw oplossingen, waarbij u SAML gebruikt voor werknemerstoegang en OIDC voor het insluiten van kaarten op andere sites.
Zelfs als beide methoden worden toegepast, kan DSO nog steeds worden gebruikt, maar dat wordt in dit scenario niet echt gebruikt.
Hoe voeg ik een OpenID-app toe vanuit Azure AD?
Om het proces voor het inschakelen van SSO voor uw apps te starten, moet u:
- Ga naar de "Azure Portal" en selecteer de "Azure Active Directory".
- Navigeer naar "Bedrijfstoepassingen" en vervolgens naar "Alle toepassingen".
- Selecteer de knop "Nieuwe toepassing" en typ de naam in het zoekvak. (OpenID en OAuth hebben de knop Toevoegen standaard uitgeschakeld. Uw tenantbeheerder moet de aanmeldknop selecteren en toegang verlenen tot de app.
- Na succesvolle autorisatie kunt u de toestemming accepteren, waarna de startpagina van de toepassing wordt geopend.
- Wanneer u de aanmeldknop selecteert, wordt u doorgestuurd naar de "Azure Active-directory" om aan de inloggegevens te voldoen.
Op dit moment heeft u toegang tot de tenant verleend voor de OpenID-oplossing voor die specifieke app.
U kunt slechts één exemplaar van een toepassing toevoegen. Als je dit al hebt gedaan en geprobeerd om toestemming te vragen, wordt deze niet opnieuw toegevoegd aan de huurder. Eén app-instantie per tenant, dat is de enige manier waarop het werkt.
Hoe authenticatie werkt met OpenID Connect
Om door te gaan met SSO-verificatie, moet u eerst begrijpen hoe een eenvoudige aanmeldingsstroom werkt:
- Gebruiker logt in en voert inloggegevens in en stemt vervolgens in met machtigingen. (Dit wordt uitgevoerd via het /oauth2/authorize commando.)
- Er wordt een id_token geretourneerd en de autorisatiecode wordt naar de browser verzonden.
- Er vindt een omleiding plaats naar de URL.
- Het id_token is gevalideerd; er wordt een sessiecookie ingesteld.
- De drager van de OAuth-code wordt verzocht om de autorisatiecode te verstrekken.
- Het token wordt geretourneerd met refresh_token.
- Web API wordt aangeroepen met een token in de Auth-header.
- Het token is gevalideerd.
- Beveiligde gegevens worden teruggestuurd naar de webserver-app.
Dit is een heel eenvoudige weergave van de autorisatiestroom, en daar komt het uiteindelijk op neer.
Het toestemmingskader inschakelen
Om een systeemeigen clienttoepassing of multitenant-webapp te ontwikkelen, kunt u het Azure AD-toestemmingsframework gebruiken. Hierdoor kan inloggen vanaf gebruikersaccounts van een bepaalde Azure AD-tenant, die in de vorige stappen toegang heeft gekregen.
Toegang tot web-API's kan nodig zijn. Bijvoorbeeld de Microsoft Graph API om toegang te krijgen tot Azure AD, Office 365 of Intune. Alle persoonlijke web-API's moeten ook toegang krijgen van de huurder.
Het toestemmingskader is gebaseerd op een beheerder of eerdere gebruiker die toestemming geeft aan een toepassing die om registratie in de directory vraagt. Het kan betrekking hebben op toegang tot directorygegevens, maar dat hoeft niet. Nadat toestemming is gegeven, neemt de applicatie namens de gebruiker contact op met de Graph API en krijgt zo nodig toegang tot de informatie.
De API biedt toegang tot verschillende datapunten, maar biedt ook toegang tot groepen en gebruikers in de Azure AD en alle andere Microsoft-cloudservices. Daarom werkt het met al uw webapplicaties.
Dit is hoe de toestemmingservaring zal plaatsvinden voor de gebruiker en ontwikkelaar:
Ontwikkelaar/Gebruiker Toestemming
Een webclienttoepassing heeft machtigingen nodig om toegang te krijgen tot een bron. De Azure-portal declareert een machtigingsverzoek om een geconfigureerde tijd in te stellen. Net als elke andere configuratie-instelling wordt deze onderdeel van de Azure AD-registratiegegevenspunten.
Om toegang te krijgen tot het machtigingspad, moet je aan de linkerkant op "App-registraties" klikken en de applicatie openen waarmee je gaat werken. Vervolgens kunt u naar het menu "API-machtigingen" navigeren en een optie "Een machtiging toevoegen" selecteren. Hierna selecteert u de "Microsoft-grafiek" en kiest u de opties uit de "Toepassing en gedelegeerde machtigingen".
Nu zijn de rechten bijgewerkt, de gebruiker staat op het punt voor het eerst SSO te gebruiken. De toepassing moet eerst een autorisatiecode ontvangen van het eindpunt in azure AD, waarna de code wordt gebruikt om toegang te krijgen tot een vernieuwd token. Als de gebruiker niet is geverifieerd, vraagt het eindpunt om een aanmelding.
Nadat ze zich hebben aangemeld, bepa alt Azure AD of de gebruiker een toestemmingsverzoek moet zien. De beslissing wordt gebaseerd op de groep die aan de gebruiker is toegekend.
Als er geen toestemming is verleend, verschijnt er een prompt en worden de machtigingen weergegeven die nodig zijn voor functionaliteit. Een gebruiker kan instemmen met verschillende machtigingen, maar anderen hebben mogelijk toegang nodig tot een tenantbeheerdersaccount.
Conclusie
Hoewel het proces achter het inschakelen van OpenID Connect vrij eenvoudig is, zal de functionaliteit en toepassing van SSO streng zijn voor de capaciteit van de ontwikkelaar die verantwoordelijk is voor de implementatie van de functie.
OIDC wordt geleverd met een verscheidenheid aan geïntegreerde plug-ins die directe toegang vanuit de doos mogelijk maken, zoals vermeld via de basisautorisatiestroom, maar alles wat een aangepaste aanpak vereist, is een meer betrokken benadering.
Lees enkele van de originele documentatie van Azure voor meer informatie over hoe u de mogelijkheid van SSO kunt uitbreiden.
