I have a CAS-Server and a Client configured via Spring-Security. Single Sign On and Single Logout are working fine so far.
I'm still facing an issue with session timeout. As I understand the ticket expiration policy is not affected by idleness of the secured CAS client side session. So a client must actively revalidate a ticket to see if it has expired and is not being posted the expiration event by the CAS server as it is the case when a single logout is performed.
To force my spring secured client to regularly check for the expiration of the ticket I might set the session timeout to a low value like a minute or so. But that has the drawback of all my session data to be removed. Not very user friendly.
Is there a way to tell spring-security to regularly check if a ticket is still valid without destroying the user session first?
I would be pretty confident on the Javascript solution as it's just a simple check to force local logout. Though, it needs to customize your CAS server, that you cannot do.
You have the solution of having a shorter session on application side to force regular re-authentication, but this means that you will invalidate often your application session and recreate it.
A better solution can be based on the gateway parameter of the CAS protocol : using this parameter will not produce a service ticket if you are not SSO authenticated. So you could have :
an application filter which, every 5 minutes, saves the current url, triggers a CAS round-trip with gateway=true and a specific service : http://myserver/myapp/checkCasSession
a specific url : /checkCasSession : if it receives a service ticket, everything is ok, the CAS session is still valid, it just restores the original url. If there is no service ticket, the local session must end and a local logout is triggered.
I think there is no such way. Spring Security and Spring Security Cas are implemented as a set of Servlet API filters / listeners. So Spring Security Cas works only during some Http request / Session event processing. I do not view any dependency on some scheduling library for spring-security-cas.jar.
It's not an easy problem you can address out of the box with Spring Security. You need to work on both sides : client and server. I would :
create a controller on CAS server side which returns a JSON indicating if the CASTGC has expired or not
every 5 minutes (for example) and each time an application page is displayed, add some javascript to call this specific CAS controller and if the CAS session has ended, ends also the application session.
You need to call the CAS server from front channel as the CAS session is held by the CASTGC cookie.
You have two sessions : the application one with its idle timeout and the CAS one with idle / hard timeouts. After having accessed the application through CAS login, the application session lives on its own and can last more than the CAS session. It's generally not a problem. What use case do you want to handle ?
Related
I have some questions about the flow the authorization code grant flow.
I know the first part of oauth2 is that send https://auth.server/oauth2/auth?scope= &redirect_uri=https://app.example.com/oauth2/callback &response_type=code&client_id=123 &state=af0ifjsldkj
I am confused about the state parameter. I understand that the state parameter is for preventing the attack of csrf. But Where should i save this parameter? If i save it into the session of auth server, how can i verify the state in the following step?
https://app.example.com/oauth2/callback?
code=MsCeLvIaQm6bTrgtp7&state=af0ifjsldkj
how can i verify the state parameter in app.example.com , but the state paramter save in the session of auth server?
Your tech stack's security library should manage this for you and the state will be saved within your app:
For a single page app it is common to save state to local storage
For a server side web app it is common to use a temporary HTTP only cookie instead
The Auth Server's only job is to ensure that it returns the same state in the response to the app that it received in the request from the app. Any off the shelf Auth Server will do that for you.
Behaviour is summarised visually in steps 4 and 7 of my blog post. In my case I am using an SPA and the OIDC Client library manages verifying response state.
As a result, my app is protected against CSRF attacks. If someone pasted this into the browser address bar my app would not attempt to process the authorization code:
https://web.mycompany.com/spa?code=xxx'&state=yyy
I'm dabbling into the art of service workers and PWA. I have trouble finding out more about authentication for the service worker. I want to poll or have a websocket to a backend, where i would need to authenticate. The service worker would be registered within the same domain and enabled when the user is already authenticated. But what happens when the user closes that session, will the service worker still work with the login cookie?
If the user closes the session/logs off then any Fetch request the SW performs that requires authentication will fail.
FYI, I asked about Session Expiry without a client present, as opposed to the user actively terminating the session here
Sadly the only work being done on SW at the moment is caching everything, offline-first, over-tuning, and "Look! I've built a proxy-server and CloudFlare on the client" :-(
I use SignalR 1.0.1 as a chat core for ASP.NET MVC3 application. Using IIS 7.5
There are two methods in MVC controller which provides access to chat views:
1. First method is public, allowing anonymous users to chat - no authorization.
2. Access to second method is restricted with [Authorize] attribute, for domain users - chat agents.
There is no explicitly specified authorization in the Hub.
For this scenario I involved both Windows and Anonymous authentication on IIS.
I also implemented custom Role Provider, which operates only in memory - not persisting anything to database.
What happens is that using '[Authorize]' attribute in controller method leads to responsing 500 from Hub, both when call is coming from authorized view, and the anonymous one:
Request (send is Hub method for sending messages):
http://localhost:8101/signalr/send?transport=serverSentEvents&connectionToken=VIXEZzWQSn5SNlA8RUy4iaOPDFdvuPBjMvFBiG2FLfvfxF347XHwtapsEV5ndU4OEI0Xb64W2ZRXTqwBiL2CXg2_JlTaTJ2RnVOj4bjvx6tQaYhAqTaXs9k2853GYqzd0
Response:
The connection id is in the incorrect format.
Server stack trace:
at Microsoft.AspNet.SignalR.PersistentConnection.GetConnectionId(HostContext context, String connectionToken)
at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest(HostContext context)
at Microsoft.AspNet.SignalR.Owin.CallHandler.Invoke(IDictionary2 environment)
at Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke(IDictionary2 environment)
at Microsoft.Owin.Host.SystemWeb.OwinCallContext.Execute()
at Microsoft.Owin.Host.SystemWeb.OwinHttpHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object extraData)<br/><br/>
But notice, that connecting to Hub works fine, returns 200 OK:
http://localhost:8101/signalr/connect?transport=serverSentEvents&connectionToken=dYOwFxa1mkgdpzw-jitRpWq9oxRlrTet8U_dAzWjFQEdGNJfVXeG7Op0NZZwvznxeNdJCuPT75CKzQqI9HRPThV3uEDt-Z2qtIl9E02gF481&connectionData=%5B%7B%22name%22%3A%22chathub%22%7D%5D&tid=9
I found little similiar thread here on stackoverflow:
signalr The connection id is in the incorrect format
from which I understand, that when invoking my Send method, the Hub is processing request with Identity different than the one used to connect to Hub, OR Hub's GetConnectionId finds, that user is actually not authorized - but how it checks that assumption, when there is no authorization specified on the Hub itself?
Can someone put some light on this?
Thanks in advance :)
SignalR signs both your connection id and your Identity together in order to create a new connectionToken every time you start a new connection. This connectionToken is then sent to the SignalR client as part of the negotiate response.
Every time you make a request to SignalR, whether it be a connect, reconnect, or send request, SignalR verifies that your connectionToken matches both your client's connection id AND Identity.
The connectionToken is essentially a CSRF token used in order to prevent attackers running third-party websites from surreptitiously making SignalR requests on behalf of shared clients. Obviously this doesn't help if you've enabled SignalR's cross-domain support, but the connectionToken still works the same in this case.
Taylor's answer was correct. You should stop and then start your SignalR connection when your client's Identity changes. This will force a new negotiate request which will give your client a new connection id with a new connectionToken signed with your client's updated Identity.
P.S. The server-sent events connect request isn't failing because it was established before your client's Identity was changed. The connectionToken is only checked at the request is received, but server-sent events keeps the response open indefinitely.
That's all true what you said and it actually takes place in my issue.
But I also found the the root cause:
One of main assumptions during design was to allow both anonymous users to use the chat without need to sign-in and the back-end users (agents) to sign-in to restricted area of chat using their Windows credentials.
So on the IIS manager I enabled both Anonymous authentication (allowing anonymous users to use the chat) and the Windows authentication (allowing agents to access using their Windows credentials).
MVC application is configured to use Windows authentication - the [Authorize] attribute mentioned in question, but only to restrict access for agent's view of chat.
What actually happens with above configuration is:
1. When client (agent) requests restricted View (let's say it's /Chat/Agent) the [Authorize] attribute initializes authentication (Windows)
2. Client-side Javascript requests Negotiate, what generates connectionId and binds it with client's Windows Identity
3. Here is the tricky part: Because Hub not uses any authentication explicitly, calling send method does not result in any authentication request - IIS Anonymous authentication takes precedency before Windows authentication, and send request is sent with anonymous Identity - but in Hub actual connectionId is related to Identity passed in point 2.
This scenario leads to situation you described - connect is called with different Identity than send and Hub returns The connection id is in the incorrect format.
While using a SSO to integrate between disparate "web applications", the user might switch back and forth between these applications. As the user navigates between these applications, a local session gets created on each of the applications in addition to a session created at the Identity Provider that is used for sso.
So, the issue is when applications have different session timeouts, leading to a broken user experience. Session timeout occurs in one application while the user is working on another application. When navigating back into the application the user had visited previously, an error occurs. This is confusing to the user, since they are not aware that they are working on different applications.
One way to avoid the problem is to have a "global session" object that every application has access to. While the user is accessing any protected resource, the application checks if the global session exists and updates its timestamp before processing the request. The local sessions will never expire (or have a very long timeout). However, when the user logs out, global session object is evicted and the sign out happens on all the applications.
This seems to be a bit heavy handed due to:
Global session object becomes single point of failure
The performance to make a "out of process" check for the global
session object and update the timestamp on access of every
protected request
Any other thoughts on how to make this work?
When navigating back into the application the user had
visited previously, an error occurs.
I don't think that would be an error. The application will redirect the request to SSO provider and as the user is already have a valid SSO session it will be a successful SSO operation and the application can re establish a new/expired session.
I'm using Flex 4(beta2) with Ruby on Rails 2.3.5 and using RubyAMF to transfer data back and forth between Flex and server.
I set up Authlogic on the Rails side for authentication.
I wasn't sure what's the best method to handle user sessions. I know this is done automatically with Rails by sending session id with cookie which Rails use to authenticate the user.
What do you suggest the best way to do this with Flex?
I thought of couple of options:
1. Manually fetching the cookie from the browser and then figuring our a way to send that to the server with every request I send.
2. Handling sessions expiration and flow on Flex side by manually expiring the session
Do you have other suggestion or recommendation?
Thanks,
Tam
Network requests in Flash use the browser networking stack so cookies in Flex work just like any other browser application. Usually authentication in Flex is no different than it is with a standard web application. Send credentials to the server which it correlates with a session id. Every subsequent request (RemoteObject, HTTPService, etc) also sends that session id.
We have seen that the flash plug-in propagates the session cookie when we do blazeDS (http) remote calls
In the past we have worked with BlaseDS and HTTPServices. In both the cases the request is sent to the server over HTTP. Our server stack as Java (JBoss to be specific).
We noticed that the flex client used to send the session information with the requests to the server. We used same information to store and fetch Principal on the server.
In one case, we propagated the token to the client. This was to avoid multiple submits for same requests - hence we used the common HTML submission approach of token generation where with every response carries with itself a new token and the client has to sent it back to the server for executing the next request.
For the session expiration, there is a good chance that a user is working on the client for any local needs and not working with the server which may have caused a expiration on the server without impacting the server. In this case, we disabled the session expiration on the server and wrote custom code to handle events - keyboard and mouse on the flex client. If the application was not used for a specified time, the flex client would expire both the sessions i.e. local and server
What do you suggest the best way to do this with Flex?
$loggedIn=Authenticate::isAuthenticated();
if(!$loggedIn)return false;
$user=Authenticate::getAuthUser();
First Authenticate the user and if he is logged in create the session. Include this in your every PHP or Ruby file, and check it. Send the Session ID to Flex to maintain the state and you set the time for your session to expire.
The above code does check, whether the user is authenticate to access the PHP or ruby class files.