Check IP with JWT Authorization in ASP.NET Core Web Api
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
add a comment |
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
add a comment |
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
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
edited Nov 20 '18 at 10:06
DoubleVoid
asked Nov 19 '18 at 11:38
DoubleVoidDoubleVoid
373629
373629
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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"))
})
Hey, thanks! I get the idea and theHandleRequirementAsync
method gets triggered. Butcontext.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 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
Nov 20 '18 at 16:16
|
show 7 more comments
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
});
}
});
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
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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"))
})
Hey, thanks! I get the idea and theHandleRequirementAsync
method gets triggered. Butcontext.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 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
Nov 20 '18 at 16:16
|
show 7 more comments
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"))
})
Hey, thanks! I get the idea and theHandleRequirementAsync
method gets triggered. Butcontext.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 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
Nov 20 '18 at 16:16
|
show 7 more comments
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"))
})
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"))
})
edited Nov 20 '18 at 16:20
answered Nov 19 '18 at 14:31
TsengTseng
34k594124
34k594124
Hey, thanks! I get the idea and theHandleRequirementAsync
method gets triggered. Butcontext.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 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
Nov 20 '18 at 16:16
|
show 7 more comments
Hey, thanks! I get the idea and theHandleRequirementAsync
method gets triggered. Butcontext.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 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
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
|
show 7 more comments
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.
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