#c# #windows #windows-store-apps
#c# #Windows #windows-store-приложения
Вопрос:
В моем приложении Windows Store (c #) у меня есть собственный механизм авторизации:
- Пользователь передал имя своей учетной записи / пароль и отправил его на сервер.
- Сервер генерирует уникальный токен и возвращает его пользователю.
- Для всех последующих запросов пользователь использовал этот токен.
Теперь я пытаюсь выполнить авторизацию, используя только учетную запись Windows.
MSDN предоставляет UserInformation class , и я могу получить name for the user account или domain name for the user . Но я думаю, что этого недостаточно для моей схемы авторизации.
Также метод GetSessionInitiationProtocolUriAsync выглядит очень интересным, но я не знаю, как правильно использовать его Uri для авторизации.
Как я могу использовать учетную запись Windows для авторизации в моем приложении?
примечание: меня интересуют обе ситуации: когда пользователь внутри домена или нет.
Спасибо.
Комментарии:
1. Вы смешиваете авторизацию и аутентификацию, учетная запись Windows предназначена для идентификации пользователя (аутентификация), после того как вы узнаете, кто он, вы предоставляете ему соответствующий доступ (авторизацию). В любом случае то, что вы ищете, — это проверка подлинности на основе утверждений. Я никогда не использовал его в приложениях магазина Windows, поэтому я не буду публиковать ответ, поскольку он может отличаться.
2. @Pedro.The.Kid спасибо за ваш комментарий. Я думаю, что подожду кого-нибудь, у кого есть опыт проверки подлинности на основе утверждений об использовании в приложениях магазина Windows.
3. В моем приложении Windows Store я регистрирую пользователей, используя их учетную запись Microsoft, через Live SDK. Для каждого пользователя будет сгенерирован уникальный токен, с помощью которого клиентское приложение регистрируется на моем сервере. Это работает для вас?
Ответ №1:
Существует множество способов реализовать это, но если вы хотите упростить процесс и владеть им, вы могли бы реализовать свой собственный метод аутентификации, который при успешной аутентификации вы могли бы создать значение хэша из их пароля и секретной соли, которые могут быть возвращены пользователю в виде файла cookie и т.д. которую вы используете для проверки каждого последующего запроса.
Что касается авторизации, вы можете реализовать свой собственный или использовать поставщика на основе ролей, связанного с локальной группой компьютеров или Active directory, используя классы ниже или просто используя старые RoleProviders.
Вы могли бы реализовать свой собственный метод аутентификации, используя метод, описанный ниже, или используя поставщика аутентификации и авторизации для ASP.Net (если ваш сервер работает на .net). В основномAsp.Net Поставщики членства и ролей. Однако метод, описанный ниже, также позволит вам получать доступ к ролям и другой информации о пользователе и изменять их.
В .Net 3.5 появилось новое пространство имен под названием System.DirectoryServices.Управление учетными записями.
Фрагмент из MSDN
Система.DirectoryServices.Пространство имен AccountManagement обеспечивает единый доступ и манипулирование пользователями, компьютерами и участниками групповой безопасности в нескольких основных хранилищах: доменных службах Active Directory (AD DS), службах каталогов Active Directory Lightweight (AD LDS) и машинной SAM (MSAM).
Система.DirectoryServices.AccountManagement управляет объектами каталога независимо от системы.Пространство имен DirectoryServices. Приложения служб управляемых каталогов могут использовать API AccountManagement для упрощения управления пользователями, компьютерами и участниками групп. Решения, которые ранее требовали сложного знания хранилища или длинного кода, такие как поиск всех групп, к которым принадлежит пользователь, выполняются в нескольких строках кода с помощью AccountManagement API.
Вы можете легко аутентифицировать учетные данные пользователя в AD, используя приведенный ниже код:
bool valid = false;
using (PrincipalContext context = new PrincipalContext(ContextType.Domain))
{
valid = context.ValidateCredentials( username, password );
}
Если вы хотите выполнить проверку с использованием учетной записи локального компьютера, вы также можете изменить конструктор:
new PrincipalContext(ContextType.Machine)
Вы можете проверить документацию на наличие других опций, и, кроме того, это позволит вам получать из магазина любую информацию, такую как членство и т.д.
Новое пространство имен было попыткой Microsoft упростить DirectoryServices, которая, я думаю, была успешной, но если вы хотите еще большего контроля, вы могли бы использовать классы DirectoryServices, но это увеличило бы сложность решения.
Я надеюсь, что это поможет, если вам потребуется дополнительная информация или вы считаете, что это не совсем то, что вы ищете, дайте мне знать, я постараюсь улучшить ответ.
Ответ №2:
Во-первых, я боюсь, что вы путаете аутентификацию и авторизацию.
Аутентификация — подтверждение личности пользователя (например, я представляю идентификатор при посещении банка)
Авторизация — принятие решения о том, разрешено ли идентификатору выполнять какое-либо действие (например, может ли клиент «Nitz» удалить учетную запись # 44422).
Учетная запись Microsoft может предоставить вам только аутентификацию — клиент будет использовать некоторую схему, чтобы доказать вашему серверу, что он принадлежитbla@microsoft.com , и вам решать, разрешено ли что-либо делать в вашем приложении (авторизация).
С учетными записями домена вы можете использовать членство в группе домена для облегчения авторизации (это даже распространено в серверных приложениях Windows), которое вы обычно получаете «бесплатно» вместе с токеном аутентификации пользователя.
Предполагая, что я вас правильно понял, и вы действительно ищете аутентификацию, вы должны предоставить два варианта поведения — один для проверки подлинности домена и один для проверки подлинности учетной записи Microsoft. Это связано с тем, что библиотеки и протоколы связи между ними сильно различаются.
Обеспечение аутентификации
Используя этот этот учебник от ребят из Microsoft Azure, вы можете настроить пример сочетания приложения и веб-сайта, который использует аутентификацию учетной записи Microsoft.
Чтобы использовать проверку подлинности домена (kerberos / NTLM), вы можете следовать этому сообщению и просто включить «интегрированную проверку подлинности Windows» на своем веб-сайте / службе (я предполагаю, что это IIS). Если вы новичок в аутентификации enteprise, я коротко скажу, что при правильной настройке (без разницы во времени, проблем с рекламой и т.д.) аутентификация проходит без проблем. Если есть проблемы, вернитесь к простому веб-сайту «hello world» и протестируйте его в Internet Explorer.
Для каждого сценария лучше всего создать метод «hello world», возвращающий аутентификационную информацию пользователя, чтобы убедиться, что вы все правильно поняли.
Предоставление авторизации
при каждом методе аутентификации вы получаете уникальный идентификатор (учетная запись Microsoft: UserId . Учетные записи домена: SID ). Ваша логика должна преобразовать эту информацию в набор разрешений — например, поддерживать таблицу, которая имеет идентификатор в одном столбце, а isAdmin в другом. Ваше приложение должно руководствоваться этой логикой при принятии решения о том, разрешить или запретить действие от клиента.
Объединение корпоративного и общедоступного
Поскольку методы аутентификации общедоступных пользователей отличаются от методов, используемых для корпоративных пользователей, вы, вероятно, получите разные идентификаторы для одного и того же пользователя при подключении с помощью разных методов (например, DOMAINbla и bla.blason@outlook.com ). Если вы намерены предоставить оба метода проверки подлинности одновременно, вам необходимо учитывать это (например, путем создания таблицы «пользователь», в которой есть один столбец для идентификаторов учетной записи Microsoft и один для идентификаторов домена SID). Обычно не имеет смысла предоставлять оба метода аутентификации одновременно, но это ваше приложение.
Надеюсь, я помог!
Ответ №3:
Однажды у меня была похожая ситуация (клиентскому приложению необходимо подключиться к серверу с несколькими учетными данными. после пользовательской аутентификации клиенту будет предоставлен токен с несколькими утверждениями, затем каждый запрос клиента будет проверен на соответствие данному токену) , если вы занимаетесь чем-то подобным, рассмотрите эту ссылку, это помогло мне решить проблему.
Примечание: вы можете реализовать пользовательскую аутентификацию и авторизацию, расширив ClaimsAuthenticationManager и Claimsauthorizationmanager соответственно
Комментарии:
1. Извините, но ClaimsAuthenticationManager — не поддерживается в приложениях магазина Windows. Спасибо за помощь.