On Nov 27, 2012, at 3:00 PM, Chris Hecker <chec...@d6.com> wrote: > >> It's the difference between an authentication method and using a TGT >> to obtain service tickets. > > 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?
Yes. As a matter of fact, you can tell the cgi not to store tickets at all using the cosignstoretickets setting in the cosign.conf. In cosign, the authentication method doesn't matter to the weblogin server; TGTs are stored purely because some service might want them. The *services* indicate what sort of authentication they deem acceptable with CosignRequireFactor. The default is to accept anything as long as the weblogin server says the service cookie is good. Cosign itself is somewhat analogous to Kerberos. The weblogin cookie is the TGT. Service cookies tied to the weblogin cookie are service tickets. With that in mind, reconsider what Wes was saying about authorization. You're thinking of setting -allow_tix on a principal so they can't log into cosign. That'll work, and it'll work now without modifying cosign. What Wes was saying is that you want some form of authorization check done on the weblogin server, some way of disabling authentication based on the username. No? andrew > > > > > 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 ------------------------------------------------------------------------------ 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
