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

Question

Я изучал Azure Access Control Service (ACS), и похоже, что он особенно хорош при обработке аутентификации от гетерогенных (настраиваемых) поставщиков удостоверений. Затем есть ряд дополнительных сценариев, которые, по-видимому, поддерживаются (см., Например, ACS How-To's).

Вопрос, который у меня есть, является обратным: это действительно поможет мне понять, для того, чтобы правильно использовать его, что ACS не хорошо для. Каковы ограничения ACS и/или каковы некоторые сценарии, когда ACS будет неуместным?

(Предположим, ради аргумента, что я планирую создать прибыльный :) - общедоступный веб-API и соответствующий интерфейс веб-сайта, размещенный в Azure, то есть я забочусь о личности пользователя. Если вам нравится, вы можете также предположить, что моя система будет построена с использованием .NET.)

Спасибо!

Answer 1

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

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

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

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

Answer 2

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

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

Quoting an MSFT employee:

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

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

• Различные RPs в одной и той же подписки [ То же ID, если пространство имен службы одинакова, отличается 2 пространств имен в одной и той же подписки]

• Если удалить и восстановить РП в той же области, тот же счет [То же ID]

Update:

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