Ещё одна недостаточно описанная тема про 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». Остальные части клиентского приложения содержат распространённые в других приложениях строчки кода, для более детального изучения архив исходников примера можно скачать здесь.
Автор: Ilya81
