Anvisningar: Migrera från Azure Access Control Service
Varning
Det här innehållet gäller för den äldre Azure AD v1.0-slutpunkten. Använd Microsofts identitetsplattform för nya projekt.
Microsoft Azure Access Control Service (ACS), en tjänst för Azure Active Directory (Azure AD), tas ur bruk den 7 november 2018. Program och tjänster som för närvarande använder Access Control måste migreras helt till en annan autentiseringsmekanism vid det laget. Den här artikeln beskriver rekommendationer för aktuella kunder när du planerar att föråldrade din användning av Access Control. Om du för närvarande inte använder Access Control behöver du inte vidta några åtgärder.
Översikt
Access Control ä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. Access Control 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 Access Control kan delas upp i tre huvudkategorier:
- Autentisera till vissa Microsoft-molntjänster, inklusive Azure Service Bus och Dynamics CRM. Klientprogram hämtar token från Access Control 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). Med hjälp av Access Control "passiv" autentisering 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) (AD FS).
- Skydda anpassade webbtjänster med token som utfärdats av Access Control. 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 Access Control.
Var och en av dessa användningsfall och deras rekommenderade migreringsstrategier beskrivs i följande avsnitt.
Varning
I de flesta fall krävs betydande kodändringar för att migrera befintliga appar och tjänster till nyare tekniker. Vi rekommenderar att du omedelbart börjar planera och köra migreringen för att undvika eventuella avbrott eller driftstopp.
Access Control 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 Access Control namnområden.
- En separat Access Control hanteringsportal där du anpassar och konfigurerar Access Control namnområden.
- En hanteringstjänst som du kan använda för att automatisera portalernas funktioner.
- 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 Access Control problem.
Om du vill använda dessa komponenter måste du skapa en eller flera Access Control namnområden. Ett namnområde är en dedikerad instans av Access Control 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 Access Control 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. Om du vill avgöra om dina program eller tjänster använder Access Control övervakar du all trafik till https://< namespace.accesscontrol.windows.net>. All trafik till den här URL:en hanteras av Access Control 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 Access Control utfasning.
Mer information om Access Control 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
Gå till PowerShell-galleriet och ladda ned Acs.Namespaces.
Installera modulen genom att köra
Install-Module -Name Acs.NamespacesHämta en lista över alla möjliga kommandon genom att köra
Get-Command -Module Acs.NamespacesOm du vill få hjälp med ett specifikt kommando kör du:
Get-Help [Command-Name] -Fulldär
[Command-Name]är namnet på ACS-kommandot.
Visa en lista över dina ACS-namnområden
Anslut till ACS med cmdleten Connect-AcsAccount .
Du kan behöva köra
Set-ExecutionPolicy -ExecutionPolicy Bypassinnan du kan köra kommandon och vara administratör för dessa prenumerationer för att kunna köra kommandona.Visa en lista över dina tillgängliga Azure-prenumerationer med cmdleten Get-AcsSubscription .
Ange dina ACS-namnområden med cmdleten Get-AcsNamespace .
Kontrollera vilka program som påverkas
Använd namnområdet från föregående steg och gå till
https://<namespace>.accesscontrol.windows.netOm ett av namnrymderna till exempel är contoso-test går du till
https://contoso-test.accesscontrol.windows.netUnder Förtroenderelationer väljer du Program från förlitande part för att se listan över appar som påverkas av ACS-tillbakadragning.
Upprepa steg 1–2 för alla andra ACS-namnområden som du har.
Pensioneringsschema
Från och med november 2017 stöds och fungerar alla Access Control komponenter fullt ut. Den enda begränsningen är att du inte kan skapa nya Access Control namnområden via den klassiska Azure-portalen.
Här är schemat för inaktuella Access Control komponenter:
- November 2017: Den Azure AD administratörsupplevelsen i den klassiska Azure-portalen har dragits tillbaka. Nu är namnområdeshantering för Access Control tillgänglig på en ny dedikerad URL:
https://manage.windowsazure.com?restoreClassic=true. Använd den här URL:en om du vill visa befintliga namnområden, aktivera och inaktivera namnområden och ta bort namnområden om du väljer att göra det. - 2 april 2018: Den klassiska Azure-portalen är helt tillbakadragen, vilket innebär att Access Control namnområdeshantering inte längre är tillgänglig via någon URL. Nu kan du inte inaktivera eller aktivera, ta bort eller räkna upp Access Control namnområden. Men Access Control hanteringsportalen fungerar fullt ut och finns på
https://<namespace>.accesscontrol.windows.net. Alla andra komponenter i Access Control fortsätta att fungera normalt. - 7 november 2018: Alla Access Control komponenter stängs av permanent. Detta inkluderar Access Control-hanteringsportalen, hanteringstjänsten, STS och regelmotorn för tokentransformering. Nu misslyckas alla begäranden som skickas till Access Control (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 gången.
Anteckning
En princip inaktiverar namnrymder som inte har begärt en token under en tidsperiod. Från och med början av september 2018 är denna tidsperiod för närvarande 14 dagars inaktivitet, men detta kommer att förkortas till 7 dagars inaktivitet under de kommande veckorna. Om du har Access Control namnområden som för närvarande är inaktiverade kan du ladda ned och installera ACS PowerShell för att återaktivera namnrymderna.
Migreringsstrategier
I följande avsnitt beskrivs övergripande rekommendationer för migrering från Access Control till andra Microsoft-tekniker.
Klienter för Microsofts molntjänster
Varje Microsoft-molntjänst som accepterar token som utfärdas av Access Control 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 officiell vägledning. För enkelhetens skull tillhandahålls varje uppsättning dokumentation här:
| Tjänst | Vägledning |
|---|---|
| Azure Service Bus | Migrera till signaturer för delad åtkomst |
| Azure Service Bus Relay | Migrera till signaturer för delad åtkomst |
| Azure Managed Cache | Migrera till Azure Cache for Redis |
| Azure DataMarket | Migrera till API:er för Azure AI-tjänster |
| BizTalk Services | Migrera till Logic Apps-funktionen i Azure App Service |
| Azure Media Services | Migrera till Azure AD autentisering |
| Azure Backup | Uppgradera Azure Backup-agenten |
SharePoint-kunder
SharePoint 2013-, 2016- och SharePoint Online-kunder har länge använt ACS för autentisering i moln-, lokala och hybridscenarier. Vissa SharePoint-funktioner och användningsfall påverkas av ACS-tillbakadragning, medan andra inte gör det. I tabellen nedan sammanfattas migreringsvägledningen för några av de mest populära SharePoint-funktionerna som utnyttjar ACS:
| Funktion | Vägledning |
|---|---|
| Autentisera användare från Azure AD | Tidigare hade Azure AD inte stöd för SAML 1.1-token som krävs av SharePoint för autentisering, och ACS användes som en mellanhand som gjorde SharePoint kompatibelt med Azure AD tokenformat. Nu kan du ansluta SharePoint direkt till Azure AD med Azure AD App Gallery SharePoint lokalt. |
| Appautentisering & server-till-server-autentisering i SharePoint lokalt | Påverkas inte av ACS-pensionering; inga ändringar krävs. |
| Auktorisering med lågt förtroende för SharePoint-tillägg (värdbaserad provider och Värdbaserad SharePoint) | Påverkas inte av ACS-pensionering; inga ändringar krävs. |
| Hybridsökning i SharePoint-molnet | Påverkas inte av ACS-pensionering; inga ändringar krävs. |
Webbprogram som använder passiv autentisering
För webbprogram som använder Access Control för användarautentisering tillhandahåller Access Control följande funktioner för webbprogramutvecklare och arkitekter:
- Djupintegrering 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 webbprogrammet och är helt anpassningsbar.
- Tokentransformering som möjliggör omfattande anpassning av de anspråk som tas emot av webbprogrammet från Access Control, inklusive:
- Skicka igenom anspråk från identitetsprovidrar.
- 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 Access Control du behöver och sedan välja mellan att använda Microsoft Entra-ID, Azure Active Directory B2C (Azure AD B2C) eller någon 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. Det ger liknande federerade autentiseringsfunktioner som Access Control, men stöder inte alla Access Control funktioner.
Det primära exemplet är federation med sociala identitetsprovidrar, till exempel Facebook, Google och Yahoo. Om användarna loggar in med de här typerna 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 Access Control. Även om både Access Control 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.
Men Microsoft Entra ID ger flera potentiella fördelar för Access Control kunder. Den 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 hjälp av WIF.
I följande tabell jämförs funktionerna i Access Control 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 låter användarna logga in endast med sina Microsoft-arbets- eller skolkonton.
| Funktion | Access Control support | stöd för Microsoft Entra-ID |
|---|---|---|
| Typer av konton | ||
| Microsofts arbets- eller skolkonton | Stöds | Stöds |
| Konton från Windows Server Active Directory och AD FS | – Stöds via federation med en Microsoft Entra klientorganisation – Stöds via direkt federation med AD FS |
Stöds endast via federation med en Microsoft Entra klientorganisation |
| Konton från andra system för företagsidentitetshantering | – Möjligt via federation med en Microsoft Entra klientorganisation – Stöds via direkt federation |
Möjligt via federation med en Microsoft Entra klientorganisation |
| Microsoft-konton för personligt bruk | Stöds | Stöds via Microsoft Entra v2.0 OAuth-protokollet, men inte via andra protokoll |
| Facebook, Google, Yahoo-konton | Stöds | Stöds inte alls |
| Protokoll och SDK-kompatibilitet | ||
| WIF | Stöds | Stöd, men begränsade instruktioner är tillgängliga |
| WS-Federation | Stöds | Stöds |
| OAuth 2.0 | Stöd för utkast 13 | Stöd för RFC 6749, den modernaste specifikationen |
| WS-Trust | Stöds | Stöds inte |
| Tokenformat | ||
| JWT | Stöds i betaversionen | Stöds |
| SAML 1.1 | Stöds | Förhandsgranskning |
| SAML 2.0 | Stöds | Stöds |
| SWT | Stöds | Stöds inte |
| Anpassningar | ||
| Anpassningsbar identifiering av hemsfär/kontoplockningsgränssnitt | Nedladdningsbar kod som kan införlivas i appar | Stöds inte |
| Ladda upp anpassade certifikat för tokensignering | Stöds | Stöds |
| Anpassa anspråk i token | – Skicka indataanspråk från identitetsprovidrar – Hämta åtkomsttoken från identitetsprovidern som ett anspråk – Utfärda utgående anspråk baserat på värden för inkommande anspråk – Utfärda utdataanspråk med konstanta värden |
– Det går inte att skicka anspråk från federerade identitetsprovidrar – Det går inte att hämta åtkomsttoken från identitetsprovidern som ett anspråk – Det går inte att utfärda utgående anspråk baserat på värden för inkommande anspråk – Kan utfärda utdataanspråk med konstanta värden – Kan utfärda utdataanspråk baserat på egenskaper för användare som synkroniserats med Microsoft Entra-ID |
| Automation | ||
| Automatisera konfigurations- och hanteringsuppgifter | Stöds via Access Control Management Service | Stöds med Hjälp av Microsoft Graph API |
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 handlar om att konfigurera 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 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 anspråken som utfärdas av Microsoft Entra-ID:t så att de matchar de anspråk som utfärdas av Access Control. 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 certifikat för tokensignering som är specifikt för ditt program och med en livslängd som du styr.
Anteckning
Den här metoden kräver en Microsoft Entra ID P1- eller P2-licens. Om du är en Access Control kund och du behöver en Premium-licens för att konfigurera enkel inloggning för ett program kontaktar du oss. Vi tillhandahåller gärna utvecklarlicenser som du kan använda.
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 i stället ASP.NET OWIN-mellanprogrammet 4.5. Anvisningarna 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å förnyelsen av signeringsnyckeln i Microsoft Entra-ID. Den här metoden använder den Microsoft Entra globala signeringsnyckeln för att utfärda token. Som standard uppdaterar WIF inte signeringsnycklar automatiskt. När Microsoft Entra ID roterar sina globala signeringsnycklar måste WIF-implementeringen vara beredd att acceptera ändringarna. Mer information finns i Viktig information om förnyelse 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 överväga är Azure AD B2C. Azure AD B2C är en molnautentiseringstjänst som, precis som Access Control, gör det möjligt för utvecklare att lägga ut sin logik för autentisering och identitetshantering på 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 Access Control ä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,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.
Men Azure AD B2C stöder 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 Access Control 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.
| Funktion | Access Control support | stöd för Azure AD B2C |
|---|---|---|
| Typer av konton | ||
| Microsofts arbets- eller skolkonton | Stöds | Stöds via anpassade principer |
| Konton från Windows Server Active Directory och AD FS | Stöds via direkt federation med AD FS | Stöds via SAML-federation med hjälp av anpassade principer |
| Konton från andra system för företagsidentitetshantering | Stöds via direkt federation via WS-Federation | Stöds via SAML-federation med hjälp av anpassade principer |
| Microsoft-konton för personligt bruk | Stöds | Stöds |
| Facebook, Google, Yahoo-konton | Stöds | Facebook och Google stöds internt stöds Yahoo via OpenID Connect-federation med hjälp av anpassade principer |
| Protokoll och SDK-kompatibilitet | ||
| Windows Identity Foundation (WIF) | Stöds | Stöds inte |
| WS-Federation | Stöds | Stöds inte |
| OAuth 2.0 | Stöd för utkast 13 | Stöd för RFC 6749, den modernaste specifikationen |
| WS-Trust | Stöds | Stöds inte |
| Tokenformat | ||
| JWT | Stöds i betaversion | Stöds |
| SAML 1.1 | Stöds | Stöds inte |
| SAML 2.0 | Stöds | Stöds inte |
| SWT | Stöds | Stöds inte |
| Anpassningar | ||
| Anpassningsbar identifiering av hemsfär/användargränssnitt för kontoplockning | Nedladdningsbar kod som kan införlivas i appar | Fullständigt anpassningsbart användargränssnitt via anpassad CSS |
| Ladda upp anpassade certifikat för tokensignering | Stöds | Anpassade signeringsnycklar, inte certifikat, som stöds via anpassade principer |
| Anpassa anspråk i token | – Skicka indataanspråk från identitetsprovidrar – Hämta åtkomsttoken från identitetsprovidern som ett anspråk – Utfärda utgående anspråk baserat på värden för inkommande anspråk – Utfärda utdataanspråk med konstanta värden |
- Kan passera genom anspråk från identitetsprovidrar; anpassade principer som krävs för vissa anspråk – Det går inte att hämta åtkomsttoken från identitetsprovidern som ett anspråk – Kan utfärda utdataanspråk baserat på värden för inkommande anspråk via anpassade principer – Kan utfärda utdataanspråk med konstanta värden via anpassade principer |
| Automation | ||
| Automatisera konfigurations- och hanteringsuppgifter | Stöds via Access Control Management Service | – Skapa användare som tillåts använda Microsoft Graph API – Det går inte att skapa B2C-klienter, program eller principer programmatiskt |
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:
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 Access Control 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 identitetsprovidrar som Google eller Facebook.
- Webbprogram som utför direkt federation till en företagsidentitetsprovider via WS-Federation-protokollet.
- Webbprogram som kräver åtkomsttoken som utfärdats av en social identitetsprovider (till exempel Google eller Facebook) som ett anspråk i de token som utfärdats av Access Control.
- Webbprogram med komplexa tokentransformeringsregler som Microsoft Entra ID eller Azure AD B2C inte kan återskapa.
- Webbprogram för flera klientorganisationer som använder ACS för att centralt hantera federation till många olika identitetsprovidrar
I dessa fall kanske du vill överväga att migrera webbappen till en annan molnautentiseringstjänst. Vi rekommenderar att du utforskar följande alternativ. Vart och ett av följande alternativ erbjuder funktioner som liknar Access Control:
Auth0 är en flexibel molnidentitetstjänst som har skapat migreringsvägledning på hög nivå för kunder med 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 större flexibilitet. Mer information om hur du använder dessa produkter finns i Pings riktlinjer för ACS-tillbakadragning.
Vårt mål med att arbeta med Ping Identity och Auth0 är att se till att alla Access Control 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 Access Control.
Webbtjänster som använder aktiv autentisering
För webbtjänster som skyddas med token som utfärdats av Access Control erbjuder Access Control följande funktioner:
- Möjlighet att registrera en eller flera tjänstidentiteter i ditt Access Control namnområde. 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 ett 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.
- Enkla regler för tokentransformering.
Tjänstidentiteter i Access Control 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 i Access Control i server-till-server-autentisering med de som är tillgängliga i Microsoft Entra-ID.
| Funktion | Access Control support | stöd för Microsoft Entra-ID |
|---|---|---|
| Registrera en webbtjänst | Skapa en förlitande part i Access Control-hanteringsportalen | Skapa en Microsoft Entra webbapp i Azure Portal |
| Så här registrerar du en klient | Skapa en tjänstidentitet i Access Control-hanteringsportalen | Skapa en till Microsoft Entra webbapp i Azure Portal |
| Protokoll som används | – OAuth WRAP-protokoll – Beviljande av OAuth 2.0 Draft 13-klientautentiseringsuppgifter |
Beviljande av autentiseringsuppgifter för OAuth 2.0-klient |
| Klientautentiseringsmetoder | – Enkelt lösenord - Signerad SWT – SAML-token från en federerad identitetsprovider |
– Enkelt lösenord - Signerad JWT |
| Tokenformat | -JWT – SAML 1.1 – SAML 2.0 -SWT |
Endast JWT |
| Tokentransformering | – Lägga till anpassade anspråk – Enkel if-then-logik för anspråksutfärdande |
Lägga till anpassade anspråk |
| Automatisera konfigurations- och hanteringsuppgifter | Stöds via Access Control Management Service | Stöds med Hjälp av Microsoft Graph API |
Vägledning om hur du implementerar server-till-server-scenarier finns i följande resurser:
- Avsnittet tjänst-till-tjänst i utvecklarguiden för Microsoft Entra
- Kodexempel för daemon med hjälp av enkla autentiseringsuppgifter för lösenordsklient
- Daemon-kodexempel med certifikatklientens autentiseringsuppgifter
Migrera till Ping Identity eller Auth0
I vissa fall kan du upptäcka att Microsoft Entra klientautentiseringsuppgifter och implementeringen av OAuth-beviljandet inte räcker för att ersätta Access Control i arkitekturen 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 tokentransformeringsregler som Microsoft Entra ID inte kan återskapa.
I dessa fall kan du överväga att migrera webbappen till en annan molnautentiseringstjänst. Vi rekommenderar att du utforskar följande alternativ. Vart och ett av följande alternativ erbjuder funktioner som liknar Access Control:
Auth0 är en flexibel molnidentitetstjänst som har skapat migreringsvägledning på hög nivå för kunder med 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 större flexibilitet. Mer information om hur du använder dessa produkter finns i Pings riktlinjer för ACS-tillbakadragning.
Vårt mål med att arbeta med Ping Identity och Auth0 är att se till att alla Access Control 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 Access Control.
Direktautentisering
För direktautentisering 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.