Edgewall Software
Modify

Opened 19 years ago

Closed 19 years ago

#1855 closed enhancement (fixed)

[PATCH] Refactored authentication mechanism

Reported by: Rede <redetin@…> Owned by: Christopher Lenz
Priority: low Milestone: 0.9
Component: general Version: devel
Severity: normal Keywords:
Cc: trac@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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

Attachments (2)

AuthProvider_refactor_r2036.patch (11.5 KB ) - added by Rede <redetin@…> 19 years ago.
Patch for authentication system refactoring
preprocessor_r2165.patch (1.8 KB ) - added by Bruce Christensen <trac@…> 19 years ago.

Download all attachments as: .zip

Change History (12)

by Rede <redetin@…>, 19 years ago

Patch for authentication system refactoring

comment:1 by anonymous, 19 years ago

Cc: brucec added

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

comment:2 by anonymous, 19 years ago

Cc: trac@… added; brucec removed

comment:3 by Rede <redetin@…>, 19 years ago

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.

comment:4 by anonymous, 19 years ago

Milestone: 0.9
Owner: changed from Jonas Borgström to anonymous
Status: newassigned
Type: defectenhancement

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.

comment:5 by Christopher Lenz, 19 years ago

Owner: changed from anonymous to Christopher Lenz
Status: assignednew

Sigh. Previous comment was by me.

comment:6 by Christopher Lenz, 19 years ago

Status: newassigned

comment:7 by Christopher Lenz, 19 years ago

Resolution: fixed
Status: assignedclosed

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

comment:8 by Bruce Christensen <trac@…>, 19 years ago

Resolution: fixed
Status: closedreopened

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.

by Bruce Christensen <trac@…>, 19 years ago

Attachment: preprocessor_r2165.patch added

comment:9 by Christopher Lenz, 19 years ago

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?

comment:10 by Bruce Christensen <trac@…>, 19 years ago

Resolution: fixed
Status: reopenedclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christopher Lenz to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.