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
