Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
On 27 Nov 2012, at 14:08, Chris Hecker chec...@d6.com wrote: 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? That's definitively not how kerberos works. In fact, the password is not sent to the KDC to obtain credentials. Instead, credentials are requested (typically an encrypted request is sent), and encrypted credentials are returned. If you can decrypt the credentials, then you may use them. Further, cosign immediately attempts to use the credentials by requesting a service ticket. This tests whether the KDC itself has been spoofed. 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. If you aren't use kerberos beyond initially validating the user password, then renewing kerberos tickets buys you nothing. 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. Seems like this is actually your problem, not renewable kerberos tickets. 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). True, but setting the idle timeone = hard timeout is exactly how this case gets exercised. 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 would think this case would be handled in an authorization step, rather than during authentication. :wes -- 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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
On 27 Nov 2012, at 14:08, Chris Hecker chec...@d6.com wrote: 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? That's definitively not how kerberos works. In fact, the password is not sent to the KDC to obtain credentials. Instead, credentials are requested (typically an encrypted request is sent), and encrypted credentials are returned. If you can decrypt the credentials, then you may use them. Further, cosign immediately attempts to use the credentials by requesting a service ticket. This tests whether the KDC itself has been spoofed. 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. If you aren't use kerberos beyond initially validating the user password, then renewing kerberos tickets buys you nothing. 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. Seems like this is actually your problem, not renewable kerberos tickets. 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). True, but setting the idle timeone = hard timeout is exactly how this case gets exercised. 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 would think this case would be handled in an authorization step, rather than during authentication. :wes -- 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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
That's definitively not how kerberos works. In fact, the password is not sent to the KDC to obtain credentials. Yeah, sorry, I meant the krb5 API that cosign talks to, I know how kerberos works at the protocol level and that credentials aren't passed over the wire, etc. I just meant it gets tickets to authenticate. Seems like this is actually your problem, not renewable kerberos tickets. I think this is an oversimplification, but hopefully my other mail explains the use case more clearly. I would think this case would be handled in an authorization step, rather than during authentication. Not sure exactly what you mean here. Kerberos doesn't do authz, yet it still has allow_tix and whatnot, so the line is a little blurry already, and the feature I want is on the authn side of the line (as far as krb5 is concerned). I don't need fancy authz stuff like acls, just the ability to ban somebody by setting -allow_tix and have that be respected by everybody who's using krb5 to authenticate my users. Chris On 2012/11/27 11:56, Wesley Craig wrote: On 27 Nov 2012, at 14:08, Chris Hecker chec...@d6.com wrote: 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? That's definitively not how kerberos works. In fact, the password is not sent to the KDC to obtain credentials. Instead, credentials are requested (typically an encrypted request is sent), and encrypted credentials are returned. If you can decrypt the credentials, then you may use them. Further, cosign immediately attempts to use the credentials by requesting a service ticket. This tests whether the KDC itself has been spoofed. 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. If you aren't use kerberos beyond initially validating the user password, then renewing kerberos tickets buys you nothing. 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. Seems like this is actually your problem, not renewable kerberos tickets. 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). True, but setting the idle timeone = hard timeout is exactly how this case gets exercised. 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 would think this case would be handled in an authorization step, rather than during authentication. :wes -- 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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
On November 27, 2012 16:17 , Chris Hecker chec...@d6.com wrote: I think the only changes to cosign would be: - on first login, make the hard limit for this session min(-H, tgt lifetime) - get renewable tickets if an option is set - before kicking the user to the login screen on timeout, try to renew the ticket, if the backend doesn't support renewing or you're not saving tickets or the renew fails, go to login screen, same as current behavior Requiring a user to reauthenticate after a given period of time (the hard timeout) is one of the design requirements for cosign. What you are proposing would provide a way around this. Which is fine, if this is what you want, I'm just explaining why cosign doesn't already support it. This can happen under the hood so a POST doesn't get eaten and the user never knows it happened, and so the user experience is way better Some care would be needed here. The user will be redirected to the central weblogin server for the ticket renewal. If the renewal is successful, they will not be served any content from the central weblogin server and will be redirected back to the original URL they requested on the cosign-protected web server. Hopefully the POST data would get preserved through this, but I'd have to actually try it. Right? I mean, why would I need an additional authz thing for this, that I'd have to maintain separately, etc., it's just basically exactly how kerberos is supposed to work for renewable tickets, and it's a small change for cosign. Unless I'm missing something? Mostly because you'd be building in a special case that could only apply if an institution used Kerberos with cosign, whereas handling this as authz is more general and would work for all institutions. For the use case of kicking off users, I suggest a two-step process, which is actually what I used to do at the University of Michigan when I was involved with the central weblogin servers for them: 1. Disable the user's Kerberos principal to prevent further logins. 2. On each central weblogin server, delete any file form the cookie database containing the user's name on the p line. The very next time any cosign-protected webserver checks in with the central weblogin server (which happens every request or 60 seconds after the last check, whichever is longer), the user will be immediately kicked off. This has the advantage that the user does not continue to have access to cosign-protected web services until their current ticket expires; they are completely locked out of all cosign-protected web servers within a maximum of 60 seconds. -- Mark Montague m...@catseye.org -- 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
Re: [Cosign-discuss] using renewable krb5 tickets instead of kicking to login page?
Requiring a user to reauthenticate after a given period of time (the hard timeout) is one of the design requirements for cosign. What you are proposing would provide a way around this. But this isn't true, renewable tickets aren't renewable forever. It is just a more secure way of allowing longer ticket lifetimes than just setting the regular lifetime to a week or whatever. It's not a fundamental change (from the user's perspective). Some care would be needed here. The user will be redirected to the central weblogin server for the ticket renewal. Ah, yeah, I don't think POSTs can live across redirects. This would have to happen before the redirect on the initial apache handling of the request, completely under the hood. Is there something preventing that from working? Mostly because you'd be building in a special case that could only apply if an institution used Kerberos with cosign, whereas handling this as authz is more general and would work for all institutions. I wonder what percentage of cosign installations use krb5 for authentication, do you have any metrics? Special cases aren't inherently bad, it depends on how special it is. Of course, no one but me has asked for this obviously, given this thread's length. :) For the use case of kicking off users, I suggest a two-step process, Yeah, I mentioned this as well, it would just be nice to be able to use the krb5 feature underneath for the usual case. Anyway, I feel like we've got the major points out. If I end up taking a look and if there's a clean way to do this that preserves the POST and everything, I'll send in a patch. Chris On 2012/11/27 15:13, Mark Montague wrote: On November 27, 2012 16:17 , Chris Hecker chec...@d6.com wrote: I think the only changes to cosign would be: - on first login, make the hard limit for this session min(-H, tgt lifetime) - get renewable tickets if an option is set - before kicking the user to the login screen on timeout, try to renew the ticket, if the backend doesn't support renewing or you're not saving tickets or the renew fails, go to login screen, same as current behavior Requiring a user to reauthenticate after a given period of time (the hard timeout) is one of the design requirements for cosign. What you are proposing would provide a way around this. Which is fine, if this is what you want, I'm just explaining why cosign doesn't already support it. This can happen under the hood so a POST doesn't get eaten and the user never knows it happened, and so the user experience is way better Some care would be needed here. The user will be redirected to the central weblogin server for the ticket renewal. If the renewal is successful, they will not be served any content from the central weblogin server and will be redirected back to the original URL they requested on the cosign-protected web server. Hopefully the POST data would get preserved through this, but I'd have to actually try it. Right? I mean, why would I need an additional authz thing for this, that I'd have to maintain separately, etc., it's just basically exactly how kerberos is supposed to work for renewable tickets, and it's a small change for cosign. Unless I'm missing something? Mostly because you'd be building in a special case that could only apply if an institution used Kerberos with cosign, whereas handling this as authz is more general and would work for all institutions. For the use case of kicking off users, I suggest a two-step process, which is actually what I used to do at the University of Michigan when I was involved with the central weblogin servers for them: 1. Disable the user's Kerberos principal to prevent further logins. 2. On each central weblogin server, delete any file form the cookie database containing the user's name on the p line. The very next time any cosign-protected webserver checks in with the central weblogin server (which happens every request or 60 seconds after the last check, whichever is longer), the user will be immediately kicked off. This has the advantage that the user does not continue to have access to cosign-protected web services until their current ticket expires; they are completely locked out of all cosign-protected web servers within a maximum of 60 seconds. -- Mark Montague m...@catseye.org -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
