Jaspic: обрабатывать доступ к защищенному ресурсу

Question

Я (еще) изучаю JASPIC, выполняя некоторые эксперименты простым проектом: this one. Когда я вызываю защищенные ресурсы, ServerAuthModule проверяет учетные данные через validateRequest и возвращает AuthStatus.SUCCESS. Ответ HTTP составляет 200, но он пуст. Я использую эти два curl команды для теста:

curl -H "Content-Type: application/json" -X POST -d '{"username":"xxx","password":"xxx"}' http://localhost:8080/JaspicWeb/services/user/login 
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0NzE0NzE1ODcsInN1YiI6InVzZXJBIn0.Gyf7w2192vlz3uSwjwtf8z1p9n9k3IqtQMQrubA7oYI" -X GET http://localhost:8080/JaspicWeb/services/user/userA 

Первая команда, чтобы получить маркер, используемый во втором. Я использую Jaspic с Wildfly10 и RestEasy.

Обновление: Я обновил связанный проект. Теперь это полный рабочий пример Jaspic.

Answer 1

SAM's CallbackHandler является причиной ваших проблем.

Первый it.jaspic.sec.TokenConfigProvider пренебрегает обработчик, переданный ему среды выполнения:

public ServerAuthConfig getServerAuthConfig(String layer, String appContext, CallbackHandler handler) throws AuthException { 
    return serverAuthConfig; 
} 

Затем it.jaspic.sec.TokenServerConfig использует свой собственный обработчик, который в основном делает ничего:

public TokenServerConfig() throws AuthException { 
    // ... 
    handler = new CallbackHandler() { 
    @Override 
    public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException { 
     // just logs its arguments 
    } 
    }; 
} 

Следовательно, it.jaspic.sec.TokenSAM#validateRequest не смог коммуницировать идентификатор вызывающего абонента во время выполнения. Так как он по-прежнему ошибочно возвращает AuthStatus.SUCCESS, это довольно неопределенное поведение с этого момента, по крайней мере, до JASPIC. Это забавно, как если бы контейнер Servlet пытался удержать обе стороны в этом случае, почитая как SAM AuthStatus, предлагающий успешный обмен сообщениями об аутентификации, с одной стороны, так и <security-constraint> приложения - с другой. Следует признать, что 401, 403 или, возможно, еще лучше, ответ 500, указывающий на механизм аутентификации, не подчиняющийся его контракту, мог быть менее запутанным.

Очевидным решением является передача обработчика в SAM. Очевидно, что API не очень помогает, но для использования одного случая с одним слоем/единственным приложением для проверки подлинности с использованием механизма аутентификации должно быть достаточно лениво создать экземпляр ServerAuthConfigс обработчиком, когда он сначала запрашивается через время выполнения через getServerAuthConfig призывание:

public synchronized ServerAuthConfig getServerAuthConfig(String layer, String appContext, CallbackHandler handler) { 
    if (serverAuthConfig == null) { 
    serverAuthConfig = new TokenServerConfig(handler); 
    } 
    return serverAuthConfig; 
} 

И, конечно же, новый конструктор под названием выше (который имеет только хранить аргумент обработчика) должен быть введен в it.jaspic.sec.TokenServerConfig.

Эти два изменения должны сделать конечную точку /services/user/userA доступной.