Procedure: Migreren vanuit de Azure Access Control Service

Waarschuwing

Deze inhoud is voor het oudere Azure AD v1.0-eindpunt. Gebruik het Microsoft Identity Platform voor nieuwe projecten.

Microsoft Azure Access Control Service (ACS), een service van Azure Active Directory (Azure AD), wordt op 7 november 2018 buiten gebruik gesteld. Toepassingen en services die momenteel gebruikmaken van Access Control, moeten dan volledig zijn gemigreerd naar een ander verificatiemechanisme. In dit artikel worden aanbevelingen voor huidige klanten beschreven, wanneer u van plan bent het gebruik van Access Control af te schappen. Als u momenteel geen Access Control gebruikt, hoeft u geen actie te ondernemen.

Overzicht

Access Control is een cloudverificatieservice die een eenvoudige manier biedt om gebruikers te verifiëren en te autoriseren voor toegang tot uw webtoepassingen en -services. Hiermee kunnen veel functies van verificatie en autorisatie uit uw code worden meegerekend. Access Control wordt voornamelijk gebruikt door ontwikkelaars en architecten van Microsoft .NET-clients, ASP.NET webtoepassingen en WCF-webservices (Windows Communication Foundation).

Gebruiksvoorbeelden voor Access Control kunnen worden onderverdeeld in drie hoofdcategorieën:

  • Verificatie bij bepaalde Microsoft-cloudservices, waaronder Azure Service Bus en Dynamics CRM. Clienttoepassingen verkrijgen tokens van Access Control om te verifiëren bij deze services om verschillende acties uit te voeren.
  • Verificatie toevoegen aan webtoepassingen, zowel aangepast als voorverpakt (zoals SharePoint). Door gebruik te maken van Access Control 'passieve' verificatie, kunnen webtoepassingen aanmelding ondersteunen met een Microsoft-account (voorheen Live ID) en met accounts van Google, Facebook, Yahoo, Azure AD en Active Directory Federation Services (AD FS).
  • Aangepaste webservices beveiligen met tokens die zijn uitgegeven door Access Control. Door gebruik te maken van 'actieve' verificatie kunnen webservices ervoor zorgen dat ze alleen toegang toestaan tot bekende clients die zijn geverifieerd met Access Control.

Elk van deze use cases en de aanbevolen migratiestrategieën worden in de volgende secties besproken.

Waarschuwing

In de meeste gevallen zijn belangrijke codewijzigingen vereist om bestaande apps en services naar nieuwere technologieën te migreren. We raden u aan onmiddellijk te beginnen met het plannen en uitvoeren van uw migratie om mogelijke storingen of downtime te voorkomen.

Access Control bevat de volgende onderdelen:

  • Een beveiligde tokenservice (STS), die verificatieaanvragen ontvangt en in ruil daarvoor beveiligingstokens uitgeeft.
  • De klassieke Azure-portal, waar u Access Control naamruimten maakt, verwijdert en in- en uitschakelt.
  • Een afzonderlijke Access Control-beheerportal, waar u Access Control naamruimten kunt aanpassen en configureren.
  • Een beheerservice, die u kunt gebruiken om de functies van de portals te automatiseren.
  • Een tokentransformatieregelengine, die u kunt gebruiken om complexe logica te definiëren voor het manipuleren van de uitvoerindeling van tokens die Access Control problemen.

Als u deze onderdelen wilt gebruiken, moet u een of meer Access Control naamruimten maken. Een naamruimte is een toegewezen exemplaar van Access Control waarmee uw toepassingen en services communiceren. Een naamruimte is geïsoleerd van alle andere Access Control klanten. Andere Access Control klanten gebruiken hun eigen naamruimten. Een naamruimte in Access Control heeft een toegewezen URL die er als volgt uitziet:

https://<mynamespace>.accesscontrol.windows.net

Alle communicatie met de STS en beheerbewerkingen wordt uitgevoerd via deze URL. U gebruikt verschillende paden voor verschillende doeleinden. Als u wilt bepalen of uw toepassingen of services gebruikmaken van Access Control, controleert u op verkeer naar https://< namespace.accesscontrol.windows.net>. Al het verkeer naar deze URL wordt verwerkt door Access Control en moet worden stopgezet.

De uitzondering hierop is verkeer naar https://accounts.accesscontrol.windows.net. Verkeer naar deze URL wordt al verwerkt door een andere service en wordt niet beïnvloed door de afschaffing van de Access Control.

Zie Access Control Service 2.0 (gearchiveerd) voor meer informatie over Access Control.

Ontdek welke van uw apps worden beïnvloed

Volg de stappen in deze sectie om erachter te komen welke van uw apps worden beïnvloed door acs-buitengebruikstelling.

ACS PowerShell downloaden en installeren

  1. Ga naar de PowerShell Gallery en download Acs.Namespaces.

  2. Installeer de module door uit te voeren

    Install-Module -Name Acs.Namespaces
    
  3. Een lijst met alle mogelijke opdrachten ophalen door uit te voeren

    Get-Command -Module Acs.Namespaces
    

    Voer het volgende uit om hulp te krijgen bij een specifieke opdracht:

     Get-Help [Command-Name] -Full
    

    waarbij [Command-Name] de naam van de ACS-opdracht is.

Uw ACS-naamruimten weergeven

  1. Maak verbinding met ACS met behulp van de cmdlet Connect-AcsAccount .

    Mogelijk moet u uitvoeren Set-ExecutionPolicy -ExecutionPolicy Bypass voordat u opdrachten kunt uitvoeren en de beheerder van deze abonnementen bent om de opdrachten uit te voeren.

  2. Geef uw beschikbare Azure-abonnementen weer met behulp van de cmdlet Get-AcsSubscription .

  3. Geef uw ACS-naamruimten weer met behulp van de cmdlet Get-AcsNamespace .

Controleren welke toepassingen worden beïnvloed

  1. Gebruik de naamruimte uit de vorige stap en ga naar https://<namespace>.accesscontrol.windows.net

    Als een van de naamruimten bijvoorbeeld contoso-test is, gaat u naar https://contoso-test.accesscontrol.windows.net

  2. Selecteer onder Vertrouwensrelatiesde optie Relying Party-toepassingen om de lijst met apps weer te geven die worden beïnvloed door acs-buitengebruikstelling.

  3. Herhaal stap 1-2 voor andere ACS-naamruimten die u hebt.

Planning voor buitengebruikstelling

Vanaf november 2017 worden alle Access Control onderdelen volledig ondersteund en operationeel. De enige beperking is dat u geen nieuwe Access Control naamruimten kunt maken via de klassieke Azure-portal.

Dit is de planning voor het afschaven van Access Control onderdelen:

  • November 2017: De Azure AD-beheerervaring in de klassieke Azure-portal is buiten gebruik gesteld. Op dit moment is naamruimtebeheer voor Access Control beschikbaar op een nieuwe, toegewezen URL: https://manage.windowsazure.com?restoreClassic=true. Gebruik deze URL om uw bestaande naamruimten weer te geven, naamruimten in en uit te schakelen en om naamruimten te verwijderen, als u dat wilt.
  • 2 april 2018: De klassieke Azure-portal is volledig buiten gebruik gesteld, wat betekent Access Control naamruimtebeheer niet meer beschikbaar is via een URL. Op dit moment kunt u uw Access Control naamruimten niet uitschakelen of inschakelen, verwijderen of opsommen. De Access Control-beheerportal is echter volledig functioneel en bevindt zich op https://<namespace>.accesscontrol.windows.net. Alle andere onderdelen van Access Control blijven normaal werken.
  • 7 november 2018: Alle Access Control onderdelen worden permanent afgesloten. Dit omvat de Access Control-beheerportal, de beheerservice, STS en de tokentransformatieregelengine. Op dit moment mislukken alle aanvragen die naar Access Control (op <namespace>.accesscontrol.windows.net) worden verzonden. U moet alle bestaande apps en services ruim voor deze tijd naar andere technologieën hebben gemigreerd.

Notitie

Een beleid schakelt naamruimten uit die gedurende een bepaalde periode geen token hebben aangevraagd. Vanaf begin september 2018 is deze periode momenteel 14 dagen van inactiviteit, maar dit wordt de komende weken verkort tot 7 dagen van inactiviteit. Als u Access Control naamruimten hebt die momenteel zijn uitgeschakeld, kunt u ACS PowerShell downloaden en installeren om de naamruimten opnieuw in te schakelen.

Migratiestrategieën

In de volgende secties worden aanbevelingen op hoog niveau beschreven voor het migreren van Access Control naar andere Microsoft-technologieën.

Clients van Microsoft-cloudservices

Elke Microsoft-cloudservice die tokens accepteert die zijn uitgegeven door Access Control ondersteunt nu ten minste één alternatieve vorm van verificatie. Het juiste verificatiemechanisme varieert voor elke service. We raden u aan de specifieke documentatie voor elke service te raadplegen voor officiële richtlijnen. Voor het gemak vindt u hier elke set documentatie:

Service Hulp
Azure Service Bus Migreren naar handtekeningen voor gedeelde toegang
Azure Service Bus Relay Migreren naar handtekeningen voor gedeelde toegang
Azure Managed Cache Migreren naar Azure Cache voor Redis
Azure DataMarket Migreren naar de API's van Azure AI-services
BizTalk Services Migreren naar de logic apps-functie van Azure App Service
Azure Media Services Migreren naar Azure AD-verificatie
Azure Backup De Azure Backup-agent upgraden

SharePoint-klanten

Klanten van SharePoint 2013, 2016 en SharePoint Online gebruiken ACS al lang voor verificatiedoeleinden in cloud-, on-premises en hybride scenario's. Sommige SharePoint-functies en gebruiksvoorbeelden worden beïnvloed door acs-buitengebruikstelling, terwijl andere niet worden beïnvloed. De onderstaande tabel bevat een overzicht van migratierichtlijnen voor enkele van de populairste SharePoint-functies die gebruikmaken van ACS:

Functie Hulp
Gebruikers verifiëren vanuit Azure AD Voorheen biedt Azure AD geen ondersteuning voor SAML 1.1-tokens die door SharePoint zijn vereist voor verificatie. ACS werd gebruikt als intermediair waardoor SharePoint compatibel is met Azure AD tokenindelingen. Nu kunt u SharePoint rechtstreeks verbinden met Azure AD met behulp van Azure AD on-premises SharePoint-app uit de galerie met apps.
App-verificatie & server-naar-serververificatie in SharePoint on-premises Niet beïnvloed door ACS-buitengebruikstelling; geen wijzigingen nodig.
Autorisatie met weinig vertrouwen voor SharePoint-invoegtoepassingen (gehoste provider en SharePoint gehost) Niet beïnvloed door ACS-buitengebruikstelling; geen wijzigingen nodig.
Hybride zoeken in SharePoint-cloud Niet beïnvloed door ACS-buitengebruikstelling; geen wijzigingen nodig.

Webtoepassingen die gebruikmaken van passieve verificatie

Voor webtoepassingen die gebruikmaken van Access Control voor gebruikersverificatie, biedt Access Control de volgende functies en mogelijkheden voor ontwikkelaars en architecten van webtoepassingen:

  • Diepgaande integratie met Windows Identity Foundation (WIF).
  • Federatie met Google-, Facebook-, Yahoo-, Azure Active Directory- en AD FS-accounts en Microsoft-accounts.
  • Ondersteuning voor de volgende verificatieprotocollen: OAuth 2.0 Draft 13, WS-Trust en Web Services Federation (WS-Federation).
  • Ondersteuning voor de volgende tokenindelingen: JSON Web Token (JWT), SAML 1.1, SAML 2.0 en Simple Web Token (SWT).
  • Een ervaring voor thuisdomeindetectie, geïntegreerd in WIF, waarmee gebruikers het type account kunnen kiezen dat ze gebruiken om zich aan te melden. Deze ervaring wordt gehost door de webtoepassing en kan volledig worden aangepast.
  • Tokentransformatie die uitgebreide aanpassing van de claims mogelijk maakt die door de webtoepassing van Access Control worden ontvangen, waaronder:
    • Claims van id-providers doorgeven.
    • Aanvullende aangepaste claims toevoegen.
    • Eenvoudige if-then-logica om claims onder bepaalde voorwaarden uit te geven.

Helaas is er niet één service die al deze equivalente mogelijkheden biedt. U moet evalueren welke mogelijkheden van Access Control u nodig hebt en vervolgens kiezen tussen het gebruik van Microsoft Entra-id, Azure Active Directory B2C (Azure AD B2C) of een andere cloudverificatieservice.

Migreren naar Microsoft Entra-id

Een pad dat u moet overwegen, is het rechtstreeks integreren van uw apps en services met Microsoft Entra-id. Microsoft Entra id is de cloudgebaseerde id-provider voor werk- of schoolaccounts van Microsoft. Microsoft Entra id is de id-provider voor Microsoft 365, Azure en nog veel meer. Het biedt vergelijkbare federatieve verificatiemogelijkheden als Access Control, maar ondersteunt niet alle Access Control functies.

Het primaire voorbeeld is federatie met sociale id-providers, zoals Facebook, Google en Yahoo. Als uw gebruikers zich aanmelden met dit type referenties, is Microsoft Entra id niet de oplossing voor u.

Microsoft Entra id biedt ook niet noodzakelijkerwijs ondersteuning voor exact dezelfde verificatieprotocollen als Access Control. Hoewel bijvoorbeeld zowel Access Control als Microsoft Entra-id OAuth ondersteunen, zijn er subtiele verschillen tussen elke implementatie. Voor verschillende implementaties moet u code wijzigen als onderdeel van een migratie.

Microsoft Entra-id biedt echter verschillende potentiële voordelen voor Access Control klanten. Het biedt systeemeigen ondersteuning voor Microsoft-werk- of schoolaccounts die worden gehost in de cloud, die vaak worden gebruikt door Access Control klanten.

Een Microsoft Entra tenant kan ook worden gefedereerd naar een of meer exemplaren van on-premises Active Directory via AD FS. Op deze manier kan uw app cloudgebruikers en gebruikers die on-premises worden gehost verifiëren. Het ondersteunt ook het WS-Federation-protocol, waardoor het relatief eenvoudig is om te integreren met een webtoepassing met behulp van WIF.

In de volgende tabel worden de functies van Access Control die relevant zijn voor webtoepassingen vergeleken met de functies die beschikbaar zijn in Microsoft Entra-id.

Op hoog niveau is Microsoft Entra-id waarschijnlijk de beste keuze voor uw migratie als u gebruikers zich alleen laat aanmelden met hun Microsoft-werk- of schoolaccount.

Mogelijkheid Access Control ondersteuning ondersteuning voor Microsoft Entra-id's
Typen accounts
Microsoft-werk- of schoolaccounts Ondersteund Ondersteund
Accounts van Windows Server Active Directory en AD FS - Ondersteund via federatie met een Microsoft Entra-tenant
- Ondersteund via directe federatie met AD FS
Alleen ondersteund via federatie met een Microsoft Entra-tenant
Accounts van andere bedrijfsidentiteitsbeheersystemen - Mogelijk via federatie met een Microsoft Entra tenant
- Ondersteund via directe federatie
Mogelijk via federatie met een Microsoft Entra-tenant
Microsoft-accounts voor persoonlijk gebruik Ondersteund Ondersteund via het OAuth-protocol Microsoft Entra v2.0, maar niet via andere protocollen
Facebook-, Google-, Yahoo-accounts Ondersteund Helemaal niet ondersteund
Compatibiliteit met protocollen en SDK
WIF Ondersteund Ondersteund, maar er zijn beperkte instructies beschikbaar
Webservices-federatie Ondersteund Ondersteund
OAuth 2.0 Ondersteuning voor Concept 13 Ondersteuning voor RFC 6749, de meest moderne specificatie
WS-Trust Ondersteund Niet ondersteund
Tokenindelingen
JWT Ondersteund in bètaversie Ondersteund
SAML 1.1 Ondersteund Preview
SAML 2.0 Ondersteund Ondersteund
SWT Ondersteund Niet ondersteund
Aanpassingen
Aanpasbare gebruikersinterface voor thuisrealmdetectie/gebruikersinterface voor het kiezen van accounts Downloadbare code die kan worden opgenomen in apps Niet ondersteund
Aangepaste certificaten voor tokenondertekening uploaden Ondersteund Ondersteund
Claims in tokens aanpassen - Invoerclaims van id-providers doorgeven
- Toegangstoken ophalen van id-provider als een claim
- Uitvoerclaims uitgeven op basis van waarden van invoerclaims
- Uitvoerclaims met constante waarden uitgeven
- Kan geen claims van federatieve id-providers doorgeven
- Kan geen toegangstoken van de id-provider ophalen als een claim
- Kan geen uitvoerclaims uitgeven op basis van waarden van invoerclaims
- Kan uitvoerclaims met constante waarden uitgeven
- Kan uitvoerclaims uitgeven op basis van eigenschappen van gebruikers die zijn gesynchroniseerd met Microsoft Entra-id
Automation
Configuratie- en beheertaken automatiseren Ondersteund via Access Control Management Service Ondersteund met behulp van de Microsoft Graph API

Als u besluit dat Microsoft Entra-id het beste migratiepad voor uw toepassingen en services is, moet u rekening houden met twee manieren om uw app te integreren met Microsoft Entra-id.

Als u WS-Federation of WIF wilt gebruiken om te integreren met Microsoft Entra-id, raden we u aan de aanpak te volgen die wordt beschreven in Federatieve eenmalige aanmelding configureren voor een toepassing die niet in de galerie is opgenomen. Het artikel verwijst naar het configureren van Microsoft Entra-id voor eenmalige aanmelding op basis van SAML, maar werkt ook voor het configureren van WS-Federation. Voor deze aanpak is een Microsoft Entra-id P1- of P2-licentie vereist. Deze aanpak heeft twee voordelen:

  • U krijgt de volledige flexibiliteit van Microsoft Entra tokenaanpassing. U kunt de claims die worden uitgegeven door Microsoft Entra-id aanpassen aan de claims die zijn uitgegeven door Access Control. Dit omvat met name de claim voor de gebruikers-id of naam-id. Als u consistente gebruikers-ID's voor uw gebruikers wilt blijven ontvangen nadat u technologieën hebt gewijzigd, moet u ervoor zorgen dat de gebruikers-id's die zijn uitgegeven door Microsoft Entra-id overeenkomen met de id's die zijn uitgegeven door Access Control.
  • U kunt een certificaat voor tokenondertekening configureren dat specifiek is voor uw toepassing en met een levensduur die u zelf bepaalt.

Notitie

Voor deze aanpak is een Microsoft Entra-id P1- of P2-licentie vereist. Als u een Access Control klant bent en u een Premium-licentie nodig hebt voor het instellen van eenmalige aanmelding voor een toepassing, neemt u contact met ons op. We bieden u graag licenties voor ontwikkelaars die u kunt gebruiken.

Een alternatieve benadering is om dit codevoorbeeld te volgen, dat iets andere instructies geeft voor het instellen van WS-Federation. Dit codevoorbeeld maakt geen gebruik van WIF, maar de ASP.NET 4.5 OWIN-middleware. De instructies voor app-registratie zijn echter geldig voor apps die gebruikmaken van WIF en vereisen geen Microsoft Entra-id P1- of P2-licentie.

Als u deze methode kiest, moet u de rollover van de ondertekeningssleutel in Microsoft Entra-id begrijpen. Bij deze benadering wordt gebruikgemaakt van de algemene ondertekeningssleutel Microsoft Entra om tokens uit te geven. Wif vernieuwt standaard niet automatisch ondertekeningssleutels. Wanneer Microsoft Entra-id de algemene ondertekeningssleutels roteert, moet uw WIF-implementatie voorbereid zijn om de wijzigingen te accepteren. Zie Belangrijke informatie over rollover van ondertekeningssleutels in Microsoft Entra-id voor meer informatie.

Als u kunt integreren met Microsoft Entra-id via het OpenID Connect- of OAuth-protocol, raden we u aan dit te doen. We hebben uitgebreide documentatie en richtlijnen voor het integreren van Microsoft Entra-id in uw webtoepassing beschikbaar in onze Microsoft Entra ontwikkelaarshandleiding.

Migreren naar Azure Active Directory B2C

Het andere migratiepad dat u moet overwegen, is Azure AD B2C. Azure AD B2C is een cloudverificatieservice waarmee ontwikkelaars, net als Access Control, hun verificatie- en identiteitsbeheerlogica kunnen uitbesteden aan een cloudservice. Het is een betaalde service (met gratis en Premium-lagen) die is ontworpen voor consumentengerichte toepassingen met maximaal miljoenen actieve gebruikers.

Net als Access Control is een van de meest aantrekkelijke functies van Azure AD B2C dat het veel verschillende soorten accounts ondersteunt. Met Azure AD B2C kunt u gebruikers aanmelden met hun Microsoft-account of Facebook-, Google-, LinkedIn-, GitHub- of Yahoo-accounts en meer. Azure AD B2C ondersteunt ook 'lokale accounts' of gebruikersnaam en wachtwoorden die gebruikers specifiek voor uw toepassing maken. Azure AD B2C biedt ook uitgebreide uitbreidbaarheid die u kunt gebruiken om uw aanmeldingsstromen aan te passen.

Azure AD B2C biedt echter geen ondersteuning voor de breedte van verificatieprotocollen en tokenindelingen die Access Control klanten mogelijk nodig hebben. U kunt Azure AD B2C ook niet gebruiken om tokens op te halen en aanvullende informatie over de gebruiker op te vragen van de id-provider, Microsoft of anderszins.

In de volgende tabel worden de functies van Access Control die relevant zijn voor webtoepassingen vergeleken met de functies die beschikbaar zijn in Azure AD B2C. Op hoog niveau is Azure AD B2C waarschijnlijk de juiste keuze voor uw migratie als uw toepassing consumentengericht is of als deze veel verschillende typen accounts ondersteunt.

Mogelijkheid Access Control ondersteuning Azure AD B2C-ondersteuning
Typen accounts
Microsoft-werk- of schoolaccounts Ondersteund Ondersteund via aangepast beleid
Accounts van Windows Server Active Directory en AD FS Ondersteund via directe federatie met AD FS Ondersteund via SAML-federatie met behulp van aangepast beleid
Accounts van andere bedrijfsidentiteitsbeheersystemen Ondersteund via directe federatie via WS-Federation Ondersteund via SAML-federatie met behulp van aangepast beleid
Microsoft-accounts voor persoonlijk gebruik Ondersteund Ondersteund
Facebook-, Google-, Yahoo-accounts Ondersteund Facebook en Google worden systeemeigen ondersteund, Yahoo ondersteund via OpenID Connect-federatie met behulp van aangepast beleid
Protocollen en SDK-compatibiliteit
Windows Identity Foundation (WIF) Ondersteund Niet ondersteund
Webservices-federatie Ondersteund Niet ondersteund
OAuth 2.0 Ondersteuning voor Concept 13 Ondersteuning voor RFC 6749, de meest moderne specificatie
WS-Trust Ondersteund Niet ondersteund
Tokenindelingen
JWT Ondersteund in bètaversie Ondersteund
SAML 1.1 Ondersteund Niet ondersteund
SAML 2.0 Ondersteund Niet ondersteund
SWT Ondersteund Niet ondersteund
Aanpassingen
Aanpasbare gebruikersinterface voor thuisrealmdetectie/gebruikersinterface voor het kiezen van accounts Downloadbare code die kan worden opgenomen in apps Volledig aanpasbare gebruikersinterface via aangepaste CSS
Aangepaste certificaten voor tokenondertekening uploaden Ondersteund Aangepaste ondertekeningssleutels, geen certificaten, ondersteund via aangepast beleid
Claims in tokens aanpassen - Invoerclaims van id-providers doorgeven
- Toegangstoken ophalen van id-provider als een claim
- Uitvoerclaims uitgeven op basis van waarden van invoerclaims
- Uitvoerclaims met constante waarden uitgeven
- Kan claims van id-providers doorgeven; aangepast beleid vereist voor sommige claims
- Kan geen toegangstoken van de id-provider ophalen als een claim
- Kan uitvoerclaims uitgeven op basis van waarden van invoerclaims via aangepast beleid
- Kan uitvoerclaims met constante waarden uitgeven via aangepast beleid
Automation
Configuratie- en beheertaken automatiseren Ondersteund via Access Control Management Service - Het maken van gebruikers die zijn toegestaan met de Microsoft Graph API
- Kan geen B2C-tenants, -toepassingen of -beleidsregels programmatisch maken

Als u besluit dat Azure AD B2C het beste migratiepad voor uw toepassingen en services is, begint u met de volgende resources:

Migreren naar Ping Identity of Auth0

In sommige gevallen vindt u mogelijk dat Microsoft Entra id en Azure AD B2C niet voldoende zijn om Access Control in uw webtoepassingen te vervangen zonder grote codewijzigingen aan te brengen. Enkele veelvoorkomende voorbeelden zijn:

  • Webtoepassingen die gebruikmaken van WIF of WS-Federation voor aanmelding met id-providers voor sociale netwerken, zoals Google of Facebook.
  • Webtoepassingen die directe federatie uitvoeren naar een enterprise-id-provider via het WS-Federation-protocol.
  • Webtoepassingen waarvoor het toegangstoken is vereist dat is uitgegeven door een sociale id-provider (zoals Google of Facebook) als een claim in de tokens die zijn uitgegeven door Access Control.
  • Webtoepassingen met complexe regels voor tokentransformatie die Microsoft Entra id of Azure AD B2C kunnen niet worden gereproduceerd.
  • Webtoepassingen met meerdere tenants die gebruikmaken van ACS voor het centraal beheren van federatie met veel verschillende id-providers

In deze gevallen kunt u overwegen om uw webtoepassing te migreren naar een andere cloudverificatieservice. We raden u aan de volgende opties te bekijken. Elk van de volgende opties biedt mogelijkheden die vergelijkbaar zijn met Access Control:

In deze afbeelding ziet u het Auth0-logo

Auth0 is een flexibele cloudidentiteitsservice die migratierichtlijnen op hoog niveau heeft gemaakt voor klanten van Access Control en die ondersteuning biedt voor bijna elke functie die ACS doet.

In deze afbeelding ziet u het Ping Identity-logo

Ping Identity biedt twee oplossingen die vergelijkbaar zijn met ACS. PingOne is een cloudidentiteitsservice die veel van dezelfde functies ondersteunt als ACS, en PingFederate is een vergelijkbaar on-premises identiteitsproduct dat meer flexibiliteit biedt. Raadpleeg de richtlijnen voor acs-buitengebruikstelling van Ping voor meer informatie over het gebruik van deze producten.

Ons doel bij het werken met Ping Identity en Auth0 is ervoor te zorgen dat alle Access Control klanten een migratiepad hebben voor hun apps en services waarmee de hoeveelheid werk die nodig is om van Access Control te gaan, wordt geminimaliseerd.

Webservices die gebruikmaken van actieve verificatie

Voor webservices die zijn beveiligd met tokens die zijn uitgegeven door Access Control, biedt Access Control de volgende functies en mogelijkheden:

  • Mogelijkheid om een of meer service-id's te registreren in uw Access Control naamruimte. Service-id's kunnen worden gebruikt om tokens aan te vragen.
  • Ondersteuning voor de OAuth WRAP- en OAuth 2.0 Draft 13-protocollen voor het aanvragen van tokens, met behulp van de volgende typen referenties:
    • Een eenvoudig wachtwoord dat wordt gemaakt voor de service-id
    • Een ondertekende SWT met behulp van een symmetrische sleutel of X509-certificaat
    • Een SAML-token dat is uitgegeven door een vertrouwde id-provider (meestal een AD FS-exemplaar)
  • Ondersteuning voor de volgende tokenindelingen: JWT, SAML 1.1, SAML 2.0 en SWT.
  • Eenvoudige regels voor tokentransformatie.

Service-id's in Access Control worden doorgaans gebruikt voor het implementeren van server-naar-server-verificatie.

Migreren naar Microsoft Entra-id

Onze aanbeveling voor dit type verificatiestroom is om te migreren naar Microsoft Entra-id. Microsoft Entra id is de cloudgebaseerde id-provider voor werk- of schoolaccounts van Microsoft. Microsoft Entra-id is de id-provider voor Microsoft 365, Azure en nog veel meer.

U kunt Microsoft Entra-id ook gebruiken voor server-naar-serververificatie met behulp van de Microsoft Entra-implementatie van de OAuth-clientreferentiestoekenning. In de volgende tabel worden de mogelijkheden van Access Control in server-naar-serververificatie vergeleken met de mogelijkheden die beschikbaar zijn in Microsoft Entra-id.

Mogelijkheid Access Control ondersteuning Microsoft Entra-id-ondersteuning
Een webservice registreren Een relying party maken in de Access Control-beheerportal Een Microsoft Entra webtoepassing maken in de Azure Portal
Een client registreren Een service-id maken in Access Control beheerportal Nog een Microsoft Entra webtoepassing maken in de Azure Portal
Protocol gebruikt - OAuth WRAP-protocol
- OAuth 2.0 Draft 13 clientreferenties verlenen
Referenties voor OAuth 2.0-client verlenen
Clientverificatiemethoden - Eenvoudig wachtwoord
- Ondertekende SWT
- SAML-token van een federatieve id-provider
- Eenvoudig wachtwoord
- Ondertekende JWT
Tokenindelingen - JWT
- SAML 1.1
- SAML 2.0
-SWT
Alleen JWT
Tokentransformatie - Aangepaste claims toevoegen
- Eenvoudige als-dan claimuitgiftelogica
Aangepaste claims toevoegen
Configuratie- en beheertaken automatiseren Ondersteund via Access Control Management Service Ondersteund met behulp van de Microsoft Graph API

Zie de volgende bronnen voor hulp bij het implementeren van server-naar-server-scenario's:

Migreren naar Ping Identity of Auth0

In sommige gevallen vindt u mogelijk dat de Microsoft Entra clientreferenties en de OAuth-toekenningsimplementatie niet voldoende zijn om Access Control in uw architectuur te vervangen zonder grote codewijzigingen. Enkele veelvoorkomende voorbeelden zijn:

  • Server-naar-serververificatie met andere tokenindelingen dan JWT's.
  • Server-naar-serververificatie met behulp van een invoertoken dat is geleverd door een externe id-provider.
  • Server-naar-serververificatie met tokentransformatieregels die Microsoft Entra id niet kunnen reproduceren.

In deze gevallen kunt u overwegen om uw webtoepassing te migreren naar een andere cloudverificatieservice. We raden u aan de volgende opties te bekijken. Elk van de volgende opties biedt mogelijkheden die vergelijkbaar zijn met Access Control:

In deze afbeelding ziet u het Auth0-logo

Auth0 is een flexibele cloudidentiteitsservice die migratierichtlijnen op hoog niveau heeft gemaakt voor klanten van Access Control en die ondersteuning biedt voor bijna elke functie die ACS doet.

In deze afbeelding ziet u het Ping Identity-logoPing Identity biedt twee oplossingen die vergelijkbaar zijn met ACS. PingOne is een cloudidentiteitsservice die veel van dezelfde functies ondersteunt als ACS, en PingFederate is een vergelijkbaar on-premises identiteitsproduct dat meer flexibiliteit biedt. Raadpleeg de richtlijnen voor acs-buitengebruikstelling van Ping voor meer informatie over het gebruik van deze producten.

Ons doel bij het werken met Ping Identity en Auth0 is ervoor te zorgen dat alle Access Control klanten een migratiepad hebben voor hun apps en services waarmee de hoeveelheid werk die nodig is om van Access Control te gaan, wordt geminimaliseerd.

Passthrough-verificatie

Voor passthrough-verificatie met willekeurige tokentransformatie is er geen gelijkwaardige Microsoft-technologie als ACS. Als dat is wat uw klanten nodig hebben, is Auth0 mogelijk degene die de dichtstbijzijnde benaderingsoplossing biedt.

Vragen, zorgen en feedback

We begrijpen dat veel Access Control klanten geen duidelijk migratiepad vinden na het lezen van dit artikel. Mogelijk hebt u hulp of hulp nodig bij het bepalen van het juiste plan. Als u uw migratiescenario's en vragen wilt bespreken, kunt u een opmerking achterlaten op deze pagina.