SAML и фоновая аутентификация REST службы

Question

У меня есть рабочий процесс приложения, как этот

(A) User-Agent (браузер) < -----> (B) App сервер < ------ > (C) Служба REST

Предположим, что сервер приложений (B) является поставщиком услуг SAML, а пользовательский домен домена аутентифицируется из браузера (A) на сервер приложений (B) с использованием профиля SSO веб-браузера.

Как приложение, выполняющееся на (B), аутентифицируется службе REST (C) как user@domain.com? (Предполагая, что B и C оба являются SAML SP на одном и том же IdP.)

Если браузер только что вызывал AJAX-вызовы как для B, так и для C, это было бы просто. Но если служба REST вызывается непосредственно из приложения, что вы делаете?

Что я борюсь с: Если само приложение не SAML SP, но интегрированного с одной (скажем, с помощью Шибболета SP и заголовок REMOTE_USER) приложение может никогда не увидеть SAML утверждения. Вы знаете, что пользователь вошел в систему и прошел аутентификацию против IdP, но не имеет возможности получить утверждение SAML для передачи на бэкэнд-сервис.

Есть ли решение или мне невезение?

Answer 1

Да, ничто не мешает вашей App Server (В) оба выступают в качестве поставщика услуг, принимая входящие утверждения из A и выступает в качестве поставщика удостоверений, выдачей своего собственного SAML билета, который он направляет на C.

Если у вас нет доступа к исходному утверждению, вам нужно будет выпустить новое утверждение в B. Если у вас есть доступ к исходному утверждению, вы можете перенаправить его на C, если C настроен на игнорирование ограничений аудитории, которые ограничивают утверждение должно быть действительным только для B.

Answer 2

Поскольку вы говорите сервер приложений B и служба REST C - оба SAML SP с одним и тем же идентификатором SAML IdP, у вас уже есть механизм, который позволяет веб-клиенту аутентифицироваться непосредственно с C (независимо от B) через SAML Web Browser SSO Profile, справа? И когда этот «рабочий процесс входа» был завершен, клиент API имеет токен аутентификации, который представляет тот факт, что «user@domain.com аутентифицирован IdP X для использования SP C» и может использоваться для аутентификации вызовов C в течение некоторого периода времени (до тех пор, пока токен авторизации не истечет).

Но B и C - отдельные услуги. И если они имеют разные SAML Поставщик услуг entityIDs зарегистрированных с тем же IdP X, то IdP X будет не рассматривать эти утверждения эквивалентны:

1. user@domain.com заверяется IdP X для использования SP C
2. user @ domain.ком заверяется IdP X использовать SP B

Так не должно быть никакого способа для обслуживания B использовать маркер аутентификации, представляющий утверждение 2 выше (что он может получить от своего SAML SSO login workflow), чтобы получить токен auth, представляющий оператор 1 выше (который может поступать только из рабочего процесса входа в систему SAML SSO для C). Также не должно быть возможным для обслуживания B «пройти» клиента API к службе C Рабочий процесс входа в систему SAML SSO без потери контроля над рабочим процессом.

С другой стороны, если B и C имеют тот же SAML провайдер EntityId зарегистрирован в IdP, то утверждение 1 выше логически и-с точки зрения безопасности эквивалентно утверждению 2 выше. В этом случае наиболее простое решение было бы для услуг B и C использовать ту же систему токенов. Который действительно единственный способ это может работать в любом случае, так как если B и C имеют тот же SAML SP EntityId тогда IdP будет иметь только один URL ACS, сконфигурированный для обоих B и C, что означает, что опять же, что касается IdP, это действительно один и тот же SAML SP.