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
