Как атрибуты сопоставляются между .NET (ADFS/WIF) и Java (федерация)

Предположим, что есть две компании: A.NET, магазин .NET, и B.Java, магазин Java. Пользователям в каждой компании необходимо получить доступ к веб-сайтам другой компании, поэтому две компании настраивают федерацию с помощью ADFS и Oracle Identity Federation или OpenSSO Federation.

В мире .NET доступ к атрибутам осуществляется как утверждения внутри IClaimsPrincipal и IClaimsIdentity.

В мире Java к атрибутам обращаются как к заголовкам HTTP.

Выполняет ли инфраструктура Федерации это сопоставление автоматически, т.е.

Если пользователь A.NET получает доступ к сайту B.Java, получают ли они свои атрибуты в качестве утверждений?

Если пользователь B.Java получает доступ к сайту A.NET, получают ли они свои атрибуты в виде заголовков?


adfs adfs2.0 wif opensso
person rbrayb    schedule 13.03.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Если предположить, что вы можете использовать WS-Federation с обеих сторон, то в обоих случаях основным артефактом, с которым вы будете иметь дело, будет токен SAML.

Как правило, ваша инфраструктура федерации полностью независима от стека приложений. ADFS будет выдавать маркеры SAML в любом случае (для приложения Java и для приложения .NET). OIF также должен будет выпустить токены SAML для обеих групп пользователей.

В мире .NET WIF будет анализировать/проверять и т. д. токен SAML в объектной модели .NET, которая представляет содержащуюся в нем информацию (заявки, эмитент и т. д.). Этой объектной моделью является ClaimsPrincipal (и все связанные интерфейсы и типы). Вам нужно будет посмотреть на эквивалент WIF в мире Java. Но в любом случае вводом является токен SAML.

В вашем сценарии вполне вероятно, что в обеих службах STS произойдет преобразование токена:

Для приложения .NET:

1- пользователь из компании B проходит аутентификацию в OIF и получает токен SAML для компании A 2- пользователь отправляет токен в ADFS 3- ADFS считывает токен от B, проверяет и выдает новый токен (потенциально и весьма вероятно добавление/преобразование/удаление претензии) 4- пользователь отправляет преобразованный токен в приложение A

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

person Eugenio Pace    schedule 14.03.2011