I am integrating against a CAS server. User logs into there, gets forwarded to a script which does the CAS validation, gets the User and logs them in. This all works fine.
Part of the spec for the integration is to ensure we ping the CAS server every 60 seconds, to ensure the user does not get logged out at the 'parent' CAS server, as they are still active.
Is there something built into the CAS setup for this purpose? I've been looking through the CAS documentation and the phpCAS client to no avail. There's a renewAuthentication method but it causes the user to have to login again when called. Perhaps this is just a configuraton issue at the server side though?
There is no way for you to ping the CAS server on behalf of the user as your application should not have access to the token identifying the user's session. The default policies automatically extend the user's single sign on session every time the user requests a new service ticket from the CAS server.
However, if you do have the TGT (which you really, really, really should avoid), you can basically request a service ticket for the user, and that would extend the life of the single sign on session (though if you did this, you would not need to do it every 60 seconds, as that's rather extreme).
Related
I am beginner in using CAS and i'm using it in one of my project to use its Single Sign On services. Till now i have implemented Single sign on, I have one JAVA client and a PHP Client. But for using Single Sign Out functionality i configured my running CAS according to CAS documentation. I have done all the changes in the deployerConfigContext.xml of my working CAS. My CAS is up running, but on logging out it doesn't show any SAML logout request. I'm using Official PHP Client and Java Client made by me. I think it may be due to these lines which i'm not able to configure it in my Client side.
The way the notification is done (back or front channel) is configured at a service level through the logoutType property. This value is set to LogoutType.BACK_CHANNEL by default.
I'm not able to understand by this line where actually i had to set the Logouttype to BACK_CHANNEL, if its my Client then why is it that it is set to BACK_CHANNEL by default as a Client can be made by anyone.
Any help is highly appreciated.
Thanks in Advance.
Take a look at the jasig documentation: http://jasig.github.io/cas/development/installation/Logout-Single-Signout.html
When a CAS session ends, it notifies each of the services that the SSO
session is no longer valid, and that relying parties need to
invalidate their own session.
This can happen in two ways:
CAS sends an HTTP POST message directly to the service ( back channel communication): this is the traditional way of performing
notification to the service.
CAS redirects (HTTP 302) to the service with a message and a RelayState parameter (front channel communication): This feature is
inspired by SAML SLO, and is needed if the client application is
composed of several servers and use session affinity. The expected
behaviour of the CAS client is to invalidate the application web
session and redirect back to the CAS server with the RelayState
parameter.
And the important part:
Usage Warning!
Front-channel SLO at this point is still experimental.
So your SSO server sends a request to the application directly. The authenticator recognizes that this request is a special one and logouts the referenced user.
Update:
Take a look at the following links:
https://wiki.jasig.org/display/casum/single+sign+out
https://github.com/Jasig/cas/blob/6c3df3a5f42d2d8b771ba773aeda3ba5a4c525e3/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/applicationContext.xml
https://github.com/Jasig/cas/blob/6c3df3a5f42d2d8b771ba773aeda3ba5a4c525e3/cas-server-core/src/main/java/org/jasig/cas/logout/LogoutManagerImpl.java
Did you accidantly remove or overwrite your logoutManager declaration in your applicationContext? Is there an logoutManager bean in your running spring context?
I would start by setting break points in the handleLogoutForSloService, performBackChannelLogout and performLogout methods of LogoutManagerImpl.java.
Are they beeing called?
Can you step through them?
Is performBackChannelLogout called?
Is this.httpClient.sendMessageToEndPoint(msg) in performBackChannelLogout successful?
If you are logged on to 2 services, performBackChannelLogout should be called twice with both service urls.
I'm currently making tests with the CAS server 3.5.2 and I'm facing
problems with the logout.
My knowledge in these topics is limited and I don't manage to go further on
that point.
I installed a CAS server and I've got 2 instances of the same java
application that point to that CAS server (appologize if I don't use the
adecuates terms).
So, when I access to the protected resources of my client aplication, I'm
redirected to the CAS login page, I check in my DB if credentials are ok
and then I access the resource. Then, if I access to the same protected
resource from the second instance of the client application I'm not
redirected to login page. That's perfect.
The problem is situated in the logout. To do so, I first execute a
session.invalidate() and access to the CAS logout page. It's ok because,
from the application from which I logged out, I must login again to access
the protected resources. On the other side, the second application remains
connected and I can access the protected resources without login again.
Well, I know that the session.invalidate() is local to the first
application but I thought that CAS server would have "broadcasted" the
desconnexion to the other application but no.
Is there somebody who can give me experience feedback for the single sing
out topic ?
First make sure that SSO is enabled in the CAS properties file, if not make sure the SSO Listener is enabled in the clients.
If they are enabled then my guess would be the issue is in either the LogoutManagerImpl.java or SamlCompliantLogoutMessageCreator.java files.
The SSO in CAS is performed through the back-channel by transmitting a SAML XML message.
I had an issue with the SSO function last year only to find out that the XML message being broadcasted had an error that prevented it from being parsed.
Finally I solved...
In web.xml, the order of filters is important. Filters for Single-sign out must be placed at the begining.
See that section https://wiki.jasig.org/display/CASC/CAS+Client+for+Java+3.1#CASClientforJava3.1-OrderofRequiredFilters
We have ServiceNow among other applications configured in ADFS for SSO, ServiceNow is the only app using SP Initiated signon however.
Sometimes when you log out, it behaves as it should and goes to https://adfs.example.com.au/adfs/ls/?wa=wsignout1.0 and tells you that you are signed out but sometimes instead of going to the signed out page you just get redirected back to ServiceNow, (you can see another SAML request happening and it lets you in) and your session is still logged in. Obviously this represents a security issue! The User logs out then leaves the machine without looking and the session is still open!
Anyone come across this before? It seems SP Initiated Sign On is buggy and I need to fix these log out issues for security reasons.
The wa=wsignout1.0 is intended to use for wsfed applications. servicenow as a SAML2 app should be sending a properly constructed samlp:logoutrequest to the /adfs/ls endpoint to do a signout properly.
Is there a way to revoke/invalidate a user's CAS session from a client application without the user visiting the CAS server's logout page?
The situation is that a user could be accessing 1-n services that all authenticate off the CAS server. One of those client services is in charge of user accounts, and sometimes needs to terminate an account. If that user is logged in to 1-n other services, those sessions need to be immediately destroyed. Normally this is accomplished by the user clicking "logout", but if the user isn't present, that's not possible.
I think you have to check regularly if the ticket has expired or not.
Check this subject
CAS and Spring-Security: regularly check if a ticket has expired
I'm going to develop site accessible to anonymous and registered users. Planed security schema is similar to let's say YouTube and most of others "web 2.0" sites. Logged user will get access to more functions, more data etc. What is best approach to implement that?
I'm thinking about create simple service returning random session code to client, and adding session object to singleton application object. When user provide credential, I'll change parameter "logged" in his session object. Session token will be passed as one of parameters in every single request, and services will change their behavior if user is registered or not (i.e. there will be returned only "public" data, or restricted content only)
Is it good approach, or should I use something different?
There is nothing inherently different about GWT security, it is the same with JSP,PHP, ASP, ROR, etc..., that is web application security.
There is already a session mechanism on the server side, that generates secure random session cookies, use it. As a bonus, it handles session expiration and other things you would have to handle if you rolled your own.
You cannot trust ANYTHING the client sends you, so if you send the username or some kind of token from the client to the server (other than the user logging in), you are doing it wrong.
If your information has any value, force SSL on all connections.
Your implementation of the server calls should check the server session for the current user info, and determine if the user is authorized to perform the action. Again, your RPC information should not include any information about the user making the call, other than the session cookie that is sent automatically with the request headers. Anything you store, such as whether the user is logged in, should be in the server side session.
Of course, you need to do something on the client to present logged in and anonymous users with the proper user interface. But that is not security, only work to present a consistent interface. All the security is on the server side.