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.
Related
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.
My ASP.NET MVC 4 application is protected by SSO (OAM) with an ISAPI filter running on IIS. When a request to my application is received, it is intercepted by ISAPI filter and redirected to SSO. User has to login at SSO and after that he is returned to my application.
The username of authenticated user (via SSO) is shared with my application in HTTP Request Headers.
Request.Headers["username"]
What I am trying to achieve is- after SSO authentication, setting FormsAuthentication within my application for username = Request.Headers["username"]. This way SSO remains transparent to my application and Identity of user is available in HttpContext object, plus, I (developer) could effectively utlize Authorize attribute for specific roles.
To achieve this- I hookup into Session_Start(), read Request.Headers["username"], Set FormsAuthentication cookie. And I get this SSO user Forms-Authenticated for my application.
But my problem is when I logout (FormsAuthentication.Signout), I redirect it to another page inside the application, which triggers a new Session (I can see Session_Start triggering when this happens)
Am I doing the right thing- FormsAuthentication after SSO? And if not, why not and then how do I make my application aware of SSO authenticated user?
It's entirely reasonable to use FormsAuthentication cookies to track the logged in user in your application after they have been authenticated using a Single-Sign-On provider. You don't show it but I'm hoping that you are also getting some ticket that you can use to verify the signed in user out-of-band with the SSO provider and not simply trusting the username header.
What you may be seeing, however, is that the user is not signed out from the SSO provider when you sign them out of your application. Because of that, as long as they have a valid cookie for the SSO provider, they will remain signed in, i.e., the user will get automatically bounced back to your application from the SSO provider without any required authentication.
That's unfortunate, but normal.
If you truly want the user to be signed out, you'll need to make use of the centralized logout functionality. I haven't worked with OAM, but it appears that it does support this: http://docs.oracle.com/cd/E21764_01/doc.1111/e15478/logout.htm
I had to explicitly kill the session inside Session_Start if requested URL is logout URL. And then with next request (like from logout to login page again), it generates a new session and runs smoothly.
protected void Session_Start()
{
if (!Request.IsAuthenticated && !IsSignoutURL)
AcceptSessionRequest(); //process local authentication
else if (IsSignoutURL)
RejectSessionRequest(); //kill the sessions
}
For background on how SSO passes authenticated user's identity to my application, read my comment to tvanfosson's post.
The post remains opened for a better idea.
I understand that when a user logs in to MVC webapp (when runtime executes FormsAuthentication.SignIn(..)), that user receiver a cookie and continues to work with the site with that cookie.
However the user can login again, from incognito window or another PC and get access to the site from both places simultaneously. I would like to prevent him from doing that.
I believe that the solution of this issue lies somewhere close, however nethier googling nor digging into MVC Forms Authentication classes provided me nothing I could work with.
So how do I forcibly sign off the last user login info (I believe it is a cookie stored inside a web server, I might be wrong) when that user successefully attempts to login in somewhere new place?
You need to implement
Application_AuthenticateRequest
in your global.asax file an validate that the user identity is still correct. e.g. you need to keep track of all session related to the user and which clients he used. You can then respond with a cookie reset in the mentioned method, if you want to sign out the user.
The only way you can do that, is by storing the user login in information in a table. So when the user tries to log in again, you can verify weather he is logged in some where else by quering the table. Once the user logs out, delete rows from the table.
Remember you would not be able to do anything with the help of cookies. Cookies will just contain form authentication ticket, which would be used by authentication module to verify whether the coming request is authenticated or not. And since the calls are stateless you can not decided anything just by looking at the cookie
I have a login screen, and upon successful login i will display a welcome screen. But the problem is if i refresh the web page. i am taken back to the login screen. If i am successfully logged in, then if i refresh i should go to the Welcome page.
I did some research and found out that i should be using cookies to handle this. Is cookies the best approach or are there any other way i could solve this ?
Could someone please point me to a good tutorial that explains how to do this? or some sample code to start with?
Here is the MSDN on the FormsAuthenticationTicket class that is used for authorizing users to your application. This is the term that you want to ask about/Google for more information on user authentication.
The basic premise is that once you have authenticated a user, you issue an encrypted cookie that contains some basic information about that user. This cookie is what is used to prove the user is who they say they are, defines the login expiration times and allows you to authorize them to different resources in your application.
Words of Caution
With that said, if you are rolling your own authorization/login system, I highly encourage you to use the built in .NET membership providers. There are many caveats to web authorization and authentication and the likelyhood that you leave a security hole open using your own code is extremely high.
Here are some other approaches that don't require cookies:
if you can use authentication provided natively by browser (i.e. Windows if your case is intranet with Windows domain) than you can base your decision on headers other than cookie header (i.e. in case of Windows auth you can use "impersonate request as user" functionality) to see if user is "logged in" to your system.
you can also set information on local system in Local storage to say "this user is logged in" and than check on login page if some other page needs to be rendered. This is not secure approach, but it maybe ok (as you still need to have some way to secure all other pages).
I would like to implement a lightweight registration less system for my asp.net page and need some direction to go
Basically I am currently at the point where I need session elements based on the user's username. But, since authentification is done using an other system, I would simply like to create session per username based on the success or failure of that other authentification system.
So, if authentification is succesfull using the information entered in the login page, simply create a new user in the system or something using the username provided (without, if possible, saving the password used).
I got a vanilla login page at the moment and would like some direction as to how to proceed while using as much of the vanilla infrastructure as possible.
Thanks you all :)
What your talking about is claims-based authentication. You trust a third-party service to have authenticated the user and trust that the information that the service tells you about that user is correct.
See what options you have for the service to pass you those details. You can use full-on SAML-based claims and Windows Identity Foundation may take on pretty much all of the work for you. If the third-party application is acting as a proxy, you could have it inject a HTTP header with the user name in. Or you could have a form, but someone or something is going to have to enter the data and post that form (you can do it automatically from Javascript when the site is launched).
If you want to use a form, it could be a modified Forms-based logon screen that doesn't check the password, just creates the Forms Authentication cookie.
If you want to use a more 'bespoke' scheme, you could create a custom security principal implementing IPrincipal, you can transparently inject this into your application and have it behave just like it would if you were doing 'proper' authentication.
Either way, don't try to mess with the way that ASP.NET security operates, just concentrate on the best way to get the information to ASP.NET via the security principal.