Весна безпека на Wildfly: помилка під час виконання ланцюжка фільтрів


194

Я намагаюся інтегрувати розширення Spring Security SAML з Spring Boot .

З цього питання я розробив повний зразок заявки. Його вихідний код доступний на GitHub:

Запустивши його як додаток Spring Boot (працює проти вбудованого сервера додатків SDK), WebApp працює чудово.

На жаль, той же процес AuthN взагалі не працює на Undertow / WildFly .

Згідно з журналами, IdP фактично виконує процес AuthN : інструкції моєї спеціальної UserDetailsреалізації правильно виконані. Незважаючи на потік виконання, Spring не налаштовує та зберігає привілеї для поточного користувача.

@Component
public class SAMLUserDetailsServiceImpl implements SAMLUserDetailsService {

    // Logger
    private static final Logger LOG = LoggerFactory.getLogger(SAMLUserDetailsServiceImpl.class);

    @Override
    public Object loadUserBySAML(SAMLCredential credential)
            throws UsernameNotFoundException, SSOUserAccountNotExistsException {
        String userID = credential.getNameID().getValue();
        if (userID.compareTo("jdoe@samplemail.com") != 0) {     // We're simulating the data access.
            LOG.warn("SSO User Account not found into the system");
            throw new SSOUserAccountNotExistsException("SSO User Account not found into the system", userID);
        }
        LOG.info(userID + " is logged in");
        List<GrantedAuthority> authorities = new ArrayList<GrantedAuthority>();
        GrantedAuthority authority = new SimpleGrantedAuthority("ROLE_USER");
        authorities.add(authority);
        ExtUser userDetails = new ExtUser(userID, "password", true, true, true,
                true, authorities, "John", "Doe");
        return userDetails;
    }
}

Під час налагодження я виявив, що проблема покладається на FilterChainProxyклас. Під час виконання, атрибут FILTER_APPLIEDз ServletRequestмає нульове значення, таким чином Spring очищає SecurityContextHolder.

private final static String FILTER_APPLIED = FilterChainProxy.class.getName().concat(".APPLIED");

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
    boolean clearContext = request.getAttribute(FILTER_APPLIED) == null;
    if (clearContext) {
        try {
            request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
            doFilterInternal(request, response, chain);
        } finally {
            SecurityContextHolder.clearContext();
            request.removeAttribute(FILTER_APPLIED);
        }
    } else {
        doFilterInternal(request, response, chain);
    }
}

У VMware vFabric tc Sever і Tomcat все працює абсолютно добре. Чи маєте ви якесь уявлення про вирішення цього питання?


2
У більшості ситуацій SecurityContextHolderслід очистити після запиту. Єдине призначення цього коду полягає в тому випадку, якщо ланцюг фільтрів застосовується більше одного разу під час одного запиту (у цьому випадку контекст повинен очищати лише початковий ланцюг). Тому я не думаю, що це питання.
Шон Овець

2
До речі, така поведінка щоразу відключає процес входу. Чи є спосіб виправити це, наприклад, правильно налаштувавши моє програмне забезпечення АС?
vdenotaris

1
Не впевнений, що ви маєте на увазі під цим. Яка поведінка та як це недійсне вхід? Очищення контексту, коли нитка закінчує обробку запиту, є нормальною поведінкою - важливо не допустити протікання локальних даних потоку до пулу потоків. У цей момент контекст зазвичай повинен кешуватися в сеансі користувача. Таким чином, він не повинен визнати недійсним логін.
Шон овець

2
Як описано вище, після SSO сервер додатків очищає дані сеансу та дані аутентифікації. Це відбувається лише з Wildfly: той самий код чудово працює з Tomcat.
vdenotaris

11
SecurityContextHolder.clearContext()не очищує дані сеансу. Він видаляє ThreadLocalзберігання контексту до виходу потоку назад у пул потоків. Моя думка, що це завжди має відбуватися в кінці запиту, тому те, що ви бачите, є нормальним і, швидше за все, не стане причиною вашої проблеми.
Шон Овець

Відповіді:


7

Досліджуючи проблему, я помітив, що у запиті про автентичність є певна проблема з файлами cookie та рефератами.

В даний час автентифікація wildfly буде працювати, якщо ви зміните контекст webapplication на Root Context:

 <server name="default-server" default-host="webapp">
     <http-listener name="default" socket-binding="http"/>
     <host name="default-host" alias="localhost" default-web-module="sso.war"/>
 </server>

Після перезапуску wildfly та очищення файлів cookie все має працювати, як очікувалося


приємне рішення, якщо ви відомі з WildFly та JBOSS, можете поглянути на це питання stackoverflow.com/questions/59006162/…
ZINE Mahmoud
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.