Gebruikers verifiëren voor Zero Trust

Dit artikel helpt u, als ontwikkelaar, bij het leren van aanbevolen procedures voor het verifiëren van uw toepassingsgebruikers in Zero Trust-toepassingsontwikkeling. Verbeter uw toepassingsbeveiliging altijd met de Zero Trust-principes van minimale bevoegdheden en verifieer expliciet.

Id-tokens in gebruikersverificatie

Wanneer u een gebruiker nodig hebt om te verifiëren bij uw app, in plaats van een gebruikersnaam en wachtwoord te verzamelen, kan uw toepassing een id-token (ID) aanvragen. Het verifiëren van gebruikers via het Microsoft Identity Platform voorkomt beveiligingsrisico's die zich voordoen wanneer uw toepassing gebruikersreferenties behoudt. Wanneer u id-tokens aanvraagt, zijn er geen gebruikersnamen en bijbehorende wachtwoorden in uw app als een slechte actor inbreuk maakt op uw toepassing of deze in gevaar komt.

Het Microsoft Identity Platform ID-token maakt deel uit van de OIDC-standaard (OpenID Verbinding maken) waarmee id-tokens worden opgegeven als JSON-webtokens (JWT). De lange JWT-tekenreeks bestaat uit drie onderdelen:

1. Headerclaims. De headerclaims die aanwezig zijn in id-tokens zijn onder andere typ (type claim), alg (algoritme voor het ondertekenen van het token) en kid (vingerafdruk voor de openbare sleutel om de handtekening van het token te valideren).
2. Nettoladingclaims. De nettolading of hoofdtekst (het middelste deel van een JSON-webtoken) bevat een reeks naamkenmerkparen. De standaard vereist dat er een claim is met de (naam van de iss uitgever) die naar de toepassing gaat die het token heeft uitgegeven (de audof doelgroepclaim).
3. Handtekening. Microsoft Entra ID genereert de tokenhandtekening die apps kunnen gebruiken om te controleren of het token ongewijzigd is en u kunt het vertrouwen.

In het volgende voorbeeld van een id-token ziet u informatie over de gebruiker en bevestigt u de verificatie voor het gebruik van de toepassing.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "00000000-0000-0000-66f3-3332eca7ea81",
  "tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]

Id-tokens in toegangsbeheer

Als u de toepassings-id (client) wilt ontvangen, registreert u uw app bij het Microsoft Identity Platform. Wanneer u een token ontvangt met een doelgroepclaim (aud) die overeenkomt met de client-id van uw app, wordt de geïdentificeerde gebruiker in het token geverifieerd bij uw app. IT-beheerders kunnen toestaan dat alle gebruikers in de tenant uw app gebruiken. Ze kunnen een groep toestaan waarvan de gebruiker lid is om uw app te gebruiken.

Als u een token ontvangt waarvan de doelgroepclaim verschilt van de client-id van uw app, negeert u het token onmiddellijk. De gebruiker wordt niet geverifieerd bij uw app omdat deze is aangemeld bij een andere app. Zorg er altijd voor dat de gebruiker gemachtigd is om uw app te gebruiken.

Deze claimdetails zijn belangrijk in gebruikersverificatie:

• Een JSON-webtoken is geldig totdat het verloopt. De exp claim (vervaldatum) geeft aan wanneer het token verloopt. Als de huidige tijd vóór de tijd in de exp claim valt, is het token geldig.
• Houd er niet rekening mee dat de gebruiker is geverifieerd vóór de tijd die is opgegeven in de nbf claim (niet vóór de tijd). De nbf en exp tijden van het token definiëren de geldige levensduur van het token. Wanneer de verlooptijd nadert, moet u ervoor zorgen dat u een nieuw id-token krijgt.
• De sub (onderwerpclaim) is een unieke id voor een toepassingsgebruiker. Dezelfde gebruiker heeft een andere sub claim voor andere apps. Als u gegevens wilt opslaan om aan een gebruiker te koppelen en te voorkomen dat een aanvaller die koppeling maakt, gebruikt u de onderwerpclaim. Omdat deze de Microsoft Entra-identiteit van de gebruiker niet beschikbaar maakt, is het de meest persoonlijke manier om gegevens aan een gebruiker te koppelen. De sub claim is onveranderbaar.
• Als u informatie over meerdere toepassingen wilt delen, gebruikt u de combinatie van tenant-id's (tid) en object-id(oid)-claims die uniek zijn voor de gebruiker. De gecombineerde tenant-id en object-id zijn onveranderbaar.
• Ongeacht wat er gebeurt met de identiteit van een persoon, de sub, oiden tid claims blijven onveranderbaar. Alles over de gebruiker kan wijzigen en u kunt uw gegevens nog steeds versleutelen om de gebruiker te identificeren op basis van het onderwerp of de gecombineerde tid claims oid .

Verificatie met OIDC

Om gebruikersverificatie te demonstreren, gaan we kijken naar toepassingen die gebruikmaken van OIDC om een gebruiker te verifiëren. Dezelfde principes zijn van toepassing op apps die gebruikmaken van Security Assertion Markup Language (SAML) of WS-Federation.

Een app verifieert de gebruiker wanneer de toepassing een id-token aanvraagt bij het Microsoft Identity Platform. Werkbelastingen (toepassingen die geen gebruikers hebben, maar die worden uitgevoerd als services, achtergrondprocessen, daemons) slaan deze stap over.

U moet altijd eerst om dit token vragen. Als u op de achtergrond een token wilt verkrijgen in Microsoft Authentication Libraries (MSAL), kan uw app beginnen met de AcquireTokenSilent methode. Als uw app kan verifiëren zonder de gebruiker te storen, ontvangt deze het aangevraagde id-token.

Als het Microsoft Identity Platform de aanvraag niet kan voltooien zonder interactie met de gebruiker, moet uw app terugvallen op de MSAL-methode AcquireTokenInteractive . Als u interactief een token wilt verkrijgen, voert u de aanvraag uit door een weboppervlak te openen naar een adres onder het https://login.microsoftonline.com domein.

Vanaf dit weboppervlak heeft de gebruiker een privégesprek met het Microsoft Identity Platform. Uw app heeft geen inzicht in dit gesprek en heeft ook geen controle over het gesprek. Het Microsoft Identity Platform kan vragen om een gebruikers-id en wachtwoord, meervoudige verificatie (MFA), verificatie zonder wachtwoord of andere verificatie-interactie die de IT-beheerder of gebruiker heeft geconfigureerd.

Uw toepassing ontvangt een id-token nadat de gebruiker de vereiste verificatiestappen heeft uitgevoerd. Wanneer uw app het token ontvangt, kunt u er zeker van zijn dat het Microsoft Identity Platform de gebruiker heeft geverifieerd. Als uw app geen id-token ontvangt, heeft het Microsoft Identity Platform de gebruiker niet geverifieerd. Sta niet toe dat niet-geverifieerde gebruikers doorgaan naar beveiligde gebieden van uw app.

Het is raadzaam voor toepassingen om een sessie voor een gebruiker te maken nadat deze een id-token van Microsoft Entra ID heeft ontvangen. In het id-token dat een app ontvangt, wordt een verloopclaim (exp) met een Unix-tijdstempel weergegeven. Deze tijdstempel geeft de aan- of na verlooptijd op waarvoor de app de JWT niet mag accepteren voor verwerking. Gebruik deze verlooptijd van het token om de levensduur van uw gebruikerssessies te stimuleren. De exp claim speelt een cruciale rol bij het houden van een expliciet geverifieerde gebruiker vóór de app met de juiste bevoegdheid en voor de juiste hoeveelheid tijd.

ondersteuning voor Single sign-on

Met verificatie met eenmalige aanmelding (SSO) kunnen gebruikers zich aanmelden met één set referenties voor meerdere onafhankelijke softwaresystemen. Met eenmalige aanmelding hoeven toepassingsontwikkelaars zich niet afzonderlijk en herhaaldelijk aan te melden bij elke toepassing. Ontwikkelaars zorgen ervoor dat alle toepassingen op het apparaat van de gebruiker het weboppervlak delen waarmee de gebruiker wordt geverifieerd. Artefacten op het weboppervlak (zoals sessiestatus en cookies) na een geslaagde eenmalige aanmelding van verificatiestation.

Zoals wordt geïllustreerd in het volgende diagram, is het eenvoudigste gebruiksvoorbeeld van een gedeeld weboppervlak een app die wordt uitgevoerd in een webbrowser (zoals Microsoft Edge, Google Chrome, Firefox, Safari). Browsertabbladen delen de status van eenmalige aanmelding.

Diagramtitel: webbrowser– eenvoudigste geval. Boven in het diagram wordt een cloudshape weergegeven die een Microsoft Entra ID-pictogram bevat. Onder de cloudshape bevindt zich een vak. Verbinding maken de cloudshape en het vak is een lijn met een pijl aan elk uiteinde. Het vaklabel is 'Aangemeld blijven, SSO-statuscookies opslaan bij aanroepen'. In het vak, aan de linkerkant, is een pictogram dat lijkt op een cookie. Onder de cookie is de onderschrift 'Privégesprek met de gebruiker'. Onder het onderschrift ziet u een pictogram dat de gebruiker vertegenwoordigt. Links van deze drie onderdelen, in het vak, is een ander vak. Het interne vaklabel is 'Tabs'. Onder het label bevinden zich vier vierkante vakken die browservensters in tabbladen vertegenwoordigen.

Het Microsoft Identity Platform beheert de status van eenmalige aanmelding in een specifieke browser, tenzij de gebruiker verschillende browsers heeft geopend op hetzelfde apparaat. In Windows 10 en hoger biedt het Microsoft Identity Platform systeemeigen ondersteuning voor browser-SSO Microsoft Edge. Wanneer de gebruiker zich heeft aangemeld bij Windows, kunnen accommodaties in Google Chrome (via de extensie windows 10-accounts) en in Mozilla Firefox v91+ (via een browserinstelling) elke browser de SSO-status van Windows zelf delen.

Zoals in het volgende diagram wordt weergegeven, is het gebruiksvoorbeeld van de systeemeigen toepassing ingewikkelder.

Diagramtitel: Systeemeigen toepassingen – ingesloten browsers – geen eenmalige aanmelding. Boven in het diagram wordt een cloudshape weergegeven die een Microsoft Entra ID-pictogram bevat. Onderaan het diagram bevinden zich vier vakken horizontaal verdeeld. Rechtsonder in elk vak bevindt zich een pictogram dat een gebruiker vertegenwoordigt. In elk van de vakken ziet u een weergave van browservensters, waaronder een cookiepictogram en een wereldbolpictogram. Verbinding maken elk van de vier vakken naar de cloudshape is een lijn met een pijl aan elk uiteinde.

Verificatiebrokerbenadering

Een veelvoorkomend patroon is dat elke systeemeigen app een eigen ingesloten webweergave heeft die voorkomt dat deze deelneemt aan eenmalige aanmelding. Om dit scenario aan te pakken, maakt Microsoft Entra ID gebruik van een verificatiebrokerbenadering (verificatiebroker ) voor systeemeigen toepassingen, zoals wordt geïllustreerd in het volgende diagram.

Diagramtitel: Verificatiebrokerbenadering. Boven in het diagram wordt een cloudshape weergegeven die een Microsoft Entra ID-pictogram bevat. Onder de cloudshape bevindt zich een rechthoekshape met het label Auth Broker. De rechthoekshape bevat een cookiepictogram en een wereldbolpictogram. Verbinding maken de cloudshape en de rechthoekshape is een lijn met een pijl aan elk uiteinde. Onderaan het diagram bevinden zich vier vakken horizontaal verdeeld. Rechtsonder in elk vak bevindt zich een pictogram dat een gebruiker vertegenwoordigt. Pictogrammen in elk vak vertegenwoordigen browservensters. Verbinding maken elk van de vier vakken op de rechthoekvorm is een lijn met een pijl aan elk uiteinde.

Met een verificatiebroker ter plaatse verzenden toepassingen verificatieaanvragen naar de broker in plaats van rechtstreeks naar het Microsoft Identity Platform. Op deze manier wordt de broker het gedeelde oppervlak voor alle verificatie op het apparaat.

Naast het bieden van een gedeeld oppervlak biedt de verificatiebroker andere voordelen. Bij de overstap op Zero Trust willen ondernemingen mogelijk dat toepassingen alleen worden uitgevoerd vanaf door ondernemingen beheerde apparaten. Voorbeelden van enterprise-apparaatbeheer zijn volledige Mobile Apparaatbeheer (MDM) en scenario's waarbij gebruikers hun eigen apparaten meenemen die deelnemen aan Mobile Application Management (MAM).

Standaard isoleren onderliggende besturingssystemen (OS) browsers. Ontwikkelaars hebben een hechtere verbinding met het besturingssysteem nodig om volledige toegang te hebben tot apparaatdetails. In Windows is de verificatiebroker de Windows Web Account Manager (WAM). Op andere apparaten is de verificatiebroker de Microsoft Authenticator-app (voor apparaten met iOS of Android) of de Bedrijfsportal App (voor apparaten met Android). Toepassingen hebben toegang tot de verificatiebroker met MSAL. In Windows heeft een app toegang tot de WAM zonder MSAL. MSAL is echter de eenvoudigste manier voor apps om toegang te krijgen tot de verificatiebroker (met name apps die niet Universeel Windows-platform apps).

Verificatiebrokers werken in combinatie met Microsoft Entra-id om primaire vernieuwingstokens (PRT) te gebruiken die de noodzaak voor verificatie van gebruikers meerdere keren verminderen. PRT's kunnen bepalen of de gebruiker zich op een beheerd apparaat bevindt. Voor Microsoft Entra ID zijn verificatiebrokers vereist, omdat hiermee Proof of Possession-tokens worden geïntroduceerd, een veiligere optie voor de bearer-tokens die tegenwoordig voorkomen.

Volgende stappen

• Problemen met Microsoft Entra-toegangstokens oplossen: Valideren dat een toegangstoken beschrijft hoe u, wanneer u een Microsoft Entra-toegangstoken hebt, controleert u of bepaalde velden overeenkomen met de record.
• Vergroot de tolerantie van verificatie- en autorisatietoepassingen die u ontwikkelt reeksadressen voor apps die gebruikmaken van het Microsoft Identity Platform en de Microsoft Entra-id. Ze bevatten richtlijnen voor client- en servicetoepassingen die namens een aangemelde gebruiker en daemon-toepassingen werken die namens hen werken. Ze bevatten aanbevolen procedures voor het gebruik van tokens en het aanroepen van resources.
• Tokens aanpassen beschrijft de informatie die u kunt ontvangen in Microsoft Entra-tokens en hoe u tokens kunt aanpassen.
• Als u groepsclaims en app-rollen in tokens configureert, ziet u hoe u uw apps configureert met app-roldefinities en beveiligingsgroepen toewijst aan app-rollen.
• Bouw apps die identiteit beveiligen via machtigingen en toestemming biedt een overzicht van machtigingen en aanbevolen procedures voor toegang.