Att ersätta AD FS och ändra en applikations autentiseringsprotokoll är två olika beslut. En applikation som redan använder WS-Federation kan eventuellt behålla protokollet samtidigt som den byter till FoxIDs som betrodd identity provider.
Den första användbara milstolpen är en applikation som känner igen samma användare, ger avsedd åtkomst och har en testad väg tillbaka. En lyckad inloggning bevisar inte i sig något av detta.
Den här guiden riktar sig till IAM- och lösningsarkitekter som förbereder den första migreringen. Den omfattar en webbläsarbaserad applikation med passiv WS-Federation, ofta förkortat WS-Fed. Microsoft 365 domänfederation, inloggning i Windows och aktiva WS-Trust klienter kräver en egen bedömning och ingår inte i exemplet.
Skilj applikationsflytten från katalogflytten
AD FS är en federationstjänst. Active Directory är den katalog som många AD FS installationer autentiserar mot. Att flytta en applikations federationstillit flyttar inte i sig katalogkonton eller lösenord.
Ett möjligt övergångsmönster behåller inledningsvis AD FS som autentiseringskälla:
| Fas | Vad applikationen litar på | Var användaren autentiseras |
|---|---|---|
| Före | AD FS utfärdar applikationens WS-Federation token | AD FS använder sin befintliga autentiseringskonfiguration |
| Första pilot | FoxIDs utfärdar en ny WS-Federation token till applikationen | FoxIDs skickar webbläsaren till AD FS via en konfigurerad autentiseringsmetod |
| En senare, separat ändring | Applikationen fortsätter att lita på FoxIDs | En annan extern identity provider eller FoxIDs Login med Directory Connector för AD ersätter AD FS efter separat validering |
FoxIDs stödjer både en WS-Federation applikationsregistrering mot applikationen och en WS-Federation autentiseringsmetod mot AD FS. Sidorna har olika uppgifter: den ena utfärdar tokens, medan den andra validerar svaret från den bakomliggande identity providern.
I piloten utfärdar AD FS en token avsedd för FoxIDs. FoxIDs validerar den och utfärdar en separat token avsedd för applikationen. Den gamla tokenen vidarebefordras alltså inte oförändrad: applikationen måste lita på FoxIDs som utfärdare och på dess signeringscertifikat.
Piloten är fortfarande beroende av AD FS. Den skapar en kontrollerad punkt där applikationens tillit och krav på claims kan verifieras, men federationstjänsten är ännu inte avvecklad.
Två vägar vidare från AD FS
Efter piloten är båda dessa vägar möjliga:
- Behåll en extern identity provider. Ersätt AD FS med en annan IdP som ansluts till FoxIDs via en autentiseringsmetod som stöds. FoxIDs förblir applikationens betrodda utfärdare av WS-Federation tokens, så applikationen behöver inte byta till den nya leverantörens protokoll.
- Använd FoxIDs Login med Active Directory. Directory Connector för Active Directory validerar lösenord mot AD. Det tar bort AD FS från applikationens inloggningsflöde samtidigt som AD behålls som auktoritativ katalog. Guiden till modernisering av Active Directory inloggning förklarar arkitekturen.
Ett senare byte till lösenordsvalidering i FoxIDs är valfritt. Lyckade inloggningar via connectorn skapar eller uppdaterar interna FoxIDs användare och lagrar, när lokal lösenordslagring är aktiverad, en lösenordshash för att förbereda dessa användare för en senare övergång. Det är gradvis migrering, inte en export av alla konton i AD. AD förblir auktoritativt medan connectorn är aktiverad.
Oavsett vilken väg ni väljer behöver kontokopplingar, claims, MFA och utloggning testas igen. Piloten med den första applikationen nedan fastställer vad som måste bevaras.
Kartlägg vad den första applikationen faktiskt använder
Välj en applikation med en ansvarig ägare, en representativ testmiljö och en konfiguration som ni kan återställa. Kontrollera att dess middleware eller leverantör stödjer byte av betrodd STS, som står för Security Token Service. En konfigurerbar metadata-URL är användbar, men anpassade kontroller av utfärdaren, kod för kontouppslagning och auktoriseringsregler spelar också roll.
Föreställ er en fiktiv utläggsapplikation. Tabellen nedan illustrerar det kontrakt som piloten ska uppfylla. Den är varken en exporterad konfiguration eller en rapport från en genomförd migrering.
| Kontraktsdel | Befintligt beteende | Krävt resultat i piloten |
|---|---|---|
| Realm / audience | urn:example:expenses identifierar applikationen |
Applikationens wtrealm matchar registreringen i FoxIDs och tokenen är avsedd för den applikationen |
| Reply URL | Testinstansen tar emot svar på https://expenses-test.example.org/signin-wsfed |
Endast avsedd callback i testmiljön accepteras och används |
| Betrodd utfärdare och signeringsnycklar | Applikationen litar på metadata och signeringsnycklar från AD FS | Testinstansen litar på de metadata, den utfärdare och de signeringsnycklar från FoxIDs som valts för piloten |
| Tokenformat | Middleware accepterar SAML 1.1 som transporteras via WS-Federation | Behåll tokenformatet om inte en separat testad ändring krävs |
| Kontouppslagning | Applikationens claim NameIdentifier identifierar medarbetaren E1042 |
Samma befintliga konto och historik väljs; inget extra konto skapas |
| Auktorisering | Rollen ExpenseApprover ger rätt att godkänna |
Behöriga användare behåller rätten; användare utan rollen kan fortfarande inte godkänna |
| Sessionsbeteende | Applikationen har en lokal cookie och en definierad utloggningspolicy | Inloggning, sessionsutgång, ny autentisering och utloggning uppfyller överenskommen policy via den nya vägen |
Använd den verkliga applikationens värden och claim-typer när ni fyller i tabellen. Kontrollera om kontouppslagningen också använder tokenens utfärdare eller namnet på den externa inloggningsleverantören: att enbart bevara synligt användar-id räcker inte alltid för att bevara kontokopplingen.
FoxIDs kan utfärda SAML 1.1 eller SAML 2.0 tokens via WS-Federation. SAML 1.1 är standard. En SAML 2.0 token i ett WS-Federation svar innebär inte ett byte till protokollet SAML 2.0 Web SSO. Hantera protokoll och tokenformat som separata beslut.
Dokumentera krypteringskrav och certifikatens utgångsdatum tillsammans med tilliten till signeringsnycklarna. Kryptering och signaturvalidering löser olika problem, och stödet måste passa den mottagande applikationen. För ASP.NET Core beskriver Microsofts guide till WS-Federation middleware MetadataAddress, Wtrealm och callback-konfigurationen som relevanta integrationsinställningar. Kontrollera er faktiska middleware och version innan ni använder ett konfigurationsexempel.
Konfigurera båda sidor i en testmiljö
Skapa piloten i en separat FoxIDs miljö och använd en testinstans av applikationen. Konfigurera anslutningen till AD FS som en autentiseringsmetod och registrera sedan den befintliga applikationen i FoxIDs med realm, reply URL, tokentyp och nödvändiga claims.
På AD FS sidan är FoxIDs en egen relying party. Upprätta tilliten med metadata från autentiseringsmetoden i FoxIDs och definiera vilka claims och vilken åtkomstpolicy AD FS ska tillämpa för den. Behåll den ursprungliga applikationens tillitsrelation till AD FS under den överenskomna rollbackperioden.
Anta inte att den ursprungliga relying partyns claim-regler, åtkomstbegränsningar eller MFA-policy automatiskt gäller för den nya tillitsrelationen. AD FS claim-regler är knutna till enskilda tillitsrelationer, som Microsoft beskriver i sin vägledning om claim-regler. Återskapa nödvändigt beteende på rätt plats och testa det.
Konfigurera sedan applikationens testinstans att använda STS-metadata från FoxIDs och förväntad utfärdare. Behåll validering av utfärdare, audience och signatur aktiverad. Använd de endpoints som genereras för den faktiska miljön i stället för att anpassa en AD FS URL för hand.
Den passiva webbläsarpiloten behöver inte det separata alternativet Microsoft Entra ID Windows sign-in. Funktionen stödjer ett annat scenario med domänfederation och aktiva klienter.
Följ claims hela vägen till applikationen
Metadata fastställer endpoints och tillitsinformation. De fastställer inte hur applikationen hittar konton eller tilldelar behörigheter.
Med en bakomliggande WS-Federation metod tar FoxIDs emot SAML claims, representerar dem internt som JWT claims och omvandlar dem tillbaka till SAML claims för applikationens token. Standardmappningen omvandlar exempelvis http://schemas.microsoft.com/ws/2008/06/identity/claims/role till role internt och tillbaka till SAML claim-typen för WS-Federation. Ta med nödvändig SAML claim-typ för rollen i både Forward claims på autentiseringsmetoden och Issue claims på applikationen. Roller ingår inte i standarduppsättningen av claims.
Identifierare behöver kontrolleras separat. För en WS-Federation autentiseringsmetod med namnet adfs lägger FoxIDs till ett prefix framför inkommande E1042, så att det blir adfs|E1042, före efterföljande claim transforms. Om utläggsapplikationen förväntar sig E1042 behöver ni definiera en uttrycklig mappning som bevarar den befintliga kontokopplingen. Ta inte bort prefix utan eftertanke: identiska identifierare från olika källor kan annars välja samma konto.
Jämför en befintlig godkännare med en medarbetare som inte får godkänna utlägg. Granska de claims som applikationen faktiskt använder, inklusive eventuell mappning i middleware, och testa de resulterande behörigheterna. Claim transforms kan ändra namn och värden, så verifiera det slutliga resultatet i stället för enbart konfigurationen.
Använd dokumentationen om claim transforms och mappning för implementeringsdetaljer. Vidarebefordra och utfärda de claims applikationen behöver. Ett jokertecken ersätter inte beslutet om vilka data den ska ta emot.
Testa både åtkomst och nekad åtkomst före övergången
Kom överens om förväntade resultat med applikationsägaren före testningen. Dokumentera både observerade tokens/claims och applikationens beteende. Använd testkonton och håll autentiseringsmaterial borta från delade rapporter.
| Test | Underlag som krävs innan ni fortsätter |
|---|---|
| En befintlig användare loggar in | Det befintliga applikationskontot med dess data och historik väljs |
| En godkännare och en vanlig medarbetare utför samma åtgärd | Godkännaren lyckas; den vanliga medarbetaren nekas |
| En användare utesluts av den gamla applikationens åtkomstpolicy | Den nya vägen nekar fortfarande användaren åtkomst |
| MFA krävs, även med en befintlig webbläsarsession hos AD FS | Det konfigurerade flödet uppfyller den säkerhetsnivå som krävs; en lyckad inloggning hos källan godtas inte i sig som tillräckligt bevis |
| Användaren loggar ut och besöker en skyddad sida igen | Applikationscookien, sessionen hos AD FS och det konfigurerade utloggnings-/cleanup-flödet uppfyller överenskommen utloggningspolicy |
| Ett nytt autentiseringsförsök kräver AD FS medan AD FS är otillgängligt | Försöket misslyckas utan att kringgå den autentiseringskälla som krävs; felet är synligt för den driftansvarige |
| Testsvar innehåller ogiltig utfärdare, audience eller signatur | Varje ogiltigt svar avvisas; valideringen förblir aktiverad |
| Den tidigare applikationskonfigurationen återställs | En ny inloggning via den ursprungliga AD FS vägen väljer rätt konto och behörigheter |
Testa sessionsutgång och ny autentisering separat från en vanlig lyckad inloggning. Ett inaktiverat konto eller en användare som förlorat en roll kan fortfarande ha en befintlig applikationssession. Kom överens om när åtkomsten måste upphöra och verifiera tidpunkten i stället för att anta att en ny federationskonfiguration återkallar alla cookies.
FoxIDs stödjer WS-Federation utloggning och cleanup-notifikationer när de är konfigurerade. Om varje deltagande applikation rensar sin lokala session beror på dess implementation och det faktiska webbläsarflödet. Kontrollera utloggningsbeteendet med de klienter och webbläsare som används i produktion.
Gör övergången till ett litet, reversibelt beslut
Dokumentera före produktionssättningen vem som kan återställa den tidigare applikationskonfigurationen, var den finns och vilka fynd som utlöser rollback. Felaktig kontokoppling, oavsiktliga behörigheter och ouppfyllda MFA-krav bör stoppa utrullningen omedelbart. Bestäm gränsvärden för inloggningsfel och driftincidenter i förväg i stället för under ändringen.
Genomför den överenskomna applikationsflytten under ett övervakat tidsfönster. En pilot användare för användare är bara möjlig om applikationen och routingdesignen stödjer det. Använd annars testinstansen först och behandla produktionsapplikationen som den enhet som flyttas.
Rollback måste omfatta mer än metadata-URL:en. Återställ tidigare tillit till utfärdare och nycklar, konfigurationen av claims och eventuella kontokopplingar som ändrats under piloten. Bestäm hur sessioner som upprättats via den nya vägen ska avslutas eller ersättas. Att återställa den gamla endpointen ångrar inte ändringar i applikationsdata och tar inte automatiskt bort dessa sessioner.
När applikationen fungerar stabilt väljer ni vilket beroende som ska tas bort härnäst. Att ersätta AD FS som bakomliggande källa, ändra applikationens protokoll till OpenID Connect och migrera kataloganvändare är separata efterföljande ändringar med egna tester. Om lagringen av användare eller lösenord ska ändras, använd beslutsguiden för lösenordsmigrering i stället för att lägga det arbetet i piloten.
Det uppmätta resultatet från den första applikationen ger nästa migrering en konkret utgångspunkt: en förstådd tillitskonfiguration, verifierat användar- och åtkomstbeteende samt en återställningsprocedur som teamet har övat. Använd migreringsvägledningen för att omsätta underlaget i en bredare plan.