Пользовательские утверждения с платформой Geneva и как "синхронизировать" пользователей в вашем приложении

Question

Может быть, этот вопрос подчеркивает, насколько мало я знаю об управлении идентификационными данными претензий, но здесь все сказано.

Если вы используете WIF в приложении, которое использует стороннюю службу STS для идентификации и использует пользовательские утверждения для авторизации (что-то уместное и специфичное для приложения, например CanCreateFooBar)

1) Как мне управлять пользователями? То есть, пользователи, скажем, AD или другого провайдера членства могут быть идентифицированы, но внутренне в моей системе мне нужно знать о них и иметь больше пользовательской информации, которая не имеет ничего общего с идентификацией (так что действительно имеет смысл иметь эту информацию доступной вне системы), и эта информация о пользователе должна сохраняться,
Вопрос в том, как я могу разумно управлять и создавать свои системные данные (начиная с идентификаторов)?
Точный сценарий, который я имею в виду: в компанию добавлен новый сотрудник, sys admin создает пользователя для домена с определенной ролью, как моя система может узнать об этом факте? (Я бы хотел, чтобы система предложила администратору системы выполнить действие.

2) Где хранятся значения претензий для этих пользователей и ролей и как я могу их изменить? В идеале я хочу иметь возможность изменять разрешения для конкретного пользователя и действия. Есть ли какие-либо рекомендации по этому поводу?

Я вижу, что это, вероятно, очень неубедительные вопросы, но когда я думаю о том, как решить проблему, я сталкиваюсь со сложными решениями или с решениями, которые требуют большого количества дубликатов (т. Е. Создают использованное в двух местах), поэтому я уверен, что Я просто не думаю об этой проблеме в правильном направлении

Спасибо

Answer 1

1) Вы не управляете пользователями, не совсем. Вы просто берете IClaimsIdentity и используете его в качестве источника для авторизации. По моему мнению, вы не должны настаивать на претензиях, если можете уйти, не делая этого - претензии должны быть источником вашей пользовательской информации.

Если вы хотите использовать утверждения, то возьмите уникальную ссылку из идентификатора утверждений, например, адрес электронной почты или хеш-код OU для ключа ppid / подписи, и используйте его для создания своей собственной базы данных и добавьте свою собственную информацию.

Однако в вашей системе никогда не исчезнут изменения в сторонней метабазе удостоверений - только до тех пор, пока в вашем приложении не будет выпущен и проанализирован новый токен SAML.

2) Значения претензий нигде не хранятся, если вы их не храните. То, как вы переводите это в разрешения, зависит от вас, но обычно вы выполняете преобразование утверждений, чтобы принять внешние утверждения и сопоставить их с утверждениями, внутренними для вашего приложения, которое вы используете для разрешений. Поскольку претензии поступают от внешних поставщиков, вы не можете их изменить - у вас нет связи с этими поставщиками.

Answer 2

Как видите, федерация не обязательно устраняет необходимость в обеспечении. Это важное понимание, которое не сразу очевидно.

Есть несколько способов решения этой проблемы, в том числе:

1. Использование мета или виртуального каталога продукта или
2. Используя "JIT Provisioning" (AKA "динамическое предоставление" или "обеспечение на лету").

Позвольте мне объяснить последнее. Это решение, которое я также опишу в своем блоге, включает в себя две STS, IP-STS и RP-STS. Первый исключительно аутентифицирует пользователя; вторая относится к вашему приложению и знает, какие утверждения необходимы для авторизации пользователей этой системы. IP-STS не может выдавать эти атрибуты, относящиеся к конкретному приложению, для этого потребуется, чтобы ваша корпоративная служба каталогов была загромождена всевозможной информацией для конкретного приложения. Вместо этого атрибуты для пользователей, которые поддерживаются в этом хранилище и выпускаются IP-STS, носят общий характер и применимы к пользователю независимо от того, какое приложение они используют. После аутентификации на IP-STS и получения от него только идентификационных утверждений токен передается на RP-STS. Этот сервис токенов тесно связан с вашим приложением. Он знает, какие требования требуются пользователям для доступа к различным ресурсам. Он может преобразовывать утверждения, удостоверяющие личность, в требования, необходимые для принятия этого решения по управлению доступом. Таким образом, RP-STS является преобразователем утверждений, который отображает связанные с идентификацией утверждения в специфичные для приложения.

Как RP-STS обеспечивает пользователя? Предположим, создан новый сотрудник, как в вашем примере выше. Когда пользователь получает доступ к вашему приложению, он возвращается на RP-STS. Он не будет авторизован там, поэтому его отправят на IP-STS. Системный администратор создал для него учетную запись, поэтому он сможет войти в систему, и его браузер вернет его обратно в RP-STS. RP-STS взломает токен, получит идентификатор пользователя (электронная почта, PPID и т. Д.) И увидит, что он не знает, кто этот пользователь. Таким образом, RP-STS обеспечит пользователя. Это будет сделано, например, путем отображения веб-страницы. Он может собирать информацию, которая помогает определить роль этого пользователя при доступе к RP. После этого пользователь будет подготовлен (т. Е. В его базе данных будет создана запись, содержащая значения претензий для него), а RP-STS выдаст токен, специфичный для вашего приложения, и перенаправит его туда. Приложение не будет знать, что он был только подготовлен; он будет просто использовать претензии, как всегда. (Смотрите, почему я назвал это JIT-подготовкой?)

Что если все изменится после подготовки пользователя? ХОРОШО. Представьте себе, что: пользователь был создан в хранилище каталогов много лет назад и был подготовлен, как описано выше в RP-STS, и он долгое время успешно использовал систему. Затем происходит изменение политики, требующее от пользователей вашего приложения принятия новых условий и положений. В следующий раз, когда пользователь войдет в приложение, он будет перенаправлен на RP-STS, на IP-STS, он пройдет аутентификацию и будет возвращен на ваш RP-STS. В этот момент он заметит, что пользователь должен принять новые условия, поэтому он покажет пользователю веб-страницу и получит согласие. После этого RP-STS выдаст токен безопасности и перенаправит его в ваше приложение. Ваше приложение, как всегда, будет обрабатывать заявки и делать то, что нужно для авторизации доступа. Он не будет знать и не будет заботиться о том, что пользователь был просто "повторно подготовлен". Кроме того, вы можете синхронизировать изменения между хранилищем идентификаторов (т. Е. Вашим корпоративным каталогом) и хранилищем претензий RP-STS, используя такой продукт, как ILM (или FIM, как он теперь называется). В зависимости от вашей системы, продукт, который выполняет синхронизацию по обратному каналу, может оказаться более подходящим.

Кстати, это не "хромые" вопросы! Есть очень острые вопросы, которые отражают глубокую мысль и разумное размышление над очень сложной проблемой. Другие, что вам нужно ответить, включают в себя:

• Как администраторы вашего приложения обновляют его политику (например, изменяют условия и положения)? Какой интерфейс /API вы должны создать? Интегрирован ли пользовательский интерфейс с тем, который используется для управления политикой IP-STS?
• Какого рода доверительные отношения должны существовать, чтобы такая система работала?
• Что если субъект не использует пассивный профиль? Что делать, если он использует активный профиль и / или не имеет пользовательского интерфейса?
• Как и где расположены ключи? Какие разрешения необходимы для использования этих ключей? Как они распределяются, распределяются, и как администраторы системы оповещаются, когда у них заканчивается срок действия?

Этот материал действительно легко продемонстрировать на собраниях групп пользователей и на конференциях, но на самом деле это очень продвинутый материал. Если у вас есть другие вопросы, не стесняйтесь размещать их здесь или свяжитесь со мной напрямую.