> 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. 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. 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. Maybe I'm misunderstanding something, but the current behavior seems like it's providing no extra security but provides a worse user experience. Chris On 2012/11/27 07:11, Mark Montague wrote: > On November 21, 2012 15:08 , Chris Hecker <chec...@d6.com> wrote: >> I have a forum that uses cosign and kerberos, and every day people need >> to log back in (I have 24 hour ticket lifetimes), but worse, if they are >> in the middle of doing something and the ticket expires, they get kicked >> to the login page as well, which is not great user experience. >> >> Most websites have the concept of a timeout based on activity, which is >> obviously different from what's going on here, but I'm wondering if >> renewable tickets would reduce this issue. Will cosign renew tickets if >> I set them all to renewable? Or, is there any aspect of cosign that >> tracks activity rather than just ticket lifetime? > > Hi, Chris, > > cosign has two types of timeouts: > > - Soft (or "idle") timeout. This is a timeout based on (lack of) > activity. This is specified by the "-i" option to cosignd and defaults > to 7200 seconds. > > - Hard timeout. After this amount of time, the user will be forced to > reauthenticate, regardless of activity, and regardless of whether the > user has Kerberos tickets or the amount of time the Kerberos tickets are > valid. The hard timeout is specified via the "-H" option to monster and > defaults to 12 hours. > > There are also a number of other relevant options documented in the > monster(8) man page. > > Requiring users to log back in (reauthenticate) is one of the design > goals of cosign, from a security perspective. Generally, you'll want to > chose the timeout and (if using services which consume proxied Kerberos > tickets) Kerberos ticket lifetime numbers so that most users will not > have to reauthenticate during the course of a single work session, but > will have to reauthenticate between work sessions or after an extended > time away from their authenticated browser sessions; the default timeout > values were chosen with these goals in mind. > > Keep in mind that the default operating mode of cosign is without > Kerberos tickets. If you have cosign get Kerberos tickets for users, > then their lifetimes impose additional restrictions on top of the > lifetimes of the cosign credentials, when dealing with cosign-protected > services that use these tickets. You'll therefore usually want to > ensure that your default ticket lifetime is equal to or greater than the > cosign hard timeout. > > Also, when cosign gets Kerberos tickets, the authentication between > cosign and Kerberos is a one-time event. Thereafter, the Kerberos > tickets are not used to prove the user's identity to cosign, they are > proxied to cosign-protected web services so that those web services can > act on behalf of the user (for example, cosignd will pass the user's > Kerberos tickets to a webmail service so that the webmail service can > authenticate as the user to back-end IMAP and SMTP services via SASL and > GSSAPI). Hence renewing the Kerberos tickets would not have the effect > you are looking for (and, in any event, cosign currently explicitly > requests non-renewable tickets). > > If you want -- for example -- to loosen security so that users can > remain logged in for a full week without reauthenticating, then set the > cosign hard time out to 1 week, and set the cosign idle timeout to > something appropriate (say, 28 hours). If you get Kerberos tickets, > then make sure that the default TGT and service ticket lifetimes are 1 > week, too -- in addition to making sure that your KDC and krb5.conf are > configured to allow this, you'll need to set the cosignticketlifetime > directive in cosign.conf appropriately, since cosignticketlifetime > defaults to 10 hours. > > I hope this helps. > > -- > 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
