bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Gamache <cgama...@gmail.com>
Subject Re: Help for alternate authentication module
Date Tue, 14 May 2013 13:10:46 GMT
Thanks for the detailed response. After I finish this email I'll dig in and
digest all those links.

Bloodhound will be running in conjunction with the other apps running
within the enterprise. Our applications keep track of authenticated users
using a cookie-based "token" ... I'd like to be able to allow users to
authorize with the standard application authorization page and transition
back and forth from Bloodhound to our application without having to
re-login or maintain two separate credential stores. It looked like there
was only one place I would have to override to make this happen and I could
do it transparently.

Ultimately, I want to hook Bloodhound into our oAuth 2.0 fabric. We're
slowly converting away from the cookie token in favor of oAuth 2.0. I fear
that would require more customization to the codebase than the simple
cookie token would (storage for tokens/refresh tokens, redirects to
out-of-band authentication forms, re-authorization, etc.). The plan was to
take baby steps and dig in on oAuth after Bloodhound is well established
within our application suite.








On Tue, May 14, 2013 at 5:05 AM, Ryan Ollos <ryan.ollos@wandisco.com> wrote:

> On Mon, May 13, 2013 at 9:54 AM, Chris Gamache <cgamache@gmail.com> wrote:
>
> > Is it possible to hook in an alternate authentication scheme to
> bloodhound?
> > I've tried to implement a custom IAuthenticator per
> > http://trac.edgewall.org/wiki/TracStandalone which looks at a cookie to
> > determine allow/deny, and I must not be doing it right. It seems like it
> is
> > not even getting called...
> >
>
> Hi Chris,
>
> I think that you'd have to disable all of the other components that
> implement IAuthenticator, including the one from AccountManagerPlugin.
>
> In a standard Trac setup, trac.web.auth.LoginModule is the enabled
> IAuthenticator component [1], and RequestDispatcher returns the authname of
> the first IAuthenticator that returns an authname that is not None [2].
>
> When AccountManagerPlugin is installed, trac.web.auth.LoginModule is
> disabled and AccountManager's LoginModule component is enabled, which
> inherits from trac.web.auth.LoginModule and overrides the authenticate
> method [3]. One possibility is that AccountManager's LoginModule is being
> called first and granting authentication before your IAuthenticator is
> called.
>
> However, I'm not sure you should be performing authorization inside an
> IAuthenticator. It looks to me that this is the job of the IPasswordStore
> implementation. I don't have a good picture of what you are trying to do,
> but it might make sense to implement an IPasswordStore even if you aren't
> technically storing any passwords. You can see how some plugins have
> implemented IPasswordStore's for the AccountManager on trac-hacks [4].
>
> Could you provide some more details about exactly what you are trying to
> do?
>
> [1]
>
> http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/auth.py?marks=85-99#L43
> [2]
>
> http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/main.py?marks=133-139#L83
> [3]
>
> http://trac-hacks.org/browser/accountmanagerplugin/trunk/acct_mgr/web_ui.py#L279
> [4] http://trac-hacks.org/tags/%27authentication%27
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message