On 5/17/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Dave wrote:
> On 5/17/07, Matt Raible <[EMAIL PROTECTED]> wrote:
>> I can't argue with 1 or 3, but #2 seems to mean that users will be
>> required to use a container that supports OpenSSO or OpenID in order
>> get those features. Acegi has OpenID support in its sandbox. When
>> that's released, we can integrate it and support OpenID across all app
>> servers, not just the ones that support it. Of course, if the mission
>> of OpenSSO is to provide a CMA Adapter for all containers, the point
>> is mute.
>
> Yes, that's the idea -- everything should be done via standard CMA so
> that Roller can take advantage of the authentication features that are
> built into app servers.
My take on the situation is that CMA is the least desirable option :/ I
have always hated CMA and felt it lacked the ability to really create a
streamlined authentication experience and I am definitely a fan of any
other option. So my preference is definitely to keep Acegi as the
default option for app authentication.
I agree, CMA needs to be fixed and I hope it will be in future revs of
the Servlet spec but that's not going to help us now.
Like the options with app installation I think that the ideal solution
is to provide a solid default option which covers most cases as easily
as possible (Acegi) but allows for alternate configurations if they are
desired (CMA). So I think the best way to try and do this is to keep
Acegi as the default authentication provider but allow users to disable
it via a config setting and indicate that they plan to setup their own
authentication via CMA or possibly some other solution.
I will admit that I am also not a fan of requiring users to hack the
security.xml file to make authentication configurations, but I would
think we could find some way of fixing that by either allowing people to
enter their settings in our config file and we use it to apply the
options to Acegi (like we do with remember me stuff).
Matt mentioned that doing remember me via CMA can be tricky, so that's
one gotcha with that approach. Another one to consider is ajax based
authentication, which is something that we need to start thinking about
now. I sent out an email about this on the list a week or two ago where
I talked about how there are some new challenges with the way
authentication is triggered once we introduce asynchronous components
into our pages and my gut feeling is that CMA would probably make this
even more difficult. Hopefully that is not the case, but it's something
to be thinking about because I would hate to spend a fair amount of time
going down that road just to find out that when we start building in
more ajax stuff that it breaks the CMA option.
That would work for me. Leave Acegi in, but make sure that it is
possible for folks to configure CMA as an alternative. At this point,
I'm definitely -1 to anything that would prevent use of CMA.
- Dave
