Custom Claims with Geneva framework и как синхронизировать пользователей в вашем приложении

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

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

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

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

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

Спасибо


claims-based-identity wif geneva-framework
person roundcrisis    schedule 10.12.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

person blowdart    schedule 10.12.2009
comment
@blowdart спасибо за ответ, очень ценю понимание. Я не очень хорошо понимаю вторую часть, хотя, как вы сообщаете своей системе через утверждения, что пользователь (Боб) candofoobar? т.е. требование в токене должно вернуться к вашему RP со значением Claimtype =CanDoFooBar =true. Если это возможно? И как вы скажете своим очкам, что это ценность для Боба? - person roundcrisis; 11.12.2009
comment
Маркер будет содержать утверждения. Если вы позволяете серверу идентификации решать, то выданный им токен будет содержать утверждение на этот счет и, конечно же, личность пользователя. Таким образом, STS отправит утверждение о пользователе Bob, содержащее urn:candofoobar = true. Это зависит от вас, если вы верите в это или нет. Если это роль, которую назначаете только вы, возьмите идентификатор пользователя, используйте его в качестве первичного ключа в таблице ролей и используйте преобразование утверждений, чтобы добавить эти роли при первой обработке токена. - person blowdart; 11.12.2009

arrow_upward
4
arrow_downward

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

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

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

Позвольте мне объяснить последнее. Это решение, которое я также описываю в своем блоге , включает две 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, и он успешно использует систему в течение долгого времени. Затем есть изменение политики, которое требует, чтобы пользователи вашего приложения приняли новые положения и условия (T&Cs). В следующий раз, когда пользователь войдет в приложение, он будет перенаправлен на RP-STS, на IP-STS, пройдет аутентификацию и вернется к вашему RP-STS. В этот момент он заметит, что пользователь должен принять новые Условия и положения, поэтому он покажет пользователю веб-страницу и получит его согласие. После этого RP-STS выдаст токен безопасности и перенаправит его в ваше приложение. Ваше приложение, как всегда, будет обрабатывать претензии и делать все, что необходимо для авторизации доступа. Он не узнает и не будет заботиться о том, что пользователь был только что «переинициализирован». В качестве альтернативы вы можете синхронизировать изменения между хранилищем удостоверений (т. е. вашим корпоративным каталогом) и хранилищем утверждений вашего RP-STS, используя такой продукт, как ILM (или FIM, как он теперь называется). В зависимости от вашей системы продукт, выполняющий синхронизацию с обратным каналом, может оказаться более подходящим.

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

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

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

person Travis Spencer    schedule 11.12.2009