Gör så här: Migrera från Azure Access Control Service

Microsoft Azure Access Control Service (ACS), en tjänst i Azure Active Directory (Azure AD), dras tillbaka den 7 november 2018. Program och tjänster som för närvarande använder åtkomstkontroll måste migreras helt till en annan autentiseringsmekanism vid det laget. I den här artikeln beskrivs rekommendationer för nuvarande kunder när du planerar att avveckla din användning av åtkomstkontroll. Om du för närvarande inte använder åtkomstkontroll behöver du inte vidta några åtgärder.

Översikt

Åtkomstkontroll är en molnautentiseringstjänst som erbjuder ett enkelt sätt att autentisera och auktorisera användare för åtkomst till dina webbprogram och tjänster. Det gör att många funktioner för autentisering och auktorisering kan räknas ut ur koden. Åtkomstkontroll används främst av utvecklare och arkitekter av Microsoft .NET-klienter, ASP.NET webbprogram och WCF-webbtjänster (Windows Communication Foundation).

Användningsfall för åtkomstkontroll kan delas in i tre huvudkategorier:

• Autentisera till vissa Microsoft-molntjänster, inklusive Azure Service Bus och Dynamics CRM. Klientprogram hämtar token från Åtkomstkontroll för att autentisera till dessa tjänster för att utföra olika åtgärder.
• Lägga till autentisering i webbprogram, både anpassade och förpaketerade (till exempel SharePoint). Genom att använda "passiv" autentisering för åtkomstkontroll kan webbprogram stödja inloggning med ett Microsoft-konto (tidigare live-ID) och med konton från Google, Facebook, Yahoo, Azure AD och Active Directory Federation Services (AD FS).
• Skydda anpassade webbtjänster med token som utfärdats av Åtkomstkontroll. Med hjälp av "aktiv" autentisering kan webbtjänster se till att de endast tillåter åtkomst till kända klienter som har autentiserats med åtkomstkontroll.

Var och en av dessa användningsfall och deras rekommenderade migreringsstrategier beskrivs i följande avsnitt.

Åtkomstkontroll har följande komponenter:

• En säker tokentjänst (STS), som tar emot autentiseringsbegäranden och utfärdar säkerhetstoken i gengäld.
• Den klassiska Azure-portalen, där du skapar, tar bort och aktiverar och inaktiverar namnområden för åtkomstkontroll.
• En separat åtkomstkontrollhanteringsportal där du anpassar och konfigurerar namnområden för åtkomstkontroll.
• En hanteringstjänst som du kan använda för att automatisera funktionerna i portalerna.
• En regelmotor för tokentransformering som du kan använda för att definiera komplex logik för att ändra utdataformatet för token som har problem med åtkomstkontroll.

Om du vill använda dessa komponenter måste du skapa en eller flera namnområden för åtkomstkontroll. Ett namnområde är en dedikerad instans av åtkomstkontroll som dina program och tjänster kommunicerar med. Ett namnområde är isolerat från alla andra Access Control-kunder. Andra Access Control-kunder använder sina egna namnområden. Ett namnområde i Åtkomstkontroll har en dedikerad URL som ser ut så här:

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

All kommunikation med STS och hanteringsåtgärder utförs på den här URL:en. Du använder olika sökvägar för olika syften. För att avgöra om dina program eller tjänster använder åtkomstkontroll övervakar du all trafik till https://< namespace.accesscontrol.windows.net>. All trafik till den här URL:en hanteras av Åtkomstkontroll och måste avbrytas.

Undantaget är all trafik till https://accounts.accesscontrol.windows.net. Trafik till den här URL:en hanteras redan av en annan tjänst och påverkas inte av utfasningen av åtkomstkontroll.

Mer information om åtkomstkontroll finns i Access Control Service 2.0 (arkiverad).

Ta reda på vilka av dina appar som påverkas

Följ stegen i det här avsnittet för att ta reda på vilka av dina appar som påverkas av ACS-tillbakadragning.

Ladda ned och installera ACS PowerShell

1. Gå till PowerShell-galleriet och ladda ned Acs.Namespaces.

2. Installera modulen genom att köra

   Install-Module -Name Acs.Namespaces
   

3. Hämta en lista över alla möjliga kommandon genom att köra

   Get-Command -Module Acs.Namespaces
   

   Om du vill få hjälp med ett specifikt kommando kör du:

    Get-Help [Command-Name] -Full
   

   där [Command-Name] är namnet på ACS-kommandot.

Visa en lista över dina ACS-namnområden

1. Anslut till ACS med cmdleten Connect-AcsAccount .

   Du kan behöva köra Set-ExecutionPolicy -ExecutionPolicy Bypass innan du kan köra kommandon och vara administratör för dessa prenumerationer för att kunna köra kommandona.

2. Visa en lista över dina tillgängliga Azure-prenumerationer med cmdleten Get-AcsSubscription .

3. Visa en lista över dina ACS-namnområden med cmdleten Get-AcsNamespace .

Kontrollera vilka program som påverkas

1. Använd namnområdet från föregående steg och gå till https://<namespace>.accesscontrol.windows.net

   Om ett av namnrymderna till exempel är contoso-test går du till https://contoso-test.accesscontrol.windows.net

2. Under Förtroenderelationer väljer du Förlitande partprogram för att se listan över appar som påverkas av ACS-tillbakadragning.

3. Upprepa steg 1–2 för alla andra ACS-namnområden som du har.

Pensionsschema

Från och med november 2017 stöds och används alla access control-komponenter fullt ut. Den enda begränsningen är att du inte kan skapa nya namnområden för åtkomstkontroll via den klassiska Azure-portalen.

Här är schemat för att avveckla åtkomstkomponenter:

• November 2017: Azure AD-administratörsupplevelsen i den klassiska Azure-portalen har dragits tillbaka. I det här läget är namnområdeshantering för åtkomstkontroll tillgänglig på en ny dedikerad URL: https://manage.windowsazure.com?restoreClassic=true. Använd den här URL:en om du vill visa dina befintliga namnområden, aktivera och inaktivera namnområden och ta bort namnområden om du vill.
• 2 april 2018: Den klassiska Azure-portalen är helt tillbakadragen, vilket innebär att namnområdeshantering för åtkomstkontroll inte längre är tillgänglig via någon URL. Nu kan du inte inaktivera eller aktivera, ta bort eller räkna upp dina namnområden för åtkomstkontroll. Åtkomstkontrollhanteringsportalen fungerar dock fullt ut och finns på https://<namespace>.accesscontrol.windows.net. Alla andra komponenter i Åtkomstkontroll fortsätter att fungera normalt.
• 7 november 2018: Alla åtkomstkontrollkomponenter stängs av permanent. Detta inkluderar hanteringsportalen för åtkomstkontroll, hanteringstjänsten, STS och regelmotorn för tokentransformering. I det här läget misslyckas alla begäranden som skickas till Åtkomstkontroll (finns på <namespace>.accesscontrol.windows.net) . Du bör ha migrerat alla befintliga appar och tjänster till andra tekniker långt före den här tiden.

Migreringsstrategier

I följande avsnitt beskrivs rekommendationer på hög nivå för migrering från åtkomstkontroll till andra Microsoft-tekniker.

Klienter för Microsofts molntjänster

Varje Microsoft-molntjänst som accepterar token som utfärdas av Åtkomstkontroll stöder nu minst en alternativ form av autentisering. Rätt autentiseringsmekanism varierar för varje tjänst. Vi rekommenderar att du läser den specifika dokumentationen för varje tjänst för att få officiell vägledning. För enkelhetens skull tillhandahålls varje uppsättning dokumentation här:

SharePoint-kunder

SharePoint 2013-, 2016- och SharePoint Online-kunder har länge använt ACS för autentiseringsändamål i moln-, lokala och hybridscenarier. Vissa SharePoint-funktioner och användningsfall påverkas av ACS-tillbakadragning, medan andra inte gör det. Tabellen nedan sammanfattar migreringsvägledningen för några av de mest populära SharePoint-funktionerna som utnyttjar ACS:

Webbprogram som använder passiv autentisering

För webbprogram som använder åtkomstkontroll för användarautentisering tillhandahåller Åtkomstkontroll följande funktioner till webbprogramutvecklare och arkitekter:

• Djup integrering med Windows Identity Foundation (WIF).
• Federation med Google-, Facebook-, Yahoo-, Azure Active Directory- och AD FS-konton samt Microsoft-konton.
• Stöd för följande autentiseringsprotokoll: OAuth 2.0 Draft 13, WS-Trust och Web Services Federation (WS-Federation).
• Stöd för följande tokenformat: JSON Web Token (JWT), SAML 1.1, SAML 2.0 och Simple Web Token (SWT).
• En identifieringsupplevelse för hemsfären, integrerad i WIF, som gör det möjligt för användare att välja vilken typ av konto de använder för att logga in. Den här upplevelsen hanteras av webbappen och är helt anpassningsbar.
• Tokentransformering som möjliggör omfattande anpassning av de anspråk som tas emot av webbprogrammet från Åtkomstkontroll, inklusive:
  • Vidarebefordra anspråk från identitetsleverantörer.
  • Lägga till ytterligare anpassade anspråk.
  • Enkel om-då-logik för att utfärda anspråk under vissa villkor.

Tyvärr finns det inte en enda tjänst som erbjuder alla dessa motsvarande funktioner. Du bör utvärdera vilka funktioner i åtkomstkontroll du behöver och sedan välja mellan att använda Microsoft Entra-ID, Azure Active Directory B2C (Azure AD B2C) eller en annan molnautentiseringstjänst.

Migrera till Microsoft Entra-ID

En väg att överväga är att integrera dina appar och tjänster direkt med Microsoft Entra-ID. Microsoft Entra ID är den molnbaserade identitetsprovidern för Microsofts arbets- eller skolkonton. Microsoft Entra ID är identitetsprovidern för Microsoft 365, Azure och mycket mer. Den har liknande federerade autentiseringsfunktioner som åtkomstkontroll, men stöder inte alla funktioner för åtkomstkontroll.

Det primära exemplet är federation med sociala identitetsprovidrar, till exempel Facebook, Google och Yahoo. Om dina användare loggar in med dessa typer av autentiseringsuppgifter är Microsoft Entra-ID inte lösningen för dig.

Microsoft Entra-ID stöder inte heller nödvändigtvis exakt samma autentiseringsprotokoll som åtkomstkontroll. Även om både Åtkomstkontroll och Microsoft Entra-ID stöder OAuth finns det till exempel subtila skillnader mellan varje implementering. Olika implementeringar kräver att du ändrar kod som en del av en migrering.

Microsoft Entra-ID ger dock flera potentiella fördelar för Access Control-kunder. Det har inbyggt stöd för Microsofts arbets- eller skolkonton i molnet, som ofta används av Access Control-kunder.

En Microsoft Entra-klientorganisation kan också federeras till en eller flera instanser av lokal Active Directory via AD FS. På så sätt kan din app autentisera molnbaserade användare och användare som finns lokalt. Det stöder också WS-Federation protokoll, vilket gör det relativt enkelt att integrera med ett webbprogram med wif.

I följande tabell jämförs funktionerna i Åtkomstkontroll som är relevanta för webbprogram med de funktioner som är tillgängliga i Microsoft Entra-ID.

På hög nivå är Microsoft Entra-ID förmodligen det bästa valet för migreringen om du endast låter användare logga in med sina Microsoft-arbets- eller skolkonton.

Om du bestämmer dig för att Microsoft Entra-ID är den bästa migreringsvägen för dina program och tjänster bör du vara medveten om två sätt att integrera din app med Microsoft Entra-ID.

Om du vill använda WS-Federation eller WIF för att integrera med Microsoft Entra-ID rekommenderar vi att du följer den metod som beskrivs i Konfigurera federerad enkel inloggning för ett program som inte är ett galleriprogram. Artikeln refererar till konfiguration av Microsoft Entra-ID för SAML-baserad enkel inloggning, men fungerar även för att konfigurera WS-Federation. För att följa den här metoden krävs en Microsoft Entra ID P1- eller P2-licens. Den här metoden har två fördelar:

• Du får fullständig flexibilitet för anpassning av Microsoft Entra-token. Du kan anpassa de anspråk som utfärdas av Microsoft Entra-ID:t så att de matchar de anspråk som utfärdas av Åtkomstkontroll. Detta omfattar särskilt anspråket för användar-ID eller namnidentifierare. Om du vill fortsätta att ta emot konsekventa användar-IDentifiers för dina användare när du har ändrat teknik kontrollerar du att användar-ID:n som utfärdats av Microsoft Entra ID matchar de som utfärdats av Access Control.
• Du kan konfigurera ett tokensigneringscertifikat som är specifikt för ditt program och med en livslängd som du styr.

En annan metod är att följa det här kodexemplet, som ger lite olika instruktioner för att konfigurera WS-Federation. Det här kodexemplet använder inte WIF, utan snarare ASP.NET 4.5 OWIN-mellanprogram. Instruktionerna för appregistrering är dock giltiga för appar som använder WIF och kräver ingen Microsoft Entra ID P1- eller P2-licens.

Om du väljer den här metoden måste du förstå rollover för signeringsnyckeln i Microsoft Entra-ID. Den här metoden använder den globala signeringsnyckeln Microsoft Entra för att utfärda token. Som standard uppdaterar WIF inte signeringsnycklar automatiskt. När Microsoft Entra-ID:t roterar sina globala signeringsnycklar måste wif-implementeringen vara beredd att acceptera ändringarna. För mer information, se Viktig information om byte av signeringsnyckel i Microsoft Entra ID.

Om du kan integrera med Microsoft Entra-ID via OpenID Connect- eller OAuth-protokollen rekommenderar vi att du gör det. Vi har omfattande dokumentation och vägledning om hur du integrerar Microsoft Entra-ID i ditt webbprogram som finns i vår Microsoft Entra-utvecklarguide.

Migrera till Azure Active Directory B2C

Den andra migreringsvägen att tänka på är Azure AD B2C. Azure AD B2C är en molnautentiseringstjänst som, till exempel Åtkomstkontroll, gör det möjligt för utvecklare att outsourca sin logik för autentisering och identitetshantering till en molntjänst. Det är en betaltjänst (med kostnadsfria nivåer och premiumnivåer) som är utformad för konsumentinriktade program som kan ha upp till miljontals aktiva användare.

Precis som åtkomstkontroll är en av de mest attraktiva funktionerna i Azure AD B2C att den stöder många olika typer av konton. Med Azure AD B2C kan du logga in användare med hjälp av deras Microsoft-konto eller Facebook- eller Google-, LinkedIn-, GitHub- eller Yahoo-konton med mera. Azure AD B2C stöder även "lokala konton" eller användarnamn och lösenord som användarna skapar specifikt för ditt program. Azure AD B2C ger också omfattande utökningsbarhet som du kan använda för att anpassa dina inloggningsflöden.

Azure AD B2C stöder dock inte bredden av autentiseringsprotokoll och tokenformat som Access Control-kunder kan kräva. Du kan inte heller använda Azure AD B2C för att hämta token och fråga efter ytterligare information om användaren från identitetsprovidern, Microsoft eller på annat sätt.

I följande tabell jämförs funktionerna i Åtkomstkontroll som är relevanta för webbprogram med de som är tillgängliga i Azure AD B2C. På hög nivå är Azure AD B2C förmodligen rätt val för migreringen om ditt program är konsumentanslutet, eller om det stöder många olika typer av konton.

Om du bestämmer dig för att Azure AD B2C är den bästa migreringsvägen för dina program och tjänster börjar du med följande resurser:

• Dokumentation om Azure AD B2C
• Anpassade principer för Azure AD B2C
• Priser för Azure AD B2C

Migrera till Ping Identity eller Auth0

I vissa fall kan du upptäcka att Microsoft Entra-ID och Azure AD B2C inte räcker för att ersätta åtkomstkontroll i dina webbprogram utan att göra större kodändringar. Några vanliga exempel kan vara:

• Webbprogram som använder WIF eller WS-Federation för inloggning med sociala identitetsleverantörer som Google eller Facebook.
• Webbprogram som utför direkt federation till en företagsidentitetsprovider via WS-Federation protokollet.
• Webbapplikationer som kräver åtkomsttokenen utfärdad av en social identitetsleverantör (till exempel Google eller Facebook) som ett anspråk i tokenen utfärdade av Åtkomstkontroll.
• Webbprogram med komplexa regler för tokentransformering som Microsoft Entra-ID eller Azure AD B2C inte kan återskapa.
• Webbapplikationer för flera användare som använder ACS för att centralt hantera federation till många olika identitetsleverantörer

I dessa fall kanske du vill överväga att migrera webbprogrammet till en annan molnautentiseringstjänst. Vi rekommenderar att du utforskar följande alternativ. Vart och ett av följande alternativ erbjuder funktioner som liknar åtkomstkontroll:

Auth0 är en flexibel molnidentitetstjänst som har skapat migrationsvägledning på hög nivå för kunder av Access Control och som stöder nästan alla funktioner som ACS gör.

Ping Identity erbjuder två lösningar som liknar ACS. PingOne är en molnidentitetstjänst som stöder många av samma funktioner som ACS, och PingFederate är en liknande lokal identitetsprodukt som ger mer flexibilitet. Mer information om hur du använder dessa produkter finns i Pings riktlinjer för ACS-pensionering.

Vårt mål med att arbeta med Ping Identity och Auth0 är att se till att alla Åtkomstkontroll-kunder har en migreringsväg för sina appar och tjänster som minimerar mängden arbete som krävs för att flytta från åtkomstkontroll.

Webbtjänster som använder aktiv autentisering

För webbtjänster som skyddas med token som utfärdats av Åtkomstkontroll erbjuder Åtkomstkontroll följande funktioner:

• Möjlighet att registrera en eller flera tjänstidentiteter i ditt namnområde för åtkomstkontroll. Tjänstidentiteter kan användas för att begära token.
• Stöd för OAuth WRAP- och OAuth 2.0 Draft 13-protokoll för att begära token med hjälp av följande typer av autentiseringsuppgifter:
  • Ett enkelt lösenord som skapas för tjänstidentiteten
  • En signerad SWT med hjälp av en symmetrisk nyckel eller X509-certifikat
  • En SAML-token utfärdad av en betrodd identitetsprovider (vanligtvis en AD FS-instans)
• Stöd för följande tokenformat: JWT, SAML 1.1, SAML 2.0 och SWT.
• Regler för enkel tokentransformering.

Tjänstidentiteter i Åtkomstkontroll används vanligtvis för att implementera server-till-server-autentisering.

Migrera till Microsoft Entra-ID

Vår rekommendation för den här typen av autentiseringsflöde är att migrera till Microsoft Entra-ID. Microsoft Entra ID är den molnbaserade identitetsprovidern för Microsofts arbets- eller skolkonton. Microsoft Entra ID är identitetsprovidern för Microsoft 365, Azure och mycket mer.

Du kan också använda Microsoft Entra-ID för server-till-server-autentisering med hjälp av Microsoft Entra-implementeringen av OAuth-klientens autentiseringsuppgifter. I följande tabell jämförs funktionerna för åtkomstkontroll i server-till-server-autentisering med de som är tillgängliga i Microsoft Entra-ID.

Vägledning om hur du implementerar server-till-server-scenarier finns i följande resurser:

• Tjänst-till-tjänst-avsnittet i Microsoft Entra-utvecklarguiden
• Exempel på daemonkod med hjälp av enkla autentiseringsuppgifter för lösenordsklient
• Daemon-kodexempel med certifikatklientautentiseringsuppgifter

Migrera till Ping Identity eller Auth0

I vissa fall kan du upptäcka att Microsoft Entra-klientens autentiseringsuppgifter och OAuth-beviljandeimplementeringen inte räcker för att ersätta åtkomstkontroll i din arkitektur utan större kodändringar. Några vanliga exempel kan vara:

• Server-till-server-autentisering med andra tokenformat än JWTs.
• Server-till-server-autentisering med hjälp av en indatatoken som tillhandahålls av en extern identitetsprovider.
• Server-till-server-autentisering med regler för tokentransformering som Microsoft Entra-ID inte kan återskapa.

I dessa fall kan du överväga att migrera webbprogrammet till en annan molnautentiseringstjänst. Vi rekommenderar att du utforskar följande alternativ. Vart och ett av följande alternativ erbjuder funktioner som liknar åtkomstkontroll:

Auth0 är en flexibel molnidentitetstjänst som har skapat vägledning på hög nivå för kunder med åtkomstkontroll och som stöder nästan alla funktioner som ACS gör.

Ping Identity erbjuder två lösningar som liknar ACS. PingOne är en molnidentitetstjänst som stöder många av samma funktioner som ACS, och PingFederate är en liknande lokal identitetsprodukt som ger mer flexibilitet. Mer information om hur du använder dessa produkter finns i Pings riktlinjer för ACS-pensionering.

Vårt mål med att arbeta med Ping Identity och Auth0 är att se till att alla Åtkomstkontroll-kunder har en migreringsväg för sina appar och tjänster som minimerar mängden arbete som krävs för att flytta från åtkomstkontroll.

Autentisering med pass-through

För genomströmningsautentisering med godtycklig tokentransformering finns det ingen motsvarande Microsoft-teknik för ACS. Om det är vad dina kunder behöver kan Auth0 vara den som tillhandahåller den närmaste uppskattningslösningen.

Frågor, problem och feedback

Vi förstår att många Access Control-kunder inte hittar någon tydlig migreringsväg när de har läst den här artikeln. Du kan behöva hjälp eller vägledning för att fastställa rätt plan. Om du vill diskutera dina migreringsscenarier och frågor kan du lämna en kommentar på den här sidan.