2009-12-10 6 views
1

Возможно, этот вопрос освещает, как мало я знаю об управлении идентификацией претензий, но здесь он идет.Пользовательские требования с основанием в Женеве и как «синхронизировать» пользователей с вашим приложением

При использовании WIF в приложении, которое использует STS для сторонней Идентичности и использует собственные требования для авторизации (то относящегося к делу и specificto приложения, как CanCreateFooBar)

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

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

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

Благодарности

ответ

1

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

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

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

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

+0

@blowdart спасибо за ответ, действительно оценивайте понимание. Я не очень хорошо понимаю вторую часть, как вы можете сообщить своей системе через утверждения, что пользователь (Bob) candofoobar? т.е. требование в токене должно возвращаться к вашему RP с искомым типом = CanDoFooBar value = true. Если это возможно? И как вы говорите своим старшим, что это ценность для Боба? – roundcrisis

+0

Токен будет содержать претензии. Если вы разрешите серверу идентификации решить, то маркер, выданный этим, будет содержать заявку на этот эффект и, конечно же, личность пользователя. Таким образом, STS отправит иск о пользователе Bob, который содержит urn: candofoobar = true. Это зависит от вас, если вы верите в это или нет. Если это роль, которую вы назначаете, тогда возьмите идентификатор пользователя, используйте это как первичный ключ в своей таблице ролей и используйте преобразование претензий, чтобы добавить эти роли, поскольку токен обрабатывается в первый раз. – blowdart

4

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

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

  1. Использование мета или продукта виртуального каталога или
  2. С помощью «JIT продовольствования» (AKA «динамическое выделение» или «на в- летной подготовки ").

Позвольте мне объяснить последнее. Это решение, which I also describe on my blog, включает в себя два 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?)

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

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

  • Как администраторы приложения обновить свою политику (например, изменение T & Cs)? Какой UI/API вы должны создать? Совместим ли интерфейс с тем, который используется для управления политикой IP-STS?
  • What sort of trust relationships must exist to make such a system work?
  • Что делать, если субъект не использует пассивный профиль? Что делать, если он использует активный профиль и/или нет пользовательского интерфейса?
  • Как и где находятся ключи? Какие разрешения необходимы для использования этих ключей?Как они перезаписываются, распространяются и как предупреждаются администраторы системы, когда они скоро истекают?

Этот материал очень прост в демонстрации на собраниях групп пользователей и на конференциях, но на самом деле это очень продвинутый материал. Если у вас есть другие вопросы, не стесняйтесь публиковать их здесь или get in touch w/ me directly.