Mixing
Check IP with JWT Authorization in ASP.NET Core Web Api
up vote
1
down vote
favorite
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
asked Nov 19 at 11:38
DoubleVoid
363628
add a comment |
up vote
1
down vote
favorite
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
asked Nov 19 at 11:38
DoubleVoid
363628
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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
asked Nov 19 at 11:38
DoubleVoid
363628
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
c# asp.net-core jwt asp.net-core-webapi
asked Nov 19 at 11:38
DoubleVoid
363628
asked Nov 19 at 11:38
DoubleVoid
363628
edited 2 days ago
asked Nov 19 at 11:38
DoubleVoid
363628
asked Nov 19 at 11:38
DoubleVoid
363628
asked Nov 19 at 11:38
DoubleVoid
363628
363628
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
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"))
})
answered Nov 19 at 14:31
Tseng
32k584116
Hey, thanks! I get the idea and theHandleRequirementAsyncmethod gets triggered. Butcontext.User.FindFirstgives 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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
1
Yea, sorry. Missed it on my part. Yes, you need to callcontext.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
yesterday
|
show 7 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
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"))
})
answered Nov 19 at 14:31
Tseng
32k584116
Hey, thanks! I get the idea and theHandleRequirementAsyncmethod gets triggered. Butcontext.User.FindFirstgives 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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
1
Yea, sorry. Missed it on my part. Yes, you need to callcontext.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
yesterday
|
show 7 more comments
up vote
2
down vote
accepted
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"))
})
answered Nov 19 at 14:31
Tseng
32k584116
Hey, thanks! I get the idea and theHandleRequirementAsyncmethod gets triggered. Butcontext.User.FindFirstgives 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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
1
Yea, sorry. Missed it on my part. Yes, you need to callcontext.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
yesterday
|
show 7 more comments
up vote
2
down vote
accepted
up vote
2
down vote
accepted
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"))
})
answered Nov 19 at 14:31
Tseng
32k584116
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"))
})
answered Nov 19 at 14:31
Tseng
32k584116
edited yesterday
answered Nov 19 at 14:31
Tseng
32k584116
answered Nov 19 at 14:31
Tseng
32k584116
answered Nov 19 at 14:31
Tseng
32k584116
32k584116
Hey, thanks! I get the idea and theHandleRequirementAsyncmethod gets triggered. Butcontext.User.FindFirstgives 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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
1
Yea, sorry. Missed it on my part. Yes, you need to callcontext.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
yesterday
|
show 7 more comments
Hey, thanks! I get the idea and theHandleRequirementAsyncmethod gets triggered. Butcontext.User.FindFirstgives 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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
1
Yea, sorry. Missed it on my part. Yes, you need to callcontext.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
yesterday
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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
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
yesterday
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
yesterday
|
show 7 more comments
draft saved
draft discarded
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
