Когда не использовать СКУД?

Не следует использовать ACS в качестве поставщика удостоверений.

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

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

Но здесь возможности ACS не следует путать с полнофункциональными решениями для каталогов, аутентификации и авторизации, такими как AD и ADFS. Короче говоря, ACS — это не упрощенная версия AD/ADFS.

Несмотря на то, что вы можете использовать Windows Live в качестве поставщика удостоверений в ACS, в некоторых случаях вы не захотите его использовать. Полученный идентификатор пользователя зависит от пространства имен ACS. Это означает, что если ваше приложение использует несколько пространств имен ACS (скажем, одно для Европы и одно для США), это может вызвать некоторые проблемы.

Представьте себе сценарий, в котором ваш пользователь входит в систему через ваше пространство имен USA. Ваше приложение получит идентификатор (хэш) для этого пользователя, и вы, возможно, создадите профиль для этого пользователя в своем приложении. Через неделю ваш пользователь отправится в Европу и может войти в систему через ваше пространство имен europe. Несмотря на то, что это тот же пользователь, вы получите другой идентификатор (хэш) для этого пользователя, что создаст впечатление, что это новый пользователь, хотя это не так. Это связано с тем, что идентификатор (хэш) зависит от пространства имен ACS.

Цитируя сотрудника MSFT:

Идентификатор пользователя, который вы получаете от ACS для идентификатора Windows Live ID, будет специфичным для этого пользователя в вашем пространстве имен службы. Если вы используете другое пространство имен службы, вы получите другое значение для того же пользователя. Итак, чтобы ответить на ваши вопросы: * Labs ACS и Prod ACS [Разные идентификаторы]

• Разные проверяющие стороны в разных подписках (в prod) [Разные идентификаторы]

• Разные RP в одной подписке [один и тот же идентификатор, если пространство имен службы одно и то же, разные для двух пространств имен в одной подписке]

• Если я удалю и пересоберу RP в тот же мир, тот же аккаунт [Same ID]

Обновление:

Чтобы ответить на один из комментариев, вы действительно не получите адрес электронной почты от поставщика удостоверений Windows Live. Но вы должны исходить из того, что вы не можете контролировать информацию, которую получаете от общедоступных поставщиков удостоверений. Хорошей практикой было бы просто зависеть от идентификатора пользователя и создать профиль для пользователя (вы будете управлять профилем в своем приложении). Когда вы получаете некоторую информацию от поставщика удостоверений, вы уже можете обновить профиль, но если эта информация недоступна, вы должны просто попросить пользователя обновить свой профиль. Обязательно просмотрите пример BlobShare для получения дополнительной информации.