> It's the difference between an authentication method and using a TGT > to obtain service tickets.
Ah, okay, yeah, I don't have cosign do anything with tickets itself, I just use krb5 for authentication (which gets a TGT to do so, as I understand it). However, it sounds like this means what Mark was saying is that once cosign has authenticated the first time (whether with krb5 or ldap or whatever), that it handles lifetimes itself, it doesn't look at the ticket lifetime at all? So, I could give the TGT an 8 hour lifetime but if cosign's soft and hard limits were longer, the user would stay logged in just fine, right? If so, that's an issue I'd have to deal with if I do this renewable thing at some point, since I want the krb5 lifetime to set the hard timeout so it's controllable from a single place. > So you'd like something like, e.g., Google's "Stay signed in" > option? Users would remain logged in for a week or more? Sort of, I guess, but I'd like the ability to revoke the credentials by setting -allow_tix in the kdc, and then the next time the ticket is renewed it'll fail and the user will get kicked. So, I don't want to bother them with a password prompt very often if they're in good standing, but I want (centralized) banning so I can kick them quickly (within the main ticket lifetime is fine, I understand the entire krb5 model makes banning slightly problematic for extant valid tickets, plus I can always manually clear cosign's cookie db if there's a really abusive user who needs an insta-ban, I assume). This implies short ticket lifetimes, but renewable tickets, or, at least, that's the way you implement this in krb5. I'm actually making the assumption that -allow_tix on a princ will fail a renew, I haven't tested it yet, but that'd be crazy if it didn't and patch-worthy, but that's a different mailing list. :) Chris On 2012/11/27 11:42, Andrew Mortensen wrote: > > On Nov 27, 2012, at 2:08 PM, Chris Hecker <chec...@d6.com> wrote: > >> >>> 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? > > It's the difference between an authentication method and using a TGT to > obtain service tickets. > > Many cosign-protected institutions use krb5 for authentication on the > weblogin server. Fewer actually use the TGTs generated by that > authentication. With the correct configuration, the filters can be permitted > to retrieve the TGT from the weblogin server, and use it to obtain service > tickets for other services. > > ** Most of the time, you do not want to do this. ** > > But there are times it may be required. For example, webmail may need to use > krb5 to authenticate the user to the mail servers. The webmail service > administrators would configure mod_cosign to retrieve kerberos tickets, and > arrange with the weblogin administrators to permit the webmail mod_cosign to > grab the user's TGT. The webmail application can then use the TGT to grab a > service ticket for the mail servers. > > Cosign's all-or-nothing approach to handing out TGTs is not ideal. I have > been working on permitting mod_cosign to request service tickets from the > weblogin server, which should make this feature less sensitive. > >> 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). > > Yes, solving the POST issue is complicated. > >> 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. > > So you'd like something like, e.g., Google's "Stay signed in" option? Users > would remain logged in for a week or more? > >> I'll obviously contribute changes back if I make them. > > That would be great. > > Best, > andrew > > > >> >> 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 > > ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
