SSO Добавление утверждений к социальному входу (SAML WS-Fed)

Я пытаюсь понять концепции SSO и то, как они подходят к моей ситуации, и я дошел до того, что немного застрял. Предполагая, что мы используем что-то вроде Azure AD, или Ping Identity, или что-то в этом роде, мы хотим включить социальный вход (учетная запись google/facebook и т. д.) — все в порядке. Я постоянно застреваю на том, как мне контролировать претензии, связанные с этой личностью?

Обзор процесса (в моей голове): - Пользователь входит в систему с учетной записью google (facebook и т. д.), они связывают учетную запись google со своей «устаревшей» учетной записью (т. е. связывают свой социальный логин со своим внутренним идентификатором, который мы, как компания, идентифицируем их как ) то, что это за процесс, не имеет значения для этого обсуждения (я не думаю).

Теперь, когда пользователь входит в систему со своей социальной учетной записью, как мне выполнить поиск этого сопоставления с его внутренним идентификатором, чтобы добавить его в качестве претензии, и добавить связанную другую заявку для этого пользователя на основе информации, которую моя организация знает о них (например, Если им больше 21 года, какой у них «уровень» участника и т. д.).

Я понимаю, что если бы у нас была одна RP, использующая SSO, она, поскольку RP, могла бы выполнять эту логику, но у нас есть ситуация, когда у нас есть несколько внутренних (и потенциально управляемых извне) систем (в настоящее время 4-5), которые мы хотим связать вместе с помощью SSO. - которые будут опираться на эти заявки на доступ/персонализацию и т.д.

Самое близкое, что я видел к этому, — это концепция RP-STS, которая эффективно из того, что я мог бы выработать, сидела перед Ping / AZ AD, чтобы стать частью цепочки, чтобы она могла выполнять внутренний поиск и добавлять дополнительные требования по мере необходимости - имеет ли это смысл как концепция? Это правильный подход?

Я уверен, что это не может быть необычным, но я не могу найти хороший пример/документацию по полной интеграции (много только AZ AD/Ping и т. д.), которые нам нужны. Должны ли быть готовые продукты, которые могут это сделать? (Нам действительно не нужна пользовательская реализация/компоненты SSO, если это возможно)


azure claims single-sign-on saml-2.0 adfs
person Rosstified    schedule 03.03.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Самое близкое, что я видел к этому, — это концепция RP-STS, которая эффективно из того, что я мог бы выработать, сидела перед Ping / AZ AD, чтобы стать частью цепочки, чтобы она могла выполнять внутренний поиск и добавлять дополнительные требования по мере необходимости - имеет ли это смысл как концепция? Это правильный подход?

Именно в этом заключается роль RP-STS (или «поставщика федерации» в некоторых источниках). Он находится между вашими приложениями и несколькими «поставщиками удостоверений» и обычно отвечает за 2 вещи:

  1. Переход протокола (например, ваше приложение может быть WS-Fed или SAML, а Facebook — OAuth2)
  2. Преобразование и обогащение утверждений (например, добавление, удаление, преобразование утверждений на основе некоторой логики).

Существует несколько реализаций этого с различной степенью сложности/гибкости и компромиссами:

  1. Служба управления доступом Azure может выполнять № 1 и (с некоторыми ограничениями) № 2. Но неясно, есть ли у службы какое-либо будущее и будет ли она включена в состав Azure AD.
  2. IdentityServer может все. Это OSS, поэтому вы «владеете» им (например, размещаете, управляете, настраиваете и т. д.). Это отличная реализация, используемая в производстве, написанная экспертами (Доминик Байер и Брок Аллен) и очень гибкая.
  3. ADFS может выполнять некоторые функции (ограниченное количество протоколов, проприетарный язык преобразования утверждений, сложный для отладки, но работающий). Вы должны разместить ADFS самостоятельно. Это продукт MSFT.

компания, в которой я работаю, также предлагает аналогичные возможности.

person Eugenio Pace    schedule 03.03.2014