[PATCH] Refactored authentication mechanism

[Rede <redetin@…>]

Refactored authentication mechanism to make it possible to add custom authenticators instead always to rely on HTTP authentication mechanism.

[Rede <redetin@…>]

Patch for authentication system refactoring

[anonymous]

I was actually about to submit a similar patch, but I'm glad to see that you beat me to it.

We use ​CAS to secure our web-based applications, and I've patched Trac 0.8 to work with it. However, I'd much rather have our authentication handler be available as a plugin.

Are the following all that I'd have to do to get a CAS authentication module working?

• Create a CASLoginModule class that implements the same functionality as LoginModule (but using CAS instead of HTTP auth)
• Disable LoginModule in the [disabled_components] section of trac.ini

[Rede <redetin@…>]

Yes that is correct. In most cases you can copy "authenticate" method from auth.py and call standard_logout in logout url. Only thing you need to do is check that userlogin is valid, and if it's valid set req.authname to user and call standard_login function.

[anonymous]

I've just finished refactoring the authentication stuff in trac.web without actually having looked at your patch. Honestly forgot about it :-P Interestly, our approaches are pretty similar.

I'm going to check my stuff in, though, and I suspect that it actually addresses the issue raised here, i.e. being able to replace the HTTP authentication by form-based login.

[Christopher Lenz]

Sigh. Previous comment was by me.

[Christopher Lenz]

Please check whether the changes in [2078] are enough for your use case. Reopen this ticket if you think something is missing. Thanks!

[Bruce Christensen <trac@…>]

I've reviewed the changes in [2078], and they're almost sufficient. However, I need a way to pre-process requests before the actual request handler is called to (possibly) do transparent authentication for each request, due to the way that CAS works.

If you don't want to read the book I wrote below, just take a look at the patch I've attached. It sums up things nicely.

CAS is a central web-based login system that runs on its own server. Individual applications redirect the user agent to the CAS server, but pass along a "callback URL" that CAS uses to send the user back when it's done. The CAS server uses a cookie set on its domain to remember when a user has been authenticated to provide "single sign on". When CAS redirects the user to the "callback URL", it also passes along a a random authentication ticket (just a random string). The application's server (not the user's browser) then connects to the CAS server to make sure that the ticket is valid. If it is, the app sets a cookie on its site so that it also remembers that the user is authenticated.

Here's where the need for request preprocessing appears:

1. The user accesses an application (other than Trac) that requires CAS authentication. That app redirects the user to CAS, which authenticates the user, sets a "user is authenticated" cookie, and redirects the user back to the original application, which now grants the user extra privileges.
2. Some time later, the user accesses Trac, but not at the login URL. She has already logged in to CAS, but Trac doesn't know that, so it thinks she's not logged in. If she logs in to Trac, Trac will send her to CAS, which will see the "user is authenticated cookie" and send her right back, at which point she'll be logged in to Trac.

Rather than have the user have to manually log in to Trac after she's already logged in to CAS, I'd like to have Trac do this automatically if it hasn't already tried. Here's what would happen instead:

1. The user accesses an application (other than Trac) that requires CAS authentication. That app redirects the user to CAS, which authenticates the user, sets a "user is authenticated" cookie, and redirects the user back to the original application, which now grants the user extra privileges.
2. Some time later, the user accesses Trac, but not at the login URL. The authentication module's request preprocessing handler is called. It checks a cookie to see if passthrough authentication has been attempted already, and sees that it hasn't. Since it hasn't been tried, it redirects the user to the CAS server for authentication. CAS sees that the user has already been authenticated and redirects her browser back to Trac with an authentication ticket. Trac sees the ticket, verifies it, and logs her in. This all happens automatically.

If the user wasn't already logged in to CAS, the transparent authentication attempt would still happen, but CAS would send the user's browser back to Trac with a message that says "she's not authenticated". Trac would set a cookie to remember that it tried transparent authentication and redirect the user back to the page she originally requested.

[Christopher Lenz]

It's not entirely clear to me why you can't do this preprocessing in the authenticate() method of your CAS-based IAuthenticator implementation. Can you clarify that?

If we add request preprocessors/filters, we'd need to also figure out a way to order them deterministically. Your patch will simply execute them in the order they've been imported (and thus registered). Or should we simply say that request filters may not depend on each other in any way?

[Bruce Christensen <trac@…>]

Sorry. I'm an idiot. :) The authenticate() method will work just fine. I don't know how I missed that.