Peter Mogensen <[email protected]> writes: > A web-application can renew an app-token any time extending an > application session. Renewing the Kerberos TGT in the webkdc-proxy > token however requires the user visiting the WebKDC. So for extended > periods of idle time the SSO session might expire before the application > session (given that the app-token has been refreshed in the mean time).
Correct. Note that the mod_webauth implementation will never do this, however; mod_webauth implements an authentication scheme wherein all authentication credential lifetimes are bounded by the lifetime of the original TGT, and nothing will outlive the original TGT lifetime. (This is intentional; I consider it an important feature.) The app-token is entirely local to the WAS, so you *can* do anything you want with it, including not use it at all and maintain your own session information. It's a purely optional part of the WebAuth protocol. The intent of the WebAuth implementation, however, is that if you do use it in the default way you get the most reasonable and secure default behavior, namely credential lifetime that matches the default behavior of Kerberos. > That would be fine, however - IFF the application decides to embed the > Kerberos service ticket from the id-token in the app-token, to (say) be > able to do S4U2proxy request for further delegated credentials, it would > have no way to renew that service ticket before timeout unless it forces > the user to visit the WebKDC. Right, because in the Kerberos authentication model that ticket belongs to the user, not to the server. If the server could arbitrarily extend its lifetime without requiring the user to be present, then Kerberos ticket lifetimes would be meaningless for S4U2proxy, which would be a significant security flaw. You would lose central control of those tickets; any server to which a user has ever authenticated would be able to use S4U2proxy for that user forever. > But we don't know in advance when the user will become idle, so we don't > know when to do that. Sure, but that's true of all Kerberos authentications. If the user goes idle, then the session is going to expire. I consider this a feature, not a bug; idle sessions are possibly stolen sessions, particularly in the web world. > Also,... renewing the basic app-token requires no special external > interaction from the application web-server, but renewing the Kerberos > service ticket do. ... and it would be preferable not to do that in > every request just to be sure it's renewed "as much as possible". > Wouldn't that effectively force you to operate with very long life times > for Kerberos service tickets if your application needs them to be valid > at some point during the application session? Honestly, my gut reaction here is "your application design is flawed" if you expect to be able to do constrained delegation for users, without requiring the user reauthenticate, when the user has been idle past the boundary of a TGT expiration. One of the core security features of Kerberos is that you don't get arbitrary open-ended authentication times. Everything goes away at the lifespan of the TGT unless the user (not the application) takes explicit action to renew their credentials. This is how Kerberos gets away with not having any ticket revocation capability. Because everything is limited in lifespan, the amount of damage done by a stolen ticket is limited to that lifespan and all authentication credentials can be revoked within that lifespan without requiring everything constantly check a revocation list. All that said, there is a feature on the WebAuth roadmap that I think may address this problem sufficiently that it would minimize the problem you're worried about: * WEBAUTH-49: Provide a way to force reauthentication of a user who has valid credentials but ones that are about to expire, and apply it only to GET requests and not POST requests. This would be useful for wikis, for example, where expired credentials will usually destroy whatever work the user is trying to save. My original intent here was to allow the WAS to force reauthentication when it knows that the user is about to do something that may take a while, such as edit a wiki page, and the credentials are in danger of expiring during that action. But I think it might help with this situation as well. > Also, considering the WebAUTH protocol support for credential delegation > by using proxy tokens I was wondering if that could be replaced by > S4U2proxy support on the Kerberos level - thus making it the same > mechanism used to delegate throughout the Kerberos infrastructure. Yes. S4U2proxy is very new, much newer than the WebAuth protocol itself, so WebAuth was not designed with it in mind. But you could indeed replace the whole proxy/cred token system with S4U2proxy, provided that your KDC had good enough ACLs on that capability. You would lose a UI feature that WebAuth currently has, where the WebLogin server warns the user what credentials the WAS will be able to obtain on their behalf, but you could re-add that by adding some sort of API for the WebLogin server to query the KDC-side ACL. Note that S4U2proxy isn't supported until MIT Kerberos 1.8 and I'm not sure the status of support in Heimdal. I'm also not sure exactly how you configure the KDC-side ACLs (the equivalent of WebAuth's token.acl). -- Russ Allbery <[email protected]> Technical Lead, ITS Infrastructure Delivery Group, Stanford University
