Considerazioni sulla topologia di distribuzione di ADFS
In questo argomento sono incluse importanti considerazioni che possono facilitare la pianificazione e la progettazione della topologia di distribuzione di Active Directory Federation Services (AD FS) da usare in un ambiente di produzione. Questo argomento offre un punto di partenza per rivedere e valutare le considerazioni che riguardano le funzionalità o le caratteristiche disponibili dopo la distribuzione di AD FS. Ad esempio, il tipo di database scelto per archiviare il database di configurazione di AD FS determinerà in ultima analisi se è possibile implementare alcune funzionalità SAML (Security Assertion Markup Language) richieste in SQL Server.
Determinazione del tipo di database di configurazione di ADFS da usare
AD FS usa un database per archiviare la configurazione e, in alcuni casi, i dati transazionali relativi al Servizio federativo. Per selezionare la funzionalità Database interno di Windows incorporata oppure Microsoft SQL Server 2005 o versione successiva per archiviare i dati nel Servizio federativo, è possibile usare il software AD FS.
I due tipi di database sono relativamente equivalenti per la maggior parte degli scopi. Esistono tuttavia alcune differenze che è utile conoscere prima di iniziare a leggere altre informazioni sulle diverse topologie di distribuzione che si possono usare con AD FS. Nella tabella seguente sono descritte le differenze tra le funzionalità supportate in Database interno di Windows e nel database SQL Server.
Funzionalità di AD FS
| Funzionalità di | Supportata in Database interno di Windows | Supportata in SQL Server | Altre informazioni su questa funzionalità |
|---|---|---|---|
| Distribuzione in una server farm federativa | Sì, con un limite di 30 server federativi per ogni farm | Sì. Non esiste un limite imposto per il numero di server federativi che si possono distribuire in una singola farm. | Determinare la topologia di distribuzione di AD FS |
| Risoluzione artefatto SAML Nota: questa funzionalità non è richiesta per scenari Microsoft Online Services, Microsoft Office 365, Microsoft Exchange o Microsoft Office SharePoint. | No | Sì | Ruolo del database di configurazione di AD FS Procedure consigliate per la pianificazione e la distribuzione sicure di AD FS |
| Rilevamento riproduzione token SAML/WS-Federation | No | Sì | Ruolo del database di configurazione di AD FS Procedure consigliate per la pianificazione e la distribuzione sicure di AD FS |
Funzionalità di database
| Funzionalità di | Supportata in Database interno di Windows | Supportata in SQL Server | Altre informazioni su questa funzionalità |
|---|---|---|---|
| Ridondanza del database di base con la replica pull in cui uno o più server che ospitano una copia di sola lettura del database richiedono le modifiche effettuate su un server di origine che ospita una copia di lettura/scrittura del database | Sì | No | Ruolo del database di configurazione di AD FS |
| Ridondanza del database con soluzioni a disponibilità elevata, ad esempio clustering di failover o mirroring (solo a livello del database) Nota: tutte le topologie di distribuzione di AD FS supportano il clustering a livello del servizio AD FS. | No | Sì | Ruolo del database di configurazione di AD FS |
Considerazioni su SQL Server
Se si sceglie SQL Server come database di configurazione per la distribuzione di ADFS, è consigliabile tenere presenti i seguenti aspetti.
Funzionalità SAML e relativo effetto sulle dimensioni e la crescita del database. Quando è abilitata la funzionalità risoluzione artefatto SAML o rilevamento riproduzione token SAML, ADFS archivia le informazioni nel database di configurazione di SQL Server per ogni token di ADFS rilasciato. La crescita del database SQL Server a seguito di questa attività non è considerata significativa e dipende dal periodo di rilevamento riproduzione token configurato. Ogni record artefatto ha una dimensione di circa 30 kilobyte (KB).
Numero di server richiesti per la distribuzione. Si dovrà aggiungere almeno un altro server (al numero totale di server richiesti per la distribuzione dell'infrastruttura di AD FS) che fungerà da host dedicato dell'istanza di SQL Server. Se si prevede di usare clustering di failover o mirroring per garantire la tolleranza di errore e la scalabilità per il database di configurazione di SQL Server, sono necessari almeno due server SQL.
Possibile impatto del tipo di database di configurazione scelto sulle risorse hardware
L'impatto sulle risorse hardware di un server federativo distribuito in una farm con Database interno di Windows rispetto a un server federativo distribuito in una farm con il database SQL Server non è significativo. È comunque importante considerare che quando si usa Database interno di Windows per la farm, ogni server federativo deve archiviare, gestire e mantenere le modifiche della replica per la copia locale del database di configurazione di ADFS, continuando contemporaneamente a eseguire le normali operazioni richieste dal Servizio federativo.
Diversamente, i server federativi distribuiti in una farm che usa il database SQL Server non includono necessariamente un'istanza locale dal database di configurazione di ADFS. Potrebbero quindi avere esigenze leggermente inferiori in termini di risorse hardware.
Verifica della capacità dell'ambiente di produzione di supportare una distribuzione di ADFS
Oltre ai server federativi distribuiti e a seconda della configurazione dell'ambiente di produzione esistente, è possibile che per fornire l'infrastruttura necessaria per supportare la nuova distribuzione di AD FS siano richiesti i seguenti server aggiuntivi:
Controller di dominio Active Directory
Autorità di certificazione (CA)
Server Web per ospitare i metadati federativi
Bilanciamento carico di rete