Check IP with JWT Authorization in ASP.NET Core Web Api












1















Is it possible to check the IP adress when using System.IdentityModel.Tokens.Jwt in an ASP.NET core Web Api application?



I thought about adding a Claim containing the IP of the user that requested it and check it somehow for each request. Normally I would use OnActionExecuting in ASP.NET MVC.



Is there a Middleware/Authorization based solution?



I Create my Jwt Token Claims like this:



private IEnumerable<Claim> getStandardClaims(IdentityUser user)
{
var claims = new List<Claim>
{
new Claim(ClaimTypes.Name, user.UserName),
new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
new Claim(JwtRegisteredClaimNames.Sub, user.UserName),
new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
new Claim("ipaddress", HttpContext.Connection.RemoteIpAddress.ToString())
};

return claims;
}


this is what the JWT Data look like:



{
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "username",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "5a6b3eb8-ed7f-48c6-b10c-a279ffd4f7c8",
"sub": "username",
"jti": "44c95b53-bfba-4f33-b4c3-834127605432",
"ipaddress": "::1",
"exp": 1542707081,
"iss": "https://localhost:5001/",
"aud": "https://localhost:5001/"
}


Edit: Possible Solution for JWT Claims?
Maybe I have to read the Claims like this (Test code, no null checks ect..):



var auth = HttpContext.Request.Headers.FirstOrDefault(x => x.Key == "Authorization");
string token = auth.Value[0].Split(' ')[1];

JwtTokenService<RefreshToken, string> jwtService = new JwtTokenService<RefreshToken, string>(null);
var principal = jwtService.GetPrincipalFromExpiredToken(token, _config["Jwt:Key"]);

Claim ipClaim = principal.FindFirst(claim => claim.Type == "ipaddress");


This is the GetPrincipalFromExpiredToken Method:



public ClaimsPrincipal GetPrincipalFromExpiredToken(string token, string securityKey)
{
var tokenValidationParameters = new TokenValidationParameters
{
ValidateAudience = false,
ValidateIssuer = false,
ValidateIssuerSigningKey = true,
IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(securityKey)),
ValidateLifetime = false
};

var tokenHandler = new JwtSecurityTokenHandler();
SecurityToken securityToken;
var principal = tokenHandler.ValidateToken(token, tokenValidationParameters, out securityToken);
var jwtSecurityToken = securityToken as JwtSecurityToken;
if (jwtSecurityToken == null || !jwtSecurityToken.Header.Alg.Equals(SecurityAlgorithms.HmacSha256, StringComparison.InvariantCultureIgnoreCase))
throw new SecurityTokenException("Invalid token");

return principal;
}









share|improve this question





























    1















    Is it possible to check the IP adress when using System.IdentityModel.Tokens.Jwt in an ASP.NET core Web Api application?



    I thought about adding a Claim containing the IP of the user that requested it and check it somehow for each request. Normally I would use OnActionExecuting in ASP.NET MVC.



    Is there a Middleware/Authorization based solution?



    I Create my Jwt Token Claims like this:



    private IEnumerable<Claim> getStandardClaims(IdentityUser user)
    {
    var claims = new List<Claim>
    {
    new Claim(ClaimTypes.Name, user.UserName),
    new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
    new Claim(JwtRegisteredClaimNames.Sub, user.UserName),
    new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
    new Claim("ipaddress", HttpContext.Connection.RemoteIpAddress.ToString())
    };

    return claims;
    }


    this is what the JWT Data look like:



    {
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "username",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "5a6b3eb8-ed7f-48c6-b10c-a279ffd4f7c8",
    "sub": "username",
    "jti": "44c95b53-bfba-4f33-b4c3-834127605432",
    "ipaddress": "::1",
    "exp": 1542707081,
    "iss": "https://localhost:5001/",
    "aud": "https://localhost:5001/"
    }


    Edit: Possible Solution for JWT Claims?
    Maybe I have to read the Claims like this (Test code, no null checks ect..):



    var auth = HttpContext.Request.Headers.FirstOrDefault(x => x.Key == "Authorization");
    string token = auth.Value[0].Split(' ')[1];

    JwtTokenService<RefreshToken, string> jwtService = new JwtTokenService<RefreshToken, string>(null);
    var principal = jwtService.GetPrincipalFromExpiredToken(token, _config["Jwt:Key"]);

    Claim ipClaim = principal.FindFirst(claim => claim.Type == "ipaddress");


    This is the GetPrincipalFromExpiredToken Method:



    public ClaimsPrincipal GetPrincipalFromExpiredToken(string token, string securityKey)
    {
    var tokenValidationParameters = new TokenValidationParameters
    {
    ValidateAudience = false,
    ValidateIssuer = false,
    ValidateIssuerSigningKey = true,
    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(securityKey)),
    ValidateLifetime = false
    };

    var tokenHandler = new JwtSecurityTokenHandler();
    SecurityToken securityToken;
    var principal = tokenHandler.ValidateToken(token, tokenValidationParameters, out securityToken);
    var jwtSecurityToken = securityToken as JwtSecurityToken;
    if (jwtSecurityToken == null || !jwtSecurityToken.Header.Alg.Equals(SecurityAlgorithms.HmacSha256, StringComparison.InvariantCultureIgnoreCase))
    throw new SecurityTokenException("Invalid token");

    return principal;
    }









    share|improve this question



























      1












      1








      1








      Is it possible to check the IP adress when using System.IdentityModel.Tokens.Jwt in an ASP.NET core Web Api application?



      I thought about adding a Claim containing the IP of the user that requested it and check it somehow for each request. Normally I would use OnActionExecuting in ASP.NET MVC.



      Is there a Middleware/Authorization based solution?



      I Create my Jwt Token Claims like this:



      private IEnumerable<Claim> getStandardClaims(IdentityUser user)
      {
      var claims = new List<Claim>
      {
      new Claim(ClaimTypes.Name, user.UserName),
      new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
      new Claim(JwtRegisteredClaimNames.Sub, user.UserName),
      new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
      new Claim("ipaddress", HttpContext.Connection.RemoteIpAddress.ToString())
      };

      return claims;
      }


      this is what the JWT Data look like:



      {
      "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "username",
      "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "5a6b3eb8-ed7f-48c6-b10c-a279ffd4f7c8",
      "sub": "username",
      "jti": "44c95b53-bfba-4f33-b4c3-834127605432",
      "ipaddress": "::1",
      "exp": 1542707081,
      "iss": "https://localhost:5001/",
      "aud": "https://localhost:5001/"
      }


      Edit: Possible Solution for JWT Claims?
      Maybe I have to read the Claims like this (Test code, no null checks ect..):



      var auth = HttpContext.Request.Headers.FirstOrDefault(x => x.Key == "Authorization");
      string token = auth.Value[0].Split(' ')[1];

      JwtTokenService<RefreshToken, string> jwtService = new JwtTokenService<RefreshToken, string>(null);
      var principal = jwtService.GetPrincipalFromExpiredToken(token, _config["Jwt:Key"]);

      Claim ipClaim = principal.FindFirst(claim => claim.Type == "ipaddress");


      This is the GetPrincipalFromExpiredToken Method:



      public ClaimsPrincipal GetPrincipalFromExpiredToken(string token, string securityKey)
      {
      var tokenValidationParameters = new TokenValidationParameters
      {
      ValidateAudience = false,
      ValidateIssuer = false,
      ValidateIssuerSigningKey = true,
      IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(securityKey)),
      ValidateLifetime = false
      };

      var tokenHandler = new JwtSecurityTokenHandler();
      SecurityToken securityToken;
      var principal = tokenHandler.ValidateToken(token, tokenValidationParameters, out securityToken);
      var jwtSecurityToken = securityToken as JwtSecurityToken;
      if (jwtSecurityToken == null || !jwtSecurityToken.Header.Alg.Equals(SecurityAlgorithms.HmacSha256, StringComparison.InvariantCultureIgnoreCase))
      throw new SecurityTokenException("Invalid token");

      return principal;
      }









      share|improve this question
















      Is it possible to check the IP adress when using System.IdentityModel.Tokens.Jwt in an ASP.NET core Web Api application?



      I thought about adding a Claim containing the IP of the user that requested it and check it somehow for each request. Normally I would use OnActionExecuting in ASP.NET MVC.



      Is there a Middleware/Authorization based solution?



      I Create my Jwt Token Claims like this:



      private IEnumerable<Claim> getStandardClaims(IdentityUser user)
      {
      var claims = new List<Claim>
      {
      new Claim(ClaimTypes.Name, user.UserName),
      new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
      new Claim(JwtRegisteredClaimNames.Sub, user.UserName),
      new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
      new Claim("ipaddress", HttpContext.Connection.RemoteIpAddress.ToString())
      };

      return claims;
      }


      this is what the JWT Data look like:



      {
      "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "username",
      "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "5a6b3eb8-ed7f-48c6-b10c-a279ffd4f7c8",
      "sub": "username",
      "jti": "44c95b53-bfba-4f33-b4c3-834127605432",
      "ipaddress": "::1",
      "exp": 1542707081,
      "iss": "https://localhost:5001/",
      "aud": "https://localhost:5001/"
      }


      Edit: Possible Solution for JWT Claims?
      Maybe I have to read the Claims like this (Test code, no null checks ect..):



      var auth = HttpContext.Request.Headers.FirstOrDefault(x => x.Key == "Authorization");
      string token = auth.Value[0].Split(' ')[1];

      JwtTokenService<RefreshToken, string> jwtService = new JwtTokenService<RefreshToken, string>(null);
      var principal = jwtService.GetPrincipalFromExpiredToken(token, _config["Jwt:Key"]);

      Claim ipClaim = principal.FindFirst(claim => claim.Type == "ipaddress");


      This is the GetPrincipalFromExpiredToken Method:



      public ClaimsPrincipal GetPrincipalFromExpiredToken(string token, string securityKey)
      {
      var tokenValidationParameters = new TokenValidationParameters
      {
      ValidateAudience = false,
      ValidateIssuer = false,
      ValidateIssuerSigningKey = true,
      IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(securityKey)),
      ValidateLifetime = false
      };

      var tokenHandler = new JwtSecurityTokenHandler();
      SecurityToken securityToken;
      var principal = tokenHandler.ValidateToken(token, tokenValidationParameters, out securityToken);
      var jwtSecurityToken = securityToken as JwtSecurityToken;
      if (jwtSecurityToken == null || !jwtSecurityToken.Header.Alg.Equals(SecurityAlgorithms.HmacSha256, StringComparison.InvariantCultureIgnoreCase))
      throw new SecurityTokenException("Invalid token");

      return principal;
      }






      c# asp.net-core jwt asp.net-core-webapi






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 20 '18 at 10:06







      DoubleVoid

















      asked Nov 19 '18 at 11:38









      DoubleVoidDoubleVoid

      373629




      373629
























          1 Answer
          1






          active

          oldest

          votes


















          2














          You can do that (and all other authorization stuff) via Policy-based authorization.



          public class IpCheckRequirement : IAuthorizationRequirement
          {
          public bool IpClaimRequired { get; set; } = true;
          }

          public class IpCheckHandler : AuthorizationHandler<IpCheckRequirement>
          {
          public IpCheckHandler(IHttpContextAccessor httpContextAccessor)
          {
          HttpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
          }

          private IHttpContextAccessor HttpContextAccessor { get; }
          private HttpContext HttpContext => HttpContextAccessor.HttpContext;


          protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IpCheckRequirement requirement)
          {
          Claim ipClaim = context.User.FindFirst(claim => claim.Type == "ipaddress");

          // No claim existing set and and its configured as optional so skip the check
          if(ipClaim == null && !requirement.IpClaimRequired)
          {
          // Optional claims (IsClaimRequired=false and no "ipaddress" in the claims principal) won't call context.Fail()
          // This allows next Handle to succeed. If we call Fail() the access will be denied, even if handlers
          // evaluated after this one do succeed
          return Task.CompletedTask;
          }

          if (ipClaim.Value = HttpContext.Connection.RemoteIpAddress?.ToString())
          {
          context.Succeed(requirement);
          }
          else
          {
          // Only call fail, to guarantee a failure, even if further handlers may succeed
          context.Fail();
          }

          return Task.CompletedTask;
          }
          }


          then add



          services.AddSingleton<IAuthorizationHandler, IpCheckHandler>();
          services.AddAuthorization(options =>
          {
          options.AddPolicy("SameIpPolicy",
          policy => policy.Requirements.Add(new IpCheckRequirement { IpClaimRequired = true }));
          });


          to your ConfigureServices method.



          Now you can annote the controllers on which you want to apply it with [Authroize(Policy = "SameIpPolicy")] or add a global policy:



          services.AddMvc(options =>
          {
          options.Filters.Add(new AuthorizeFilter("SameIpPolicy"))
          })





          share|improve this answer


























          • Hey, thanks! I get the idea and the HandleRequirementAsync method gets triggered. But context.User.FindFirst gives me the user Claims for the Identity instance I guess? I need the claims I've put into my JWT token (see original post on how I add these claims. The JWT Authorization works fine btw.

            – DoubleVoid
            Nov 20 '18 at 9:46











          • Then you have an odd setup. Typically your Identity server (which generates the JWT token) and your resource server are two distinct applications. In resource servers (WebAPIs only, no MVC) you usually use JWT for authorization and Cookie authorization for MVC. Did you really call the given method via Ajax (or postman or other addon) with the JWT bearer token included in the request?

            – Tseng
            Nov 20 '18 at 9:57











          • Yes, I use Postman. Using no token gives me an unauthorized error code. In my setup there is just one server. I edited my post, added a "possible" solution. This way I can read the claims from the jwt. At the moment my Identity User has no claims set. I don't want to hit the database. But I guess I would have to add Identity Claims and sync them with my JWT and update the IP Adress for the ip claim?!

            – DoubleVoid
            Nov 20 '18 at 10:08











          • I think something wrong with your (default) authentication scheme. The authentication scheme tells the system whose claim to use (in case you have more than one authentication in use). If you set up Cookie authentication scheme as default it will always use its claims, not the one from JWT. Either you set JWT auth schema as default, and annotate Cookie/Identity where needed [Authorize(AuthenticationSchemes = "CookieAuthenticationDefaults.AuthenticationScheme")].

            – Tseng
            Nov 20 '18 at 10:18






          • 1





            Yea, sorry. Missed it on my part. Yes, you need to call context.Succeed(requirement); if you want it evaluate as success. But only call .Fail() if you want guarantee it to fail (other authorization handlers wont be evaluated for this requirement). By not calling .Fail() you allow next handler to succeed. See Why would I want multiple handlers for a requirement?

            – Tseng
            Nov 20 '18 at 16:16











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53373832%2fcheck-ip-with-jwt-authorization-in-asp-net-core-web-api%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          2














          You can do that (and all other authorization stuff) via Policy-based authorization.



          public class IpCheckRequirement : IAuthorizationRequirement
          {
          public bool IpClaimRequired { get; set; } = true;
          }

          public class IpCheckHandler : AuthorizationHandler<IpCheckRequirement>
          {
          public IpCheckHandler(IHttpContextAccessor httpContextAccessor)
          {
          HttpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
          }

          private IHttpContextAccessor HttpContextAccessor { get; }
          private HttpContext HttpContext => HttpContextAccessor.HttpContext;


          protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IpCheckRequirement requirement)
          {
          Claim ipClaim = context.User.FindFirst(claim => claim.Type == "ipaddress");

          // No claim existing set and and its configured as optional so skip the check
          if(ipClaim == null && !requirement.IpClaimRequired)
          {
          // Optional claims (IsClaimRequired=false and no "ipaddress" in the claims principal) won't call context.Fail()
          // This allows next Handle to succeed. If we call Fail() the access will be denied, even if handlers
          // evaluated after this one do succeed
          return Task.CompletedTask;
          }

          if (ipClaim.Value = HttpContext.Connection.RemoteIpAddress?.ToString())
          {
          context.Succeed(requirement);
          }
          else
          {
          // Only call fail, to guarantee a failure, even if further handlers may succeed
          context.Fail();
          }

          return Task.CompletedTask;
          }
          }


          then add



          services.AddSingleton<IAuthorizationHandler, IpCheckHandler>();
          services.AddAuthorization(options =>
          {
          options.AddPolicy("SameIpPolicy",
          policy => policy.Requirements.Add(new IpCheckRequirement { IpClaimRequired = true }));
          });


          to your ConfigureServices method.



          Now you can annote the controllers on which you want to apply it with [Authroize(Policy = "SameIpPolicy")] or add a global policy:



          services.AddMvc(options =>
          {
          options.Filters.Add(new AuthorizeFilter("SameIpPolicy"))
          })





          share|improve this answer


























          • Hey, thanks! I get the idea and the HandleRequirementAsync method gets triggered. But context.User.FindFirst gives me the user Claims for the Identity instance I guess? I need the claims I've put into my JWT token (see original post on how I add these claims. The JWT Authorization works fine btw.

            – DoubleVoid
            Nov 20 '18 at 9:46











          • Then you have an odd setup. Typically your Identity server (which generates the JWT token) and your resource server are two distinct applications. In resource servers (WebAPIs only, no MVC) you usually use JWT for authorization and Cookie authorization for MVC. Did you really call the given method via Ajax (or postman or other addon) with the JWT bearer token included in the request?

            – Tseng
            Nov 20 '18 at 9:57











          • Yes, I use Postman. Using no token gives me an unauthorized error code. In my setup there is just one server. I edited my post, added a "possible" solution. This way I can read the claims from the jwt. At the moment my Identity User has no claims set. I don't want to hit the database. But I guess I would have to add Identity Claims and sync them with my JWT and update the IP Adress for the ip claim?!

            – DoubleVoid
            Nov 20 '18 at 10:08











          • I think something wrong with your (default) authentication scheme. The authentication scheme tells the system whose claim to use (in case you have more than one authentication in use). If you set up Cookie authentication scheme as default it will always use its claims, not the one from JWT. Either you set JWT auth schema as default, and annotate Cookie/Identity where needed [Authorize(AuthenticationSchemes = "CookieAuthenticationDefaults.AuthenticationScheme")].

            – Tseng
            Nov 20 '18 at 10:18






          • 1





            Yea, sorry. Missed it on my part. Yes, you need to call context.Succeed(requirement); if you want it evaluate as success. But only call .Fail() if you want guarantee it to fail (other authorization handlers wont be evaluated for this requirement). By not calling .Fail() you allow next handler to succeed. See Why would I want multiple handlers for a requirement?

            – Tseng
            Nov 20 '18 at 16:16
















          2














          You can do that (and all other authorization stuff) via Policy-based authorization.



          public class IpCheckRequirement : IAuthorizationRequirement
          {
          public bool IpClaimRequired { get; set; } = true;
          }

          public class IpCheckHandler : AuthorizationHandler<IpCheckRequirement>
          {
          public IpCheckHandler(IHttpContextAccessor httpContextAccessor)
          {
          HttpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
          }

          private IHttpContextAccessor HttpContextAccessor { get; }
          private HttpContext HttpContext => HttpContextAccessor.HttpContext;


          protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IpCheckRequirement requirement)
          {
          Claim ipClaim = context.User.FindFirst(claim => claim.Type == "ipaddress");

          // No claim existing set and and its configured as optional so skip the check
          if(ipClaim == null && !requirement.IpClaimRequired)
          {
          // Optional claims (IsClaimRequired=false and no "ipaddress" in the claims principal) won't call context.Fail()
          // This allows next Handle to succeed. If we call Fail() the access will be denied, even if handlers
          // evaluated after this one do succeed
          return Task.CompletedTask;
          }

          if (ipClaim.Value = HttpContext.Connection.RemoteIpAddress?.ToString())
          {
          context.Succeed(requirement);
          }
          else
          {
          // Only call fail, to guarantee a failure, even if further handlers may succeed
          context.Fail();
          }

          return Task.CompletedTask;
          }
          }


          then add



          services.AddSingleton<IAuthorizationHandler, IpCheckHandler>();
          services.AddAuthorization(options =>
          {
          options.AddPolicy("SameIpPolicy",
          policy => policy.Requirements.Add(new IpCheckRequirement { IpClaimRequired = true }));
          });


          to your ConfigureServices method.



          Now you can annote the controllers on which you want to apply it with [Authroize(Policy = "SameIpPolicy")] or add a global policy:



          services.AddMvc(options =>
          {
          options.Filters.Add(new AuthorizeFilter("SameIpPolicy"))
          })





          share|improve this answer


























          • Hey, thanks! I get the idea and the HandleRequirementAsync method gets triggered. But context.User.FindFirst gives me the user Claims for the Identity instance I guess? I need the claims I've put into my JWT token (see original post on how I add these claims. The JWT Authorization works fine btw.

            – DoubleVoid
            Nov 20 '18 at 9:46











          • Then you have an odd setup. Typically your Identity server (which generates the JWT token) and your resource server are two distinct applications. In resource servers (WebAPIs only, no MVC) you usually use JWT for authorization and Cookie authorization for MVC. Did you really call the given method via Ajax (or postman or other addon) with the JWT bearer token included in the request?

            – Tseng
            Nov 20 '18 at 9:57











          • Yes, I use Postman. Using no token gives me an unauthorized error code. In my setup there is just one server. I edited my post, added a "possible" solution. This way I can read the claims from the jwt. At the moment my Identity User has no claims set. I don't want to hit the database. But I guess I would have to add Identity Claims and sync them with my JWT and update the IP Adress for the ip claim?!

            – DoubleVoid
            Nov 20 '18 at 10:08











          • I think something wrong with your (default) authentication scheme. The authentication scheme tells the system whose claim to use (in case you have more than one authentication in use). If you set up Cookie authentication scheme as default it will always use its claims, not the one from JWT. Either you set JWT auth schema as default, and annotate Cookie/Identity where needed [Authorize(AuthenticationSchemes = "CookieAuthenticationDefaults.AuthenticationScheme")].

            – Tseng
            Nov 20 '18 at 10:18






          • 1





            Yea, sorry. Missed it on my part. Yes, you need to call context.Succeed(requirement); if you want it evaluate as success. But only call .Fail() if you want guarantee it to fail (other authorization handlers wont be evaluated for this requirement). By not calling .Fail() you allow next handler to succeed. See Why would I want multiple handlers for a requirement?

            – Tseng
            Nov 20 '18 at 16:16














          2












          2








          2







          You can do that (and all other authorization stuff) via Policy-based authorization.



          public class IpCheckRequirement : IAuthorizationRequirement
          {
          public bool IpClaimRequired { get; set; } = true;
          }

          public class IpCheckHandler : AuthorizationHandler<IpCheckRequirement>
          {
          public IpCheckHandler(IHttpContextAccessor httpContextAccessor)
          {
          HttpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
          }

          private IHttpContextAccessor HttpContextAccessor { get; }
          private HttpContext HttpContext => HttpContextAccessor.HttpContext;


          protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IpCheckRequirement requirement)
          {
          Claim ipClaim = context.User.FindFirst(claim => claim.Type == "ipaddress");

          // No claim existing set and and its configured as optional so skip the check
          if(ipClaim == null && !requirement.IpClaimRequired)
          {
          // Optional claims (IsClaimRequired=false and no "ipaddress" in the claims principal) won't call context.Fail()
          // This allows next Handle to succeed. If we call Fail() the access will be denied, even if handlers
          // evaluated after this one do succeed
          return Task.CompletedTask;
          }

          if (ipClaim.Value = HttpContext.Connection.RemoteIpAddress?.ToString())
          {
          context.Succeed(requirement);
          }
          else
          {
          // Only call fail, to guarantee a failure, even if further handlers may succeed
          context.Fail();
          }

          return Task.CompletedTask;
          }
          }


          then add



          services.AddSingleton<IAuthorizationHandler, IpCheckHandler>();
          services.AddAuthorization(options =>
          {
          options.AddPolicy("SameIpPolicy",
          policy => policy.Requirements.Add(new IpCheckRequirement { IpClaimRequired = true }));
          });


          to your ConfigureServices method.



          Now you can annote the controllers on which you want to apply it with [Authroize(Policy = "SameIpPolicy")] or add a global policy:



          services.AddMvc(options =>
          {
          options.Filters.Add(new AuthorizeFilter("SameIpPolicy"))
          })





          share|improve this answer















          You can do that (and all other authorization stuff) via Policy-based authorization.



          public class IpCheckRequirement : IAuthorizationRequirement
          {
          public bool IpClaimRequired { get; set; } = true;
          }

          public class IpCheckHandler : AuthorizationHandler<IpCheckRequirement>
          {
          public IpCheckHandler(IHttpContextAccessor httpContextAccessor)
          {
          HttpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
          }

          private IHttpContextAccessor HttpContextAccessor { get; }
          private HttpContext HttpContext => HttpContextAccessor.HttpContext;


          protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IpCheckRequirement requirement)
          {
          Claim ipClaim = context.User.FindFirst(claim => claim.Type == "ipaddress");

          // No claim existing set and and its configured as optional so skip the check
          if(ipClaim == null && !requirement.IpClaimRequired)
          {
          // Optional claims (IsClaimRequired=false and no "ipaddress" in the claims principal) won't call context.Fail()
          // This allows next Handle to succeed. If we call Fail() the access will be denied, even if handlers
          // evaluated after this one do succeed
          return Task.CompletedTask;
          }

          if (ipClaim.Value = HttpContext.Connection.RemoteIpAddress?.ToString())
          {
          context.Succeed(requirement);
          }
          else
          {
          // Only call fail, to guarantee a failure, even if further handlers may succeed
          context.Fail();
          }

          return Task.CompletedTask;
          }
          }


          then add



          services.AddSingleton<IAuthorizationHandler, IpCheckHandler>();
          services.AddAuthorization(options =>
          {
          options.AddPolicy("SameIpPolicy",
          policy => policy.Requirements.Add(new IpCheckRequirement { IpClaimRequired = true }));
          });


          to your ConfigureServices method.



          Now you can annote the controllers on which you want to apply it with [Authroize(Policy = "SameIpPolicy")] or add a global policy:



          services.AddMvc(options =>
          {
          options.Filters.Add(new AuthorizeFilter("SameIpPolicy"))
          })






          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 20 '18 at 16:20

























          answered Nov 19 '18 at 14:31









          TsengTseng

          34k594124




          34k594124













          • Hey, thanks! I get the idea and the HandleRequirementAsync method gets triggered. But context.User.FindFirst gives me the user Claims for the Identity instance I guess? I need the claims I've put into my JWT token (see original post on how I add these claims. The JWT Authorization works fine btw.

            – DoubleVoid
            Nov 20 '18 at 9:46











          • Then you have an odd setup. Typically your Identity server (which generates the JWT token) and your resource server are two distinct applications. In resource servers (WebAPIs only, no MVC) you usually use JWT for authorization and Cookie authorization for MVC. Did you really call the given method via Ajax (or postman or other addon) with the JWT bearer token included in the request?

            – Tseng
            Nov 20 '18 at 9:57











          • Yes, I use Postman. Using no token gives me an unauthorized error code. In my setup there is just one server. I edited my post, added a "possible" solution. This way I can read the claims from the jwt. At the moment my Identity User has no claims set. I don't want to hit the database. But I guess I would have to add Identity Claims and sync them with my JWT and update the IP Adress for the ip claim?!

            – DoubleVoid
            Nov 20 '18 at 10:08











          • I think something wrong with your (default) authentication scheme. The authentication scheme tells the system whose claim to use (in case you have more than one authentication in use). If you set up Cookie authentication scheme as default it will always use its claims, not the one from JWT. Either you set JWT auth schema as default, and annotate Cookie/Identity where needed [Authorize(AuthenticationSchemes = "CookieAuthenticationDefaults.AuthenticationScheme")].

            – Tseng
            Nov 20 '18 at 10:18






          • 1





            Yea, sorry. Missed it on my part. Yes, you need to call context.Succeed(requirement); if you want it evaluate as success. But only call .Fail() if you want guarantee it to fail (other authorization handlers wont be evaluated for this requirement). By not calling .Fail() you allow next handler to succeed. See Why would I want multiple handlers for a requirement?

            – Tseng
            Nov 20 '18 at 16:16



















          • Hey, thanks! I get the idea and the HandleRequirementAsync method gets triggered. But context.User.FindFirst gives me the user Claims for the Identity instance I guess? I need the claims I've put into my JWT token (see original post on how I add these claims. The JWT Authorization works fine btw.

            – DoubleVoid
            Nov 20 '18 at 9:46











          • Then you have an odd setup. Typically your Identity server (which generates the JWT token) and your resource server are two distinct applications. In resource servers (WebAPIs only, no MVC) you usually use JWT for authorization and Cookie authorization for MVC. Did you really call the given method via Ajax (or postman or other addon) with the JWT bearer token included in the request?

            – Tseng
            Nov 20 '18 at 9:57











          • Yes, I use Postman. Using no token gives me an unauthorized error code. In my setup there is just one server. I edited my post, added a "possible" solution. This way I can read the claims from the jwt. At the moment my Identity User has no claims set. I don't want to hit the database. But I guess I would have to add Identity Claims and sync them with my JWT and update the IP Adress for the ip claim?!

            – DoubleVoid
            Nov 20 '18 at 10:08











          • I think something wrong with your (default) authentication scheme. The authentication scheme tells the system whose claim to use (in case you have more than one authentication in use). If you set up Cookie authentication scheme as default it will always use its claims, not the one from JWT. Either you set JWT auth schema as default, and annotate Cookie/Identity where needed [Authorize(AuthenticationSchemes = "CookieAuthenticationDefaults.AuthenticationScheme")].

            – Tseng
            Nov 20 '18 at 10:18






          • 1





            Yea, sorry. Missed it on my part. Yes, you need to call context.Succeed(requirement); if you want it evaluate as success. But only call .Fail() if you want guarantee it to fail (other authorization handlers wont be evaluated for this requirement). By not calling .Fail() you allow next handler to succeed. See Why would I want multiple handlers for a requirement?

            – Tseng
            Nov 20 '18 at 16:16

















          Hey, thanks! I get the idea and the HandleRequirementAsync method gets triggered. But context.User.FindFirst gives me the user Claims for the Identity instance I guess? I need the claims I've put into my JWT token (see original post on how I add these claims. The JWT Authorization works fine btw.

          – DoubleVoid
          Nov 20 '18 at 9:46





          Hey, thanks! I get the idea and the HandleRequirementAsync method gets triggered. But context.User.FindFirst gives me the user Claims for the Identity instance I guess? I need the claims I've put into my JWT token (see original post on how I add these claims. The JWT Authorization works fine btw.

          – DoubleVoid
          Nov 20 '18 at 9:46













          Then you have an odd setup. Typically your Identity server (which generates the JWT token) and your resource server are two distinct applications. In resource servers (WebAPIs only, no MVC) you usually use JWT for authorization and Cookie authorization for MVC. Did you really call the given method via Ajax (or postman or other addon) with the JWT bearer token included in the request?

          – Tseng
          Nov 20 '18 at 9:57





          Then you have an odd setup. Typically your Identity server (which generates the JWT token) and your resource server are two distinct applications. In resource servers (WebAPIs only, no MVC) you usually use JWT for authorization and Cookie authorization for MVC. Did you really call the given method via Ajax (or postman or other addon) with the JWT bearer token included in the request?

          – Tseng
          Nov 20 '18 at 9:57













          Yes, I use Postman. Using no token gives me an unauthorized error code. In my setup there is just one server. I edited my post, added a "possible" solution. This way I can read the claims from the jwt. At the moment my Identity User has no claims set. I don't want to hit the database. But I guess I would have to add Identity Claims and sync them with my JWT and update the IP Adress for the ip claim?!

          – DoubleVoid
          Nov 20 '18 at 10:08





          Yes, I use Postman. Using no token gives me an unauthorized error code. In my setup there is just one server. I edited my post, added a "possible" solution. This way I can read the claims from the jwt. At the moment my Identity User has no claims set. I don't want to hit the database. But I guess I would have to add Identity Claims and sync them with my JWT and update the IP Adress for the ip claim?!

          – DoubleVoid
          Nov 20 '18 at 10:08













          I think something wrong with your (default) authentication scheme. The authentication scheme tells the system whose claim to use (in case you have more than one authentication in use). If you set up Cookie authentication scheme as default it will always use its claims, not the one from JWT. Either you set JWT auth schema as default, and annotate Cookie/Identity where needed [Authorize(AuthenticationSchemes = "CookieAuthenticationDefaults.AuthenticationScheme")].

          – Tseng
          Nov 20 '18 at 10:18





          I think something wrong with your (default) authentication scheme. The authentication scheme tells the system whose claim to use (in case you have more than one authentication in use). If you set up Cookie authentication scheme as default it will always use its claims, not the one from JWT. Either you set JWT auth schema as default, and annotate Cookie/Identity where needed [Authorize(AuthenticationSchemes = "CookieAuthenticationDefaults.AuthenticationScheme")].

          – Tseng
          Nov 20 '18 at 10:18




          1




          1





          Yea, sorry. Missed it on my part. Yes, you need to call context.Succeed(requirement); if you want it evaluate as success. But only call .Fail() if you want guarantee it to fail (other authorization handlers wont be evaluated for this requirement). By not calling .Fail() you allow next handler to succeed. See Why would I want multiple handlers for a requirement?

          – Tseng
          Nov 20 '18 at 16:16





          Yea, sorry. Missed it on my part. Yes, you need to call context.Succeed(requirement); if you want it evaluate as success. But only call .Fail() if you want guarantee it to fail (other authorization handlers wont be evaluated for this requirement). By not calling .Fail() you allow next handler to succeed. See Why would I want multiple handlers for a requirement?

          – Tseng
          Nov 20 '18 at 16:16




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53373832%2fcheck-ip-with-jwt-authorization-in-asp-net-core-web-api%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          這個網誌中的熱門文章

          Tangent Lines Diagram Along Smooth Curve

          Yusuf al-Mu'taman ibn Hud

          Zucchini