При использовании Windows Identity Foundation (WIF) с несколькими службами токенов безопасности (STS) можно ли подготовить пользователей до того, как они впервые получат доступ к приложению?
Например, предположим, что у меня есть веб-сайт BufferOverrun, где пользователи могут входить в систему и задавать / отвечать на вопросы, и я хочу поддерживать аутентификацию с помощью внешних учетных записей Google. Когда пользователь впервые обращается к странице, он должен пройти аутентификацию с помощью своей учетной записи Google, после чего он сможет получить доступ к веб-приложению. В этом сценарии есть два STS: Google (для аутентификации личности) и пользовательский для моего приложения (для авторизации).
Как я могу назначить заявки пользователю до того, как этот пользователь получит доступ к системе?
Поскольку удостоверение принадлежит моему приложению извне, я не могу назначать утверждения непосредственно этому удостоверению (и я бы все равно не хотел, поскольку они будут специфичными для приложения). Но поскольку пользователь не получил доступа к системе, у меня нет внутреннего удостоверения, которому можно было бы назначать утверждения. Я вижу два возможных решения:
- Подождите, пока пользователь получит доступ к системе (создав несколько утверждений по умолчанию для конкретных приложений), затем используйте какой-нибудь внутренний инструмент подготовки, чтобы изменить эти утверждения по своему усмотрению.
- Инструмент подготовки позволяет пользователям вручную отображать утверждение удостоверения по умолчанию (например, адрес электронной почты) до того, как это удостоверение аутентифицируется, вводя его вручную, чтобы при первом доступе, если удостоверение подтверждает это утверждение, предоставлялся определенный набор утверждений приложения. .
Я вижу несколько проблем как с 1, так и с 2. Для 1 все пользователи имеют некоторый неявный доступ к системе, даже если утверждения приложения по умолчанию не разрешают никаких функций. Кажется, это отлично работает для чего-то вроде stackoverflow, где исходная учетная запись имеет определенный набор разрешений, и когда пользователь использует системы, предоставляются новые заявки. Однако это, вероятно, желательно не для всех приложений. 2 подвержен ошибкам, так как требует, чтобы администратор вручную указывал претензию.
В обоих случаях выше, как мне предоставить удостоверение, которое имеет доступ для фактического использования инструмента подготовки (т. е. учетной записи администратора)?
Для этого я предполагаю, что во время установки приложения я требую, чтобы пользователь аутентифицировал и установил утверждения приложения для этого удостоверения так, чтобы у них были «административные» привилегии. Это хорошая реализация?
Исторически (сейчас я имею в виду существующее приложение) приложение специально взаимодействовало только с Active Directory. Это было решено с помощью встроенной учетной записи администратора (не связанной с AD), которая позволяла пользователю с правами администратора выполнить первый вход. После аутентификации с помощью приложения администратора этот пользователь может искать в AD пользователей / группы и предоставлять их индивидуально. Любой пользователь / группа, не предоставленная администратором, вообще не будет иметь доступа к системе. Я не думаю, что эта парадигма применима к использованию внешней STS, такой как Google и т. Д., Поэтому я пытаюсь создать архитектуру, которая позволила бы использовать внешние STS-системы. Желательно, но не обязательно, сохранить возможность поиска в STS. На практике обе задействованные службы STS, скорее всего, будут Active Directory, использующими федеративные службы.
Примечание. Это похоже на этот вопрос и этот вопрос.
