When studying ASP.net membership provider I faced with such a question and could not find an answer.
It is clear that We have Database, where provider stores information like name/pwd etc. , but how does it find the right key for the current user? Is it transfered via HTTP headers and saved in users' cookie?
Basically, the forms authentication ticket is contained inside a cookie. The cookie is stored at clients side, and sent back to server with the page request for authentication .
If you use ASP.NET Universal Providers' Membership, I would like to suggest to use ASP.Net Login control; it works right out of the box with Membership provider without writing any code.
Related
I have 2 web applications, one is ASP.NET MVC 5 + WIF hosted in IIS, another is a web service based on WCF and self-hosted. Both of them are under same domain (so there are no security issues to change cookie format) and referring to the same STS (in same security realm), so theoretically if one user already authenticated, he should be able to access other entities within same security realm without authentication.
However, these 2 websites are using different session token format. For ASP.NET MVC 5 project, it uses WIF implemented standard security session token and serialized to cookie; for WCF web service, it uses its own token/cookie format.
Then we have a problem.
When user navigates from ASP.NET MVC website to WCF web service, because WCF web service cannot recognize WIF session token (FedAuth and FedAuth1), so it redirects user to STS and login again, that is not the biggest problem, the biggest problem is, after use logged in, and POST raw SAML2 token back to WCF web service, WCF web service creates its own format token and tries to set client cookie, it actually doesn't work, I guess maybe there are already FedAuth and FedAuth1 cookie in header so header cannot accommodate more tokens (4K limit?)? Having thought about this for a while, there are are several solutions come into my mind:
Unifying token format. I need to subclass SecurityTokenHandler (maybe also need to subclass CookieHandler), use the same token format that WCF service uses, so when jumps to WCF web service, it can recognize the session token. That needs to dig deep into FAM and SAM.
Force re-login. I can clear FedAuth and FedAuth1 cookies before navigates to WCF web service, it is acceptable that user needs to login again, this is a short term fix, but how can I capture this navigation away event and clear cookie? The only way I think I can do is before I change window.location.href, use jQuery.cookie to clear cookie, I am not sure if it is the correct way, this is my first question.
Adding a cookie translation layer between ASP.NET and WCF, use WIF session token in ASP.NET website, and when jumps to WCF web service, change the token format. But for this solution I don't know how to capture the jump action and how can I get raw SAML2 token? May be I can save it in WSFederationAuthenticationModule_SecurityTokenReceived event handler? But how to deal with multi tokens from multi users and multi sessions?
Are there other better suggestions?
It is a Plain ASP.NET application using SQL Membership Provider for authentication. While application runs good most of the time. We have recently seeing complains from users saying they are seeing other users account.
I am pretty sure & confirmed again I directly consume HttpContext.Current.User.Identity.Name in the code to get user information. So under heavy load I get different user name returned.
Has anyone faced similar issue ? Have possible cause ?
Application Runs in ASP.NET 4.0, Web Forms , No caching ,Not handled any cookies in code, no Javascripts that is sniffing cookies.
I see these two links taking about same but no answers posted.
http://bytes.com/topic/asp-net/answers/324385-serious-issue-httpcontext-current-user-identity-name
http://www.experts-exchange.com/Web_Development/Miscellaneous/Q_21105924.html
Forms Authentication shouldn't be related to Membership provider too much.
FormsAuthentication saves signed user information into .ASPXAUTH cookie. And when next request comes to server, it decrypts cookie value and set it back to HttpContext.Current.User.Identity.Name. It uses MachineKey for encryption\decription. Then it creates FormsIdentity object based on FormsAuthenticationTicket object that holds username. So, your userName is stored on client. And whole this process doesn't include usage of Membership provider.
Forms Authentication uses Membership only when you do login for user, and then based on logged in user FormsAuthentication creates a cookie with UserName.
About your problem, you need to check .ASPXAUTH cookie value for those requests who has invalid UserName. You can try to log cookie information for these bad requests, and then you can decrypt them to get userName info from request. Or if you can reproduce it locally you can disable Forms cookie encryption (protection element), and then check it's value for bad requests
Hi,
I need to determind how my site uses Cookies to inform the user in proper way.
The solutio is a ASP.NET MVC website using .NET Membership. Im storing data in sessions on server but nothing is saved manual to cookies on the client. I Supose however that the ASP.NET Membership is using cookies (for autologin) but im not sure witch data it really stores on the client?
Could you pleas explain or give me a link for this?
BestRegards
The forms authentication ticket (the cookie on the client) stores values such as the username and cookie expiration time along with some other boolean fields related to the remember me checkbox and sliding expiration. This is if you use cookie-based forms authentication which is the default and a typical choice. More information can be found at the following site:
Forms Authentication Explained
It is important to note that sessions and the forms authentication ticket (cookie) are not related in any way. You can have a session without being logged in and you can login and never touch the session object. This is an important difference.
EDIT
This cookie is not used for 'auto login'. After authentication, putting in a username and password, the cookie is created and is used for authorization - can you access these resources - throughout your site.
ASP.NET Membership enabled sites will have up to 3 cookies:
Session token
Authentication token
Roles cache (if enabled in
web.config)
To see them, open your site in the browser of your choice, login, and inspect the cookies. In IE its Tools -> Internet Options -> Settings (next to Browsing History) -> View Files
Im a newcommer in ASP.NET (Switched from Java/PHP) And tried to create a simple Login.
Now i get Stuck, are there any Sessions in ASP.NET to store if the User is logged in? Or how does the ASP.NET World store this information?
Greetings!
Yes! Read more on asp.net session. Generally we uses Form-authentication to authenticate and authorize the request in ASP.NET.
Articles/posts:
An Overview of Forms Authentication
Using Forms Authentication in ASP.NET
You can use session as well as cookie.
For cookies read this http://www.codeproject.com/KB/aspnet/Beginners_Cookies.aspx
For sessions assign like this
Session["adminid"]="value";
and retrieve value like this
string sessionval=Session["adminid"].toString();
I have an asp.net application in which I have used forms authentication.
Now, there is a need that user authentication is done outside of my application.
There will be an intro page which will do needed authentication.
Then, after authentication is successful user should be redirected to my app.
Of course, if user is not authenticated via that external page and tries to access my app directly, I need to redirect him back to this external log in page.
What's the best way to implement such a functionality? One way which I think is feasible is that I transfer some particular encrypted string in cookie from external login page and verify it in my application. So, based on that, I can see if user is authenticated via this external page or not.
Your own suggestion of validating the external site's cookie is how I would implement this functionality as well.
I would simply go with adding a Webservice in the first application that you in your stage can connect to a check if the user is logged in, the only problem with this is that you need to know which user whants access to your site and also to confirm that this is truly that user (So a user cant use other users who are logged in). This info could probably be sent via a cookie.
You probably should no be rolling your own single sign on solution in 2011. Rather, you should look at some emerging standards -- particularly OAuth and OpenID. Getting rolling with them is easy -- check out the OpenID website template on MSDN.
At the end we decided to use SAML 2.0 protocol.
External login page posts SAML complient XML digitally signed with certificate to other application. In this XML authenticated username is transferred. Application which receives this XML verifies digital signature with certificate's public key, and if validation is OK, reads username from XML, applies internal application authorization logic and at the end creates auth. cookie. We will probably add encryption so data protection would be complete.