On November 27, 2012 12:57 , Chris Hecker <chec...@d6.com> wrote: >> If you get Kerberos tickets, then make sure that the default TGT and >> service ticket lifetimes are 1 week, too > But that violates the entire point of short lived tickets, and is why > there are renewable tickets in krb5 in the first place.
Except: the tickets obtained by cosign (*) are not being used to authenticate the user to cosign. Keep in mind that passing Kerberos tickets to cosign-protected web servers so that the protected web servers can in turn authenticate to other back-end services as the user is an optional feature of cosign that most sites do not use. A very common way to use cosign is to have it authenticate against an LDAP directory; no tickets are involved. Or to put this another way, renewing the ticket does not do any good because cosign itself does not use the tickets for authentication of the user. In fact, cosign, when requesting tickets, explicitly requests non-renewable tickets. (*) The situation is different if you have cosign configured to use SPNEGO for authenticating users. In this case, the tickets are obtained by the user's device and passed via the user's web browser to the cosign CGI on the central weblogin servers. cosign still won't renew these tickets, however, as it currently lacks the code for that, but if a user renews the ticket on their device, the central weblogin servers will automatically and (usually) transparently accept it without the user ever knowing that cosign reauthentication has occurred. > In other words, I just want to avoid the problem where the user is > active, but the ticket expires in the middle of doing something. Assume > I have the krb5 tickets and cosign's soft and hard timeout are both set > to 24 hours. If I get a ticket at 3pm on Monday, and then log in at > 2:45pm on Tuesday and do some stuff, I will have to reauthenticate in 15 > minutes (at least, that appears to be the behavior I'm observing) > regardless of whether I'm active or not right then, and even though I > started a session while still authenticated. That is bad user > experience and doesn't really help with security since I already had > access for 15 minutes. The horses are out of the barn, as they say. My recommendation is to choose slightly different numbers for the timeout so that the sort of multi-work-session overlap you describe does not occur. The problem you are encountering is not anticipated because you have essentially disabled the idle time out while making the hard time out something that is likely to span multiple user work sessions. If users typically work, say, 16 hours at a time, then set your hard time out to be, say, 20 hours and keep your idle timeout at 2 hours. This way, if the user logs in to cosign (important distinction: they do not get a ticket, they log in to cosign) at 3pm on Monday, then their session will expire 2 hours after they go home, and when they come in at 2:45pm on Tuesday, they'll have to reauthenticate before doing anything else -- but after reauthenticating, they'll be able to continue doing work until they go home again. Even if you set the idle timeout to 20 hours too (effectively disabling it by making it equal to the hard time out), the user would not encounter a situation where their credentials on Tuesday are only briefly valid. The above solution is not perfect; there will always be corner cases. But it -- or something similar -- should work for the vast majority of users the vast majority of the time. My experience here at the University of Michigan with a user community of 250,000 people per year across each of 10 years we've been running cosign supports this. And the security goal of "after the user is away for a substantial period of time, require them to reauthenticate before resuming work" is met. > What I want is exactly what renewable tickets do for kerberos, which is > that if I am active and renew the ticket while it's valid, I can keep > working without a password prompt. It seems like if the ticket is valid > and the user is active, cosign should just try to renew the ticket. If > it fails, then yeah, kick the user to the login screen, but if it > renews, then let them keep going without knowing anything happened. cosign does not currently do this. However, you could modify cosign to do this, if you want. I haven't looked into this in detail, but I'd recommend starting by changing cgi/login.c to request renewable tickets; that should be a 1 line change. Then I'd suggest adding code to daemon/monster.c to check the kerberos ticket lifetime, and, if it's close to expiring and the user is currently active (per the last-accessed timestamp stored in the cookie database), to renew the ticket and then update the cookie database times appropriately to prevent the session from expiring. Be aware that your phrase, above, "if I am active and renew the ticket while it's valid" reveals a problem: the user would not initiate the renewal of the ticket, the central weblogin server would. The user would take no action in the scenario you describe. (Note that if you are using SPNEGO, then the user themselves would indeed renew the ticket on their workstation, but reauthentication on the central weblogin server would usually happen invisibly, without the user being aware of it, and you would not be having the situation you describe -- which is the basis of my assumption that you are not using SPNEGO in your environment). -- Mark Montague m...@catseye.org ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
