OAuth 2.0, сервер приложений - WebSphere Liberty - неясное перенаправление на Microsoft через 10 минут

ProgramBox

OAuth 2.0, сервер приложений — WebSphere Liberty — неясное перенаправление на Microsoft через 10 минут

Post author:admin
Запись опубликована:1 февраля, 2023
Post category:Вопросы по программированию

#javascript #oauth-2.0 #oauth #websphere-liberty

Вопрос:

У меня простая служба REST со встроенным интерфейсом Swagger, сервер приложений — WepSphere Liberty, я успешно реализовал поток кода авторизации для авторизации OAuth 2.0 с использованием функции openidConnectClient. Работает нормально, пользователь регистрируется на сайте Microsoft и успешно перенаправляется на мое веб-приложение. Проблема в том, что через 10 минут, когда я пытаюсь выполнить простой запрос к серверу через пользовательский интерфейс Swagger, я получаю сообщение об ошибке

 <html xmlns="http://www.w3.org/1999/xhtml">
<head>
<script type="text/javascript" language="javascript">var loc=window.location.href;document.cookie="WASReqURLOidcn377114111=" loc "; path=/;"</script><script type="text/javascript" language="javascript">window.location.replace("https://login.microsoftonline.com/xxxxxxxxx-xxxx-xxxx-xxxx-xxxxx/oauth2/v2.0/authorize?response_type=codeamp;client_id=.......</script>
<title>Redirect To OP</title> 
</head>
<body></body>
</html>

server.xml:

     <authFilter id="app-filter">
        <requestHeader id="excludeBearer" name="Authorization" value="Bearer" matchType="notContain"/>
        <requestHeader id="excludeBasic" name="Authorization" value="Basic" matchType="notContain"/>
    </authFilter>
    <openidConnectClient id="app-oidc"
                         authFilterRef="app-filter"
                         useSystemPropertiesForHttpClientConnections="true"
                         jwkEndpointUrl="https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/discovery/v2.0/keys"
                         issuerIdentifier="https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0"
                         audiences="<clientId of our application>"
                         userIdentityToCreateSubject="<our custom claim>"
                         mapIdentityToRegistryUser="false"
                         inboundPropagation="none"
                         signatureAlgorithm="RS256"
                         tokenReuse="true"
                         clientId="..."
                         clientSecret="..."
                         authorizationEndpointUrl="https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/oauth2/v2.0/authorize"
                         tokenEndpointUrl="https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/oauth2/v2.0/token"
                         responseType="code"
                         groupIdentifier="roles"
                         sslRef="defaultSSLConfig">
    </openidConnectClient>

Похоже, что-то происходит, и он пытается авторизоваться снова
Для меня это странно, время жизни токена oauth по умолчанию составляет 1 час 30 минут, я даже не знаю, что именно происходит

Может ли кто-нибудь помочь мне с этой проблемой?

Ответ №1:

Я полагаю, что это связано с истечением срока действия кэша Liberty, и кэшированный объект был удален. Существует несколько способов решения этой проблемы, и я предпочитаю следующее.

1. добавьте <authnCache timeout="1800s" /> это изменение тайм-аута кэша с 10 минут по умолчанию до 30 минут.

(Необязательно) 2. добавьте disableLtpaCookie=»true» в элемент конфигурации openidConnectClient, который будет использовать время жизни id_token в качестве времени сеанса безопасности.

3. добавьте isClientSideRedirectSupported=»false» в элемент конфигурации openidConnectClient, который поддерживает javascript, и перенаправьте браузер напрямую на IdP для входа в систему.

Ответ №2:

Я пока не могу комментировать, но у меня есть несколько вопросов / комментариев.

Какая конкретная ошибка?
После авторизации Microsoft вы должны получить токен авторизации, но запрашиваете ли вы токен доступа?
Выполняется ли запрос до этих 10 минут
Кроме того, дважды проверьте свои запросы URL, чтобы увидеть, нет ли ошибок в запросе.

1. На самом деле, нет никакой ошибки в значении «что-то не работает». Мы наблюдаем попытку повторного входа в систему через 10 минут, точно так же, как если время ожидания сеанса составляет 10 минут. Вопрос в том, откуда берутся эти 10 минут и как мы можем управлять этим таймаутом? Первые 10 минут все работает нормально, все остальные настройки в порядке: мы можем войти в систему (т. Е. URL-адреса перенаправления настроены правильно, и мы извлекаем и используем access_token. Функция openidConnectClient делает это волшебство).

Ответ №3:

@Chunlong

Не могли бы вы, пожалуйста, предоставить дополнительную информацию о тайм-ауте кэша? Это о authCache чем? (Документы IBM)

PS Просто небольшое замечание относительно isClientRedirectSupported=»false»: если использовать эту функцию, сервлет, предоставляемый openidConnectClientFeature, не будет отправлять обратно 302 при переходе к приложению. Вместо этого — servlet ответит статусом 200 и html с формой самопоставки. Технически — это не перенаправление, но результат будет тем же: браузер отобразит страницу входа IdP.

(К сожалению, у меня недостаточно репутации для комментариев)

1. Да, ссылка, которую вы разместили, верна. Например, чтобы установить время ожидания кэша равным 30 минутам, добавьте authnCache timeout =»1800s»

2. @Chunlong, большое спасибо! Не знал о таком уровне WLP…