WebAPI how to disable another user from the admin
I have created a simple WebAPI in Visual Studio C# to act as my backend to Angular.
Users can register via the Angular frontend and passed to a controller in the WebAPI to register that user in the backend DB (MSSql). All fine.
I am using token authentication from Angular to my API and using claims and roles to verify the user is logged in and has access to the requested controller.
How, as an Admin, can I disable another user so they are instantly locked out?
An example would be: A rogue user starts abusing the Angular application and I need to lock them down instantly and not to wait until their token expires and they are required to login again.
I could do a check in each and every controller to lookup the user in the DB and check their status and if I have set their status to "locked-out" then return say a 403 forbidden status from the controller but this seems a lot to lookup the user for each DB request they make.
Is there a "dot-net" way of doing it? I would love to be able, as the admin, to instantiate the said user, change their claim value for "status" to "locked-out" and I simply check their claim when making api requests but I can't see a way of changing another users claims.
Any ideas?
Thank you.
authentication asp.net-web-api oauth
asked Nov 25 '18 at 11:51
RowieRowie
184
add a comment |
I have created a simple WebAPI in Visual Studio C# to act as my backend to Angular.
Users can register via the Angular frontend and passed to a controller in the WebAPI to register that user in the backend DB (MSSql). All fine.
I am using token authentication from Angular to my API and using claims and roles to verify the user is logged in and has access to the requested controller.
How, as an Admin, can I disable another user so they are instantly locked out?
An example would be: A rogue user starts abusing the Angular application and I need to lock them down instantly and not to wait until their token expires and they are required to login again.
I could do a check in each and every controller to lookup the user in the DB and check their status and if I have set their status to "locked-out" then return say a 403 forbidden status from the controller but this seems a lot to lookup the user for each DB request they make.
Is there a "dot-net" way of doing it? I would love to be able, as the admin, to instantiate the said user, change their claim value for "status" to "locked-out" and I simply check their claim when making api requests but I can't see a way of changing another users claims.
Any ideas?
Thank you.
authentication asp.net-web-api oauth
asked Nov 25 '18 at 11:51
RowieRowie
184
1
You don't have to implement this in each and every controller. Check out "web.api authorization filter"
– Ivaylo Stoev
Nov 25 '18 at 12:13
In addition to the filter suggested by @IvayloStoev you can create a .net delegating handler and hook it up early in your pipeline review all requests. msdn.microsoft.com/query/…
– No Refunds No Returns
Nov 26 '18 at 5:21
add a comment |
I have created a simple WebAPI in Visual Studio C# to act as my backend to Angular.
Users can register via the Angular frontend and passed to a controller in the WebAPI to register that user in the backend DB (MSSql). All fine.
I am using token authentication from Angular to my API and using claims and roles to verify the user is logged in and has access to the requested controller.
How, as an Admin, can I disable another user so they are instantly locked out?
An example would be: A rogue user starts abusing the Angular application and I need to lock them down instantly and not to wait until their token expires and they are required to login again.
I could do a check in each and every controller to lookup the user in the DB and check their status and if I have set their status to "locked-out" then return say a 403 forbidden status from the controller but this seems a lot to lookup the user for each DB request they make.
Is there a "dot-net" way of doing it? I would love to be able, as the admin, to instantiate the said user, change their claim value for "status" to "locked-out" and I simply check their claim when making api requests but I can't see a way of changing another users claims.
Any ideas?
Thank you.
authentication asp.net-web-api oauth
asked Nov 25 '18 at 11:51
RowieRowie
184
I have created a simple WebAPI in Visual Studio C# to act as my backend to Angular.
Users can register via the Angular frontend and passed to a controller in the WebAPI to register that user in the backend DB (MSSql). All fine.
I am using token authentication from Angular to my API and using claims and roles to verify the user is logged in and has access to the requested controller.
How, as an Admin, can I disable another user so they are instantly locked out?
An example would be: A rogue user starts abusing the Angular application and I need to lock them down instantly and not to wait until their token expires and they are required to login again.
I could do a check in each and every controller to lookup the user in the DB and check their status and if I have set their status to "locked-out" then return say a 403 forbidden status from the controller but this seems a lot to lookup the user for each DB request they make.
Is there a "dot-net" way of doing it? I would love to be able, as the admin, to instantiate the said user, change their claim value for "status" to "locked-out" and I simply check their claim when making api requests but I can't see a way of changing another users claims.
Any ideas?
Thank you.
authentication asp.net-web-api oauth
authentication asp.net-web-api oauth
asked Nov 25 '18 at 11:51
RowieRowie
184
asked Nov 25 '18 at 11:51
RowieRowie
184
asked Nov 25 '18 at 11:51
RowieRowie
184
asked Nov 25 '18 at 11:51
RowieRowie
184
asked Nov 25 '18 at 11:51
RowieRowie
184
184
1
You don't have to implement this in each and every controller. Check out "web.api authorization filter"
– Ivaylo Stoev
Nov 25 '18 at 12:13
In addition to the filter suggested by @IvayloStoev you can create a .net delegating handler and hook it up early in your pipeline review all requests. msdn.microsoft.com/query/…
– No Refunds No Returns
Nov 26 '18 at 5:21
add a comment |
1
You don't have to implement this in each and every controller. Check out "web.api authorization filter"
– Ivaylo Stoev
Nov 25 '18 at 12:13
In addition to the filter suggested by @IvayloStoev you can create a .net delegating handler and hook it up early in your pipeline review all requests. msdn.microsoft.com/query/…
– No Refunds No Returns
Nov 26 '18 at 5:21
1
1
You don't have to implement this in each and every controller. Check out "web.api authorization filter"
– Ivaylo Stoev
Nov 25 '18 at 12:13
You don't have to implement this in each and every controller. Check out "web.api authorization filter"
– Ivaylo Stoev
Nov 25 '18 at 12:13
In addition to the filter suggested by @IvayloStoev you can create a .net delegating handler and hook it up early in your pipeline review all requests. msdn.microsoft.com/query/…
– No Refunds No Returns
Nov 26 '18 at 5:21
In addition to the filter suggested by @IvayloStoev you can create a .net delegating handler and hook it up early in your pipeline review all requests. msdn.microsoft.com/query/…
– No Refunds No Returns
Nov 26 '18 at 5:21
add a comment |
1 Answer
1
active
oldest
votes
Expanding on my comment above, we have a handler in our pipeline that handles Authorization. We do look at that Authorization header and parse it but all of the controllers rely on the already-parsed value that we hang in the Properties collection. That way all AuthZ/AuthN occurs in this handler and whatever the handler sets in the Properties collection is what all of the application sees.
In your case the handler would need to be able to check whatever throttle or lockout you are using and replace the actual claims received with your "user is locked out" claims instead.
answered Nov 26 '18 at 5:24
No Refunds No ReturnsNo Refunds No Returns
5,43441936
add a comment |
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%2f53467134%2fwebapi-how-to-disable-another-user-from-the-admin%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
Expanding on my comment above, we have a handler in our pipeline that handles Authorization. We do look at that Authorization header and parse it but all of the controllers rely on the already-parsed value that we hang in the Properties collection. That way all AuthZ/AuthN occurs in this handler and whatever the handler sets in the Properties collection is what all of the application sees.
In your case the handler would need to be able to check whatever throttle or lockout you are using and replace the actual claims received with your "user is locked out" claims instead.
answered Nov 26 '18 at 5:24
No Refunds No ReturnsNo Refunds No Returns
5,43441936
add a comment |
Expanding on my comment above, we have a handler in our pipeline that handles Authorization. We do look at that Authorization header and parse it but all of the controllers rely on the already-parsed value that we hang in the Properties collection. That way all AuthZ/AuthN occurs in this handler and whatever the handler sets in the Properties collection is what all of the application sees.
In your case the handler would need to be able to check whatever throttle or lockout you are using and replace the actual claims received with your "user is locked out" claims instead.
answered Nov 26 '18 at 5:24
No Refunds No ReturnsNo Refunds No Returns
5,43441936
add a comment |
Expanding on my comment above, we have a handler in our pipeline that handles Authorization. We do look at that Authorization header and parse it but all of the controllers rely on the already-parsed value that we hang in the Properties collection. That way all AuthZ/AuthN occurs in this handler and whatever the handler sets in the Properties collection is what all of the application sees.
In your case the handler would need to be able to check whatever throttle or lockout you are using and replace the actual claims received with your "user is locked out" claims instead.
answered Nov 26 '18 at 5:24
No Refunds No ReturnsNo Refunds No Returns
5,43441936
Expanding on my comment above, we have a handler in our pipeline that handles Authorization. We do look at that Authorization header and parse it but all of the controllers rely on the already-parsed value that we hang in the Properties collection. That way all AuthZ/AuthN occurs in this handler and whatever the handler sets in the Properties collection is what all of the application sees.
In your case the handler would need to be able to check whatever throttle or lockout you are using and replace the actual claims received with your "user is locked out" claims instead.
answered Nov 26 '18 at 5:24
No Refunds No ReturnsNo Refunds No Returns
5,43441936
edited Dec 16 '18 at 23:31
answered Nov 26 '18 at 5:24
No Refunds No ReturnsNo Refunds No Returns
5,43441936
answered Nov 26 '18 at 5:24
No Refunds No ReturnsNo Refunds No Returns
5,43441936
answered Nov 26 '18 at 5:24
No Refunds No ReturnsNo Refunds No Returns
5,43441936
5,43441936
add a comment |
add a comment |
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%2f53467134%2fwebapi-how-to-disable-another-user-from-the-admin%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
1
You don't have to implement this in each and every controller. Check out "web.api authorization filter"
– Ivaylo Stoev
Nov 25 '18 at 12:13
In addition to the filter suggested by @IvayloStoev you can create a .net delegating handler and hook it up early in your pipeline review all requests. msdn.microsoft.com/query/…
– No Refunds No Returns
Nov 26 '18 at 5:21