Когда следует использовать правило утверждения авторизации
Это правило можно использовать в службах федерации Active Directory (AD FS), когда необходимо принять тип входящего утверждения, а затем применить действие, которое определит, будет ли пользователь разрешен или запрещен доступ на основе значения, указанного в правиле. При использовании этого правила вы передаете или преобразовываете утверждения, соответствующие следующей логике правила, на основе любого из параметров, настроенных в правиле:
| Параметр правила | Логика правила |
|---|---|
| Разрешение всем пользователям | Если тип входящего утверждения равен любому типу утверждения, и значение равно любому значению, тогда выпустить утверждение со значением, равным Permit. |
| Разрешить доступ пользователям с этим входящим утверждением | Если тип входящего утверждения равен указанному типу утверждения и значение равно заданному значению утверждения, то выдать утверждение со значением равно Permit |
| Запретить доступ пользователям, имеющим это входящее требование | Если тип входящего утверждения равен указанному типу утверждения и значение равно указанному значению утверждения, то выдать утверждение со значением равно Запретить. |
В следующих разделах приведены основные сведения о правилах утверждений и дополнительные сведения об использовании этого правила.
Правила требований
Правило утверждения представляет экземпляр бизнес-логики, который принимает входящее утверждение, применяет к нему условие (если x затем y) и создает исходящее утверждение на основе параметров условия. В следующем списке приведены важные советы, которые следует знать о правилах утверждений, прежде чем читать далее в этом разделе:
В оснастке управления AD FS правила утверждений можно создавать только с помощью шаблонов правил утверждений.
Правила утверждений обрабатывают входящие утверждения, поступающие либо непосредственно от поставщика утверждений (например, Active Directory или другой службы федерации), либо из выходных данных правил преобразования принятия в доверии к поставщику утверждений.
Правила утверждений обрабатываются обработчиком выдачи утверждений в хронологическом порядке в заданном наборе правил. Задав приоритет правил, можно дополнительно уточнить или фильтровать утверждения, созданные предыдущими правилами в заданном наборе правил.
Шаблоны правил утверждений всегда требуют указания типа входящего утверждения. Однако можно обрабатывать несколько значений утверждений с одним и тем же типом утверждений с помощью одного правила.
Дополнительные сведения о правилах утверждений и наборах правил утверждений см. в разделе Роль правил утверждений. Дополнительные сведения о том, как обрабатываются правила, см. в разделе Роль подсистемы утверждений. Дополнительные сведения об обработке наборов правил утверждений см. в разделе Роль конвейера утверждений.
Разрешение всем пользователям
При использовании шаблона правила "Разрешить всем пользователям" все пользователи получат доступ к проверяющей стороне. Однако для дальнейшего ограничения доступа можно использовать дополнительные правила авторизации. Если одно правило разрешает пользователю доступ к стороне-получателю, а другое правило запрещает ему доступ, результат запрета имеет приоритет над результатом разрешения, и пользователю отказано в доступе.
Пользователи, которым разрешен доступ к доверяющей стороне из службы федерации, по-прежнему могут быть отклонены доверяющей стороной.
Разрешить доступ пользователям с этим входящим утверждением
Если вы используете шаблон правила, чтобы разрешить или запретить пользователей на основе входящего утверждения, и устанавливаете условие на разрешение, вы можете предоставить доступ конкретному пользователю к доверяющей стороне на основе типа и значения входящего утверждения. Например, этот шаблон правила можно использовать для создания правила, разрешающего доступ только тем пользователям, у которых есть групповое утверждение со значением Администраторы домена. Если одно правило разрешает пользователю доступ к доверяющей стороне, а другое правило запрещает пользователю доступ к доверяющей стороне, результат запрета переопределяет результат разрешения, и пользователю отказывают в доступе.
Пользователи, которым разрешен доступ к проверяющей стороне из службы федерации, по-прежнему могут быть отказано в обслуживании проверяющей стороной. Если вы хотите разрешить всем пользователям доступ к проверяющей стороне, используйте шаблон правила "Разрешить всем пользователям".
Запретить доступ пользователям, имеющим это входящее требование
При использовании шаблона правила "Разрешить или Запретить пользователей на основе входящего утверждения" для создания правила и установки условия запрета, можно запретить пользователю доступ к доверяющей стороне на основе типа и значения входящего утверждения. Например, этот шаблон правила можно использовать для создания правила, которое отклонит всех пользователей, имеющих утверждение группы со значением "Пользователи домена".
Если вы хотите использовать условие запрета, но также включите доступ к проверяющей стороне для конкретных пользователей, необходимо позже явно добавить правила авторизации с условием разрешения, чтобы разрешить этим пользователям доступ к проверяющей стороне.
Если пользователю отказывают в доступе, когда механизм выдачи утверждений обрабатывает набор правил, дальнейшая обработка правил прекращается, и AD FS возвращает пользователю ошибку "Доступ запрещен".
Авторизация пользователей
В AD FS правила авторизации используются для выдачи разрешения или запрета утверждения, которое определяет, будет ли пользователь или группа пользователей (в зависимости от используемого типа утверждений) иметь доступ к веб-ресурсам в заданной проверяющей стороне или нет. Правила авторизации можно задать только для доверенных сторон.
Наборы правил авторизации
Различные наборы правил авторизации существуют в зависимости от типа разрешений или запрета операций, которые необходимо настроить. К этим наборам правил относятся следующие:
правила авторизации выдачи: эти правила определяют, может ли пользователь получать подтверждения от доверяющей стороны и, следовательно, доступ к доверяющей стороне.
правила авторизации делегатов: эти правила определяют, может ли пользователь выступать в качестве другого пользователя для стороны, полагающейся на это. Когда пользователь выступает в качестве другого пользователя, утверждения о запрашиваемом пользователе по-прежнему помещаются в токен.
правила авторизации олицетворения: эти правила определяют, может ли пользователь полностью олицетворить другого пользователя проверяющей стороне. Олицетворение другого пользователя является очень мощной возможностью, так как проверяющая сторона не знает, что пользователь олицетворен.
Дополнительные сведения о том, как процесс правила авторизации вписывается в конвейер выдачи утверждений, см. в разделе "Роль обработчика выдачи утверждений".
Поддерживаемые типы утверждений
AD FS определяет два типа утверждений, которые используются для определения того, разрешено пользователю что-либо делать или запрещено. Эти универсальные идентификаторы ресурсов типа утверждений (URI) приведены следующим образом:
разрешение: http://schemas.microsoft.com/authorization/claims/permit
Запретить: http://schemas.microsoft.com/authorization/claims/deny
Создание этого правила
Вы можете создать обе авторизационные правила, используя либо язык правил утверждений, либо шаблон правила Разрешить всех пользователей, либо шаблон правила Разрешить или запретить пользователей на основе входящего утверждения в оснастке управления AD FS. Шаблон правила "Разрешить всем пользователям" не предоставляет никаких параметров конфигурации. Однако шаблон правила "Разрешить или Запретить пользователей на основе входящего утверждения" предоставляет следующие параметры конфигурации:
Указание имени правила утверждения
Указание типа входящего утверждения
Введите входящее значение утверждения
Разрешить доступ пользователям с этим входящим утверждением
Запретить доступ пользователям, имеющим это входящее требование
Дополнительные инструкции по созданию этого шаблона см. в статье Создание правила для разрешения всех пользователей или создание правила для разрешения или запрета пользователей на основе входящего утверждения в руководстве по развертыванию AD FS.
Использование языка правил утверждения
Если утверждение должно отправляться только в том случае, если значение утверждения соответствует пользовательскому шаблону, необходимо использовать пользовательское правило. Для получения дополнительной информации, см. раздел Когда использовать пользовательское правило утверждения.
Пример создания правила авторизации на основе нескольких утверждений
При использовании синтаксиса языка правила утверждений для авторизации утверждений утверждение также может быть выдано на основе наличия нескольких утверждений в исходных утверждениях пользователя. Следующее правило выдает утверждение авторизации только в том случае, если пользователь является членом редакторов групп и прошел проверку подлинности с помощью проверки подлинности 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");
Пример создания правил авторизации, определяющих, кому можно поручать создание или удаление доверительных отношений с прокси-серверами федерации.
Прежде чем служба федерации может использовать прокси-сервер федерации для перенаправления клиентских запросов, необходимо сначала установить доверие между службой федерации и прокси-компьютером сервера федерации. По умолчанию доверие прокси-сервера устанавливается при успешном предоставлении любого из следующих учетных данных в мастере настройки прокси-сервера федерации AD FS:
Учетная запись службы, используемая службой федерации, которую прокси-сервер будет защищать.
Учётная запись домена Active Directory, являющаяся членом группировки локальных администраторов на всех серверах федерации в ферме серверов федерации.
Если вы хотите указать, какой пользователь или пользователи могут создать доверие прокси для данной службы федерации, можно использовать любой из следующих методов делегирования. Этот список методов находится в порядке приоритета, основываясь на рекомендациях группы продуктов AD FS наиболее безопасных и наименее проблемных методов делегирования. Необходимо использовать только один из этих методов в зависимости от потребностей вашей организации:
Создайте группу безопасности домена в Active Directory (например, FSProxyTrustCreators), добавьте эту группу в группу локальных администраторов на каждом из серверов федерации в ферме, а затем добавьте только учетные записи пользователей, к которым необходимо делегировать это право новой группе. Это предпочтительный метод.
Добавьте учетную запись домена пользователя в группу администраторов на каждом из серверов федерации в ферме.
Если по какой-то причине вы не можете использовать любой из этих методов, можно также создать правило авторизации для этой цели. Хотя это не рекомендуется (из-за возможных осложнений, которые могут возникнуть, если это правило написано неправильно), можно использовать настраиваемое правило авторизации, чтобы делегировать права учетным записям пользователей домена Active Directory на создание или даже удаление доверительных отношений между всеми прокси-серверами федерации, связанными с данной службой федерации.
При выборе метода 3 можно использовать следующий синтаксис правила для выдачи заявления о авторизации, которое позволит указанному пользователю (в данном случае contoso\frankm) создать доверительные отношения для одного или нескольких прокси-серверов федерации с Службой федерации. Это правило необходимо применить с помощью команды 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 );Позже, если вы хотите удалить пользователя, чтобы пользователь больше не смог создать доверенные прокси-серверы, можно вернуться к правилу авторизации доверия прокси-сервера по умолчанию, чтобы удалить право пользователя на создание доверия прокси для службы федерации. Это правило также необходимо применить с помощью команды 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 );
Дополнительные сведения об использовании языка правил утверждений см. в разделе Роль языка правил утверждений.