2016-10-21 10 views
0

ソーシャルネットワーク認証を使用するAzureモバイルアプリがあります。カスタムトークンハンドラを使用して、要求としてユーザーロールを追加しようとしています。カスタムロールクレームを使用したAzureモバイルアプリ認証 - クレームが消える

これはすべてlocalhost上で実行されているときに動作します。トークンはトークンハンドラに追加され、AuthorizationAttribute OnAuthorizationメソッドが呼び出されたときに使用できます。指定されたロールによる属性の承認は、期待通りに機能します。

実行中の場合、クレームが追加されますが、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; 
    } 
} 

役割項 例の主張:ここ

コードでありますアイデンティティclからのロールクレームコレクション

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

承認は、Web APIをコントローラ

[Authorize(Roles = "admin")] 

承認は、指定された1つまたは複数の役割を持つ属性があるエンドポイントへのすべての呼び出しが失敗した(401)

わからないにの属性目指しますAzureで動作しているときに、アイデンティティに残っていたか、または保持されていないクレームが起きているかどうか。

おかげ マイケル

答えて

1

- https://adrianhall.github.io/develop-mobile-apps-with-csharp-and-azure/chapter2/custom/#using-third-party-tokens

は、追加の請求の範囲とカスタム認証について少し注意してください。元のトークンを使用してカスタムAPIを呼び出し、有効性を確認してから、新しいトークン(zumoトークン)を作成する必要があります。これらの主張を必要なものに使用することができます。

+0

私はログイン後に新しいエンドポイントを呼び出す必要があります。有効なトークンがあれば、そのエンドポイントでロールクレームを含む新しいトークンを作成し、それをクライアントに返します。その後、そのトークンを使用するすべての呼び出しには、承認フィルタが検証し、要求されたリソースへのアクセスを許可する必要があるかどうかを判断する新しい役割クレームが含まれます。 – MIantosca

+0

これを行うこともできますし、 APIのルックアップとクレーム調整を1つにまとめたものです。私はおそらく、私が主張にあるものを正確に管理しているので、後者を個人的に行うだろう。しかし、どちらも可能性です。 –

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

私はこの解決策を最初に取り上げたときに、そのブログ記事を参照しました。私はそれが記述するように、それは元々地方vs Azureのための異なったコードでそれを設定しました。しかし、私がデバッグを開始したとき、私はコードがほとんど同じであることを認識しました。 3つの設定は、Azureポータルの設定として設定され、両方の環境で認証が正常に動作しています。承認されていないカスタムクレームだけです。 – MIantosca

+0

投稿の最後に記載されているカスタムAuthorizeAttributeを追加しましたか? –

+0

私はカスタムAuthorizeAttributeを作成し、OnAuthorizationメソッドの要求を検査することができました。これが、Azureには存在しないが、それらはローカルホストに存在していたことを発見しました。また、Out of the BoxのAuthorizeAttributeは、ロールクレームでうまく動作するので、必要ではないはずですが、クレームの有無を確認することができました。 – MIantosca

関連する問題