AD FS vervangen en het authenticatieprotocol van een applicatie wijzigen zijn afzonderlijke beslissingen. Een applicatie die al WS-Federation gebruikt, kan dat protocol mogelijk behouden terwijl zij FoxIDs als vertrouwde identity provider gaat gebruiken.
De eerste nuttige mijlpaal is één applicatie die dezelfde gebruikers herkent, de bedoelde toegang verleent en een geteste terugweg heeft. Een geslaagde aanmelding op zichzelf bewijst geen van deze resultaten.
Deze handleiding is bedoeld voor IAM- en solutionarchitecten die deze eerste migratie voorbereiden. Het voorbeeld betreft een browsergebaseerde applicatie met passieve WS-Federation, vaak afgekort tot WS-Fed. Domeinfederatie voor Microsoft 365, aanmelden bij Windows en actieve WS-Trust clients vragen om een eigen beoordeling en vallen buiten dit voorbeeld.
Scheid de applicatiemigratie van de directorymigratie
AD FS is een federatieservice; Active Directory is de directory waartegen veel AD FS installaties gebruikers authenticeren. Een wijziging van de federatievertrouwensrelatie van een applicatie verplaatst op zichzelf geen directoryaccounts of wachtwoorden.
Een mogelijk overgangspatroon behoudt AD FS aanvankelijk als authenticatiebron:
| Fase | Wat de applicatie vertrouwt | Waar de gebruiker zich authenticeert |
|---|---|---|
| Vooraf | AD FS geeft het WS-Federation token voor de applicatie uit | AD FS gebruikt de bestaande authenticatieconfiguratie |
| Eerste pilot | FoxIDs geeft een nieuw WS-Federation token voor de applicatie uit | FoxIDs stuurt de browser naar AD FS via een geconfigureerde authenticatiemethode |
| Een latere, afzonderlijke wijziging | De applicatie blijft FoxIDs vertrouwen | Een andere externe identity provider of FoxIDs Login met Directory Connector voor AD vervangt AD FS na afzonderlijke validatie |
FoxIDs ondersteunt zowel een WS-Federation applicatieregistratie aan de applicatiezijde als een WS-Federation authenticatiemethode aan de kant van AD FS. Beide kanten hebben een andere taak: de ene geeft tokens uit, de andere valideert het antwoord van de achterliggende provider.
In de pilot geeft AD FS een token uit dat voor FoxIDs bestemd is. FoxIDs valideert het en geeft een afzonderlijk token uit voor de applicatie. Het oude token wordt dus niet transparant doorgestuurd: de applicatie moet de issuer en het ondertekeningscertificaat van FoxIDs vertrouwen.
De pilot blijft afhankelijk van AD FS. Hij biedt een gecontroleerd punt om de vertrouwensrelatie en claimvereisten van de applicatie te verifiëren, maar neemt de federatieservice nog niet uit gebruik.
Twee vervolgroutes zonder AD FS
Na de pilot zijn beide routes mogelijk:
- Behoud een externe identity provider. Vervang AD FS door een andere IdP die via een ondersteunde authenticatiemethode met FoxIDs is verbonden. FoxIDs blijft de vertrouwde WS-Federation issuer van de applicatie, zodat de applicatie het protocol van de nieuwe provider niet hoeft over te nemen.
- Gebruik FoxIDs Login met Active Directory. De Directory Connector voor Active Directory valideert wachtwoorden tegen AD. Daardoor verdwijnt AD FS uit het aanmeldpad van de applicatie, terwijl AD de autoritatieve directory blijft. De handleiding voor modernisering van Active Directory login licht deze architectuur toe.
Een latere overstap naar wachtwoordvalidatie in FoxIDs is optioneel. Geslaagde aanmeldingen via de connector maken interne FoxIDs gebruikers aan of werken ze bij. Als lokaal opslaan van wachtwoorden is ingeschakeld, wordt ook een wachtwoordhash opgeslagen om die gebruikers voor te bereiden op een latere overstap. Dit is een geleidelijke migratie, geen export van alle accounts in AD; AD blijft autoritatief zolang de connector is ingeschakeld.
Welke route u ook kiest, test accountkoppelingen, claims, MFA en logout opnieuw. De onderstaande pilot met de eerste applicatie legt vast wat behouden moet blijven.
Leg vast wat de eerste applicatie daadwerkelijk gebruikt
Kies een applicatie met een eigenaar, een representatieve testomgeving en een configuratie die u kunt herstellen. Controleer of de middleware of leverancier een wijziging van de vertrouwde STS, oftewel Security Token Service, ondersteunt. Een configureerbare metadata-URL is nuttig, maar eigen issuercontroles, code voor het opzoeken van accounts en autorisatieregels zijn eveneens van belang.
Neem een fictieve declaratieapplicatie als voorbeeld. De onderstaande tabel beschrijft een illustratief doelcontract, geen geëxporteerde configuratie of verslag van een voltooide migratie.
| Contractonderdeel | Bestaand gedrag | Vereist resultaat van de pilot |
|---|---|---|
| Realm / audience | urn:example:expenses identificeert de applicatie |
De wtrealm van de applicatie komt overeen met haar FoxIDs registratie en het token is voor die applicatie bestemd |
| Reply URL | De testinstantie ontvangt antwoorden op https://expenses-test.example.org/signin-wsfed |
Alleen de bedoelde testcallback wordt geaccepteerd en gebruikt |
| Vertrouwde issuer en ondertekeningssleutels | De applicatie vertrouwt de metadata en ondertekeningssleutels van AD FS | De testinstantie vertrouwt de voor deze pilot gekozen metadata, issuer en ondertekeningssleutels van FoxIDs |
| Tokenformaat | De middleware accepteert SAML 1.1 binnen WS-Federation | Behoud dit tokenformaat, tenzij een afzonderlijk geteste wijziging nodig is |
| Account opzoeken | De claim NameIdentifier van de applicatie verwijst naar medewerker E1042 |
Hetzelfde bestaande account en dezelfde historie worden geselecteerd; er wordt geen tweede account aangemaakt |
| Autorisatie | De rol ExpenseApprover geeft toestemming om goed te keuren |
Bevoegde gebruikers behouden die toestemming; gebruikers zonder deze rol kunnen nog steeds niet goedkeuren |
| Sessiegedrag | De applicatie heeft een lokale cookie en een vastgelegd logoutbeleid | Aanmelden, verlopen van sessies, nieuwe authenticatie en logout voldoen via het nieuwe pad aan het afgesproken beleid |
Vul de tabel in met de werkelijke waarden en claimtypen van de applicatie. Controleer of het opzoeken van accounts ook de tokenissuer of de naam van de externe loginprovider gebruikt: alleen de zichtbare gebruikers-ID behouden is mogelijk niet genoeg om de accountkoppeling te behouden.
FoxIDs kan via WS-Federation SAML 1.1 of SAML 2.0 tokens uitgeven; SAML 1.1 is de standaard. Een SAML 2.0 token in een WS-Federation antwoord betekent geen overstap naar het protocol SAML 2.0 Web SSO. Houd beslissingen over het protocol en het tokenformaat gescheiden.
Leg naast de ondertekeningsvertrouwensrelatie ook encryptievereisten en vervaldatums van certificaten vast. Encryptie en handtekeningvalidatie lossen verschillende problemen op en de ondersteuning moet aansluiten bij de ontvangende applicatie. Voor ASP.NET Core noemt Microsofts handleiding voor WS-Federation middleware onder meer MetadataAddress, Wtrealm en de callbackconfiguratie als relevante integratie-instellingen. Controleer uw daadwerkelijke middleware en versie voordat u een configuratievoorbeeld toepast.
Configureer beide kanten in een testomgeving
Maak de pilot in een aparte FoxIDs omgeving en gebruik een testinstantie van de applicatie. Configureer de verbinding met AD FS als authenticatiemethode en registreer daarna de bestaande applicatie in FoxIDs met haar realm, reply URL, tokentype en vereiste claims.
Aan de kant van AD FS is FoxIDs een zelfstandige relying party. Leg deze vertrouwensrelatie vast met de metadata van de FoxIDs authenticatiemethode en bepaal welke claims en welk toegangsbeleid AD FS moet toepassen. Houd de oorspronkelijke AD FS vertrouwensrelatie van de applicatie beschikbaar gedurende het afgesproken rollbackvenster.
Ga er niet van uit dat de claimregels, toegangsbeperkingen of het MFA-beleid van de oorspronkelijke relying party automatisch voor deze nieuwe vertrouwensrelatie gelden. AD FS claimregels horen bij afzonderlijke vertrouwensrelaties, zoals beschreven in Microsofts documentatie over claimregels. Richt het vereiste gedrag op de juiste plek opnieuw in en test het.
Configureer vervolgens de testinstantie van de applicatie voor de STS-metadata en verwachte issuer van FoxIDs. Laat de validatie van issuer, audience en handtekening ingeschakeld. Gebruik de endpoints die voor de daadwerkelijke omgeving worden gegenereerd in plaats van handmatig een AD FS URL aan te passen.
Voor de passieve browserpilot is de aparte optie Microsoft Entra ID Windows sign-in niet nodig. Die functie ondersteunt een ander scenario voor domeinfederatie en actieve clients.
Volg de claims tot in de applicatie
Metadata legt endpoints en vertrouwensinformatie vast, maar niet hoe de applicatie accounts opzoekt en rechten toekent.
Bij een achterliggende WS-Federation methode ontvangt FoxIDs SAML claims, stelt deze intern voor als JWT claims en zet ze voor het applicatietoken weer om naar SAML claims. De standaardmapping zet bijvoorbeeld http://schemas.microsoft.com/ws/2008/06/identity/claims/role intern om naar role en voor WS-Federation weer terug naar het SAML claimtype. Neem het vereiste SAML claimtype voor de rol op in zowel Forward claims aan de kant van de authenticatiemethode als Issue claims aan de applicatiezijde; rollen behoren niet tot de standaardset claims.
Identifiers vragen om een aparte controle. Bij een WS-Federation authenticatiemethode met de naam adfs voegt FoxIDs een prefix toe aan de ontvangen identifier E1042, zodat deze adfs|E1042 wordt vóór verdere claimtransformaties. Als de declaratieapplicatie E1042 verwacht, definieer dan een expliciete mapping die de bestaande accountkoppeling behoudt. Verwijder prefixes niet zonder onderscheid: identieke identifiers uit verschillende bronnen zouden anders hetzelfde account kunnen selecteren.
Vergelijk een bestaande goedkeurder met een medewerker die geen declaraties mag goedkeuren. Onderzoek welke claims de applicatie daadwerkelijk gebruikt, inclusief eventuele mapping in de middleware, en test de resulterende rechten. Claimtransformaties kunnen namen en waarden wijzigen; verifieer daarom de uiteindelijke uitvoer, niet alleen de configuratie.
Gebruik de documentatie over claimtransformaties en mapping voor implementatiedetails. Stuur de claims door en geef de claims uit die de applicatie nodig heeft; een wildcard vervangt niet de beslissing over welke gegevens zij mag ontvangen.
Test toegang en weigering vóór de overstap
Spreek de verwachte resultaten vóór het testen af met de applicatie-eigenaar. Leg zowel de waargenomen tokens/claims als het gedrag van de applicatie vast. Gebruik testaccounts en houd authenticatiemateriaal buiten gedeelde rapporten.
| Test | Vereist bewijs voordat u doorgaat |
|---|---|
| Een bestaande gebruiker meldt zich aan | Het bestaande applicatieaccount, de gegevens en de historie worden geselecteerd |
| Een goedkeurder en een gewone medewerker voeren dezelfde handeling uit | De goedkeurder slaagt; de gewone medewerker wordt geweigerd |
| Het toegangsbeleid van de oude applicatie sluit een gebruiker uit | Het nieuwe pad weigert deze gebruiker nog steeds toegang |
| MFA is vereist, ook met een bestaande AD FS browsersessie | De geconfigureerde flow voldoet aan het vereiste zekerheidsniveau; alleen een geslaagde aanmelding bij de achterliggende provider geldt niet als voldoende bewijs |
| De gebruiker meldt zich af en bezoekt opnieuw een beveiligde pagina | De applicatiecookie, de AD FS sessie en de geconfigureerde logout-/cleanupflow voldoen aan het afgesproken logoutbeleid |
| Een nieuwe authenticatiepoging vereist AD FS terwijl AD FS niet beschikbaar is | De poging mislukt zonder de vereiste authenticatiebron te omzeilen; de storing is zichtbaar voor de operationeel verantwoordelijke |
| Testantwoorden bevatten een ongeldige issuer, audience of handtekening | Elk ongeldig antwoord wordt geweigerd; de validatie blijft ingeschakeld |
| De eerdere applicatieconfiguratie wordt hersteld | Een nieuwe aanmelding via het oorspronkelijke AD FS pad selecteert het juiste account en de juiste rechten |
Test het verlopen van sessies en nieuwe authenticatie afzonderlijk van een gewone geslaagde aanmelding. Een uitgeschakeld account of een gebruiker van wie een rol is verwijderd, kan nog een bestaande applicatiesessie hebben. Spreek af wanneer toegang moet eindigen en verifieer dat moment in plaats van aan te nemen dat een nieuwe federatieconfiguratie elke cookie intrekt.
FoxIDs ondersteunt WS-Federation logout en cleanupmeldingen wanneer die zijn geconfigureerd. Of alle deelnemende applicaties hun lokale sessie wissen, hangt af van hun implementatie en de daadwerkelijke browserflow. Controleer het logoutgedrag met de clients en browsers die in productie worden gebruikt.
Maak de overstap een kleine, omkeerbare beslissing
Leg vóór productie vast wie de vorige applicatieconfiguratie kan herstellen, waar die is opgeslagen en welke bevindingen tot rollback leiden. Een verkeerde accountkoppeling, onbedoelde rechten en niet-gehaalde MFA-vereisten moeten de uitrol onmiddellijk stoppen. Spreek drempels voor aanmeldfouten en operationele incidenten vooraf af in plaats van ze tijdens de wijziging te bedenken.
Migreer de afgesproken applicatiescope binnen een bewaakt tijdvenster. Een pilot per gebruiker is alleen mogelijk als de applicatie en het routeringsontwerp dat ondersteunen; gebruik anders eerst de testinstantie en behandel de productieapplicatie als de eenheid die wordt gewijzigd.
Rollback moet meer omvatten dan de metadata-URL. Herstel de eerdere vertrouwensrelatie met issuer en sleutels, de claimconfiguratie en eventuele accountkoppelingen die tijdens de pilot zijn gewijzigd. Bepaal hoe sessies die via het nieuwe pad zijn ontstaan worden beëindigd of vervangen. Het herstellen van het oude endpoint maakt wijzigingen in applicatiegegevens niet ongedaan en verwijdert die sessies niet automatisch.
Zodra deze applicatie stabiel is, bepaalt u welke afhankelijkheid als volgende wordt verwijderd. AD FS als achterliggende bron vervangen, het applicatieprotocol wijzigen naar OpenID Connect en directorygebruikers migreren zijn afzonderlijke vervolgstappen, elk met eigen tests. Als de opslag van gebruikers of wachtwoorden verandert, gebruik dan de beslisgids voor wachtwoordmigratie in plaats van dat werk aan deze pilot toe te voegen.
Het gemeten resultaat van de eerste applicatie geeft de volgende migratie een concreet vertrekpunt: een begrepen vertrouwensconfiguratie, geverifieerd gebruikers- en toegangsgedrag en een herstelprocedure die het team heeft geoefend. Gebruik de migratiehandleiding om dit bewijs te vertalen naar het bredere plan.