Webservices en ACS
Bijgewerkt: 19 juni 2015
Van toepassing op: Azure
Hier volgen de deelnemers aan het basisscenario waarin een webservice is geïntegreerd met Microsoft Azure Active Directory Access Control (ook wel bekend als Access Control Service of ACS):
Relying Party-toepassing: uw webservice.
Client: een webserviceclient die toegang probeert te krijgen tot uw webservice.
Id-provider: een site of service die de client kan verifiëren.
ACS : de partitie van ACS die is toegewezen aan uw relying party-toepassing.
In het webservicescenario wordt echter ervan uitgegaan dat de client geen toegang heeft tot een browser en autonoom werkt (zonder dat een gebruiker rechtstreeks deelneemt aan het scenario).
De client moet een beveiligingstoken verkrijgen dat is uitgegeven door ACS om u aan te melden bij uw service. Dit token is een ondertekend bericht van ACS naar uw toepassing, met een set claims over de identiteit van de client. ACS geeft geen token uit, tenzij de client eerst zijn of haar identiteit bewijst.
In een webservice en ACS-scenario kan een client zijn of haar identiteit op de volgende manieren bewijzen:
Door rechtstreeks te verifiëren met ACS en de referentiestypen van de ACS-service-id te gebruiken
In de volgende afbeelding ziet u het webservicescenario met de client die zijn identiteit bewijst met acs-serviceidentiteitsreferentietypen.
.gif "Windows Azure Active Direct Access Control")
De client wordt geverifieerd bij ACS met behulp van een van de referentiestypen van de ACS-service-id. In ACS kan dit een SWT-token (Simple Web Token) zijn dat is ondertekend met een symmetrische sleutel, een X.509-certificaat of een wachtwoord. Zie Service-identiteiten voor meer informatie.
ACS valideert de ontvangen referenties, voert de ontvangen identiteitsclaims in in de ACS-regelengine, berekent de uitvoerclaims en maakt een token dat deze claims bevat.
ACS retourneert het door ACS uitgegeven token aan de client.
De client verzendt het DOOR ACS uitgegeven token naar de relying party-toepassing.
De relying party-toepassing valideert het token dat is uitgegeven door ACS en retourneert vervolgens de aangevraagde resourceweergave.
Door een beveiligingstoken te presenteren van een andere vertrouwde verlener (id-provider) die die client heeft geverifieerd
In de volgende afbeelding ziet u het webservicescenario met de client die zijn identiteit bewijst met een beveiligingstoken van een id-provider.
.gif "ACS 2.0 Web Service Scenario")
De client meldt zich aan bij de id-provider (verzendt bijvoorbeeld de referenties).
Nadat de client is geverifieerd, geeft de id-provider een token uit.
De id-provider retourneert het token naar de client.
De client verzendt het door de id-provider uitgegeven token naar ACS.
ACS valideert het door de id-provider uitgegeven token, voert de gegevens in het door de id-provider uitgegeven token in bij de ACS-regelengine, berekent de uitvoerclaims en maakt een token dat deze claims bevat.
ACS geeft een token uit aan de client.
De client verzendt het DOOR ACS uitgegeven token naar de relying party-toepassing.
De relying party-toepassing valideert de handtekening op het door ACS uitgegeven token en valideert de claims in het door ACS uitgegeven token.
De relying party-toepassing retourneert de aangevraagde resourceweergave.
Zie ook
Concepten
Access Control Service 2.0
Aan de slag met ACS
Procedure: Mijn eerste claimbewuste ASP.NET-service maken met ACS