I'm developping a webapp linked to a CAS server with phpCAS. Up to now everything was going well, I was able to access my app after the CAS authentication. I'm now supposed to implement a logout feature : when someone logs out of the CAS server, it sends logout request to all apps opened for that session.
The problem is my app doesn't seem to receive that request. I contacted the adminstrator who told me that he can see the request leaving the server. He then asked me to confirm him that my server received that request.
And here is the problem : I have no idea how to see if the server received the logout request (a json file...apparently a POST Method is used to send the data to the address of my app...as you see, I have no idea what I'm talking about.). I've been searching for days now and I'm totally in the dark. I tried to use tcpdump. I see a TCP F Flag when I logout of the CAS server so it seemed first like a good thing. But I have no idea how to see if my server has received a logout request.
Hoping that someone can help me...
Thanking you in advance.
And here is the problem : I have no idea how to see if the server received the logout request
You need to design some kind of filter/interceptor that sits in front of your application and intercepts all requests. This filter should examine the request body to see if the request is indeed a logout request. If it is, parse and consume the request body and begin to logout and remove the application session accordingly.
...with a little bit of searching and effort, it looks like phpCAS can handle logout requests on its own:
https://github.com/apereo/phpCAS/blob/master/docs/examples/example_logout.php
apparently a POST Method is used to send the data to the address of my app
Not "apparently"; rather, exactly. According to the docs:
The CAS Server MAY support Single Logout (SLO). SLO means that the user gets logged out not only from the CAS Server, but also from all visited CAS client applications. If SLO is supported by the CAS Server, the CAS Server MUST send a HTTP POST request containing a logout XML document (see Appendix C) to all service URLs provided to CAS during this CAS session whenever a Ticket Granting Ticket is explicitly expired by the user (e.g. during logout). CAS Clients that do not support the SLO POST requests MUST ignore these requests. SLO requests MAY also be initiated by the CAS Server upon TGT idle timeout.
And then here is the actual payload.
I have an issue with Worklight 6.1. I will describe the scenario below:
User logs in the app and a new session is created for him. Then he stays inactive for some time until the session times out. When clicking on a button, an HTTP request is performed towards an HTTP adapter. However the Worklight server (Liberty) sees that there is no active session for this user and returns the appropriate response that the user is logged out and the user is redirected to the login page. This is correct up to here.
When the user logs in again and is redirected to the landing page, the previous request seems to have been cached and is performed resulting in an error as the necessary information is not yet available. How can I prevent this request from occruring when the user re logs in?
Thank you.
it's not possible to prevent the original request from re-sending after authentication.
The logic of the authentication and the logic of the application are separated and the result of a successful login will be the invocation of the original failed invocation.
What you can do is add to the adapter procedure implementation the logic that makes sure all the information is available, and if not - send an empty response to the client and in the client do whatever you want to do when the data is missing.
This should be done for all the procedures that rely on the session state.
How can I sign in with a different account per tab in asp.net mvc 5 and Identity?
Is there a configuration that doesn't use cookies?
This is my configuration code:
' Enable the application to use a cookie to store information for the signed in user
app.UseCookieAuthentication(New CookieAuthenticationOptions() With {.AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, .LoginPath = New PathString("/Account/Login") _
})
' Use a cookie to temporarily store information about a user logging in with a third party login provider
app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie)
This is not possible. The web is stateless: each request is a unique snowflake, unaffected by any other request made before or after. However, since logically some sort of state needs to exist for things like authentication, sessions were created to basically fake a sense of state.
To work, sessions have a server-side and client-side component. On the server, some persistence layer is employed to store user-related data tied to a token that uniquely identifies the particular session. On the client, a cookie is set with that token. When the client makes another request, all the cookies that belong to the particular domain in play are sent along with the request back to the server, which includes the cookie with the session token if one exists. Once the server sees this cookie in the request, it uses the token to look up the session from the persistence layer and restore the state the user had during the previous request.
The point is that this process is dumb. The client blindly sends any cookies the server sets back to the server with each request. And, if the server gets a cookie with a session token it recognizes, it blindly restores the state. There's no consideration for how many tabs are in play or even what the content of the cookie is (the client doesn't know and doesn't care that the cookie is being used to manage a session, authentication, etc.).
Long and short, there's nothing you can do to force a session per tab or window. On the client-side, you can open a different browser (which would not have the cookie holding the session token) or use something like Chrome's incognito mode (which creates a sandboxed browsing experience without any previously set cookies). However, those are choices the user makes, not the website.
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.
I am running ASP.NET MVC 4.5 application on server2012 using SignalR with settings enabling websockets.
On the page there is Log In / Log Out button, and I have to maintain active connections on server.
When server used for transport serverSentEvents everything works fine and when user changed authentication I got callback to
$.connection.hub.error(function (error) {
// stop current signalR connection and start new one
createNewConnection();
});
but when I set up server for websockets, it stopped to call error function. I found in fora that common solution would be to ping server periodically and update cookies, but when I ping server using signalR - websockets, server does not recognize that user identity has changed.
Basically when I start connection with user logged already in and then click on log out, server will maintain websocket connection unchanged, with the same user identity:
Context.User.Identity.Name
will be the same after user logged out.
I know that user identity cannot change during active signalR connection, but I would need to check if cookies didn't change, as it can change from another opened tab or window.
So what you're seeing is 100% expected. With all transports EXCEPT WebSockets they all have intermittent communication.
Ex: SSE - There's 1 connection that's established and never broken to receive information and there's AJAX requests that are triggered whenever you attempt to send data from the client to the server, the AJAX requests being the intermittent requests.
Now, on each request to the server SignalR validates the user identity. Sooo for every client -> server send in SSE the user identity is validated. However, in WebSockets there's only ever 1 request active (to instantiate the connection) and sends and receives flow bidirectionally over the connection.
Therefore, since WebSockets only ever has 1 request it never knows about identity changes.
On the other hand, if you are using SignalR 2.0.0+ your connection will learn of an invalid user identity within a 5 minute time span (SignalR sends an ajax request every 5 mins to the server).
Hope this information helps!