Quando usare una regola attestazioni di autorizzazione

  • Articolo

È possibile usare questa regola in Active Directory Federation Services (AD FS) quando è necessario accettare un tipo di attestazione in ingresso e quindi applicare un'azione che determinerà se a un utente sarà consentito o negato l'accesso in base al valore specificato nella regola. Quando si usa questa regola, si consente l'ingresso o si trasformano le attestazioni corrispondenti alla logica della regola seguente, in base all'opzione configurata nella regola:

Opzione della regola Logica della regola
Consentire l'accesso a tutti gli utenti Se il tipo di attestazione in ingresso è uguale a qualsiasi tipo di attestazione e il valore è uguale a qualsiasi valore, rilasciare un'attestazione con valore uguale a Consenti
Consenti accesso agli utenti con questa attestazione in ingresso Se il tipo di attestazione in ingresso è uguale a tipo di attestazione specificato e il valore è uguale a valore di attestazione specificato, rilasciare un'attestazione con valore uguale a Consenti
Nega accesso agli utenti con questa attestazione in ingresso Se il tipo di attestazione in ingresso è uguale a tipo di attestazione specificato e il valore è uguale a valore di attestazione specificato, rilasciare un'attestazione con valore uguale a Nega

Le sezioni seguenti forniscono un'introduzione di base alle regole attestazioni e indicano i casi in cui è necessario usare questa regola.

Informazioni sulle regole attestazioni

Una regola attestazioni rappresenta un'istanza della logica di business che accetta un'attestazione in ingresso, applica una condizione (se x quindi y) e genera un'attestazione in uscita in base ai parametri della condizione. L'elenco seguente fornisce suggerimenti importanti sulle regole attestazioni da tenere presenti prima di procedere con la lettura di questo argomento:

  • Nello snap-in di gestione di AD FS, le regole attestazioni possono essere create solo utilizzando modelli di regola attestazioni

  • Le regole attestazioni elaborano le attestazioni in ingresso direttamente da un provider di attestazioni (ad esempio Active Directory o un altro servizio federativo) oppure dall'output delle regole di trasformazione accettazione in un trust del provider di attestazioni.

  • Le regole attestazioni sono elaborate dal motore di rilascio delle attestazioni in ordine cronologico entro un determinato set di regole. Impostando la precedenza sulle regole, è possibile perfezionare o filtrare ulteriormente le attestazioni generate dalle regole precedenti all'interno di un set di regole specificato.

  • Per i modelli di regola attestazioni è sempre necessario specificare un tipo di attestazione in ingresso. Tuttavia, è possibile elaborare più valori di attestazione con lo stesso tipo di attestazione usando una singola regola.

Per ulteriori informazioni sulle regole attestazione e i set di regole attestazione, vedere ruolo delle attestazioni regole. Per ulteriori informazioni sulle modalità di elaborazione delle regole, vedere il ruolo del motore di attestazioni. Per ulteriori informazioni, modalità di elaborazione dei set di regole attestazione, vedere ruolo delle Pipeline delle attestazioni.

Consentire l'accesso a tutti gli utenti

Quando si usa la regola Consentire l'accesso a tutti gli utenti, tutti gli utenti avranno accesso alla relying party. Per limitare ulteriormente l'accesso, è tuttavia possibile usare altre regole di autorizzazione. Se una regola consente a un utente di accedere alla relying party, mentre un'altra regola nega l'accesso, il risultato di quest'ultima sostituisce quello che della regola che lo consente, quindi all'utente viene negato l'accesso.

Agli utenti che hanno ricevuto l'autorizzazione di accesso alla relying parti da parte del Servizio federativo potrebbe comunque essere negato l'accesso dalla stessa relying party.

Consenti accesso agli utenti con questa attestazione in ingresso

Quando si usa il modello di regola Consentire o negare l'accesso agli utenti in base a un'attestazione in ingresso e si imposta la condizione su Consenti, è possibile consentire l'accesso alla relying party a utenti specifici in base al tipo e al valore di un'attestazione in ingresso. Ad esempio, è possibile usare questo modello di regola per creare una regola che consenta solo a determinati utenti di avere un'attestazione basata su gruppo con un valore Domain Admins. Se una regola consente a un utente di accedere alla relying party, mentre un'altra regola nega l'accesso, il risultato di quest'ultima sostituisce quello che della regola che lo consente, quindi all'utente viene negato l'accesso.

Agli utenti che hanno ricevuto l'autorizzazione di accesso alla relying parti da parte del Servizio federativo potrebbe comunque essere negato l'accesso dalla stessa relying party. Se si vuole consentire a tutti gli utenti di accedere alla relying party, usare il modello di regola Consentire l'accesso a tutti gli utenti.

Nega accesso agli utenti con questa attestazione in ingresso

Quando si usa il modello di regola Consentire o negare l'accesso agli utenti in base a un'attestazione in ingresso per creare una regola e si imposta la condizione su nega, è possibile negare agli utenti l'accesso alla relying party in base al tipo e al valore di un'attestazione in ingresso. Ad esempio, è possibile usare questo modello di regola per creare una regola che neghi a tutti gli utenti di avere un'attestazione basata su gruppo con un valore Domain Admins.

Se si vuole usare la condizione Nega e abilitare comunque l'accesso alla relying party per utenti specifici, è necessario aggiungere in seguito in modo esplicito le regole di autorizzazione con la condizione Consenti per abilitare l'accesso degli utenti alla relying party.

Se a un utente a cui è negato l'accesso quando il motore di rilascio delle attestazioni elabora il set di regole, l'elaborazione di ulteriori regole si arresta e AD FS restituisce un errore “Accesso negato” alla richiesta dell'utente.

Autorizzazione degli utenti

In AD FS le regole di autorizzazione vengono usate per rilasciare un'attestazione Consenti o Nega che determinerà se un utente o un gruppo di utenti, a seconda del tipo di attestazione usato, potrà accedere o meno alle risorse basate sul Web in una relying party specifica. Le regole di autorizzazione possono essere impostate solo per attendibilità di relying party.

Set di regole di autorizzazione

Esistono diversi set di regole di autorizzazione, a seconda del tipo di operazioni consentite o negate che è necessario configurare. Questi set di regole includono:

  • Regole di autorizzazione rilascio: queste regole determinano se un utente può ricevere attestazioni per una relying party e perciò accedere alla relying party.

  • Regole di autorizzazione di delega: determinano se un utente può agire come un altro utente per l'accesso alla relying party. In questo caso, le attestazioni relative all'utente richiedente sono ancora all'interno del token.

  • Regole di autorizzazione di rappresentazione: determinano se un utente può rappresentare completamente un altro utente per l'accesso alla relying party. La rappresentazione di un altro utente è una funzionalità molto potente, perché la relying party non riconoscerà che l'utente è rappresentato.

Per altri dettagli sul modo in cui il processo delle regole di autorizzazione si inserisce nella pipeline di rilascio delle autorizzazioni, vedere Ruolo del motore di rilascio delle attestazioni.

Tipi di attestazione supportati

AD FS definisce due tipi di attestazione usati per determinare se a un utente è consentito o negato l'accesso. Gli URI (Uniform Resource Identifier) di questo tipo di attestazione sono i seguenti:

  1. Autorizza: http://schemas.microsoft.com/authorization/claims/permit

  2. Nega: http://schemas.microsoft.com/authorization/claims/deny

Come creare la regola

È possibile creare entrambe le regole di autorizzazione usando il linguaggio delle regole attestazioni oppure il modello di regola Consentire l'accesso a tutti gli utenti o Consentire o negare l'accesso agli utenti in base a un'attestazione in ingresso nello snap-in Gestione AD FS. Il modello di regola Consentire l'accesso a tutti gli utenti non include opzioni di configurazione. Il modello di regola Consentire o negare l'accesso agli utenti in base a un'attestazione in ingresso include invece le opzioni di configurazione seguenti:

  • Specificare un nome regola attestazione

  • Specificare un tipo di attestazione in ingresso

  • Immettere un valore attestazione in ingresso

  • Consenti accesso agli utenti con questa attestazione in ingresso

  • Nega accesso agli utenti con questa attestazione in ingresso

Per altre istruzioni su come creare questo modello, vedere Creare una regola per consentire a tutti gli utenti di o Creare una regola per consentire o negare agli utenti in base a un'attestazione in ingresso nella Guida alla distribuzione di AD FS.

Uso del linguaggio delle regole attestazioni

Se un'attestazione deve essere inviata solo quando il relativo valore corrisponde a un modello personalizzato, è necessario usare una regola personalizzata. Per altre informazioni, vedere When to Use a Custom Claim Rule.

Esempio di creazione di una regola di autorizzazione basata su più attestazioni

Quando si usa la sintassi del linguaggio delle regole attestazioni per autorizzare le attestazioni, è anche possibile che un'attestazione venga rilasciata in base alla presenza di più attestazioni nelle attestazioni originali dell'utente. La regola seguente rilascia un'attestazione di autorizzazione solo se l'utente è membro del gruppo Editors e si è autenticato usando l'autenticazione di Windows:

[type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
value == "urn:federation:authentication:windows" ]
&& [type == "http://schemas.xmlsoap.org/claims/Group ", value == "editors"]
=> issue(type = "http://schemas.xmlsoap.org/claims/authZ", value = "Granted");

Esempio di creazione di regole di autorizzazione che delegano chi può creare o rimuovere trust di proxy server federativo

Per consentire a un Servizio federativo di usare un proxy server federativo per reindirizzare le richieste dei client, è necessario stabilire prima un trust tra il Servizio federativo e il computer proxy server federativo. Per impostazione predefinita, un trust proxy viene stabilito quando le credenziali seguenti vengono fornite correttamente nella configurazione guidata del proxy server federativo di AD FS:

  • Account del servizio usato dal Servizio federativo che sarà protetto dal proxy

  • Account di dominio di Active Directory membro del gruppo Administrators locale in tutti i server federativi di una server farm federativa

Per specificare l'utente o gli utenti autorizzati a creare un trust proxy per un determinato Servizio federativo, è possibile usare uno qualsiasi dei metodi di delega seguenti. Questo elenco di metodi è redatto in ordine di priorità, in base alle raccomandazioni del team del prodotto AD FS relative ai metodi di delega più sicuri e meno problematici. È necessario usare solo uno di questi metodi, in base alle esigenze dell'organizzazione:

  1. Creare un gruppo di sicurezza di dominio in Active Directory (ad esempio, FSProxyTrustCreators), aggiungere questo gruppo al gruppo Administrators locale in ogni server federativo della farm e quindi aggiungere a questo nuovo gruppo solo gli account utente ai quali si vuole delegare questo diritto. Questo è il metodo preferito.

  2. Aggiungere l'account di dominio dell'utente al gruppo Administrators di ogni server federativo della farm.

  3. Se per qualche motivo non è possibile usare uno di questi metodi, si può anche usare una regola di autorizzazione a questo scopo. Anche se non è consigliabile, a causa delle possibili complicazioni che possono verificarsi se la regola non viene scritta correttamente, è possibile usare questa regola di autorizzazione per delegare gli account utente di dominio di Active Directory che possono creare o anche rimuovere i trust tra i proxy server federativi associati a un determinato Servizio federativo.

    Se si sceglie il terzo metodo, è possibile usare la sintassi della regola seguente per rilasciare un'attestazione di autorizzazione che consentirà a un utente specifico, in questo caso contoso\frankm, di creare trust per uno o più proxy server federativi per il Servizio federativo. Questa regola deve essere applicata con il comando di Windows PowerShell Set-ADFSProperties AddProxyAuthorizationRules.

    c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", issuer=~"^AD AUTHORITY$" value == "contoso\frankm" ] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true")

exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-32-544", Issuer =~ "^AD AUTHORITY$"])
=> issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^AD AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustManagerSid({0})", param= c.Value );

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/proxytrustid", Issuer =~ "^SELF AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustProvisioned({0})", param=c.Value );

    In seguito, per rimuovere l'utente in modo che non possa più creare trust proxy, è possibile ripristinare la regola di autorizzazione per il trust proxy predefinita che rimuoverà il diritto dell'utente alla creazione di trust proxy per il Servizio federativo. Anche questa regola deve essere applicata con il comando di Windows PowerShell Set-ADFSProperties AddProxyAuthorizationRules.

    exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-32-544", Issuer =~ "^AD AUTHORITY$"])
=> issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^AD AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustManagerSid({0})", param= c.Value );

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/proxytrustid", Issuer =~ "^SELF AUTHORITY$" ] => issue(store="_ProxyCredentialStore",types=("https://schemas.microsoft.com/authorization/claims/permit"),query="isProxyTrustProvisioned({0})", param=c.Value );

Per ulteriori informazioni su come utilizzare il linguaggio di regola attestazione, vedere il ruolo del linguaggio di regola attestazione.