On 5/17/07, Dave <[EMAIL PROTECTED]> wrote:
On 5/17/07, Matt Raible <[EMAIL PROTECTED]> wrote:
> The problem with ditching Acegi is we have to add back in our own
> custom Remember Me and SSL Switching logic. Also, you'd have to
> document how to create a JDBC Realm for each application server.
> Why do you like CMA better than Acegi? Because IBM is using it?
You laugh ;-) but the fact that IBM is doing does tell us something.
Here's why I like CMA better:
1) CMA can be configured without editing files inside the WAR.
2) CMA allows us to take advantage of the nice authentication stuff
that is now built into app servers, e.g. In my builds, I may be
required to take advantage of the OpenSSO/OpenID stuff that is being
built into Glassfish (via standard CMA).
3) One less jar on the classpath ;-)
Yes, we'll have to implement our own remember me and SSL switching,
but IMHO that's easier than the ugliness of security.xml.
But again, I'm not proposing removing Acegi at this point. I'm going
to propose an installer and I hope to do so without introducing or
removing any Roller dependencies.
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. However, then we've locked into a particular SSO
implementation, rather than allowing systems like SiteMinder and CAS.
Just some things to think about. IMO, CMA is quite broken compared to
Acegi - but we used it in Roller for years and it worked. I guess
we're not using the advanced features of Acegi (like ACLs and
method-level security) so removing it probably wouldn't be too hard.
Matt
- Dave
--
http://raibledesigns.com
