Пользовательские претензии с Женевской структурой и как «синхронизировать» пользователей подберите ваше приложение

Question

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

При использовании WIF в приложении, которое использует сторонние STS для идентификации и использует пользовательские претензии для авторизации (что -то соответствующее и определяет приложение, такое как CanCreateFoobar)

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

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

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

Спасибо

Answer 1

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

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

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

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

Answer 2

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

Есть несколько способов устранения этого, включая:

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

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

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

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

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

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

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