[cas-dev] Remember Me login

March, Andres amarch at soe.sony.com
Wed Jan 3 19:25:20 EST 2007 

I have finished a basic implementation of this using a variation on Arnaud's patch and a Berkeley DB ticket registry.  Basically I created a new action for the login web flow that looks for the save password/remember me flag.  If it has been set, the Result returned from the action goes to a SendTicketGrantingTicketAction that has been configured with a persistent cookie generator.  Otherwise, it goes to the SendTicketGrantingTicketAction that is configured with the session length cookie generator.  It makes configuration very simple and doesn't require any changes to CAS classes.  The action that checks the save password parameter is pasted below.

 

As for the extending the life of the tickets in the registry, I did not want to keep 3 months worth of tickets around, so I add a Berkeley DB backed ticket registry.  I believe it will prove to be extremely efficient even though it writes to disk.  The one thing I have not done is pass the cookie life info as part of the credentials to be used in the expiration policy.  This is obviously not ideal because even session length TGTs will not be deleted by the registry cleaner until my 3 month mark.  Scott's suggestion on how to do this makes sense, so I will probably try and do something similar.  I just wanted to create a working implementation first, which did not require modifications to CAS code.

 

public class CheckSavePasswordAction extends

                                AbstractAction {

 

                @Override

                protected Event doExecute(RequestContext context) throws Exception {

                                

                                boolean savePassword = ContextUtils.getParameterAsBoolean(context, "savePassword");

                                 

                                if (savePassword) {

                                                return result("savePassword");

                                

                                } else {

                                                return result("noSavePassword");

                                }

                }              

 

}

 

________________________________

From: cas-dev-bounces at tp.its.yale.edu [mailto:cas-dev-bounces at tp.its.yale.edu] On Behalf Of Scott Battaglia
Sent: Thursday, December 21, 2006 11:10 AM
To: Mailing list for CAS developers
Subject: Re: [cas-dev] Remember Me login

 

I've thought about this a little, on how to get that information into the ExpirationPolicy.  We can't change any of our major APIs so that means that this information would need to be transferred along with the Credentials (which arguably could be something useful when authenticating as a handler may not want to authenticate something if its planned usage is a long time).  To get this information within the ticket it would need to be transferred to the Authentication object as an attribute (which again arguably makes sense as we're saying this authentication is for extended usage).  The only flaw in this plan is getting that knowledge to the expiration policy.  As the TicketState interface is mostly used internally, it is probably safe to add a "getAuthentication" method to that to expose it (and again arguably the Authentication is part of the ticket's state and should have been there). 

Another alternative is to create a ExpirationPolicyFactory but I think this may over-complicate things.

Thoughts?
-Scott

On 12/20/06, March, Andres <amarch at soe.sony.com> wrote:

Yeah, we are looking at a persistent cookie length of months.  We would like to limit the number of auths we are holding onto. 

> -----Original Message-----
> From: cas-dev-bounces at tp.its.yale.edu [mailto:cas-dev-
> bounces at tp.its.yale.edu] On Behalf Of Arnaud Lesueur
> Sent: Wednesday, December 20, 2006 10:39 AM
> To: Mailing list for CAS developers
> Subject: Re: [cas-dev] Remember Me login
>
> What is the problem for you to set the grantingTicketExpirationPolicy to 
> the max(user choice 1, user choice 2) ?
>
> The only problem I see is related to memory usage. And after endurance
> tests with a cleaning policy of 20 hours, this
> was not a problem ...
>
> We put this patch in production with :
> - a session cookie
> - a persistent cookie of 20 hours
> And a cleaninng policy of 20 hours.
>
> But OK, the session is only 20 hours and not sereval days or weeks. 
>
> Arnaud Lesueur
>
> Le Mer 20 décembre 2006 19:16, March, Andres a écrit :
> > That is great but I don't see how your patch would work without
> modifying the lifespan of the ticket in the registry. 
> > Sure the cookie would live longer but the TGT would expire when the
> registry cleaner executed.
> >
> >
> >> -----Original Message-----
> >> From: cas-dev-bounces at tp.its.yale.edu [mailto:cas-dev-
> >> bounces at tp.its.yale.edu] On Behalf Of Arnaud Lesueur Sent: Wednesday,
> December 20, 2006 10:05 AM 
> >> To: Mailing list for CAS developers
> >> Subject: Re: [cas-dev] Remember Me login
> >>
> >>
> >> Well I have already make an implementation for this use case. 
> >>
> >>
> >> The main idea is to customize the SendTicketGrantingTicketAction
> depending
> >> on a user choice parameter on the login form.
> >>
> >> You may found my implementation here : http://www.ja-
> >> sig.org/issues/secure/attachment/10691/persistentCookie.zip have a look
> at my issue : 
> >> http://www.ja-sig.org/issues/browse/CAS-366
> >>
> >>
> >> I still think is a good feature which should be added to CAS project 
> ...
> >>
> >>
> >> Scott, if you agree I might adapt the code to 3.1 and commit it.
> >>
> >>
> >>
> >> Arnaud Lesueur
> >> 
> >>
> >>
> >> Le Mer 20 décembre 2006 18:47, March, Andres a écrit :
> >>
> >>> I see what you mean but the concrete instantiation is still the issue,
> >>> 
> >> IMHO.  A factory pattern would allow me to
> >>
> >>> control the creation of the Ticket and set whichever expiration policy
> I
> >> wanted.  There is only one expirationPolicy 
> >>> possible in the CASImpl as you are aware.  Also, I need some way to
> pass
> >> the user's choice of whether to do a short
> >>> or long expiration to the place where the policy is set.  I don't know 
> >> the best way to do this yet.  If you have any
> >>> ideas, I would be happy to implement it and contribute it back.
> Thanks
> >> for the reply.
> >>>
> >>> 
> >>>
> >>> ________________________________
> >>>
> >>>
> >>>
> >>> From: cas-dev-bounces at tp.its.yale.edu [mailto:cas-dev-
> >>>
> >> bounces at tp.its.yale.edu] On Behalf Of Scott Battaglia
> >>> Sent: Wednesday, December 20, 2006 6:19 AM 
> >>> To: Mailing list for CAS developers
> >>> Subject: Re: [cas-dev] Remember Me login
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>> I haven't had time to think about it fully yet, but we may need to
> >>>
> >> modify the CAS server to support this (choosing on
> >>> of many expiration policies was not in the original design. 
> >>>
> >>> You won't need a custom TicketGrantingTIcketImpl though, just a
> >>>
> >> different expiration policy (one with a longer
> >>> length). 
> >>>
> >>> -Scott
> >>>
> >>>
> >>>
> >>> On 12/12/06, March, Andres <amarch at soe.sony.com > wrote:
> >>>
> >>>
> >>>
> >>> I'm implementing a Remember Me (Save Password) feature and want to
> make
> >>>
> >> the cookie have a variable lifespan: browser 
> >>> session if they don't choose "Remember Me" or 3 months if they do.
> >> However, my plan to substitute my own
> >>
> >>> implementation for TicketGrantingTicketImpl is not possible because it 
> >> is currently instantiated in a concrete
> >>> fashion in the CentralAuthenticationServiceImpl rather than using a
> >> factory.  Any ideas?
> >>>
> >>> 
> >>>
> >>> ________________________________
> >>>
> >>>
> >>>
> >>> From: cas-dev-bounces at tp.its.yale.edu [mailto: cas-dev-
> >>>
> >> bounces at tp.its.yale.edu
> >>> <mailto:cas-dev-bounces at tp.its.yale.edu > ] On Behalf Of Scott
> Battaglia
> >>> Sent: Friday, November 17, 2006 10:59 AM
> >>> To: Mailing list for CAS developers
> >>> Subject: Re: [cas-dev] Remember Me login 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Well TicketGrantingTickets themselves have a life-expectancy of
> whatever
> >>> 
> >> time you decide.  It can be short or long.
> >>> The key is making sure the cookie expiration time matches up with the
> >>>
> >> TicketGrantingTicket expiration time. 
> >>
> >>>
> >>>
> >>> Cookies only store the TicketGrantingTicket identifier.
> >>>
> >>>
> >>>
> >>> -Scott 
> >>>
> >>>
> >>>
> >>> On 11/17/06, Alan D. Cabrera < alan.cabrera at simulalabs.com
> >>>
> >> <mailto: alan.cabrera at simulalabs.com> > wrote:
> >>
> >>>
> >>>
> >>> Does anyone have any thoughts on my comments?  Arnaud? 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Regards,
> >>>
> >>>
> >>>
> >>> Alan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Nov 15, 2006, at 12:13 PM, Alan D. Cabrera wrote: 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Do I understand the code correctly when I say that you store the
> ticket
> >>> 
> >> in a cookie?  IIUC, won't the ticket expire
> >>> after a short while?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Regards, 
> >>>
> >>>
> >>>
> >>> Alan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>> On Nov 15, 2006, at 10:15 AM, Arnaud Lesueur wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Hi,
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>> I have already open an issue in JIRA few months ago on this request
> and
> >>>
> >> I also put my code as attachement. This 
> >>
> >>>
> >>>
> >>> available here : http://www.ja-sig.org/issues/browse/CAS-366
> >>>
> >>>
> >>>
> >>> If you think, this feature is usefull please vote for it !
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>> Arnaud Lesueur
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Le Mer 15 novembre 2006 18:47, Jack Tang a écrit : 
> >>>
> >>>
> >>>
> >>> Hi Alan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Can you share the code with me? I am now hacking the some problem.
> >>>
> >>>
> >>>
> >>> Thank you very much.
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> /Jack
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>> On 11/10/06, Alan D. Cabrera < alan.cabrera at simulalabs.com
> >>>
> >> <mailto: alan.cabrera at simulalabs.com> > wrote:
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>> On Nov 9, 2006, at 8:10 AM, Peter Havelaar wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Alan D. Cabrera <alan.cabrera at ...> writes:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>> We also wish to support "remember me".   What we plan on doing is
> >>>
> >>>
> >>>
> >>> hacking the
> >>> 
> >>> CASFilter so that we store an encrypted token in a cookie.  Its
> >>>
> >>>
> >>>
> >>> format will be:
> >>>
> >>> 
> >>>
> >>> userid:expiration:salt
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> If the CASFilter sees this cookie, it will refresh the session 
> >>>
> >>>
> >>>
> >>> variables.
> >>>
> >>>
> >>>
> >>> We also intend to modify the CAS login code to include 
> >>>
> >>>
> >>>
> >>> cas.remember URL
> >>>
> >>> parameter which would instruct the filter to construct the token.
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> That is great!
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>> When are these changes scheduled to be performed?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Well, we're making these changes internally this week.   I am happy to 
> >>>
> >>>
> >>>
> >>> submit the code back to the community.  Can anyone on the team
> comment?
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>> Regards,
> >>>
> >>>
> >>>
> >>> Alan
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Alan D. Cabrera
> >>>
> >>>
> >>> 
> >>> VP Engineering
> >>>
> >>>
> >>>
> >>> Simula Labs - The Open Source Venture Partners
> >>>
> >>>
> >>> 
> >>> p: +1 510 225 5588 f: +1 800 822 0471
> >>>
> >>>
> >>>
> >>> alan at simulalabs.com www.simulalabs.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________ 
> >>>
> >>>
> >>>
> >>> cas-dev mailing list cas-dev at tp.its.yale.edu
> >> http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>>
> >>>
> >>>
> >>> cas-dev mailing list 
> >>>
> >>> cas-dev at tp.its.yale.edu
> >>>
> >>> http://tp.its.yale.edu/mailman/listinfo/cas-dev 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Alan D. Cabrera
> >>>
> >>>
> >>>
> >>> VP Engineering 
> >>>
> >>>
> >>>
> >>> Simula Labs - The Open Source Venture Partners
> >>>
> >>>
> >>>
> >>> p: +1 510 225 5588 f: +1 800 822 0471 
> >>>
> >>>
> >>>
> >>> alan at simulalabs.com
> >>>
> >>> www.simulalabs.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>>
> >>>
> >>>
> >>> cas-dev mailing list
> >>>
> >>> cas-dev at tp.its.yale.edu
> >>>
> >>> http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Alan D. Cabrera 
> >>>
> >>>
> >>>
> >>> VP Engineering
> >>>
> >>>
> >>>
> >>> Simula Labs - The Open Source Venture Partners 
> >>>
> >>>
> >>>
> >>> p: +1 510 225 5588 f: +1 800 822 0471
> >>>
> >>>
> >>>
> >>> alan at simulalabs.com
> >>>
> >>> www.simulalabs.com
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>> _______________________________________________
> >>> cas-dev mailing list cas-dev at tp.its.yale.edu
> >> http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________ 
> >>> cas-dev mailing list cas-dev at tp.its.yale.edu
> >> http://tp.its.yale.edu/mailman/listinfo/cas-dev 
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cas-dev mailing list cas-dev at tp.its.yale.edu
> >> http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >>
> >>> 
> >>>
> >>
> >>
> >> _______________________________________________
> >> cas-dev mailing list cas-dev at tp.its.yale.edu 
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >>
> >
> > _______________________________________________
> > cas-dev mailing list cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >
> >
> > 
>
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20070103/94b1cd02/attachment-0001.html

More information about the cas-dev mailing list