Delen via

Een oplossing voor identiteitsbeheer kiezen

  • Artikel

De meeste web-apps ondersteunen verificatie om ervoor te zorgen dat gebruikers zijn wie ze beweren te zijn. Een gebruiker kan een persoon of een andere app zijn. Het beheer van toegang zorgt ervoor dat gebruikers alleen de informatie kunnen zien en wijzigen die ze mogen zien en wijzigen. Een eindgebruiker mag bijvoorbeeld geen toegang hebben tot de beheersectie van een website. Identity beheeroplossingen zijn gebouwd om de vereisten van verificatie- en autorisatiegerelateerde taken af te handelen. Voor meer informatie over identiteitsbeheer, zie Wat is identiteits- en toegangsbeheer?. Veel oplossingen voor identiteitsbeheer voor .NET-web-apps zijn beschikbaar, elk met verschillende mogelijkheden en vereisten voor gebruik of installatie. Dit artikel bevat richtlijnen voor het kiezen van de juiste oplossing.

Basisidentiteitsbeheer met ASP.NET Core Identity

ASP.NET Core wordt geleverd met een ingebouwde verificatieprovider: ASP.NET Core Identity. De provider bevat de API's, gebruikersinterface en back-enddatabaseconfiguratie ter ondersteuning van het beheren van gebruikersidentiteiten, het opslaan van gebruikersreferenties en het verlenen of intrekken van machtigingen. Andere functies die worden ondersteund, zijn onder andere:

Voor de meeste scenario's is dit mogelijk de enige provider die nodig is.

Voor meer informatie:

In andere scenario's kan een server of service die verificatie en identiteit beheert nuttig zijn.

Bepalen of een OIDC-server nodig is

Web-apps vereisen een manier om eerdere acties te onthouden, omdat het web standaard staatloos is. Anders worden gebruikers gedwongen hun referenties in te voeren telkens wanneer ze naar een nieuwe pagina navigeren. De algemene oplossing voor het onthouden van de status is cookies, een browsermechanisme voor het opslaan van gegevens. De webserver verzendt de eerste cookie, vervolgens slaat de browser deze op en stuurt deze terug met elke aanvraag. Dit wordt automatisch gedaan zonder dat de ontwikkelaar code hoeft te schrijven. Cookies zijn eenvoudig te gebruiken en ingebouwd in de browser, maar zijn ontworpen voor gebruik binnen één website of webdomein. De standaardoplossing die is ingebouwd in ASP.NET Core maakt gebruik van cookie-gebaseerde verificatie.

Tokens zijn containers met metagegevens die expliciet worden doorgegeven via de headers of hoofdtekst van HTTP-aanvragen. Het belangrijkste voordeel van tokens ten opzichte van cookies is dat ze niet zijn gekoppeld aan een specifieke app of domein. In plaats daarvan worden tokens meestal ondertekend met asymmetrische cryptografie. OIDC-servers geven bijvoorbeeld tokens uit met informatie over identiteit met behulp van de JSON-webtoken (JWT) indeling die ondertekening omvat. Asymmetrische cryptografie maakt gebruik van een combinatie van een persoonlijke sleutel die alleen bekend is bij de ondertekenaar en een openbare sleutel die iedereen kan kennen. Tokens kunnen ook worden versleuteld.

Er kan niet met het ondertekende token worden geknoeid vanwege de persoonlijke sleutel. De openbare sleutel:

  • Hiermee kunt u het token valideren om ervoor te zorgen dat het niet is gewijzigd.
  • Garandeert dat deze is gegenereerd door de entiteit die de persoonlijke sleutel bevat.

Het belangrijkste nadeel van het gebruik van tokens is dat ze een service (meestal een OIDC-server) nodig hebben om zowel problemen op te lossen als validatie voor tokens te bieden. De service moet worden geïnstalleerd, geconfigureerd en onderhouden.

Een veelvoorkomende reden waarom een OIDC-server is vereist, is voor toepassingen die web-API's beschikbaar maken die door andere apps worden gebruikt. Voor blootgestelde web-API's worden client-UIS's zoals SPA (Single Page Applications), mobiele clients en desktopclients beschouwd als onderdeel van dezelfde app. Spa-voorbeelden zijn Angular, React en Blazor WebAssembly. Als andere apps dan uw web-app of client-UIS een beveiligde API-aanroep naar uw app moeten maken, wilt u waarschijnlijk tokens gebruiken. Als u alleen client-UIS's hebt, biedt ASP.NET Core Identity de mogelijkheid om een token te verkrijgen tijdens verificatie. Het verificatietoken dat is uitgegeven door ASP.NET Core Identity:

  • Kan worden gebruikt door mobiele en desktopclients. Cookies hebben de voorkeur boven tokens voor zowel beveiliging als eenvoud.
  • Is niet geschikt voor het beheren van toegang vanuit apps van derden.

Een andere reden waarom een OIDC-server is vereist, is voor het delen van aanmeldingen met andere apps. Deze functie wordt vaak aangeduid als single sign-on. Met deze functie kunnen gebruikers:

  • Meld u eenmaal aan met het formulier van een web-app.
  • Gebruik de resulterende referenties om te verifiëren bij andere apps zonder dat u zich opnieuw hoeft aan te melden of een ander wachtwoord hoeft te kiezen.

Een OIDC-server heeft doorgaans de voorkeur om een veilige en schaalbare oplossing te bieden voor eenmalige aanmelding.

Voor apps die geen aanmeldingen met andere apps delen, is de eenvoudigste manier om een app snel te beveiligen de ingebouwde ASP.NET Core Identity-provider te gebruiken. Anders is er een OIDC-server nodig die wordt geleverd door een oplossing voor identiteitsbeheer van derden. OIDC-servers zijn beschikbaar als:

  • Producten die u installeert op uw server, zelfhost-genoemd.
  • Containers worden uitgevoerd op een host zoals Docker.
  • Webservices waarmee u integreert om identiteiten te beheren.

Sommige oplossingen zijn gratis en open source, terwijl andere commercieel gelicentieerd zijn. Zie oplossingen voor identiteitsbeheer voor een lijst met beschikbare opties. Het is mogelijk dat uw organisatie al gebruikmaakt van een id-provider. In dat geval kan het zinvol zijn om de bestaande provider te gebruiken in plaats van met een andere oplossing te gaan. Alle belangrijke oplossingen bieden documentatie voor het configureren van ASP.NET Core voor het gebruik van hun product of service.

Niet-verbonden scenario's

Veel oplossingen, zoals Microsoft Entra ID, zijn op de cloud gebaseerd en vereisen dat er een internetverbinding werkt. Als uw omgeving geen internetverbinding toestaat, kunt u de service niet gebruiken.

ASP.NET Core Identity werkt perfect in niet-verbonden scenario's, zoals:

  • De app heeft geen toegang tot internet.
  • De app moet nog steeds werken op het lokale netwerk, zelfs als de verbinding met internet is verbroken.

Als u een volledige OIDC-server nodig hebt voor een niet-verbonden scenario, kiest u een van de volgende opties:

  • Een oplossing waarmee u de service op uw eigen computers kunt installeren en uitvoeren.
  • Voer de authenticatieservice lokaal uit als een container.

Bepalen waar gebruikersgegevens, zoals aanmeldingen, worden opgeslagen

Een andere belangrijke factor om rekening mee te houden is waar de aanmeldingsgegevens van de gebruiker worden opgeslagen. Veel ontwikkelaars kiezen voor externe cloudservices, zoals Microsoft Entra ID voor het beheren van identiteiten. Een cloudserviceprovider:

  • Neemt de verantwoordelijkheden voor het veilig opslaan van gegevens.
  • houdt de software up-to-date met de nieuwste beveiligingspatches en releases.
  • Voldoet aan privacyvoorschriften.

Anderen geven er de voorkeur aan om gegevens op hun eigen servers op te slaan vanwege regelgeving, naleving, beleid of andere redenen.

Als de gegevens op uw servers zijn opgeslagen, moet u waarschijnlijk een installeerbare of op containers gebaseerde oplossing kiezen.

Identity versus OIDC-server

Gebruik het volgende diagram om te bepalen of u het ASP.NET Core Identity-systeem of een OIDC-server wilt gebruiken voor verificatie en autorisatie:

Identity beheerbeslissingsstroom

De volgende tabel bevat enkele van de dingen die u moet overwegen bij het kiezen van uw oplossing voor identiteitsbeheer.

Functie selfhost (infrastructuur of container) Cloud
App-integratie Lokale oplossingen die als bibliotheken of frameworks worden geïmplementeerd, kunnen vaak rechtstreeks in uw eigen app worden geïntegreerd. Voor oplossingen op basis van containers is een hand-off vereist tussen uw web-app en de service op basis van containers. Cloudoplossingen integreren doorgaans op specifieke punten in uw aanmeldingsstroom en bieden configuratie om de gebruikersinterface bij te werken zodat deze overeenkomt met uw thema, maar het beschikbare aanpassingsniveau is beperkt.
configuratie Zelfhostoplossingen vereisen het configureren van de software voor de omgeving, naast het instellen van hoe u identiteiten wilt beheren. Op containers gebaseerde oplossingen bieden doorgaans een webgebruikersinterface voor configuratie. Cloudoplossingen bieden doorgaans een webgebruikersinterface voor configuratie.
Aangepast Zelfgehoste oplossingen zijn doorgaans zeer aanpasbaar, inclusief wijzigingen op basis van code. Hoewel containeroplossingen uitbreidbaarheidsopties bieden, zijn ze vaak beperkter. Cloudservices staan aanpassingen toe, maar deze zijn doorgaans beperkt tot wijzigingen op basis van configuratie.
Onderhoud Geïnstalleerde producten vereisen een toegewezen resource om ervoor te zorgen dat alle beveiligingspatches tijdig worden toegepast en om upgrades te beheren. Het upgrade- en patchproces voor containers gaat meestal soepeler en omvat simpelweg het installeren van de opgegeven containerafbeelding. De serviceprovider onderhoudt de cloudoplossing, waaronder het toepassen van benodigde patches en het afhandelen van upgrades.
opslag van gebruikersreferenties U bent verantwoordelijk voor gegevensbeheer en het afhandelen van schendingen. Het beheren van de risico's die zijn gekoppeld aan het afhandelen van gebruikersreferenties en het naleven van regelgeving. is gedelegeerd aan de serviceprovider.

Zie Identity beheeroplossingen voor ASP.NET Corevoor meer informatie over beschikbare opties.

Volgende stappen