> 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 <[email protected]> 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 > [email protected] > > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
