WordPress Single Sign On с использованием SSP и ADFS в качестве прокси-сервера IdP

Question

Ну, я застрял в течение нескольких дней, и это единственная моя надежда.

Я настроил Windows 2012 r2 с ADFS 3.0, bitnami Wordpress (4.2.2) с помощью модуля SAML 2.0 Single Sign on и сервера Ubuntu с SimpleSAMLphp 1.13.

конфигурация

Wordpress выглядит следующим образом:

WordPress NameID политик:

WordPress атрибуты:

Для аутентификации источника я использую модуль файл ППСА. У него есть атрибуты:

User-Name для пользователя id, mail для адреса пользователя и Filter-Id для группы пользователей.

На стороне ADFS, я настроил доверие поставщика услуг как SSP и доверие доверяющей стороны как WP.

правила претензии в отношении тех, являются:

SSP:

Правило 1: Для того, чтобы преобразовать политику идентификационное имя. Если это правило не установлено, протокол SSP WP присваивает неверной ошибке NameIDPolicy.

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] == "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

Правило 2: Передайте все требования

c:[Type == "https://example.com/simplesamlphp/saml2/idp/metadata.php"] => issue(claim = c);

WordPress:

Правило 1: Преобразование атрибута имя атрибута РГ

c:[Type == "User-Name"] => add(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Value = c.Value);

Правило 2: Преобразование атрибутов почты

c:[Type == "mail"] => add(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/emailaddress", Value = c.Value);

Правило 3: Преобразование группы атрибутов

c:[Type == "Filter-Id"] => add(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/Group", Value = c.Value);

Правило 4: Con Vert в GivenName приписывать

c:[Type == "User-Name"] => add(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/givenname", Value = c.Value);

Правило 5: Преобразовать Фамилия атрибут

c:[Type == "User-Name"] => add(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/surname", Value = c.Value);

Правило 6: Преобразование политики Имя Идентификатор & выдает все претензии

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");

Пользователь получает аутентификацию штрафа (SP/IdP-Initiated). Но на стороне WP я получаю сообщение об ошибке Username was not provided.

ADFS журнал трассирующими показывает мне SSO token is null or empty. Cannot write SSO token to Cookies.

Я проверил IdP для входа пользователя в систему, и это показывает, пользователь вошел в систему. Журнал Tracer также показывает Valid assertion returned from 'https://example.com/simplesamlphp/saml2/idp/metadata.php'

Я предполагаю, что есть что-то не так с правилами претензий, но я не являюсь конечно, потому что конфигурация выглядит и работает нормально.

Любые указатели приветствуются!

Спасибо!

Answer 1

Так цепь WP -> ADFS -> SSP

Обычно для NameID, вы используете правила преобразования, например,

Преобразование электронной почты в NameID с форматом электронной почты.

Для CP вам необходимы правила сквозной передачи для каждого атрибута.

Это правило "c: [Тип ==" https://example.com/simplesamlphp/saml2/idp/metadata.php "] => issue (Claim = c);" не проходит через все правила - лучше всего их выполнять индивидуально.

Правила RP выглядят правильно, но правило NameID имеет формат электронной почты, поэтому он должен быть получен из электронной почты, а не из имени.