CAS Login Page redirect fails if session expires

[zheng.guozhu]

Kevin,

I think it is because that the CAS3 is using webflow to handle the login
flow, and the flowid is used as th login ticket. But the flowid depends on
the session, so in my case, I divided the login flow into two, one for
credential requestor, and another for credential acceptor. Then the user can
sign on from the login form at any time. I don't know whether it will cause
security issues.

Another point I should mention is that the current CAS3 login flow solution
will not support cluster. If we deploy the CAS3 server with random accessing
cluster solution, the flowid will always not exist in another server. So I
think the current login flow solution which based on Webflow is not good
enough.

By the way, I am using JBossCache to implement the tickets replication for
my cluster solution, but it made me sad that the JBossCache is very bad for
perfomance and stability.

Happy new year!

Zheng Guo Zhu

On 12/30/05, kevin james <kevinjj33 at yahoo.com> wrote:
>
>
> Hi Andrew,
>
> Thanks for your quick and pretty insightful reply.
>
> Yes, I have deployed CAS 3 , with a CAS 2 client, For now I put a meta
> refresh tag in the loginView.jsp to keep the session alive, but I will try
> changing the session length in the web.xml and see if it suffices my
> users' behaviours.
>
> I will log a bug report too.
>
> Thanks Much
>
>
> *Andrew Petro <andrew.petro at yale.edu>* wrote:
>
> Kevin,
>
>
> >
> > Hello
> >
> > I have a strange problem when I try to logon with CAS .
> > If I wait for a certatin period of time to login after I get the
> > CAS login screen with the service ticket appended to the URL like
> > https:/cas/login?service?=http://myservice,
>
>
> Careful. What you've described is the CAS login screen with the
> service identifier on the URL. No Service Ticket has yet been issued.
>
>
> > there is a session expire and then when the Login button is hit,
> > the URL loses the service parameter and asks me to login again (the
> > URL is now just https:/cas/login) , when i login it ofcourse logs
> > me into the default CAS logged-in page, inidicating that I have
> > successfully logged onto CAS. phew..too many logins
>
>
> I assume you're using CAS 3.
> This sounds like a bug, an unfortunate side effect of the way CAS 3
> uses Spring Web MVC Web Flows to do the login workflow. I'd guess
> the flow is forgetting the service under this particular failure
> modality.
>
> In CAS 2 no sessions are used and unless I'm mistaken letting the
> LoginTicket expire (the equivalent of a session identifier for the
> CAS 2 login form! ) only has the consequence of failing the
> authentication attempt -- the system does not forget the target
> service. If you're seeing this in CAS 2, please especially let me
> know as it would be news to me that this problem is possible there.
>
> >
> >
> > Is there a parameter somewhere that I have to append about session
> > expiery in the login page, I am using CAS to sign into the LifeRay
> > portal , running on Linux. I am using a CAS 2 client specifically
> > ESUP's LDAPHandler with Active Directory.
>
>
> No, there isn't a parameter for dynamically configuring the session
> expiration timeout on the login page. You can change the CAS server
> session length in its web.xml. Increasing that session length will
> likely increase the time a login page is viable before you see this
> issue.
>
> Please log a bug report on this -- ideally we should fix the failure
> modality to always remember the desired service on a form pos! t, even
> on an otherwise bogus post.
>
> http://www.ja-sig.org/issues/secure/CreateIssue!default.jspa<http://www.ja-sig.org/issues/secure/CreateIssue%21default.jspa>
>
> >
> > Any help is appreicated.
>
>
> If you're seeing this in CAS 3, consider cranking up the session
> length until you don't see the issue for a sufficient portion of
> legitimate uses of your CAS server. This issue is annoying and
> should be fixed, but I'd be surprised if there are a lot of users who
> start to log into a service and wander off for more than say 15
> minutes and then return and try to log in.
>
> If you're seeing this in CAS 2 fixing it is likely to be more
> difficult to parameterize, though turning up the timeout on CAS 2
> LoginTickets in CAS 2 might have the same effect as lengthening the
> timeout on sessions in CAS 3.
>
> Andrew
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
> ------------------------------
> Yahoo! for Good - Make a difference this year.<http://us.rd.yahoo.com/mail_us/taglines/charity/*http://brand.yahoo.com/cybergivingweek2005/>
>
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20051231/eabb986a/attachment.html