I have setup an IdentityServer4 application with .net core 1.1 version. I have a requirement where an Admin user can deactivate users in the system. After deactivating, those users should not be able to use the system. They should be forced SignOut from all the browsers and devices.
Note: Application is configured to use oAuth and OpenId.
What is the best way to handle this scenario?
The best option for your requirements is to switch to reference tokens with server-side validation, as described in the docs. It is not the basic OpenId Connect protocol, but it provides server-side control over token validity.
OpenId Asp.net identity
If you are using Asp.net identity as you have tagged. You can go into the database and change the users SecurityStamp on the AspNetUsers. This will cause the user to be logged out of the system the next time it is validated. By default i believe its validated every thirty minutes but this is something you can configure yourself.
To lock them out you can set the LockoutEnd to sometime in the distant future. Locked out users will not be able to login until the time has expired. This column is also on the on the AspNetUsers table.
Oauth2
Remember locking out a user is probably not going to effect any access tokens or refresh tokens that may have been granted to clients the user has granted access to. So as for Oauth things will be a little more complicated.
Access tokens granted to clients for this user will continue to work until they have expired unless you are testing that the user has been locked out even when your api is validating the access token. So if you want to do this then your going to have to add that into the validation of your application / API.
Refresh tokens I believe are stored in the PersistedGrants table in the identity server. This is not something i have dug into much its just a hint. Old refresh tokens will probably still work but i would think you could add something into the identity server to ensure that this user has not been locked out before returning an access token.
Related
We have built some Asp.Net Core web API, with the authentication/authorization built on top of Asp.Net Core identy, with some JWT token exchange for our angular frontend. Basically, the users can login with username+password, this provide them a JWT with a short validity that the frontend regularly refresh. If the token is not valid anymore, the user will have to login again.
This part works great.
Now, we have to add another concept, a bit like on Azure Devop, we need to add "agent", those are not users, they will just need to be authenticated, in a slightly different way:
They will run on unnattended(locked) computers
They will be configured once and then run forever
Each agent should NOT be considered as a user. They should not be stored as such(or at least provide a way to distinguish them)
Those agent should only have some kind of token/private key to authenticate themself, that doesn't expire. This method of authentication should not be allowed to other users
So based on this:
Is this something that already exists, or have this pattern a name?
Is there a way to achieve this through Asp.Net Core identity or am I better off ?
Any link or lead on how to implement in parallel of an existing auth would be highly appreciated.
We currently have an Identity server 4 application. Using entity framework core and asp .net identity.
We have a group of supporters who need to be able to access our users accounts in order to help them with issues over the phone. Our users are not able to figure out how to use team viewer. As most of them are mobile and will only have a cellphone at the time.
I know all the security ramifications of allowing other people to sign into your account however there is really no way around this. Our customers have accepted that our supporters can connect to their account when they request it. We trust that our supporters only do this when its requested.
Current solution and its issues
The current hack creates an api endpoint which only our supporters can use as it has been locked down so that only those with supporter permission can use it. They send the users email and we hack create them an access token which is then used by the application (Web version) to act like its the user who is having issues.
This solution was created by my predecessor basically by taking the supporters access token and replacing all of the claims with this supporters id to the users id and returning it to the application. I hate this solution on a number of levels and its very unstable every time i look at this method it breaks. currently its not working because audience clams are incorrect for some reason.
What i want to do
I would really like to do this in a less hack way. So is there a way to sign in a user to the application without it actually being them thats doing the signing in and return an access token?
I have tried doing
await _signInManager.SignInAsync(user, false, null);
But i cant seam to figure out how to get that to return an access token.
What i would really like to do is have the ability for supporters to login to any ones account but do it securely somehow.
The problem with the user account is that it's not bound to one application. So by allowing others to login using the account, you give them also access to other applications. As a workaround you could use 'public' accounts, like engineer_01, engineer_02, etc.
But, this may not be necessary at all. What you really want IMO is to impersonate the user, instead of 'hacking' the account.
One way to do this, is to extend IdentityServer with a custom grant type using extension grants.
How this could work:
A signed-in user, who is allowed to impersonate users for the particular client/resource, requests an access token at the new impersonation endpoint.
The user sends the sub from the user to impersonate to the endpoint, where the user and (combination of ) sub are verified.
When access is granted a new (short-lived) access token is returned which can be used to impersonate the user, without having to know the credentials of the user.
The access token should contain information of the endpoint so it can be determined whether the user is impersonated.
We implemented an impersonation feature that is integrated into the browser-based sign in flow. If a user with permission chooses to sign in as another user then we add additional claims to their IDS4 authentication cookie which then supports issuing extra claims in the resulting token that reflect that it's an impersonation session and who the original actor is.
Navigate to client application
Sign in using whatever credentials
Check if any impersonation permissions exist (how these are defined is entirely up to you)
Prompt for impersonation account selection (or just continue as self)
Sign in as the selected account (with record of original actor)
Redirect to authorize endpoint
Issue tokens and redirect back to client application
I need to implement the secure system, in MVC which will recognize that user logged in is followed proper authentication steps.
Can i know which authentication scheme will be better of the following.
Form authentication will be using cookie, which in turn get the user details based on the cookie. In form authentication we have advantage that with the cookie available in browser, system will auto login from that.
Storing the logged in user information in session and checking that user logged in. But if the session expires we need to logout the system. Suppose the user need to work till entire day, some time user can leave without interaction for 20 mins, system automatically sign-out the user.
Storing the logged user details in sql server session which will be having performance issues.
So i need to implement secure and performance oriented scheme which will be maintain user information securely and also have advantages like auto login with cookie.
Primary goal is to maintain which user logged in and he should be authenticated through the system which he is accessing and safely logout the system
The 1-option is not safe because you can pick up the cookie data and insert it into another browser to impersonate the user.
I use the 2-option for example with my website because it has a secure structure. If the browser is closed and opened again the session is destroyed but you can always use it as long as the same browser is open to access your profile without having to log in.
The 3-option has too much editing and processing effort so I wouldn't recommend it.
Maintaining the user would simply fall when you maintain the user data
in the database via an admin panel which you create. So you have the
possibility to install an ACL system later.
I, have created a JWT token with claim as permission Read or Write or Delete as shown in the figure below.
Now, both the Admin/Normal User log on to the system. Admin and normal user get the token and store in the local storage.
For the first time the normal user won't get Read/Write/Create/Delete UI controls. The token expire time is 2 min.
Now the admin change the permission for the normal user in the database as below
.
Since, the token is not expire for the normal user. Still he can't read and write. The logic works if token expire then user login again then he can view the read/write UI control
How can I, achieve this simultaneously with permission changes by admin.
Some of the reference link
https://jonhilton.net/identify-users-permissions-with-jwts-and-asp-net-core-webapi/
https://www.jerriepelser.com/blog/using-roles-with-the-jwt-middleware/
As this logic is handling in the server you need to inform the UI of a change in permissions for that user. In this situation something like SignalR which is really easy to get working with .NET Core would work perfectly. This can alert the UI of a change in the permissions and go and get the user another JWT token passed through websockets events, which unlocks the UI logic. This then can be re-saved in local storage for that user (obviously if there currently using the platform)
https://learn.microsoft.com/en-us/aspnet/core/signalr/dotnet-client?view=aspnetcore-2.1
I do not think there a prebuilt way in JWT to do what you are trying to do, JWT creates the tokens for authenticated users. It is up to you to expiry and create new valid tokens with valid permissions.
I'm writing a tutorial of using IMAP XOAUTH2 authentication in .NET (the standard MVC5 web app which is created by the MVC5 wizard).
I now have all parts except access_token from which I'll create XOAUTH2 IMAP key (the app authenticates, token seems to get refreshed if required, and I know how to build XOAUTH2 IMAP key and do IMAP login when access_token is available). I just need that token.
Although I have some ideas how this can be done I need to make sure I'm not doing anything stupid. For instance, I think I can use something like context.Identity.AddClaim in ConfigureAuth to put the access_token to our identity and then get it from there when doing IMAP login (on another page) but not sure if this info isn't already available.
Maybe, I can have access to that access_token in any place in the code without the need to manually put it in some object (which would be redundant and look silly for a reader experienced in OWIN and MVC5)? I develop .net components for SMTP/IMAP, I'm not a MVC5 expert, just need to write a simple example for using my IMAP lib with it.
Well, looks like saving access/refresh token details in ASP.NET Identity database makes sense anyway (despite the fact is's stored in encrypted cookies). This lets the access token data be accessible even when the browser is not available. For instance, if someone registers in a web app with their Google and Microsoft account and then another app (e.g. Windows service) consumes the access token initially retrieved by the web app to access the user's account (to check for new e-mails or whatever).
Also, it's possible to make sure both versions of access token details (in ASP.NET Identity database and cookies) stay in sync. This is useful if the access token gets updated with a refresh token (as access tokens need to be updated every hour). The standard ASP.NET MVC5 app cannot refresh access access tokens so you need to refresh them by your own code. I extended ASP.NET MVC5 template with refresh tokens, saving access/refresh tokens in ASP.NET Identity database and updating access tokens in cookies to make sure that access tokens in both locations match.
If anyone interested, you can grab some code and explanations at:
http://www.afterlogic.com/mailbee-net/docs/OAuth2RegularAccountsWebApps.html#SyncingTokens