> Except: the tickets obtained by cosign (*) are not being used to > authenticate the user to cosign.
This part confuses me. I'm not using SPNEGO, this is all on the cosign side, but if I've got cosign set up to use krb5 as the authentication backend, how is it not using tickets to authenticate in some sense? In other words, it takes the user's credentials, passes them to the KDC, and if a TGT comes back, the user is authenticated, right? How else could it work? I understand what you're saying about how the other backends not supporting renewable authentication would make this a kerberos-specific feature, but I thought using kerberos for the authentication backend was pretty common with cosign. > 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. Yeah, I thought about this as I was typing my reply but forgot to include it in the mail...maybe I'm making it worse by slamming both to 24 hours, like you say. At least, if the soft timeout expires, they'll have to get a fresh ticket and reset the clock. I'll do this first, since it's relative easy, thanks. > However, you could modify cosign to do this, if you want. I will probably do this at some point to get the experience I want if the soft timeout thing doesn't totally fix it. It will at least push the corner case to the renewable lifetime rather than the ticket lifetime and I figured it wouldn't be too hard (which is why I was confused that it didn't work this way already). > 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. Yeah, but that's the point, right? If the user is checking back in often enough to not trigger the soft timeout, they'll eventually hit the hard timeout and potentially get screwed (bad experience at best, lose data on a POST that straddles the hard timeout at worst). The high level use case here is I want short lifetimes so I can revoke credentials effectively/quickly, but I want good user experience for valid users, which means infrequent login prompts. The risk for me is not somebody sitting down and a workstation and using somebody else's login, the risk is banning a user and them continuing to have access, so I want short lifetimes and renews to fail if they're banned. It seems like this use case would not be too hard for cosign to support. I'll obviously contribute changes back if I make them. Chris On 2012/11/27 10:41, Mark Montague wrote: > 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
