属性を使用したIPベースの承認ポリシー

Question

クライアントIPに基づいてREST APIを保護しようとしています。

は、これらの要求の例でブログアプリケーションを想像してみて：appsettings.jsonで定義されて

/post/list    // Everyone  should see the posts 
/post/create    // Only Authors should create a post 
/post/update/42   // Only Authors should update a post 
/post/delete/42   // Only Admins should delete a post 
/comment/42/list   // Everyone  should see a post's comments 
/comment/42/create  // Everyone  should create a comment 
/comment/42/delete/1337 // Only Admins should delete a comment 

IPのホワイトリスト：ここで

"IpSecurity": { 
    "Author": "123.456.789.43,123.456.789.44", 
    "Admin": "123.456.789.42" 
} 

は私が好き応じRequireRole属性を持つアクションの例があります実装する：

[HttpGet("post/list")] 
public List<Post> List() 
// ... 

[RequireRole("Author")] 
[HttpGet("post/create")] 
public StandardResponse Create([FromBody]Post post) 
// ... 

[RequireRole("Admin")] 
[HttpGet("post/delete/{id}")] 
public StandardResponse Delete(int id) 
// ... 

はスタートアップ

var IpSecurity = Configuration.GetSection("IpSecurity"); 
services.Configure<IpSecurityConfig>(IpSecurity); 

からの注射定義され、それは良いアイデアのように聞こえるでしょうか？

私はカスタム認証ポリシー、ミドルウェア、またはそのフィルタを行う必要がありますか？

RequireRole属性を実装するにはどうすればよいですか？

---

Thisは、IPホワイトリストを実装する方法のアイデアを与えるが、ミドルウェアは、文脈アクションへのアクセス権を持っていないので、私は私の要件を定義するための属性を使用することはできません。私がお勧めしたい...

を彼らがスプーフィングすることができるように、との要求が拒否される前に、あなたのスタックにそれは非常深い作る - あなたはIPベースの認証の意味について考えてきたと仮定すると、

Answer 1

はい、それが一目で分かり簡単に見えるので、少なくともよくないに見えています。

「ロール」という用語を使用すると、後継者を混乱させる可能性があります。代わりに "MachineRole"と呼んでください。

public void ConfigureServices(IServiceCollection services) 
{ 
    //after services.AddMvc() : 

    services.AddAuthorization(o => { o.AddPolicy(MachineRole.AuthorMachine, p => p.RequireClaim(nameof(MachineRole), MachineRole.AuthorMachine)); }); 
    services.AddAuthorization(o => { o.AddPolicy(MachineRole.AdminMachine, p => p.RequireClaim(nameof(MachineRole), MachineRole.AdminMachine)); }); 
} 

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) 
{ 
    // ... 

    app.UseClaimsTransformation(AddMachineRoleClaims); 

    // app.UseMvc(...); 
    // ...etc... 
} 

public Task<ClaimsPrincipal> AddMachineRoleClaims(ClaimsTransformationContext ctx) 
{ 
    var connectionRemoteIpAddress = ctx.Context.Connection.RemoteIpAddress.MapToIPv4(); 
    if (Configuration.GetSection("IpSecurity")["Author"].Contains(connectionRemoteIpAddress.ToString())) 
    { 
     ctx.Principal.AddIdentity(new ClaimsIdentity(new[] { new Claim(nameof(MachineRole), MachineRole.AuthorMachine) })); 
    } 
    if (Configuration.GetSection("IpSecurity")["Admin"].Contains(connectionRemoteIpAddress.ToString())) 
    { 
     ctx.Principal.AddIdentity(new ClaimsIdentity(new[] { new Claim(nameof(MachineRole), MachineRole.AdminMachine) })); 
    } 

    return Task.FromResult(ctx.Principal); 
} 

public static class MachineRole 
{ 
    public const string AuthorMachine = "AuthorMachine"; 
    public const string AdminMachine = "AdminMachine"; 
} 

：AspNetCoreそれは、MVC4下 Startup.csにおける通常の方法では、このようなものだったように私には少し複雑に見えるに

実装（そして、同様の理由により、[Authorize(Roles="..."]を使用していません）

その後、あなたは、これは単純ではない、という事実によって、私は十分にイライラした

[Authorize(Policy = MachineRole.AdminMachine)] 

Answer 2

クレームを割り当てるミドルウェアを作成するか、少なくともIDを設定する（ユーザーが認証されるように）。次に、（ミドルウェアのIDに割り当てた）クレームまたは許可ポリシー（https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies）のいずれかを使用します。あなたは、ポリシーに関連付けられたIPアドレスに基づいて、各要求を拒否することができます：

[Authorize(Policy="AuthorIp")] 
[HttpGet("post/create")] 
public StandardResponse Create([FromBody]Post post) 

Answer 3

使用することができ、それは私が書くことを可能にするためにhttps://github.com/chrisfcarroll/RequireClaimAttributeAspNetCoreをやったMVC4にあったように単純ではありません特に、 ：

[RequireClaim("ClaimType",Value = "RequiredValue")] 
    public IActionResult Action(){}