I have a Symfony 4.4 application, using symfony/security-bundle. The application accepts SAML connections. When a SAML connection comes in for a user that doesn't exist yet, Symfony...
Stores some data from the SAML request in the session with Symfony\Component\HttpFoundation\Session\SessionInterface::set()
Redirects the user to a registration page, which renders an Angular app that makes several concurrent API calls to help populate the page.
When the user submits the registration form, Angular makes another API call, which registers the user with a combination of form data and data stored in the session with SessionInterface::get().
The problem: Often, one of the API requests from step 2 will have header Set-cookie: PHPSESSID=deleted. This tells the browser to delete the cookie, throwing away the key to the session. As a result, the API call from step 3 has no way of retrieving the information from the session.
I'm storing session data in Redis, using Symfony's Symfony\Component\HttpFoundation\Session\Storage\Handler\RedisSessionHandler. I have confirmed the session data is in Redis, even after the session cookie gets deleted.
Temporary solution: Adding a new firewall with security: false, covering just the endpoints in step 2, prevented the endpoints from deleting the session cookie. So it seems that the security component is to blame.
How can I save data in the session for an unauthenticated user, and ensure the session cookie isn't removed before I need to retrieve the session data?
I am wanting to create real RESTful APIs with ASP.Net. According to REST architecture. The application must be stateless. Meaning I can't use normal sessions. I found a document here describing how to use Redis as a session state provider. Since it would be external (as in not part of the server), would it be suitable for creating stateless APIs? How would I go about it. Would I just create a key to declare the user as authenticated and then maybe a key to reference the current user, or am I thinking wrong?
You could use Redis as a cache to hold various pieces of state about the user. The idea is that when the user logs in, you probably need to load a bunch of information about them from your database (name, address, etc...) at that point, you know the user will likely need to reuse some of that information, so you don't want to keep reloading it from the database each time. Instead you can cache it in Redis for a few minutes, so on the user's next request you can just pull the data very quickly from Redis instead of having to go back to your database.
For authentication, you could create a temporary token in the redis cache that you also throw back to the user as a cookie so that you can check for it's existence on subsequent requests instead of needing to run a bunch of time-consuming bcrypt hashes or some such for each subsequent authentication.
This all remains stateless because even if the cache is not available for whatever reason, the user's requests still contain all the state necessary to answer his or her requests. All that Redis is doing is allowing you to speed up your responses if it's available.
Like the Facebook application, you only enter your credentials when you open the application for the first time. After that, you're automatically signed in every time you open the app. How does one accomplish this?
There's a commom line in all auto-login implementations
Upon an initial login, a token is received and stored on the client side
Upon subsequent visits, if token is available on the client side, the server resolves the identity and logs in automatically
Now concrete implementation variations can be numerous. The token can be a session ID (encripted or not), OAuth token, custom token, username and password should be avoided. Storing token can be on within a browser cookie, browser local storage, can have a server counter-part. Security is the major concern. Generally about the topic you can read more here https://softwareengineering.stackexchange.com/questions/200511/how-to-securely-implement-auto-login
You have an interesting explanation of how does Stackoverflow do it https://meta.stackexchange.com/questions/64260/how-does-sos-new-auto-login-feature-work.
I have an asp.net Web Api 2 / Identity 2 application that requires a user to be authenticated. The authentication works but I notice that when I restart my local development machine and try to access a method that requires authentication then I get a failure.
As my application is unchanged from the asp.net sample then I think it uses cookies to store user data on the client. Where and how does the Server or IIS store information on which users have authenticated? Does it do this just the once or on every HTTP? Is there a difference between my using Token or cookie authentication in the way that the authentication and also authorization is checked on the server?
I think you are misunderstanding how authentication works with ASP.Net. As an example, let me show you some cookie details for a site of mine that uses Identity (note the token is actually in the cookie, the two are not mutually exclusive concepts):
Name __RequestVerificationToken
Value afeILhaIvRr56jXXXXXXXXXXX
Host site.azurewebsites.net
Path /
Expires At end of session
Note that the cookie, by default, expires at the end of your session. That means when you restart your development machine, your cookie is expired and your token is no longer valid.
In particular I have read that with token authentication then there is no need for continual re-authentication every time a request is made to the server
You need to understand that HTTP is a stateless protocol. Each request happens in a vacuum, and therefore you need to pass some data back to the server so that it can tell that the person who authenticated with Request A is really the initiator of Request B. Almost always, that piece of data is from a cookie. So, every request does indeed re-authenticate, and typically with a token in a cookie.
The only piece of data about your session that is stored on the client is the cookie (unless you are doing something atypical). The rest is on the server. How it is stored can vary:
Inproc: Easiest to setup, sessions are stored in process. So when your server or app pool is restarted, that data disappears
State Server Mode: Sessions are stored in process, but outside of the ASP.Net worker process, so the application can be restarted without losing session data
SQL Server: Unsurprisingly, this stores data in a database. Very resilient, but more work to setup. Also your best option if you are on a web farm.
ref: http://msdn.microsoft.com/en-us/library/vstudio/ms178586(v=vs.100).aspx
Expanding on the great answer by Chris, I would like to add that there are two possible models here. In forms authentication (which is the default membership type for asp.net) the cookie can either store authentication information and then it's called a ticket or the information can be stored in session, with the cookie being a simple identifier for "reconnecting" the authenticated session with the requesting client on each subsequent request.
This "reconnecting" happens in the Application_AuthenticateRequest method of the global.asax. If you are using the default forms authentication storage, i.e. an SQL DB created for you by the framework, the reconnection will be done automatically. If you are using a custom authentication store (like accessing active directory yourself or a custom users table structure) you can override the the method and reconnect the authenticated session using your own implementation. In any case, the authentication data is populated in the User.Identity object's different properties. From that point, if you use the [Authorize] attribute, the framework accesses the object to check if the user is indeed authenticated and authorized.
I any case, the authentication information is tied to both the cookie and the session. Assuming your session is InProc, like Chris said, when the session is lost (through timeout, app pool recycle or restart of the dev machine) the server-side of the session is lost and your authentication / session cookie is replaced by a new one on the next request.
EDIT: Ohh... and one more side comment. Make sure you distinguish between authentication and authorization. The client is not re-authenticated on each request. Authentication is the process of providing your credentials and being identified by the server. Authorization is, now that the server has verified who you are, on each request it checks if you are authorized to access the resource you are requesting.
The server doesn't store information about who's authenticated and who isn't. Depending on your authentication mechanism (forms, tokens?), typically, when a user logs in, the server will return some form of authentication token that the client should pass back to the server on each API call.
Without knowing more about your configuration, it's difficult to explain why when you restart your server you have to re-authenticate, it sounds like the authentication token generated by the server is invalidated on restart.
Where and how does the Server or IIS store information on which users have authenticated?
IIS does not store state based on cookie authentication. Everything is determined based on the request. Either a request has the correct encrypted information, or it doesn't. If you look at a default Forms authentication in ASP.NET, you will find a cookie called .ADUAUTH ... this cookie has all the information to authenticate the request. If the cookie is half expired, it will be reset, but that's all IIS does.
Does it do this just the once or on every HTTP?
Every HTTP request is unique, so yes, per HTTP request.
Is there a difference between my using Token or cookie authentication in the way that the authentication and also authorization is checked on the server?
It's always checked on the server: To find out more, check out: How ASP.NET Security Works: http://msdn.microsoft.com/en-us/library/ks310b8y.ASPX
I think my answer could be a little contradicting to all of the above.. But I think If I understand right..
IIS stores inside the memory space of the ASP.NET worker process, i.e the session data in the RAM.
The storing of authentication state depends on the authentication model you are using. For example: if you are using the Federated authentication, through ADFS, then when a user loads your web page he is required to sign in providing his credentials. The ADFS then sets the authentication token which is stored in the session data, the session id is stored as cookies in user's browser. The server has the mapping of Session Id to its session data.
Now the user is authenticated. The ADFS looks for authentication token to mark a user as authenticated.
When you restart the server, the session data is lost as the data is stored in RAM.
There are ways to handle this, there are 3 types of session storage:
1. InProc (Stored in memory space of ASP .NET Worker process - RAM)
2. State Server (Stored out side of ASP .NET worker process, like on cloud Azure storage)
3. SQL Server session storage (Stored in SQL server)
I think you are adopting 1, because of which you encounter the problem.
In cases 2 and 3, the session is not lost when you restart the server.
Several things --
Token based authentication is not really authentication. It is just issuing you a unique token (can be a guid, unique string, etc) and then associating it with something (like your IP address) and saving that association server side (in a database?). Now whenever you use that token, from the client app, the server checks the association already stored and serves or denies or request.
In many ways, it is very similar to using Cookies to maintain authentication. Only, token-auth was designed more for web services operation than for UIs.
In short: Out of the box, the membership provider will run it's authentication method and upon success, it will create an auth ticket/token/cookie that will be stored from the site. In addition to this, there is a session cookie that is stored with the site as well. When you make a page request, it'll pull these things and use them to determine whether or not you are already authenticated. If it finds the ticket and sees that it is still good, it'll allow access.
When you restart your local environment, the session and it's information is destroyed which is why you have to log in again.
There is an entire pipeline in the framework that makes all of this stuff happen (having to do with authentication, authorization, and identity) and there are number of ok articles on the interwebs explaining this, but imo, they're almost all incomplete or hard to follow. If you want a great soup-to-nuts explanation, PluralSight.com has some training videos that will deconstruct and explain the entire pipeline for you. Understanding the pipeline can help you implement your own custom authentication, and I highly recommend it.
We are building a set of web applications which all utilize their own unique role providers using sql server and utilizing Windows Identity Foundation to provide a Secure Token service to handle the membership using Active Directory. This solution also provides the benefit of single sign on. One oversight was only allowing users a single session. Tracking if the user already has an active session seems easy enough to implement, it’s what and how to deal with a user’s session if it’s determined they are already logged on elsewhere .
My question is what is the recommended approach for killing an existing user session if the user attempts to spawn an additional session? Would also like to advise the user that an existing session has been detected and by continuing, that existing session will be terminated. (This part also seems trivial…)
Example Scenario with 2 web apps and a STS Identity app:
User attempts to access application A:
STS Identity extension determines user is not already logged on, provides a claim and caches a user/session identifier.
User attempts to access application B on different computer. (they can access application B if using the same session)
STS Identity determines user has active session and denies logon.
There seem to be some other issuer to overcome, for example….
How to update the logged on user cache from the application A if the user is actively keeping their session alive.
How would you deal with the user not explicitly logging off, say by closing the browser or the session timing out.
Other problems???
Any guidance would be appreciated.
We have opted to handle concurrency at the application level, using a simple table that stores the users session id. If a new session for the application is created elsewhere, the existing session is terminated with the use being redirected back to the STS with a message (carried in the query string) the reason why they've been redirected back to the login page.