Å erstatte AD FS og endre autentiseringsprotokollen til en applikasjon er to forskjellige beslutninger. En applikasjon som allerede bruker WS-Federation, kan kanskje beholde protokollen mens den bytter til FoxIDs som betrodd identity provider.
Den første nyttige milepælen er en applikasjon som gjenkjenner de samme brukerne, gir den tiltenkte tilgangen og har en testet vei tilbake. En vellykket innlogging dokumenterer ikke i seg selv noen av disse resultatene.
Denne veiledningen er for IAM- og løsningsarkitekter som forbereder den første migreringen. Den omhandler en nettleserbasert applikasjon med passiv WS-Federation, ofte forkortet WS-Fed. Microsoft 365 domeneføderasjon, pålogging i Windows og aktive WS-Trust klienter krever en egen vurdering og inngår ikke i eksemplet.
Skill flytting av applikasjonen fra flytting av katalogen
AD FS er en føderasjonstjeneste. Active Directory er katalogen mange AD FS installasjoner autentiserer mot. Å flytte en applikasjons føderasjonstillit flytter ikke i seg selv katalogkontoer eller passord.
Et mulig overgangsmønster beholder AD FS som autentiseringskilde i første omgang:
| Fase | Hva applikasjonen stoler på | Hvor brukeren autentiseres |
|---|---|---|
| Før | AD FS utsteder applikasjonens WS-Federation token | AD FS bruker sitt eksisterende autentiseringsoppsett |
| Første pilot | FoxIDs utsteder et nytt WS-Federation token til applikasjonen | FoxIDs sender nettleseren til AD FS gjennom en konfigurert autentiseringsmetode |
| En senere, separat endring | Applikasjonen stoler fortsatt på FoxIDs | En annen ekstern identity provider eller FoxIDs Login med Directory Connector for AD erstatter AD FS etter separat validering |
FoxIDs støtter både en WS-Federation applikasjonsregistrering mot applikasjonen og en WS-Federation autentiseringsmetode mot AD FS. Sidene har ulike oppgaver: den ene utsteder tokener, mens den andre validerer svaret fra den bakenforliggende identity provideren.
I piloten utsteder AD FS et token beregnet på FoxIDs. FoxIDs validerer det og utsteder et separat token beregnet på applikasjonen. Det gamle tokenet blir altså ikke bare videresendt: applikasjonen må stole på FoxIDs som utsteder og på signeringssertifikatet.
Piloten er fortsatt avhengig av AD FS. Den gir et kontrollert punkt der applikasjonens tillit og krav til claims kan verifiseres, men føderasjonstjenesten er ennå ikke avviklet.
To veier videre fra AD FS
Etter piloten er begge disse veiene mulige:
- Behold en ekstern identity provider. Erstatt AD FS med en annen IdP som kobles til FoxIDs gjennom en støttet autentiseringsmetode. FoxIDs forblir applikasjonens betrodde utsteder av WS-Federation tokener, slik at applikasjonen ikke trenger å bytte til den nye leverandørens protokoll.
- Bruk FoxIDs Login med Active Directory. Directory Connector for Active Directory validerer passord mot AD. Dermed fjernes AD FS fra applikasjonens innloggingsflyt, mens AD beholdes som den autoritative katalogen. Veiledningen til modernisering av Active Directory innlogging forklarer arkitekturen.
En senere overgang til passordvalidering i FoxIDs er valgfri. Vellykkede innlogginger gjennom connectoren oppretter eller oppdaterer interne FoxIDs brukere og lagrer, når lokal passordlagring er aktivert, en passordhash som forbereder disse brukerne på en senere overgang. Dette er gradvis migrering, ikke en eksport av alle kontoer i AD. AD forblir autoritativt mens connectoren er aktivert.
Uansett hvilken vei dere velger, må kontokoblinger, claims, MFA og utlogging testes på nytt. Piloten med den første applikasjonen nedenfor fastslår hva som må bevares.
Kartlegg hva den første applikasjonen faktisk bruker
Velg en applikasjon med en ansvarlig eier, et representativt testmiljø og en konfigurasjon dere kan gjenopprette. Kontroller at middleware eller leverandøren støtter bytte av betrodd STS, som står for Security Token Service. En konfigurerbar metadata-URL er nyttig, men egne kontroller av utsteder, kode for kontooppslag og autorisasjonsregler har også betydning.
Se for dere en fiktiv applikasjon for utlegg. Tabellen nedenfor illustrerer kontrakten piloten skal oppfylle. Den er verken en eksportert konfigurasjon eller en rapport fra en gjennomført migrering.
| Kontraktselement | Eksisterende oppførsel | Påkrevd resultat i piloten |
|---|---|---|
| Realm / audience | urn:example:expenses identifiserer applikasjonen |
Applikasjonens wtrealm samsvarer med registreringen i FoxIDs, og tokenet er beregnet på denne applikasjonen |
| Reply URL | Testinstansen mottar svar på https://expenses-test.example.org/signin-wsfed |
Bare den tiltenkte callbacken i testmiljøet godtas og brukes |
| Betrodd utsteder og signeringsnøkler | Applikasjonen stoler på metadata og signeringsnøkler fra AD FS | Testinstansen stoler på metadata, utsteder og signeringsnøkler fra FoxIDs som er valgt for piloten |
| Tokenformat | Middleware godtar SAML 1.1 som formidles gjennom WS-Federation | Behold tokenformatet med mindre en separat testet endring er nødvendig |
| Kontooppslag | Applikasjonens claim NameIdentifier finner medarbeider E1042 |
Samme eksisterende konto og historikk velges; ingen ekstra konto opprettes |
| Autorisasjon | Rollen ExpenseApprover gir rett til å godkjenne |
Godkjennere beholder rettigheten; brukere uten rollen kan fortsatt ikke godkjenne |
| Sesjonsoppførsel | Applikasjonen har en lokal informasjonskapsel og en definert utloggingspolicy | Innlogging, utløp, ny autentisering og utlogging oppfyller avtalt policy gjennom den nye flyten |
Bruk den virkelige applikasjonens verdier og claim-typer når dere fyller ut tabellen. Undersøk om kontooppslaget også bruker tokenets utsteder eller navnet på den eksterne innloggingsleverandøren: å bevare synlig bruker-id alene er ikke alltid nok til å bevare kontokoblingen.
FoxIDs kan utstede SAML 1.1 eller SAML 2.0 tokener gjennom WS-Federation. SAML 1.1 er standard. Et SAML 2.0 token i et WS-Federation svar er ikke et bytte til protokollen SAML 2.0 Web SSO. Behandle protokoll og tokenformat som separate beslutninger.
Dokumenter krypteringskrav og sertifikatenes utløpsdato sammen med tilliten til signeringsnøklene. Kryptering og signaturvalidering løser ulike problemer, og støtten må passe til applikasjonen som mottar tokenet. For ASP.NET Core beskriver Microsofts veiledning til WS-Federation middleware MetadataAddress, Wtrealm og callback-konfigurasjonen som relevante integrasjonsinnstillinger. Kontroller deres faktiske middleware og versjon før dere bruker et konfigurasjonseksempel.
Konfigurer begge sider i et testmiljø
Opprett piloten i et separat FoxIDs miljø, og bruk en testinstans av applikasjonen. Konfigurer forbindelsen til AD FS som en autentiseringsmetode. Registrer deretter den eksisterende applikasjonen i FoxIDs med realm, reply URL, tokentype og nødvendige claims.
På AD FS siden er FoxIDs en egen relying party. Opprett tilliten med metadata fra autentiseringsmetoden i FoxIDs, og definer claims og tilgangspolicy som AD FS skal bruke for den. Behold den opprinnelige applikasjonens tillit til AD FS i den avtalte rollbackperioden.
Ikke anta at den opprinnelige relying partyens claim-regler, tilgangsbegrensninger eller MFA-policy automatisk gjelder for den nye tillitsrelasjonen. AD FS claim-regler er knyttet til individuelle tillitsrelasjoner, slik Microsoft beskriver i sin veiledning om claim-regler. Gjenskap nødvendig oppførsel på riktig sted, og test den.
Konfigurer så applikasjonens testinstans til å bruke STS-metadata fra FoxIDs og forventet utsteder. Behold validering av utsteder, audience og signatur aktivert. Bruk endepunktene som genereres for det faktiske miljøet, i stedet for å tilpasse en AD FS URL manuelt.
Den passive nettleserpiloten trenger ikke det separate alternativet Microsoft Entra ID Windows sign-in. Denne funksjonen støtter et annet scenario med domeneføderasjon og aktive klienter.
Følg claims helt frem til applikasjonen
Metadata fastsetter endepunkter og tillitsinformasjon. De fastsetter ikke hvordan applikasjonen finner kontoer eller tildeler rettigheter.
Med en bakenforliggende WS-Federation metode mottar FoxIDs SAML claims, representerer dem internt som JWT claims og konverterer dem tilbake til SAML claims for applikasjonens token. Standardmappingen konverterer for eksempel http://schemas.microsoft.com/ws/2008/06/identity/claims/role til role internt og tilbake til SAML claim-typen for WS-Federation. Ta med den nødvendige SAML claim-typen for rollen i både Forward claims på autentiseringsmetoden og Issue claims på applikasjonen. Roller er ikke med i standardsettet av claims.
Identifikatorer må kontrolleres separat. For en WS-Federation autentiseringsmetode med navnet adfs legger FoxIDs et prefiks foran den innkommende identifikatoren E1042, slik at den blir adfs|E1042, før etterfølgende claim transforms. Hvis utleggsapplikasjonen forventer E1042, må dere definere en eksplisitt mapping som bevarer den eksisterende kontokoblingen. Ikke fjern prefikser ukritisk: identiske identifikatorer fra ulike kilder kan ellers velge samme konto.
Sammenlign en eksisterende godkjenner med en medarbeider som ikke skal kunne godkjenne utlegg. Undersøk hvilke claims applikasjonen faktisk bruker, inkludert eventuell mapping i middleware, og test de resulterende rettighetene. Claim transforms kan endre navn og verdier, så verifiser sluttresultatet fremfor bare konfigurasjonen.
Bruk dokumentasjonen om claim transforms og mapping for implementeringsdetaljer. Videresend og utsted de claims applikasjonen trenger. Et jokertegn erstatter ikke avgjørelsen om hvilke data den skal motta.
Test både tilgang og avvisning før overgangen
Avtal forventede resultater med applikasjonseieren før testing. Dokumenter både observerte tokener/claims og applikasjonens oppførsel. Bruk testkontoer, og hold autentiseringsmateriale utenfor delte rapporter.
| Test | Dokumentasjon som kreves før dere fortsetter |
|---|---|
| En eksisterende bruker logger inn | Den eksisterende applikasjonskontoen med data og historikk velges |
| En godkjenner og en vanlig medarbeider utfører samme handling | Godkjenneren lykkes; den vanlige medarbeideren avvises |
| En bruker er utelukket av den gamle applikasjonens tilgangspolicy | Den nye flyten nekter fortsatt denne brukeren tilgang |
| MFA er påkrevd, også med en eksisterende nettlesersesjon hos AD FS | Den konfigurerte flyten oppfyller påkrevd sikkerhetsnivå; en vellykket innlogging hos kilden er ikke tilstrekkelig bevis i seg selv |
| Brukeren logger ut og besøker en beskyttet side på nytt | Applikasjonens informasjonskapsel, sesjonen hos AD FS og den konfigurerte utloggings-/cleanup-flyten oppfyller avtalt utloggingspolicy |
| Et nytt autentiseringsforsøk krever AD FS mens AD FS er utilgjengelig | Forsøket mislykkes uten å omgå den påkrevde autentiseringskilden; feilen er synlig for driftsansvarlig |
| Testsvar har ugyldig utsteder, audience eller signatur | Hvert ugyldig svar avvises; validering forblir aktivert |
| Den tidligere applikasjonskonfigurasjonen gjenopprettes | En ny innlogging gjennom den opprinnelige AD FS flyten velger riktig konto og riktige rettigheter |
Test sesjonsutløp og ny autentisering separat fra en vanlig vellykket innlogging. En deaktivert konto eller en bruker som har mistet en rolle, kan fortsatt ha en eksisterende applikasjonssesjon. Avtal når tilgangen skal opphøre, og verifiser tidspunktet fremfor å anta at en ny føderasjonskonfigurasjon tilbakekaller alle informasjonskapsler.
FoxIDs støtter WS-Federation utlogging og cleanup-varsler når dette er konfigurert. Om hver deltakende applikasjon avslutter sin lokale sesjon, avhenger av implementeringen og den faktiske nettleserflyten. Kontroller utlogging med klientene og nettleserne som brukes i produksjon.
Gjør overgangen til en liten, reverserbar beslutning
Før produksjonssetting må dere dokumentere hvem som kan gjenopprette den tidligere applikasjonskonfigurasjonen, hvor den er lagret, og hvilke funn som utløser rollback. Feil kontokobling, utilsiktede rettigheter og uoppfylte MFA-krav bør stoppe utrullingen umiddelbart. Avtal terskler for innloggingsfeil og driftshendelser på forhånd i stedet for under selve endringen.
Gjennomfør den avtalte applikasjonsmigreringen i et overvåket tidsvindu. En pilot bruker for bruker er bare mulig hvis applikasjonen og routingdesignet støtter det. Bruk ellers testinstansen først, og behandle produksjonsapplikasjonen som enheten som flyttes.
Rollback må omfatte mer enn metadata-URL-en. Gjenopprett tidligere tillit til utsteder og nøkler, konfigurasjonen av claims og eventuelle kontokoblinger som ble endret under piloten. Bestem hvordan sesjoner opprettet gjennom den nye flyten skal avsluttes eller erstattes. Gjenoppretting av det gamle endepunktet reverserer ikke endringer i applikasjonsdata og fjerner ikke automatisk disse sesjonene.
Når applikasjonen er stabil, velger dere hvilken avhengighet som skal fjernes neste gang. Å erstatte AD FS som bakenforliggende kilde, endre applikasjonens protokoll til OpenID Connect og migrere katalogbrukere er separate oppfølgende endringer med egne tester. Hvis lagring av brukere eller passord skal endres, bruk beslutningsveiledningen for passordmigrering fremfor å legge dette arbeidet inn i piloten.
Det målte resultatet fra den første applikasjonen gir neste migrering et konkret utgangspunkt: en forstått tillitskonfigurasjon, verifisert bruker- og tilgangsoppførsel og en gjenopprettingsprosedyre teamet har øvd på. Bruk migreringsveiledningen til å omsette dette underlaget i en bredere plan.