Openid Connect Single Signout с посредником по правам в Enterprise Integrator - PullRequest
Новая
       36

Openid Connect Single Signout с посредником по правам в Enterprise Integrator

0 голосов
/ 15 января 2019

Я использую wso2is в качестве провайдера OpenID для запуска веб-приложения. Затем я выполняю сервисные вызовы из своего приложения через корпоративного интегратора wso2, используя OAuth Mediator и Entitlement Mediator (используя wso2is в качестве моего PDP).

Это все работает очень хорошо. Проблема возникает, когда я иду, чтобы выйти из системы пользователя.

Я отправляю пользователя в / oidc / logout на моем сервере wso2is и перенаправляю его обратно на URL выхода для моего приложения. Это также хорошо работает и регистрирует пользователя из приложения веб-интерфейса.

Проблема возникает, если я тогда пытаюсь получить доступ к сервису, используя маркер доступа пользователя, вышедшего из системы. К счастью, я получу доступ к сервису, пока не истечет токен доступа.

В идеале мне бы хотелось, чтобы wso2ie отказывал в доступе к сервису (либо на уровне посредника oauth, либо на уровне посредника прав), когда пользователь вышел из системы.

Я смотрел на выход из внешнего интерфейса, выход из внутреннего интерфейса и управление сеансами openid, и я не уверен, что лучше всего подходит для того, что я пытаюсь сделать.

Я также посмотрел на конечную точку oidc / revoke, которая чувствует, что она делает именно то, что мне нужно, но я не смог заставить ее работать должным образом. Независимо от того, как я делаю запрос, он всегда жалуется, что этого идентификатора клиента нет в запросе (даже если я явно установил его в публикуемых данных)

Ниже мое определение сервиса в wso2ei 


    <?xml version="1.0" encoding="UTF-8"?>
    <!--Here is the service definition-->
    <proxy xmlns="http://ws.apache.org/ns/synapse"
       name="ManagerPage"
       startOnLoad="true"
       statistics="disable"
       trace="disable"
       transports="https">
    <target>
      <inSequence>
         <property name="scope" scope="default" type="STRING" value="openid"/>
         <oauthService password="admin"
                       remoteServiceUrl="https://a8auth-dev.ls.cbn:8443/services/"
                       username="admin"/>
         <entitlementService callbackClass="org.wso2.carbon.identity.entitlement.mediator.callback.OAUTHEntitlementCallbackHandler"
                             client="basicAuth"
                             remoteServicePassword="PASSWORD"
                             remoteServiceUrl="https://a8auth-dev.ls.cbn:8443/services"
                             remoteServiceUserName="USER">
            <onReject>
               <send>
                  <endpoint>
                     <address uri="https://a8services-dev.ls.cbn:8443/noperm/"/>
                  </endpoint>
               </send>
            </onReject>
            <onAccept>
               <send>
                  <endpoint>
                     <address uri="https://a8services-dev.ls.cbn:8445/manager/"/>
                  </endpoint>
               </send>
            </onAccept>
            <obligations/>
            <advice/>
         </entitlementService>
      </inSequence>
    </target>
    <description/>
    </proxy>

Нужно ли создавать компонент-посредник, который будет проверять управление сеансами OpenID? Может быть, это уже существует?

Нужно ли расширять OAuth Mediator для лучшей проверки статуса сеансов?

Любой пример, ссылки или указатели в правильном направлении были бы хороши.

Спасибо.

Ответы [ 2 ]

0 голосов
/ 15 февраля 2019

Спецификация OIDC только определяет, как обращаться с аутентифицированным сеансом пользователя (хотя маркер доступа является частью ответа). Таким образом, при выходе из OIDC мы просто имеем дело с завершением аутентифицированного сеанса пользователя.

Отзыв токена, полученного при входе в OIDC, выходит за рамки спецификации. Даже в нашей текущей реализации это не является чем-то простым, поскольку мы не поддерживаем корреляцию между id_token и выданным токеном доступа.

Однако у нас есть точка расширения, введенная в [1], которую можно использовать для аналогичного требования во время выхода из системы OIDC. Следует отметить, что даже с этим расширением корреляция между id_token и токеном доступа должна обрабатываться разработчиком расширения.

[1] https://github.com/wso2/product-is/issues/3227

Пожалуйста, перейдите по ссылке ниже для лучшего объяснения

http://wso2 -oxygen-tank.10903.n7.nabble.com / Действительность-оф-доступа-токенов-после-РСИН-SLO-td158896.html # a158919

0 голосов
/ 14 февраля 2019

Оказывается, я использовал неправильный идентификатор для токена, который пытался отозвать. Как только я начал использовать атрибут jti из jwt, все заработало как положено.

...