Локальные учётные записи в Microsoft Azure Mobile Services

Ещё одна недостаточно описанная тема про Microsoft Azure Mobile Services — авторизация, которая к тому ж налажена лишь в последних версиях. Разумеется, с самых ранних версий было перечисление MobileServiceAuthenticationProvider, позволявшее простым способом выполнить авторизацию одним из заданных методов. Но вряд ли этот набор — всегда самое удобное решение для пользователей. Тут возможно два направления расширения — добавление новых вариантов механизма OpenId или свой механизм авторизации. Далее будет рассмотрен второй вариант.

Начнём с того, что если для создания проекта использовать слишком старый шаблон из Visual Studio (например 2-е обновление для 2013-го), то в нём версия NuGet для WindowsAzure.MobileServices.Backend может не поддерживать рассмотренное далее решение. На период написания статьи с последней версией 1.0.439 были сложности совместимости с новыми версиями других модулей, поэтому здесь используется следующий набор:

Install-Package AutoMapper -Version 3.2.1 Install-Package System.IdentityModel.Tokens.Jwt -Version 3.0.2 Install-Package Microsoft.Owin.Security -Version 2.1.0 Install-Package Microsoft.Owin.Security.OAuth -Version 2.1.0 Install-Package Microsoft.Owin.Security.Cookies -Version 2.1.0 Install-Package Microsoft.Owin.Security.Jwt -Version 2.1.0 Install-Package Microsoft.Owin.Security.ActiveDirectory -Version 2.1.0 Install-Package Microsoft.Owin.Security.Facebook -Version 2.1.0 Install-Package Microsoft.Owin.Security.Google -Version 2.1.0 Install-Package Microsoft.Owin.Security.Twitter -Version 2.1.0 Install-Package Microsoft.Owin.Security.MicrosoftAccount -Version 2.1.0 Install-Package WindowsAzure.MobileServices.Backend.Entity -Version 1.0.405

Сперва создадим классы DemoCredentials (наследованный от ProviderCredentials) и LocalLoginProvider (наследованный от LoginProvider) и объявим их следующим образом:

    public class DemoCredentials: ProviderCredentials     {         public string AccessToken { get; set; }          public DemoCredentials()             : base(DemoLoginProvider.ProviderName)         {          }     }      public class DemoLoginProvider: LoginProvider     {         public const string ProviderName = "Demo";          public override string Name         {             get { return ProviderName; }         }          public DemoLoginProvider(IServiceTokenHandler tokenHandler)             : base(tokenHandler)         {          }          public override void ConfigureMiddleware(Owin.IAppBuilder appBuilder, Microsoft.WindowsAzure.Mobile.Service.ServiceSettingsDictionary settings)         {             return;         }          public override ProviderCredentials CreateCredentials(System.Security.Claims.ClaimsIdentity claimsIdentity)         {             System.Security.Claims.Claim name = claimsIdentity.FindFirst(System.Security.Claims.ClaimTypes.NameIdentifier);             System.Security.Claims.Claim providerAccessToken = claimsIdentity.FindFirst(ServiceClaimTypes.ProviderAccessToken);             DemoCredentials credentials = new DemoCredentials             {                 UserId = this.TokenHandler.CreateUserId(Name, name != null ? name.Value : null),                 AccessToken = providerAccessToken != null ? providerAccessToken.Value : null             };             return credentials;         }          public override ProviderCredentials ParseCredentials(Newtonsoft.Json.Linq.JObject serialized)         {             return serialized.ToObject<DemoCredentials>();         }     } 

Метод ConfigureMiddleware в данном случае не нужен, поскольку он предназначен для внешней авторизации.

Далее создадим API-контроллер и объявим в нём основной метод авторизации, который будет возвращать тип данных LoginResult. Для упрощения примера в нём не будет проверки параметров авторизации, полагаю, читателям не составит сложностей добавить необходимый для конкретной задачи способ их проверки.

        [HttpPost]         [Route("api/Authentication/Authenticate")]         [AllowAnonymous]         public async Task<HttpResponseMessage> Authenticate()         {             DemoLoginProvider provider = new DemoLoginProvider(Handler);             System.Security.Claims.ClaimsIdentity claimsIdentity = new System.Security.Claims.ClaimsIdentity();             claimsIdentity.AddClaim(new System.Security.Claims.Claim(System.Security.Claims.ClaimTypes.NameIdentifier, "fakeUser"));             LoginResult loginResult = provider.CreateLoginResult(claimsIdentity, Services.Settings.MasterKey);             return Request.CreateResponse(HttpStatusCode.OK, loginResult);         } 

Класс LoginResult содержит очень важный параметр — AuthenticationToken, который понадобится на клиентской стороне. Он выдаётся сервером на заданное в параметрах время и определяет сам факт наличия авторизации от имени конкретного пользователя — в данном случае «Demo:fakeUser».

Свойство Handler объявляется в контроллере следующим образом:

        public IServiceTokenHandler Handler { get; set; }

После этого Autofac будет выставлять его требуемое значение.

Далее рассмотрим пример клиентского приложения на основе Xamarin.Android. Можно использовать одну сборку, но в целях демонстрации межплатформенных возможностей будет использоваться PCL с профилем 111. Этот профиль поддерживается в Xamarin.Android, Xamarin.iOS и WinStore-приложениях. Для упрощения примера будет использовано сокращённое количество слоёв приложения, а при реализации пользовательского интерфейса будет исключена обработка жизненного цикла activity. Выполним команду:

Install-Package WindowsAzure.MobileServices

Затем реализуем метод авторизации:

        public async Task AuthenticateAsync()         {             LoginResultDTO loginResult = await _channel.InvokeApiAsync<LoginResultDTO>("Authentication/Authenticate").ConfigureAwait(false);             MobileServiceUser user = new MobileServiceUser(loginResult.User.UserId)             {                 MobileServiceAuthenticationToken = loginResult.AuthenticationToken             };             _channel.CurrentUser = user;         } 

После этого при вызове любого метода контроллера, требующего авторизации, в свойстве User контроллера будет содержаться указанное значение «Demo:fakeUser». Остальные части клиентского приложения содержат распространённые в других приложениях строчки кода, для более детального изучения архив исходников примера можно скачать здесь.