Peter Mogensen <[email protected]> writes: > On 2012-09-04 19:09, Russ Allbery wrote:
>> 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.) > But still... if you issue service tickets with a shorter life time than > the TGT and store them in the app-token, they might need to be renewed, > which require the webkdc-proxy-token. By either a redirect to the WebKDC > or a mehanism similar to the proxy-token (just not issuing delegated > credentials, but renewing the service-ticket). Yes, that's true. You have to have the proxy token on hand to renew any of the cred tokens. That sort of credential renewal process isn't something that we anticipated as part of the original WebAuth design, in part because Stanford uses some very uniform policies around ticket lifetime. >> Right, because in the Kerberos authentication model that ticket belongs >> to the user, not to the server. > Well.. strictly speaking it belongs to the Weblogin service, since each > time it receives it, it can act as the user. Sort of. It's actually the WebKDC rather than WebLogin in this case, which I mention only because that's the intended protocol model: the WebKDC is equivalent to a Kerberos KDC in most respects. So the WebKDC does "own" all of the tickets handled via WebAuth in the same sense that the Kerberos KDC owns all of the tickets for your realm, but it's really intended to be thought of as a trust broker that handles the Kerberos protocol. The delegation model implemented by proxy and cred tokens is very similar to S4U2proxy, with the proxy token playing the role of the service ticket in Kerberos and the cred token playing the role of the obtained user credentials. As with S4U2proxy, any given server has to wait for the user to present the service ticket to that service before it can use that service ticket to obtain delegated credentials to act on the user's behalf, and the lifetime is bounded by the lifetime of the original credentials presented by the user. One thing that is different, forced by the way that the web protocols work, is that the process of reauthenticating a user when the service ticket has expired but the user's single sign-on credentials have not is much more heavy-weight on the web than it is with Kerberos proper, and is not entirely transparent to the user. (And doesn't work at all with HTTP methods other than GET.) >> 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. > Yes, ... but having no externally issued auth data in its session cookie > a web-application can normally relative costless renew a session cookie > on any activity and ensure expiry only after a certain amount of idle > time. What I'm looking for is a way to do that, which (I realize) might > be impossible. WebAuth is happy with this... *if* you don't have delegated credentials. As long as there are no delegated credentials, WebAuth is happy for you to go your merry way once you've gotten the authentication information. mod_webauth provides an application session implementation mostly for the sake of convenience, but you can safely ignore it (you just will lose the ability to have Apache do the session management and authentication or authorization verification for you). With delegated credentials, I'm not sure there's a way to do this right now. I think you'd encounter the same problem with S4U2proxy, actually, although I suppose with it you could handle the somewhat narrower case of a service ticket with a shorter lifespan but which is renewable. > If the session contains something important over which expiry the > application has no control (like a Kerberos service ticket) without > constantly involving the WebKDC in a costly renewal process this can't > be done. Yes, I think that's correct. > Sure... but it might be impossible to the user to predict the length of > tolerated idle time if even short idle time starting just before the TGT > expiry can result in session termination. Yeah, indeed. > I know it's wishful thinking on my part, but I guess most users would > think of it as a better user experience, if timeouts were only dependent > on how long time you were idle and not when you were idle. Yeah, I definitely agree with that. Note, though, that this feature: >> 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. would basically let you establish the minimum idle time that you want to not interrupt the session, by letting you always refresh the session if only that much or less time is remaining and the user is not idle. However.... > Partly. > I think it's a good idea, but wouldn't that only work if you are GET'ing a > HTML doc? ... it wouldn't work for AJAX applications only making request > for data. ...it does only work with GET. It should work with GET even from an AJAX application, *provided* that the user doesn't need to do an interactive login, but of course if the reason why the session is expiring is because the user's single sign-on credentials are expiring, that doesn't help. In that case, you need the whole browser to participate. Note that WebAuth does put the expiration time of the credentials in the environment, so your application could make use of that data plus the above feature to do its own forced refresh under its control if need be. See the WEBAUTH_TOKEN_EXPIRATION environment variable. That, though, only works if you have control over the application code. > ...and the redirect would make you loose any javascript state, so you > would have to think about when to do it and serialize everything > important into the applications state. Indeed. > Loosing that feature might be OK in a lot of scenarios where the user > don't even know that there's a speciel backend server involved. > ... which it seems is exactly what MS describes in MS-SFU as a feature > of S4U. Right. It depends on what sort of philosophy you want to take to user notification. WebAuth currently makes that somewhat configurable. It does expose its roots at a university, where we have a wide variety of different web sites run by different people and don't present a unified front or expect users to treat us all as one security entity. > One thing I don't understand about S4U is that S4U2self has no option > for the service to actually prove that it is in session with an > authenticated user. > The fact that S4U2self with PA-FOR-USER allows a service just to demand > a ticket makes it unsafe to combine with S4U2proxy. That would allow any > service with access to both these protocols to get credentials to others > services at any time. I'm not horribly familiar with how all this stuff works, but I would have expected the KDC to embed into the service tickets it issues some marker that it can use to confirm that it issued that ticket via a user AS-REQ or TGS-REQ rather than via S4U2self. I seem to recall that the Microsoft implementation uses the signed PAC information for that purpose? I don't know if it puts the same signed PAC information into S4U2self tickets in the same way. -- Russ Allbery <[email protected]> Technical Lead, ITS Infrastructure Delivery Group, Stanford University
