С конфигой samlWebSso20 на WebSphere Либерти и сервере ADFS, что такое правильный способ определения ролей безопасности/контрсилы

Question

Я положил в месте samlWebSso20 конфигурации с помощью Liberty Buildpack на Bluemix и ADFS idp от моего клиента.

У меня есть одно веб-приложение, развернутое на экземпляре Liberty.

Я использую опцию Server Directory нажать на Bluemix, как описано here

Вот мой server.xml:

<?xml version="1.0" encoding="UTF-8"?> 
<server description="johan"> 
<featureManager> 
    <feature>webProfile-7.0</feature> 
    <feature>samlWeb-2.0</feature> 
    <feature>appSecurity-2.0</feature> 
</featureManager> 

<samlWebSso20 id="defaultSP" nameIDFormat="unspecified" 
    spCookieName="my_cookie" 
    idpMetadata="${server.config.dir}/resources/security/FederationMetadata.xml" 
    userIdentifier="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" 
    sessionNotOnOrAfter="2h"> 
</samlWebSso20> 

<keyStore id="defaultKeyStore" password="***" /> 

<webApplication context-root="/" location="MySampleApp.war" name="MySampleApp" type="war"> 
    <security-role name="any-authenticated"> 
     <special-subject type="ALL_AUTHENTICATED_USERS" /> 
    </security-role> 

    <security-role name="administrators"> 
     <user name="user1@customer.com" /> 
     <user name="user2@customer.com" /> 
    </security-role> 
</webApplication> 

А вот web.xml приложения, размещенного на Liberty

<?xml version="1.0" encoding="UTF-8"?> 
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" 
version="3.0"> 
<security-constraint> 
    <display-name>SampleAppServicesConstraint</display-name> 
    <web-resource-collection> 
     <web-resource-name>SampleAppServices</web-resource-name> 
     <url-pattern>/*</url-pattern> 
     <http-method>GET</http-method> 
     <http-method>PUT</http-method> 
     <http-method>HEAD</http-method> 
     <http-method>TRACE</http-method> 
     <http-method>POST</http-method> 
     <http-method>DELETE</http-method> 
     <http-method>OPTIONS</http-method> 
    </web-resource-collection> 
    <auth-constraint> 
     <role-name>any-authenticated</role-name> 
    </auth-constraint> 
</security-constraint> 
<security-constraint> 
    <display-name>SampleAppAdminConstraint</display-name> 
    <web-resource-collection> 
     <web-resource-name>SampleAppAdmin</web-resource-name> 
     <url-pattern>/admin</url-pattern> 
     <http-method>GET</http-method> 
    </web-resource-collection> 
    <auth-constraint> 
     <role-name>administrators</role-name> 
    </auth-constraint> 
</security-constraint> 
<display-name>SampleApp</display-name> 
<welcome-file-list> 
    <welcome-file>index.html</welcome-file> 
    <welcome-file>index.htm</welcome-file> 
    <welcome-file>index.jsp</welcome-file> 
    <welcome-file>default.html</welcome-file> 
    <welcome-file>default.htm</welcome-file> 
    <welcome-file>default.jsp</welcome-file> 
</welcome-file-list> 

Когда я попал в/админ маршрут SampleApp, я попадаю на страницу ADFS входа. Затем я вхожу в систему с user1@customer.com и перенаправляюсь к моему приложению. Тем не менее, я получаю 403, даже если пользователь находится в роли «администраторов». Ниже приводится сообщение об ошибке в логах:

[AUDIT ] CWWKS9104A: Authorization failed for user user1@customer.com while invoking MySampleApp on /admin. The user is not granted access to any of the required roles: [administrators]. 

Обратите внимание, что если изменить роль AuthConstraint от administrators к any_authenticated для/администратора маршрута, user1@customer.com может затем получить доступ к странице администратора.

Не могли бы вы поделиться опытом и объяснить, что я делаю неправильно.

Благодаря

Answer 1

Изменить

<security-role name="administrators"> 
    <user name="user1@customer.com" /> 
    <user name="user2@customer.com" /> 
</security-role> 

Для

<security-role name="administrators"> 
     <user name="user1@customer.com" access-id="user:<issuer name here> /user1@customer.com"/> 
     <user name="user2@customer.com" access-id="user:<issuer name here> /user1@customer.com"/> 
</security-role> 

где имя эмитента, как оказалось в SAML.