Неверная политика NameID для wordpress

У меня есть следующая настройка:

Windows 2012 R2 с ADFS 3.0. Настройка WordPress в качестве SP (доверие к проверяющей стороне) и SimpleSAMLphp в качестве IdP (доверие к стороне требований).

Я хочу аутентифицировать пользователей WordPress с помощью SSP. Поток управления выглядит следующим образом: пользователь входит в WordPress. Затем на странице отображается количество поставщиков IdP, настроенных на сервере ADFS. Пользователь выбирает SSP. Пользователь аутентифицируется с помощью SSP, и ответ отправляется в ADFS, которая, в свою очередь, передает информацию в WordPress.

Я настроил все проверяющие и заявляющие стороны, и они хорошо работают по отдельности (WP-ADFS, ADFS-SSP), но когда я пытаюсь аутентифицировать WP с помощью SSP, мне выдается error: The SAML authentication request had a NameID Policy that could not be satisfied.

У меня есть правила, настроенные как: Правило стороны претензии:

Преобразование входящего правила: переход NameID в имя учетной записи Windows

Правило проверяющей стороны:

Правило 1:

Правила LDAP: SAM-Account-Name->имя учетной записи Windows, адреса электронной почты->адрес электронной почты

Правило 2:

Преобразование входящего требования: имя учетной записи Windows-> NameID Transient Identifier

Я только начал работать с SSO на сервере Windows, поэтому мало что знаю о правиле претензий, и я предполагаю, что с ним может быть что-то не так, поскольку по отдельности все модули работают нормально. (например, WP как SP и ADFS как IdP, ADFS как SP и SSP как IdP).

Что именно я делаю не так.

Пожалуйста, дайте мне знать, если я пропустил какие-либо детали.

Спасибо!


wordpress single-sign-on adfs3.0 simplesamlphp
person harshad    schedule 14.03.2016    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Первый шаг — выяснить, какая политика NameID запрашивается. Установите SAML Tracer в FireFox и запустите свой поток. Вы увидите, что AuthnRequest может иметь в списке NameIDPolicy (пример <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress").

Как только вы узнаете, какой NameID необходим, вы можете попытаться настроить Wordpress для принятия другого типа (по умолчанию SSP использует urn:oasis:names:tc:SAML:2.0:nameid-format:transient) или настроить SSP для выпуска NameID в ожидаемом формате.

Вот пример использования authproc в SSP для использования атрибута mail для NameId.

'authproc' => array(
             60 => array(
                    'class' => 'saml:AttributeNameID',
                    'attribute' => 'mail',
                    'Format' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress',
            ),
    ),

Существуют и другие NameID задокументированные фильтры генерации.

person Patrick    schedule 14.03.2016
comment
Спасибо за предложение дополнения, это было действительно полезно. В трассировщике я обнаружил, что saml AuthnRequest указывает NameIDPolicy как transient в запросе saml WP и ADFS. Однако AuthnRequest для SSP указывает NameIDPolicy как unspecified. Я установил NameIDPolicy на transient в sp-remote.php SSP, и ответ SAML также указывает то же самое для SSP. Однако на стороне WP я получаю сообщение об ошибке NameIDPolicy в ответном сообщении SAML. - person harshad; 15.03.2016
comment
Ну, я нашел причину. В ADFS я установил правило утверждения на unspecified (скорее всего, во время различных отладочных решений). Но теперь, после установки NameIDPolicy на email везде, я думаю, что проблема решена, потому что теперь я получаю сообщение об ошибке, например, username not provided для входа в систему, инициированного SP/IdP. - person harshad; 15.03.2016