2016-10-21 1 views
0

У нас есть приложение Azure Mobile, использующее проверку подлинности в социальной сети. Попытка добавления роли пользователя в качестве претензий с использованием пользовательского обработчика маркеров.Аутентификация мобильных приложений Azure с претензиями на персональную роль - претензии исчезают

Это все работает при запуске на локальном хосте - маркеры добавляются в обработчик маркера, и они доступны при вызове метода авторизации OnAuthorization AuthorizationAttribute. Атрибут Authorize с указанными ролями работает как ожидалось.

Но при запуске Azure - заявки добавляются, но когда метод OnAuthorization называется, требования к пользовательской роли исчезли.

Вот код:

Запуск/Конфигурация класса

public class OwinStartup 
{ 
    public void Configuration(IAppBuilder app) 
    { 
     var config = GlobalConfiguration.Configuration; 

     new MobileAppConfiguration() 
     .AddPushNotifications() 
     .ApplyTo(config); 

     MobileAppSettingsDictionary settings = config.GetMobileAppSettingsProvider(). 
GetMobileAppSettings(); 

     app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions() 
     { 
      SigningKey = ConfigurationManager.AppSettings["authSigningKey"], 
      ValidAudiences = new[] { ConfigurationManager.AppSettings["authAudience"] }, 
      ValidIssuers = new[] { ConfigurationManager.AppSettings["authIssuer"] }, 
      TokenHandler = new AppServiceTokenHandlerWithCustomClaims(config) 
     }); 

     //Authenticate stage handler in OWIN Pipeline 
     app.Use((context, next) => 
     { 
      return next.Invoke(); 
     }); 

     app.UseStageMarker(PipelineStage.Authenticate); 

    } 

маркеров Обработчик, который добавляет Роль претензий

public class AppServiceTokenHandlerWithCustomClaims : AppServiceTokenHandler 
{ 
    public AppServiceTokenHandlerWithCustomClaims(HttpConfiguration config) 
     : base(config) 
    { 

    } 

    public override bool TryValidateLoginToken(
     string token, 
     string signingKey, 
     IEnumerable<string> validAudiences, 
     IEnumerable<string> validIssuers, 
     out ClaimsPrincipal claimsPrincipal) 
    { 
     var validated = base.TryValidateLoginToken(token, signingKey, validAudiences, validIssuers, out claimsPrincipal); 

     if (validated) 
     { 
      string sid = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier).Value; 

      var roleProvider = UnityConfig.Container.Resolve<IRoleProvider>("RoleProvider"); 

      var roles = roleProvider.GetUserRolesBySid(sid); 

      foreach (var role in roles) 
      { 
       ((ClaimsIdentity)claimsPrincipal.Identity).AddClaim(new Claim(ClaimTypes.Role, role)); 
      } 
     } 
     return validated; 
    } 
} 

Роль Claim В качестве примера требование роли от тождества cl направлена ​​коллекция

{http://schemas.microsoft.com/ws/2008/06/identity/claims/role: admin} 

Авторизоваться Атрибут на Web Api контроллер

[Authorize(Roles = "admin")] 

Каждый вызов к конечной точке, которая имеет атрибут, Авторизоваться с одной или несколькими ролями, указанными не удается (401)

Не уверен, что происходит с претензиями, которые либо лишаются, либо не сохраняются в Identity при работе в Azure.

благодаря Майкл

ответ

1

Я получил главу об этом в книге - https://adrianhall.github.io/develop-mobile-apps-with-csharp-and-azure/chapter2/custom/#using-third-party-tokens

Примечания бит о пользовательской аутентификации с дополнительными требованиями. Вам нужно вызвать пользовательский API с исходным токеном, проверить маркер на достоверность, а затем создать новый токен (маркер zumo) с требуемыми вами претензиями. Затем вы можете использовать эти претензии для всего, что требуется.

+0

, поэтому я должен вызывать новую конечную точку после входа в систему и в этой конечной точке, если токен в действии, создать новый, который включает в себя заявки на роль и вернуть их клиенту. Затем все последующие вызовы с этим токеном будут включать в себя новые требования к роли, которые фильтр Authorize может проверить, и определить, должен ли им быть предоставлен доступ к запрашиваемому ресурсу. – MIantosca

+0

Вы могли бы это сделать, или вы могли бы выполнить полный пользовательский аут и выполнить проверку, графические API-запросы и формулы, корректирующие все в одном. Я бы, наверное, сделал последнее лично, потому что я контролирую именно то, что в претензиях. Тем не менее, обе возможности. –

0

Согласно this blog post, некоторые из ваших вариантов может быть неправильным. Параметры AppSettings предназначены только для локальной отладки и не будут работать в Azure.

Попробуйте это:

public void Configuration(IAppBuilder app) 
{ 
    var config = GlobalConfiguration.Configuration; 

    new MobileAppConfiguration() 
     .AddPushNotifications() 
     .ApplyTo(config); 

    MobileAppSettingsDictionary settings = config 
     .GetMobileAppSettingsProvider() 
     .GetMobileAppSettings(); 

    // Local Debugging 
    if (string.IsNullOrEmpty(settings.HostName)) 
    { 
     app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions() 
     { 
      SigningKey = ConfigurationManager.AppSettings["authSigningKey"], 
      ValidAudiences = new[] { ConfigurationManager.AppSettings["authAudience"] }, 
      ValidIssuers = new[] { ConfigurationManager.AppSettings["authIssuer"] }, 
      TokenHandler = new AppServiceTokenHandlerWithCustomClaims(config) 
     }); 
    } 
    // Azure 
    else 
    { 
     var signingKey = GetSigningKey(); 
     string hostName = GetHostName(settings); 

     app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions 
     { 
      SigningKey = signingKey, 
      ValidAudiences = new[] { hostName }, 
      ValidIssuers = new[] { hostName }, 
      TokenHandler = new AppServiceTokenHandlerWithCustomClaims(config) 
     }); 
    } 


    //Authenticate stage handler in OWIN Pipeline 
    app.Use((context, next) => 
    { 
     return next.Invoke(); 
    }); 

    app.UseStageMarker(PipelineStage.Authenticate); 

} 

private static string GetSigningKey() 
{ 
    // Check for the App Service Auth environment variable WEBSITE_AUTH_SIGNING_KEY, 
    // which holds the signing key on the server. If it's not there, check for a SigningKey 
    // app setting, which can be used for local debugging. 

    string key = Environment.GetEnvironmentVariable("WEBSITE_AUTH_SIGNING_KEY"); 

    if (string.IsNullOrWhiteSpace(key)) 
    { 
     key = ConfigurationManager.AppSettings["SigningKey"]; 
    } 

    return key; 
} 

private static string GetHostName(MobileAppSettingsDictionary settings) 
{ 
    return string.Format("https://{0}/", settings.HostName); 
} 
+0

Я ссылался на это сообщение в блоге, когда сначала работал над этим решением. Первоначально я настраивал его на другой код для локального и Azure, как он описывает. Но когда я начал отлаживать, я понял, что код почти такой же. Три настройки настраиваются как параметры на портале Azure, и аутентификация работает нормально в обеих средах. Это нестандартные требования к авторизации, которые не работают. – MIantosca

+0

Вы добавили пользовательский атрибут AuthorizeAttribute, описанный в конце сообщения? –

+0

Я сделал - я создал пользовательский атрибут AuthorizeAttribute и смог проверить претензии в методе OnAuthorization, и именно так я обнаружил, что претензии на Azure отсутствовали, но они присутствовали на localhost.Кроме того, функция AuthorizeAttribute отлично работает с претензиями на роль - поэтому она не должна быть необходимой, но это позволило мне подтвердить присутствие или отсутствие претензий. – MIantosca

Смежные вопросы