Короткий ответ, как правило, "да", но, конечно, есть более длинный ответ: -).
Имеет ли смысл хранить информацию о пользователе (кроме идентификатора имени) в таблицах ACS и локальной базы данных?
Да, это может иметь смысл. Но в целях оптимизации вы можете хранить копию некоторой информации профиля пользователя в другом месте (локально для приложения). Информация о правилах ACS будет «основной записью», в которой вы обновляете значения в своем локальном хранилище всякий раз, когда получаете токен, и проверяете, были ли изменения или нет.
Звучало так, будто вы можете создавать неограниченные группы правил и правила внутри них. Это правильно?
Нет, «безлимитный» - это большое число. Существуют ограничения на количество пространств имен, проверяющих сторон и правил. Проверьте документацию. ACS также поддерживает «каскадные» преобразования, которые могут помочь вам сократить количество правил.
Например:
- электронная почта: eugeniop@mail.com -> компания: Contoso
- Компания: Contoso -> Язык: английский
2-е правило будет срабатывать всякий раз, когда выдано утверждение типа «Компания», значение «Contoso».
Тогда вы можете иметь:
- электронная почта: rob@othermail.com -> компания: Contoso
Претензия "language" будет добавлена автоматически.
Я бы имел дело с разными компаниями и пользователями внутри компании. Было бы разумным выбором создать группу правил для каждой компании, а затем создать правила для каждого пользователя?
В среде с несколькими арендаторами было бы лучше иметь проверяющую сторону на каждого арендатора. Это то, что мы делаем в примере 7 (Федерация с несколькими партнерами), доступном здесь: http://claimsid.codeplex.com
Похоже, что API довольно надежный и позволит сделать это автоматически на странице регистрации и т. Д. Правильно или неправильно?
Да
Было бы целесообразно и рекомендовано выполнить запрос к ACS, чтобы вернуть информацию о пользователе (например, запросить его адрес электронной почты, когда он не в сети, чтобы отправить ему сообщение о чем-либо)
Это возможно. Однако в ACS отсутствует понятие «пользователь». Так что вам придется расшифровать это из правил. У вас не может быть вызова типа «GetUserprofile (string user)»
Не могли бы вы собрать объемную информацию для составления отчетов от ACS?
API поддерживает объемную информацию, но для создания отчетов лучше иметь реплицированную информацию в вашей собственной базе данных.
Еще одна мысль: механизм правил ACS сегодня очень прост и выполняет только простые преобразования (плюс каскадирование), но ничто по сравнению с тем, что ADFS может сделать сегодня, где правила могут быть действительно сложными (например, поиск в базе данных и т. Д.)