At udskifte AD FS og ændre en applikations autentifikationsprotokol er to forskellige beslutninger. En applikation, der allerede bruger WS-Federation, kan muligvis beholde protokollen, mens den skifter til FoxIDs som sin betroede identity provider.
Den første nyttige milepæl er én applikation, som genkender de samme brugere, giver den tilsigtede adgang og har en afprøvet vej tilbage. Et vellykket login dokumenterer ikke i sig selv nogen af de tre ting.
Denne guide er til IAM- og løsningsarkitekter, der forbereder den første migration. Den handler om en browserbaseret applikation med passiv WS-Federation, ofte forkortet WS-Fed. Microsoft 365 domænefederation, login på Windows og aktive WS-Trust klienter kræver deres egen vurdering og indgår ikke i eksemplet.
Adskil flytningen af applikationen fra flytningen af kataloget
AD FS er en federationstjeneste. Active Directory er det katalog, som mange AD FS installationer autentificerer mod. Når en applikation skifter federationstillid, flytter det ikke i sig selv katalogets konti eller passwords.
En mulig overgang er at beholde AD FS som autentifikationskilde i første omgang:
| Fase | Hvad applikationen stoler på | Hvor brugeren autentificeres |
|---|---|---|
| Før | AD FS udsteder applikationens WS-Federation token | AD FS bruger sin eksisterende autentifikationsopsætning |
| Første pilot | FoxIDs udsteder et nyt WS-Federation token til applikationen | FoxIDs sender browseren videre til AD FS via en konfigureret autentifikationsmetode |
| En senere, særskilt ændring | Applikationen stoler fortsat på FoxIDs | En anden ekstern identity provider eller FoxIDs Login med Directory Connector til AD erstatter AD FS efter særskilt validering |
FoxIDs understøtter både en WS-Federation applikationsregistrering mod applikationen og en WS-Federation autentifikationsmetode mod AD FS. De to sider har forskellige opgaver: Den ene udsteder tokens, mens den anden validerer svaret fra den eksterne identity provider.
I piloten udsteder AD FS et token beregnet til FoxIDs. FoxIDs validerer det og udsteder et separat token beregnet til applikationen. Det gamle token bliver altså ikke blot videresendt: Applikationen skal stole på FoxIDs' issuer og signeringscertifikat.
Piloten afhænger stadig af AD FS. Den giver et kontrolleret sted at verificere applikationens tillid og krav til claims, men federationstjenesten er endnu ikke udfaset.
To veje videre fra AD FS
Efter piloten er begge disse veje mulige:
- Behold en ekstern identity provider. Erstat AD FS med en anden IdP, der forbindes til FoxIDs gennem en understøttet autentifikationsmetode. FoxIDs er fortsat applikationens betroede udsteder af WS-Federation tokens, så applikationen ikke behøver at skifte til den nye udbyders protokol.
- Brug FoxIDs Login med Active Directory. Directory Connector til Active Directory validerer passwords mod AD. Dermed fjernes AD FS fra applikationens loginforløb, mens AD bevares som det autoritative katalog. Guiden til modernisering af Active Directory login forklarer arkitekturen.
Et senere skift til passwordvalidering i FoxIDs er valgfrit. Vellykkede login gennem connectoren opretter eller opdaterer interne FoxIDs brugere og gemmer, når lokal passwordlagring er aktiveret, et passwordhash, som forbereder de pågældende brugere til et senere skift. Det er gradvis migration, ikke en eksport af alle konti i AD. AD er fortsat autoritativt, mens connectoren er aktiveret.
Uanset hvilken vej I vælger, skal kontokobling, claims, MFA og logout testes igen. Piloten med den første applikation nedenfor fastlægger, hvad der skal bevares.
Kortlæg, hvad den første applikation faktisk bruger
Vælg en applikation med en ansvarlig ejer, et repræsentativt testmiljø og en konfiguration, I kan gendanne. Kontrollér, at middleware eller leverandør understøtter at skifte den betroede STS, som står for Security Token Service. En konfigurerbar metadata-URL er nyttig, men egne issuer-kontroller, kode til kontoopslag og autorisationsregler har også betydning.
Forestil jer en fiktiv applikation til udlæg. Tabellen beskriver de krav, piloten skal opfylde. Den er hverken en eksporteret konfiguration eller en rapport fra en gennemført migration.
| Krav | Eksisterende adfærd | Krævet resultat i piloten |
|---|---|---|
| Realm / audience | urn:example:expenses identificerer applikationen |
Applikationens wtrealm matcher registreringen i FoxIDs, og tokenet er beregnet til den applikation |
| Reply URL | Testinstansen modtager svar på https://expenses-test.example.org/signin-wsfed |
Kun den tilsigtede callback i testmiljøet accepteres og bruges |
| Betroet issuer og signeringsnøgler | Applikationen stoler på AD FS metadata og signeringsnøgler | Testinstansen stoler på de FoxIDs metadata, den issuer og de signeringsnøgler, der er valgt til piloten |
| Tokenformat | Middleware accepterer SAML 1.1 i WS-Federation | Behold formatet, medmindre en særskilt afprøvet ændring er nødvendig |
| Kontoopslag | Applikationens NameIdentifier-claim finder medarbejder E1042 |
Den samme eksisterende konto og historik vælges; der oprettes ikke en ekstra konto |
| Autorisation | Rollen ExpenseApprover giver ret til at godkende |
Godkendere beholder rettigheden; brugere uden rollen kan fortsat ikke godkende |
| Sessionsadfærd | Applikationen har en lokal cookie og en defineret logoutpolitik | Login, udløb, fornyet autentifikation og logout opfylder den aftalte politik gennem det nye forløb |
Udfyld tabellen med den rigtige applikations værdier og claim-typer. Undersøg også, om kontoopslaget bruger tokenets issuer eller navnet på den eksterne loginudbyder: Det er ikke altid nok at bevare det synlige bruger-id for at bevare koblingen til den eksisterende konto.
FoxIDs kan udstede tokens i formatet SAML 1.1 eller SAML 2.0 via WS-Federation. SAML 1.1 er standarden. Et SAML 2.0 token i et WS-Federation svar er ikke det samme som at skifte til protokollen SAML 2.0 Web SSO. Behandl protokol og tokenformat som forskellige beslutninger.
Registrér krypteringskrav og certifikatudløb sammen med signeringstilliden. Kryptering og signaturvalidering løser forskellige opgaver, og understøttelsen skal passe til den modtagende applikation. For ASP.NET Core beskriver Microsofts guide til WS-Federation middleware blandt andet MetadataAddress, Wtrealm og callback-konfigurationen. Kontrollér jeres konkrete middleware og version, før I anvender et konfigurationseksempel.
Konfigurér begge sider i et testmiljø
Opret piloten i et separat FoxIDs miljø, og brug en testinstans af applikationen. Konfigurér forbindelsen til AD FS som en autentifikationsmetode. Registrér derefter den eksisterende applikation i FoxIDs med dens realm, reply URL, tokentype og nødvendige claims.
På AD FS siden er FoxIDs en selvstændig relying party. Opret tilliden med metadata fra FoxIDs autentifikationsmetoden, og fastlæg de claims og den adgangspolitik, AD FS skal anvende for den. Behold den oprindelige applikations AD FS tillid i den aftalte rollbackperiode.
Antag ikke, at den oprindelige relying partys claim-regler, adgangsbegrænsninger eller MFA-politik automatisk gælder for den nye tillid. AD FS claim-regler er knyttet til de enkelte tillidsrelationer, som Microsoft beskriver i sin vejledning om claim-regler. Genskab den nødvendige adfærd det rette sted, og test den.
Konfigurér derefter applikationens testinstans til FoxIDs STS-metadata og den forventede issuer. Behold validering af issuer, audience og signatur. Brug de endpoints, der genereres til det konkrete miljø, frem for at tilpasse en AD FS URL i hånden.
Den passive browserpilot kræver ikke den særskilte indstilling Microsoft Entra ID Windows sign-in. Den funktion understøtter et andet scenarie med domænefederation og aktive klienter.
Følg claims helt frem til applikationen
Metadata beskriver endpoints og tillidsoplysninger. De fastlægger ikke, hvordan applikationen finder konti og tildeler rettigheder.
Med en ekstern WS-Federation metode modtager FoxIDs SAML claims, repræsenterer dem internt som JWT claims og konverterer dem tilbage til SAML claims i applikationens token. Standardmappingen konverterer for eksempel http://schemas.microsoft.com/ws/2008/06/identity/claims/role til role internt og tilbage til SAML claim-typen for WS-Federation. Medtag den nødvendige SAML claim-type for rollen i både Forward claims på autentifikationsmetoden og Issue claims på applikationen. Roller indgår ikke i standardudvalget af claims.
Identifikatorer kræver et særskilt tjek. For en WS-Federation autentifikationsmetode med navnet adfs sætter FoxIDs et præfiks foran det modtagne id E1042, så det bliver adfs|E1042, før de efterfølgende claim transforms. Hvis udlægsapplikationen forventer E1042, skal I definere en eksplicit mapping, der bevarer koblingen til den eksisterende konto. Fjern ikke præfikser ukritisk: Ens identifikatorer fra forskellige kilder kan ellers pege på samme konto.
Sammenlign en eksisterende godkender med en medarbejder, som ikke må godkende udlæg. Undersøg de claims, applikationen faktisk bruger, inklusive eventuel mapping i middleware, og test de resulterende rettigheder. Claim transforms kan ændre navne og værdier, så verificér det endelige resultat frem for konfigurationen alene.
Brug dokumentationen om claim transforms og mapping til implementeringsdetaljerne. Videresend og udsted de claims, applikationen behøver. Jokertegnet * er ikke en erstatning for at beslutte, hvilke data den skal modtage.
Test både adgang og afvisning før skiftet
Aftal forventede resultater med applikationsejeren, før I tester. Registrér både de observerede tokens/claims og applikationens adfærd. Brug testkonti, og hold autentifikationsmateriale ude af delte rapporter.
| Test | Dokumentation, der skal være på plads, før I fortsætter |
|---|---|
| En eksisterende bruger logger ind | Den eksisterende applikationskonto, dens data og historik vælges |
| En godkender og en almindelig medarbejder udfører samme handling | Godkenderen får adgang; den almindelige medarbejder afvises |
| En bruger er udelukket af den gamle applikations adgangspolitik | Det nye forløb nægter også denne bruger adgang |
| MFA er påkrævet, også med en eksisterende AD FS browsersession | Det konfigurerede forløb opfylder det krævede sikkerhedsniveau; et vellykket login hos kilden er ikke tilstrækkeligt bevis i sig selv |
| Brugeren logger ud og åbner en beskyttet side igen | Applikationscookien, sessionen hos AD FS og det konfigurerede logout-/cleanup-forløb følger den aftalte logoutpolitik |
| Et nyt login kræver AD FS, mens AD FS er utilgængelig | Forsøget afvises uden at omgå den krævede autentifikationskilde; den driftsansvarlige kan se fejlen |
| Testsvar har forkert issuer, audience eller signatur | Hvert ugyldigt svar afvises; validering forbliver slået til |
| Den tidligere applikationskonfiguration gendannes | Et nyt login gennem det oprindelige AD FS forløb vælger den korrekte konto og de korrekte rettigheder |
Test sessionsudløb og fornyet autentifikation særskilt fra et almindeligt vellykket login. En deaktiveret konto eller en bruger, der har mistet en rolle, kan stadig have en eksisterende applikationssession. Aftal, hvornår adgangen skal ophøre, og verificér tidspunktet frem for at antage, at en ny federationskonfiguration tilbagekalder alle cookies.
FoxIDs understøtter WS-Federation logout og cleanup-notifikationer, når det er konfigureret. Om alle deltagende applikationer rydder deres lokale session, afhænger af implementeringen og det konkrete browserforløb. Kontrollér logout med de klienter og browsere, der bruges i produktion.
Gør skiftet til en lille beslutning med en vej tilbage
Før produktion skal det være dokumenteret, hvem der kan gendanne den tidligere applikationskonfiguration, hvor den er gemt, og hvilke fund der udløser rollback. Forkert kontokobling, utilsigtede rettigheder og manglende opfyldelse af MFA-krav bør stoppe udrulningen med det samme. Aftal grænser for loginfejl og driftshændelser frem for at opfinde dem under ændringen.
Flyt det aftalte applikationsomfang i et overvåget tidsrum. En pilot med enkelte brugere er kun mulig, hvis applikationen og routingdesignet understøtter det. Brug ellers testinstansen først, og behandl produktionsapplikationen som den enhed, der flyttes.
Rollback skal omfatte mere end metadata-URL'en. Gendan den tidligere tillid til issuer og nøgler, claims-konfigurationen og eventuelle kontokoblinger, der blev ændret under piloten. Beslut, hvordan sessioner fra det nye forløb afsluttes eller erstattes. Det gamle endpoint gendanner ikke ændrede applikationsdata og fjerner ikke automatisk de sessioner.
Når applikationen fungerer stabilt, vælger I den næste afhængighed, der skal fjernes. At erstatte AD FS som kilde, skifte applikationens protokol til OpenID Connect og migrere katalogbrugere er særskilte opfølgende ændringer med hver deres tests. Hvis bruger- eller passwordlagring skal ændres, så brug beslutningsguiden til passwordmigration frem for at lægge arbejdet ind i denne pilot.
Det målte resultat fra den første applikation giver næste migration et konkret udgangspunkt: en forstået tillidskonfiguration, verificeret bruger- og adgangsadfærd samt en gendannelsesprocedure, teamet har afprøvet. Brug migrationsvejledningen til at omsætte erfaringerne til den samlede plan.