Как я должен обрабатывать идентификатор пользователя для приложения Windows Phone/WCF/ASP.NET MVC?

Я работаю над приложением, которое позволяет вводить и отображать данные как из приложения Windows Phone, так и из веб-интерфейса MVC 3. Доступ к данным для телефонного клиента осуществляется через аутентифицированные службы WCF, размещенные в приложении MVC 3. Пользователи будут отслеживать информацию, которая уникальна для них, поэтому служба будет показывать только данные, которые я ввел.

Каков самый простой способ справиться с идентификацией в этом сценарии? Я думал об использовании Windows Live ID, поскольку телефонное приложение имеет доступ к свойству анонимного идентификатора Windows Live. Тем не менее, из того, что я могу сказать, нет возможности получить доступ к веб-интерфейсу Windows Live, который дает мне тот же идентификатор Windows Live ID - Windows Вход Live Messenger Connect дает мне уникальный идентификатор сайта, который будет отличаться от анонимного идентификатора клиента телефона.

В качестве альтернативы, я мог бы использовать аутентификацию Facebook как на клиенте, так и на телефоне с Facebook SDK. Моя забота заключается в обеспечении обслуживания вызовов. Я думаю, что при первом подключении устройства к сервису с помощью идентификатора Facebook сервер выдаст ему ключ, и для доступа к службе требуются как идентификатор Facebook, так и серверный ключ.

Мысли о вышесказанном? Есть ли более простое решение, которое мне не хватает?

Ответ 1

Дорогой Джон, У меня нет опыта разработки WP, но я немного искал WCF Auth. за пару дней, и выяснил, что apiKey auth - лучший способ для меня. Роб Джейкобс объяснил, как это работает в этой статье;

http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx

Ответ 2

Альтернативой API-ключу является использование идентификаторов идентичности и безопасности, основанных на требованиях. Вы можете использовать службу контроля доступа Windows Azure как доверенный эмитент токенов безопасности, добавив, что он настроен на использование LiveID, Facebook, Google, любого OpenID и любого поставщика удостоверений WS-Federation. Как веб-сайт, так и веб-сервис будут доверять ACS.

ACS предоставит вам токены SAML для веб-сайта (позволяя вашим пользователям входить в него с помощью LiveID, Google или FB).

ACS также может выпускать простые веб-токены (SWT), которые особенно удобны для служб REST (при условии, что клиент использует телефон).

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

Использование ACS дает вам большую гибкость без всей полноты. Создание веб-сайта "заявляет о себе" и доверие ACS очень прямолинейно. Больше примеров здесь: http://claimsid.codeplex.com

Ответ 3

Если вам нужно связать телефон с пользователем на сайте MVC, вы можете сделать что-то Netflix и Amazon сделать для Roku и других устройств и иметь какой-то процесс активации. Чтобы упростить работу, вы можете использовать QR-код или какой-либо другой тип штрих-кода, созданный на сайте MVC, попросить пользователя сделать снимок и обработать изображение с помощью Сканирующая библиотека штрих-кодов Silverlight ZXing. Вероятно, немного запутанный, но он работает для всех телеприставок.