On 15 May 2013, at 11:24, Ryan Ollos <[email protected]> wrote:
> On Tue, May 14, 2013 at 6:10 AM, Chris Gamache <[email protected]> wrote: > >> 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. > > > The AuthOpenIdPlugin might be worth looking at as an example, > https://github.com/dairiki/authopenid-plugin Would it make sense to also deploy that plugin for our http://issues.apache.org/bloodhound issue tracker? That may make it easier for users to raise bugs and get involved without Yet-Another-Registration™ I have little experience with deploying Open ID, but I believe we can still discover email addresses (for notifications) with the users permission in many cases. Just trying to lower the barrier to entry :)
