Когда следует использовать правило пропуска или фильтрации утверждений
Это правило можно использовать в службы федерации Active Directory (AD FS) (AD FS), если необходимо принять определенный тип входящего утверждения, а затем применить действие, которое определит, какие выходные данные должны происходить на основе значений входящего утверждения. При использовании этого правила вы пропускаете или фильтруете все утверждения, соответствующие логике правила в следующей таблице, на основе параметров, настроенных в правиле.
Параметр правила | Логика правила |
---|---|
Передавать все значения требования | Если тип входящего утверждения равен указанному типу утверждения, а значение равно любому значению, то следует пропустить утверждение. |
Пропускать только конкретное значение утверждения | Если тип входящего утверждения равен указанному типу утверждения, а значение равно указанному значению утверждения, то следует пропустить утверждение. |
пропуск только значений утверждений, соответствующих указанному значению суффикса электронной почты; | Если тип входящего утверждения равен указанному типу утверждения, а значение равно указанному значению суффикса, то следует пропустить утверждение. |
Пропускать только значения утверждения, начинающиеся с указанного значения | Если тип входящего утверждения равен указанному типу утверждения, а значение начинается с указанного значения утверждения, то следует пропустить утверждение. |
В следующих разделах содержатся основные сведения о правилах утверждений и предоставляются дополнительные сведения об использовании этого правила.
Общие сведения о правилах утверждения
Правило утверждения представляет экземпляр бизнес-логики, который предусматривает применение к входящему утверждению условия (если X, то Y) и создание исходящего утверждения на основе параметров условия. В следующем списке перечислены важные рекомендации в отношении правил утверждений, с которыми следует ознакомиться перед прочтением дальнейших сведений в этом разделе.
В оснастке управления AD FS правила утверждений можно создавать только с помощью шаблонов правил утверждений.
Правила утверждений обрабатывают входящие утверждения непосредственно от поставщика утверждений (например, Active Directory или другой службы федерации) или из выходных данных правил преобразования принятия для отношения доверия с поставщиком утверждений.
Правила утверждений обрабатываются подсистемой выдачи утверждений в хронологическом порядке в пределах заданного набора правил. Установив приоритет правил, можно дополнительно уточнить или отфильтровать утверждения, созданные предыдущими правилами в данном наборе правил.
Шаблоны правил утверждения всегда требуют указывать тип входящего утверждения. Тем не менее, можно обрабатывать несколько значений утверждений с одним типом утверждения, используя одно правило.
Дополнительные сведения о правилах утверждений и наборах правил утверждений см. в разделе "Роль правил утверждений". Дополнительные сведения о том, как обрабатываются правила, см. в разделе "Роль обработчика утверждений". Дополнительные сведения об обработке наборов правил утверждений см. в разделе "Роль конвейера утверждений".
Передавать все значения требования
При использовании этого действия все значения входящих утверждений для указанного типа утверждений пропускаются как исходящие утверждения. Например, когда тип входящего утверждения указан как тип утверждения роли, все значения входящих утверждений индивидуально копируются в новые исходящие утверждения с типом роли.
Фильтрация утверждения
В AD FS термин фильтрации утверждений означает фильтрацию или ограничение входящих значений утверждений, чтобы передавать или передавать только определенные значения в качестве исходящих утверждений. Существует шаблон правила Пропуск или фильтрация входящего утверждения, делающий эту функцию возможной. В свойствах этого правила можно задать условия для фильтрации входящих значений, чтобы пропускались только значения, удовлетворяющие заданным условиям.
Например, вы можете использовать это правило для пропуска только утверждений, соответствующих значению утверждения "Покупатель" и имеющих тип входящего утверждения "Роль", или выдавать только утверждения об имени пользователя, но не утверждения, содержащие номер социального страхования пользователя.
Когда вы применяете условие фильтра с этим правилом, все входящие утверждения проверяются, чтобы определить, какие из них соответствуют критерию, установленному правилом. Все остальные утверждения игнорируются; таким образом, пропускаются только указанные значения утверждений, соответствующие типу выбранного утверждения.
Например, как показано на следующем рисунке, если правило устанавливается с условием для фильтрации только входящих утверждений, которые ключом к типу утверждения участника-пользователя, а также заканчиваются @fabrikam.com, все остальные входящие утверждения игнорируются, если они не соответствуют этим критериям. Это включает входящее утверждение с типом утверждения адреса электронной почты, даже если его значение утверждения заканчивается @fabrikam.com. В этом случае только утверждение, содержащее значение Nick@fabrikam.com , отправляется проверяющей стороне.
Настройка этого правила для отношения доверия с поставщиком утверждений
При использовании отношений доверия с поставщиком утверждений это правило можно настроить для пропуска только входящих утверждений от поставщика утверждений, удовлетворяющих определенным ограничениям. Например, может потребоваться принять только утверждения электронной почты от поставщика утверждений; Таким образом, этот шаблон правила используется для принятия типов утверждений электронной почты, которые заканчиваются доменным именем поставщика утверждений (DNS).
Настройка этого правила в отношениях доверия с проверяющей стороной
При использовании отношений доверия с проверяющей стороной это правило можно настроить для пропуска или фильтрации исходящих утверждений, которые будут отправляться проверяющей стороне. Некоторые проверяющие стороны могут не понимать определенные типы утверждений, или некоторые утверждения могут содержать конфиденциальные сведения, которые не должны отправляться определенным проверяющим сторонам. Данный шаблон правила помогает осуществить эти политики для конкретных отношений доверия с проверяющей стороной.
Создание правила
Это правило создается с помощью языка правила утверждения или использования шаблона правила передачи или фильтрации входящего утверждения в оснастке управления AD FS. Этот шаблон правила предоставляет следующие возможности настройки:
указание имени правила утверждения;
указание типа входящего утверждения;
Передавать все значения требования
Пропускать только конкретное значение утверждения
пропуск только значений утверждений, соответствующих указанному значению суффикса электронной почты;
Пропускать только значения утверждения, начинающиеся с указанного значения
Дополнительные инструкции по созданию этого шаблона см. в разделе "Создание правила для передачи или фильтрации входящего утверждения " в руководстве по развертыванию AD FS.
С помощью языка правил утверждений
Если утверждение должно отправляться только в том случае, когда его значение соответствует настраиваемому шаблону, необходимо использовать настраиваемое правило. Дополнительные сведения см. в разделе "Когда следует использовать правила утверждений".
Примеры создания синтаксиса правила пропуска или фильтрации
Простое правило фильтрации будет выполнять фильтрацию на основе одного из свойств, описанных выше. Например, следующее правило будет пропускать все утверждения электронной почты:
c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] => issue(claim = c);
Фильтры можно логически объединять с помощью оператора AND. Например, следующее правило принимает все утверждения электронной почты со значением johndoe@fabrikam.com:
c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", value == "johndoe@fabrikam.com "] => issue(claim = c);
В приведенных выше примерах в фильтрах всегда используется оператор равенства. Язык правил утверждений поддерживает следующие операторы:
== — равно (с учетом регистра)
!= — не равно (с учетом регистра)
=~ — соответствует регулярному выражению
!~ — не соответствует регулярному выражению
Например, следующее правило будет принимать все утверждения электронной почты, которые не были выданы сервером федерации и имеют суффикс boeing.com:
c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", value =~ "^.*@boeing\.com$" , issuer != "LOCAL AUTHORITY"] => issue(claim = c);
Рекомендации по созданию настраиваемых правил
Фильтр может применяться для одного или нескольких свойств каждого утверждения, как описано в следующей таблице.
Свойство утверждения | Описание |
---|---|
Тип | Тип утверждения (обычно в виде URI) отражает неявное соглашение между партнерами в федерации о том, какого рода информация передается в утверждении. Например, утверждения типа http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress будут содержать адрес электронной почты пользователя. |
Значение | Значение утверждения. Например, утверждение типа http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress может иметь значение johndoe@fabrikam.com |
ValueType | ValueType представляет способ интерпретации сведений, содержащихся в значении утверждения. Обычно значение ValueType будет задано http://www.w3.org/2001/XMLSchema#string, но значение утверждения может содержать данные в кодировке Base64Binary (например, изображение) или дату, логическое значение и т. д. |
Издатель | Издатель представляет сторону, ранее выдавшую утверждения о пользователе. Если утверждения получены на сервере федерации поставщика утверждений, издатель всех утверждений будет иметь значение LOCAL AUTHORITY. Если утверждения были получены сервером федерации поставщика федерации, в качестве издателя утверждений будет установлен идентификатор поставщика утверждений, подписавшего токен. Таким образом, при обработке правил в утверждениях, полученных от поставщика утверждений, в качестве издателя всех утверждений будет установлено одно и то же значение. При создании правил для проверяющей стороны свойство Issuer (издатель) может использоваться, чтобы различать утверждения, исходящие от разных поставщиков утверждений. |
OriginalIssuer | Это свойство утверждения предназначено для передачи сведений о сервере федерации, изначально выдавшем утверждение. Поскольку в качестве свойства Issuer утверждений устанавливается последний сервер федерации, подписавший токен, сведения об исходном издателе полезны в сценариях, когда утверждение проходит через несколько серверов федерации (например, проверяющей стороне, которая получает токен от сервера федерации поставщика федерации, может быть нужно знать, какой конкретный сервер федерации поставщика утверждений выполнил проверку подлинности пользователя). |
Свойства | Помимо пяти свойств, описанных выше, каждое утверждение также имеет контейнер свойств, в котором могут храниться названные свойства. Эти свойства не сериализуются в токене и имеют смысл только для передачи сведений между компонентами конвейера выдачи утверждений в рамках области одного сервера федерации. Например, можно задать свойство во время обработки правил поставщика утверждений, а затем ссылаться на это свойство в правилах проверяющей стороны. |