Sostituire AD FS e cambiare il protocollo di autenticazione di un'applicazione sono decisioni distinte. Un'applicazione che usa già WS-Federation potrebbe mantenere quel protocollo quando il suo identity provider attendibile diventa FoxIDs.
Il primo traguardo utile è un'applicazione che riconosca gli stessi utenti, conceda l'accesso previsto e disponga di un percorso di ritorno collaudato. Un login riuscito, da solo, non dimostra nessuno di questi risultati.
Questa guida si rivolge agli architetti IAM e di soluzioni che preparano la prima migrazione. Riguarda un'applicazione basata su browser che usa WS-Federation passivo, spesso abbreviato in WS-Fed. La federazione di domini Microsoft 365, l'accesso a Windows e i client attivi WS-Trust richiedono una valutazione specifica e non rientrano in questo esempio.
Separa lo spostamento dell'applicazione da quello della directory
AD FS è un servizio di federazione; Active Directory è la directory rispetto alla quale molte installazioni AD FS autenticano gli utenti. Spostare la relazione di trust federativo di un'applicazione non sposta, di per sé, gli account o le password della directory.
Un possibile schema di transizione mantiene inizialmente AD FS come origine dell'autenticazione:
| Fase | Di cosa si fida l'applicazione | Dove si autentica l'utente |
|---|---|---|
| Prima | AD FS emette il token WS-Federation dell'applicazione | AD FS usa la configurazione di autenticazione esistente |
| Primo progetto pilota | FoxIDs emette un nuovo token WS-Federation per l'applicazione | FoxIDs indirizza il browser ad AD FS tramite un metodo di autenticazione configurato |
| Una modifica successiva e separata | L'applicazione continua a fidarsi di FoxIDs | Un altro identity provider esterno, oppure FoxIDs Login con Directory Connector per AD, sostituisce AD FS dopo una convalida separata |
FoxIDs supporta sia una registrazione dell'applicazione WS-Federation rivolta all'applicazione sia un metodo di autenticazione WS-Federation rivolto ad AD FS. I due lati hanno compiti diversi: uno emette token, l'altro convalida la risposta del provider a monte.
Nel progetto pilota, AD FS emette un token destinato a FoxIDs. FoxIDs lo convalida ed emette un token distinto destinato all'applicazione. Non è un inoltro trasparente del vecchio token: l'applicazione deve fidarsi dell'emittente e del certificato di firma di FoxIDs.
Il progetto pilota dipende ancora da AD FS. Crea un punto controllato in cui verificare la relazione di trust e i requisiti dei claims dell'applicazione, ma non dismette ancora il servizio di federazione.
Due percorsi per superare la dipendenza da AD FS
Dopo il progetto pilota sono possibili entrambi questi percorsi:
- Mantenere un identity provider esterno. Sostituisci AD FS con un altro IdP collegato a FoxIDs tramite un metodo di autenticazione supportato. FoxIDs rimane l'emittente WS-Federation attendibile dell'applicazione, che quindi non deve adottare il protocollo del nuovo provider.
- Usare FoxIDs Login con Active Directory. Il Directory Connector per Active Directory convalida le password rispetto ad AD. Questo rimuove AD FS dal percorso di login dell'applicazione, mantenendo AD come directory autorevole. La guida alla modernizzazione di Active Directory spiega questa architettura.
Un successivo passaggio alla convalida delle password in FoxIDs è facoltativo. I login riusciti tramite il connettore creano o aggiornano utenti interni di FoxIDs e, quando il salvataggio locale delle password è abilitato, memorizzano un hash della password per preparare quegli utenti a un cut-over successivo. È una migrazione graduale, non un'esportazione di tutti gli account AD; AD rimane l'origine autorevole finché il connettore è abilitato.
Qualunque percorso tu scelga, ripeti i test su associazioni degli account, claims, MFA e logout. Il progetto pilota della prima applicazione descritto di seguito stabilisce cosa deve essere preservato.
Documenta cosa usa effettivamente la prima applicazione
Scegli un'applicazione con un responsabile, un ambiente di test rappresentativo e una configurazione ripristinabile. Verifica che il middleware o il fornitore consentano di cambiare l'STS attendibile, abbreviazione di Security Token Service. Un URL dei metadati configurabile è utile, ma contano anche i controlli personalizzati sull'emittente, il codice di ricerca degli account e le regole di autorizzazione.
Considera un'applicazione fittizia per la gestione delle spese. La tabella seguente illustra i requisiti del risultato atteso: non è una configurazione esportata né il resoconto di una migrazione completata.
| Elemento | Comportamento esistente | Risultato richiesto nel progetto pilota |
|---|---|---|
| Realm / audience | urn:example:expenses identifica l'applicazione |
Il wtrealm dell'applicazione corrisponde alla sua registrazione in FoxIDs e il token è destinato a quell'applicazione |
| URL di risposta | L'istanza di test riceve le risposte su https://expenses-test.example.org/signin-wsfed |
Viene accettato e usato solo il callback previsto per il test |
| Emittente attendibile e chiavi di firma | L'applicazione si fida dei metadati e delle chiavi di firma di AD FS | L'istanza di test si fida dei metadati, dell'emittente e delle chiavi di firma di FoxIDs selezionati per questo progetto pilota |
| Formato del token | Il middleware accetta SAML 1.1 trasportato tramite WS-Federation | Mantieni quel formato, a meno che non sia necessaria una modifica verificata con test separati |
| Ricerca dell'utente | Il claim NameIdentifier dell'applicazione identifica il dipendente E1042 |
Vengono selezionati lo stesso account esistente e la sua cronologia; non viene creato un secondo account |
| Autorizzazione | Il ruolo ExpenseApprover consente di approvare le spese |
Gli utenti autorizzati conservano il permesso; gli utenti senza quel ruolo continuano a non poter approvare |
| Comportamento delle sessioni | L'applicazione ha un cookie locale e una policy di logout definita | Login, scadenza, nuova autenticazione e logout rispettano la policy concordata attraverso il nuovo percorso |
Completa la tabella con i valori e i tipi di claim dell'applicazione reale. Verifica se la ricerca degli account include anche l'emittente del token o il nome del provider esterno di login: mantenere solo l'ID utente visibile potrebbe non preservare l'associazione con l'account.
FoxIDs può emettere token SAML 1.1 o SAML 2.0 tramite WS-Federation; SAML 1.1 è l'impostazione predefinita. Un token SAML 2.0 all'interno di una risposta WS-Federation non equivale a passare al protocollo SAML 2.0 Web SSO. Mantieni separate le decisioni sul protocollo e sul formato del token.
Documenta i requisiti di crittografia e la scadenza dei certificati insieme al trust della firma. La crittografia e la convalida della firma risolvono problemi diversi e devono essere supportate dall'applicazione ricevente. Per ASP.NET Core, la guida Microsoft al middleware WS-Federation indica MetadataAddress, Wtrealm e la configurazione del callback come impostazioni rilevanti per l'integrazione. Verifica il middleware e la versione effettivamente in uso prima di applicare un esempio di configurazione.
Configura entrambi i lati in un ambiente di test
Crea il progetto pilota in un ambiente FoxIDs separato e usa un'istanza di test dell'applicazione. Configura la connessione ad AD FS come metodo di autenticazione, quindi registra l'applicazione esistente in FoxIDs con realm, URL di risposta, tipo di token e claims necessari.
Sul lato AD FS, FoxIDs è una relying party a sé stante. Stabilisci la relazione di trust usando i metadati del metodo di autenticazione di FoxIDs e definisci i claims e la policy di accesso che AD FS deve applicare. Mantieni disponibile il trust originale dell'applicazione in AD FS per la finestra di rollback concordata.
Non dare per scontato che le regole dei claims, le restrizioni di accesso o la policy MFA della relying party originale si applichino automaticamente a questo nuovo trust. Le regole dei claims di AD FS sono associate alle singole relazioni di trust, come descritto nella guida Microsoft alle regole dei claims. Ricrea il comportamento richiesto nel punto appropriato e verificalo.
Configura quindi l'istanza di test dell'applicazione per usare i metadati STS di FoxIDs e l'emittente previsto. Mantieni abilitata la convalida di emittente, audience e firma. Usa gli endpoint generati per l'ambiente effettivo anziché adattare manualmente un URL di AD FS.
Il progetto pilota con browser passivo non richiede l'opzione separata Microsoft Entra ID Windows sign-in. Questa funzionalità supporta uno scenario diverso, con federazione di domini e client attivi.
Segui i claims fino all'applicazione
I metadati definiscono endpoint e informazioni di trust; non determinano il comportamento degli account e dei permessi nell'applicazione.
Con un metodo WS-Federation a monte, FoxIDs riceve claims SAML, li rappresenta internamente come claims JWT e li riconverte in claims SAML per il token dell'applicazione. Per esempio, il mapping predefinito converte http://schemas.microsoft.com/ws/2008/06/identity/claims/role in role internamente e poi di nuovo nel tipo di claim SAML per WS-Federation. Includi il tipo di claim SAML del ruolo richiesto sia nell'elenco Forward claims del metodo di autenticazione a monte sia nell'elenco Issue claims dell'applicazione a valle; i ruoli non fanno parte dell'insieme predefinito di claims.
Gli identificatori richiedono un controllo separato. Per un metodo di autenticazione WS-Federation chiamato adfs, FoxIDs aggiunge un prefisso all'identificatore ricevuto E1042, che diventa adfs|E1042 prima delle successive trasformazioni dei claims. Se l'applicazione delle spese si aspetta E1042, definisci un mapping esplicito che preservi l'associazione con l'account esistente. Non rimuovere i prefissi indiscriminatamente: identificatori uguali provenienti da origini diverse potrebbero altrimenti selezionare lo stesso account.
Confronta un utente già autorizzato ad approvare le spese con un dipendente che non deve poterlo fare. Esamina i claims effettivamente usati dall'applicazione, inclusi eventuali mapping del middleware, e verifica i permessi risultanti. Le trasformazioni dei claims possono cambiare nomi e valori: verifica quindi il risultato finale, non soltanto la configurazione.
Consulta la documentazione sulle trasformazioni e sul mapping dei claims per i dettagli di implementazione. Inoltra ed emetti i claims necessari all'applicazione; un carattere jolly non sostituisce la decisione su quali dati debba ricevere.
Verifica accessi consentiti e negati prima del cut-over
Concorda i risultati attesi con il responsabile dell'applicazione prima dei test. Registra sia il token e i claims osservati sia il comportamento dell'applicazione, usando account di test e tenendo il materiale di autenticazione fuori dai report condivisi.
| Test | Evidenza richiesta prima di procedere |
|---|---|
| Un utente esistente effettua il login | Vengono selezionati l'account esistente dell'applicazione, i suoi dati e la sua cronologia |
| Un approvatore e un dipendente ordinario eseguono la stessa azione | L'approvatore riesce a completarla; al dipendente ordinario viene negata |
| Un utente è escluso dalla policy di accesso della vecchia applicazione | Il nuovo percorso continua a negare l'accesso a quell'utente |
| È richiesta MFA, anche con una sessione browser AD FS esistente | Il flusso configurato soddisfa il livello di garanzia richiesto; un login riuscito presso il provider a monte non è accettato, da solo, come prova sufficiente |
| L'utente esegue il logout e visita nuovamente una pagina protetta | Il cookie dell'applicazione, la sessione AD FS e il flusso di logout/cleanup configurato rispettano la policy di logout concordata |
| Un nuovo tentativo di autenticazione richiede AD FS mentre AD FS non è disponibile | Il tentativo non riesce senza aggirare l'origine di autenticazione richiesta; l'errore è visibile al responsabile operativo |
| Le risposte di test contengono emittente, audience o firma non validi | Ogni risposta non valida viene rifiutata; la convalida rimane abilitata |
| Viene ripristinata la precedente configurazione dell'applicazione | Un nuovo login attraverso il percorso AD FS originale seleziona l'account e i permessi corretti |
Verifica la scadenza delle sessioni e una nuova autenticazione separatamente da un normale login riuscito. Un account disabilitato o un utente a cui è stato rimosso un ruolo potrebbe avere ancora una sessione attiva nell'applicazione. Concorda quando deve cessare l'accesso e verifica quella tempistica, anziché presumere che una nuova configurazione di federazione revochi tutti i cookie.
FoxIDs supporta il sign-out e le notifiche di cleanup WS-Federation quando configurati. Che ogni applicazione partecipante cancelli la propria sessione locale dipende dalla sua implementazione e dal flusso effettivo del browser. Verifica il comportamento del logout con i client e i browser usati in produzione.
Rendi il cut-over una decisione circoscritta e reversibile
Prima di passare in produzione, documenta chi può ripristinare la precedente configurazione dell'applicazione, dove è conservata e quali riscontri fanno scattare il rollback. Associazioni errate degli account, permessi imprevisti e requisiti MFA non soddisfatti devono interrompere immediatamente il rollout. Concorda soglie per gli errori di login e gli incidenti operativi anziché inventarle durante il cambiamento.
Esegui la migrazione dell'applicazione entro l'ambito concordato e durante una finestra monitorata. Un progetto pilota utente per utente è possibile solo se l'applicazione e il modello di routing lo supportano; altrimenti usa prima l'istanza di test e considera l'applicazione di produzione come unità di cambiamento.
Il rollback deve riguardare più del solo URL dei metadati. Ripristina il trust precedente verso emittente e chiavi, la configurazione dei claims e le eventuali associazioni degli account modificate durante il progetto pilota. Decidi come terminare o sostituire le sessioni stabilite attraverso il nuovo percorso. Ripristinare il vecchio endpoint non annulla le modifiche ai dati dell'applicazione e non rimuove automaticamente quelle sessioni.
Quando questa applicazione è stabile, decidi quale dipendenza eliminare successivamente. Sostituire AD FS a monte, cambiare il protocollo dell'applicazione in OpenID Connect e migrare gli utenti della directory sono interventi successivi distinti, ciascuno con i propri test. Se cambierà l'archiviazione di utenti o password, usa la guida decisionale alla migrazione delle password invece di includere quel lavoro in questo progetto pilota.
Il risultato misurato della prima applicazione fornisce alla migrazione successiva un punto di partenza concreto: una configurazione di trust compresa, un comportamento di utenti e accessi verificato e una procedura di ripristino che il team ha esercitato. Usa la guida alla migrazione per trasformare queste evidenze in un piano più ampio.