You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Matt Raible <mr...@gmail.com> on 2005/10/04 22:33:02 UTC
Re: Acegi Integration Status
Sorry it took me so long - this kinda got lost in my inbox.
I've updated my local project with 2.0 from SVN and uploaded the code to the
following URL. It should have .svn folders in it so you can diff it against
the roller_2.0 branch.
http://static.raibledesigns.com/downloads/roller-2.0-withacegi.tar.gz
It's 47 MB.
Thanks,
Matt
On 9/29/05, Matt Raible <mr...@gmail.com> wrote:
>
> I'll try to do that later tonight.
>
> Thanks,
>
> Matt
>
> On 9/29/05, Allen Gilliland <Al...@sun.com> wrote:
> > Matt,
> >
> > i think all the new files that are needed are missing. like the
> WEB-INF/security.xml and the new jars, etc.
> >
> > maybe you can package that stuff up in a zip file and add that to the
> wiki as well?
> >
> > -- Allen
> >
> >
> > On Wed, 2005-09-28 at 11:26, Matt Raible wrote:
> > > It's attached to the proposal.
> > >
> > > http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AcegiSecurity
> > >
> > > Please note the remaining issues listed on the wiki.
> > >
> > > Matt
> > >
> > > On 9/28/05, Allen Gilliland <Al...@sun.com> wrote:
> > > > Matt,
> > > >
> > > > I wasn't able to recieve the patch you sent with this email probably
> because it got caught by a spam filter or something.
> > > >
> > > > can you possibly post it somewhere on the web so I can grab it?
> > > >
> > > > -- Allen
> > > >
> > > >
> > > > On Mon, 2005-09-19 at 16:36, Matt Raible wrote:
> > > > > On 9/17/05, Allen Gilliland <Al...@sun.com> wrote:
> > > > > > cool ... this sounds like a welcome improvement over CMA.
> > > > > >
> > > > > > i know we've talked about using Acegi on the list before, but is
> there a
> > > > > > proposal plan that outlines genrally how Acegi integration
> works, what
> > > > > > new classes would be created, and how SSO would tie in?
> > > > >
> > > > > No, I should do this. First, I wanted to prove that it would
> actually
> > > > > work. As far as SSO, Acegi integrates with Yale's CAS system -
> more
> > > > > information is available in Acegi's documentation.
> > > > >
> > > > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
>
> > > > >
> > > > > If you look at the forum link below, you'll see I got an answer to
> my
> > > > > question and was able to get everything working today. I've
> attached
> > > > > a patch of what changes in existing classes.
> > > > >
> > > > > The biggest change is that a lot of the startup logic in
> LoginServlet
> > > > > moved to RollerContext (where everything else is initialized).
> Other
> > > > > changes include removing the secure and unsecure port numbers in
> > > > > roller.properties. This is because Acegi defaults to 8443 (when
> using
> > > > > 8080 for http://) and 443 (when using 80 for http://).
> > > > >
> > > > > The one thing I haven't done in this patch is to remove the
> UserCookie
> > > > > object (and code from UserManager) - but this will no longer be
> > > > > necessary either.
> > > > >
> > > > > I'll try to write up a proposal on the wiki in the next day or
> two.
> > > > > Any suggestions on an existing proposal to use for a template?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Matt
> > > > >
> > > > >
> > > > > >
> > > > > > -- Allen
> > > > > >
> > > > > >
> > > > > > On Sat, 2005-09-17 at 08:34, Matt Raible wrote:
> > > > > > > FYI...
> > > > > > >
> > > > > > > I did some work yesterday to create a version of Roller that
> uses
> > > > > > > Acegi Security for its security mechanism as an alternative to
> CMA.
> > > > > > > It's my believe that this should be possible w/o changing a
> single
> > > > > > > line of Java code. In fact, it should result in deleting quite
> a bit
> > > > > > > of code (LoginServlet, LoginFilter, UserCookie, etc.).
> > > > > > >
> > > > > > > However, I've run into one issue.
> > > > > > >
> > > > > > > <snip>
> > > > > > > Principal principal = request.getUserPrincipal();
> > > > > > > String username = principal.getName();
> > > > > > >
> > > > > > > With CMA, this returns "mraible" (my login name). However,
> with Acegi,
> > > > > > > it returns:
> > > > > > >
> > > > > > > userName= "net.sf.acegisecurity.providers.dao.User@a8eaf3:
> Username:
> > > > > > > mraible; Password: [PROTECTED]; Enabled: true;
> AccountNonExpired:
> > > > > > > true; credentialsNonExpired: true; AccountNonLocked: true;
> Granted
> > > > > > > Authorities: editor"
> > > > > > > </snip>
> > > > > > >
> > > > > > > I've posted this to the Acegi Security forums, but haven't had
> a response yet.
> > > > > > >
> > > > > > > http://forum.springframework.org/viewtopic.php?t=8917
> > > > > > >
> > > > > > > I suspect it's a bug. A workaround is to use
> request.getRemoteUser(),
> > > > > > > but I'd rather see this fixed in Acegi.
> > > > > > >
> > > > > > > To reiterate why I'm doing this little experiment: it's
> because Acegi
> > > > > > > has more fine-grained control of security - allowing you to
> get a
> > > > > > > user's role or information in any layer (b/c the information
> is stored
> > > > > > > in a thread local). Furthermore, it has Remember Me and SSL
> Switching
> > > > > > > built in.
> > > > > > >
> > > > > > > AppFuse had the same setup that Roller has at one point. In
> fact, most
> > > > > > > of the Login/RememberMe/SSL Switching is from AppFuse. I
> switched to
> > > > > > > Acegi in AppFuse about 6 months ago and it's resulted in
> nothing but
> > > > > > > good things. We've been able to plug a few security holes that
> > > > > > > would've been more difficult if we were using CMA.
> > > > > > >
> > > > > > > Another good reason to switch is this will get us away from
> something
> > > > > > > users complain about often: the redirect to j_security_check -
> where
> > > > > > > the password is shown in the URL.
> > > > > > >
> > > > > > > Have a good weekend,
> > > > > > >
> > > > > > > Matt
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
>
Re: Acegi Integration Status
Posted by Allen Gilliland <Al...@Sun.COM>.
I'm not sure I follow, did you mean you want to set the log4j log level to WARN for the acegi package? If so then that won't solve the problem because the messages are being logged at WARN level right now, so we would need to go to ERROR level.
I would prefer not to discard all the messages Acegi is sending to INFO and WARN level logging, but I suppose that can't be helped if they insist on logging debug type messages at WARN level.
-- Allen
On Thu, 2005-12-01 at 14:06, Matt Raible wrote:
> I think a reasonable solution would be to set the Acegi debug level to
> be WARN. After all, we haven't been getting any authentication
> messages from CMA before.
>
> Matt
>
> On 12/1/05, Allen Gilliland <Al...@sun.com> wrote:
> > Actually, I don't even think these should be INFO level. We use INFO as the default log level and that means that on every attempted/successful login we would be getting these messages. That will be rediculous on a 2000 user system and I don't even want to think what it would look like for the jRoller guys.
> >
> > I think these messages need to be DEBUG level.
> >
> > -- Allen
> >
> >
> > On Thu, 2005-12-01 at 12:35, Matt Raible wrote:
> > > We could take out the LoggerListener bean in security.xml. I agree
> > > that these should be set to INFO for successful authentications. I
> > > can open an issue on this if you like.
> > >
> > > Matt
> > >
> > > On 12/1/05, Allen Gilliland <Al...@sun.com> wrote:
> > > > Matt,
> > > >
> > > > is there any way we can cut down on these kinds of messages without having to set the logger to ERROR level or higher?
> > > >
> > > > WARN 2005-12-01 11:08:32,047 LoggerListener:onApplicationEvent - Authentication event AuthenticationFailureBadCredentialsEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@14c7cd: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5; exception: Bad credentials presented
> > > > WARN 2005-12-01 11:08:50,331 LoggerListener:onApplicationEvent - Authentication event AuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
> > > > WARN 2005-12-01 11:08:50,343 LoggerListener:onApplicationEvent - Authentication event InteractiveAuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
> > > >
> > > > why on earth would they have WARN level logging for simply indicating passed/failed authentications??
> > > >
> > > > -- Allen
> > > >
> > > >
> > > > On Mon, 2005-11-28 at 15:31, Allen Gilliland wrote:
> > > > > On Mon, 2005-11-28 at 13:23, Matt Raible wrote:
> > > > > > > >
> > > > > > > > 1. Use the ports from roller.properties to configure SSL Switching.
> > > > > > > >
> > > > > > > > This should be configurable with a PortResolverImpl - here's an example:
> > > > > > > >
> > > > > > > > http://forum.springframework.org/showthread.php?t=19903
> > > > > > >
> > > > > > > agreed.
> > > > > > >
> > > > > > > >
> > > > > > > > 2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
> > > > > > > > should be used to secure certain pages.
> > > > > > >
> > > > > > > can we do this programmatically? it would suck if users had to modify the xml file in the webapp just to enable secure logins.
> > > > > >
> > > > > > We should be able to configure everything programmatically (after
> > > > > > initial load). If you look at the new method I added to
> > > > > > RollerContext, you'll see that many beans are manipulated after the
> > > > > > fact.
> > > > > >
> > > > > > It should just be a matter of grabbing the existing property and
> > > > > > manipulating it, then re-setting it.
> > > > >
> > > > > Ah, I get it now. Very cool.
> > > > >
> > > > > -- Allen
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> >
> >
Re: Acegi Integration Status
Posted by Matt Raible <mr...@gmail.com>.
I think a reasonable solution would be to set the Acegi debug level to
be WARN. After all, we haven't been getting any authentication
messages from CMA before.
Matt
On 12/1/05, Allen Gilliland <Al...@sun.com> wrote:
> Actually, I don't even think these should be INFO level. We use INFO as the default log level and that means that on every attempted/successful login we would be getting these messages. That will be rediculous on a 2000 user system and I don't even want to think what it would look like for the jRoller guys.
>
> I think these messages need to be DEBUG level.
>
> -- Allen
>
>
> On Thu, 2005-12-01 at 12:35, Matt Raible wrote:
> > We could take out the LoggerListener bean in security.xml. I agree
> > that these should be set to INFO for successful authentications. I
> > can open an issue on this if you like.
> >
> > Matt
> >
> > On 12/1/05, Allen Gilliland <Al...@sun.com> wrote:
> > > Matt,
> > >
> > > is there any way we can cut down on these kinds of messages without having to set the logger to ERROR level or higher?
> > >
> > > WARN 2005-12-01 11:08:32,047 LoggerListener:onApplicationEvent - Authentication event AuthenticationFailureBadCredentialsEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@14c7cd: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5; exception: Bad credentials presented
> > > WARN 2005-12-01 11:08:50,331 LoggerListener:onApplicationEvent - Authentication event AuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
> > > WARN 2005-12-01 11:08:50,343 LoggerListener:onApplicationEvent - Authentication event InteractiveAuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
> > >
> > > why on earth would they have WARN level logging for simply indicating passed/failed authentications??
> > >
> > > -- Allen
> > >
> > >
> > > On Mon, 2005-11-28 at 15:31, Allen Gilliland wrote:
> > > > On Mon, 2005-11-28 at 13:23, Matt Raible wrote:
> > > > > > >
> > > > > > > 1. Use the ports from roller.properties to configure SSL Switching.
> > > > > > >
> > > > > > > This should be configurable with a PortResolverImpl - here's an example:
> > > > > > >
> > > > > > > http://forum.springframework.org/showthread.php?t=19903
> > > > > >
> > > > > > agreed.
> > > > > >
> > > > > > >
> > > > > > > 2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
> > > > > > > should be used to secure certain pages.
> > > > > >
> > > > > > can we do this programmatically? it would suck if users had to modify the xml file in the webapp just to enable secure logins.
> > > > >
> > > > > We should be able to configure everything programmatically (after
> > > > > initial load). If you look at the new method I added to
> > > > > RollerContext, you'll see that many beans are manipulated after the
> > > > > fact.
> > > > >
> > > > > It should just be a matter of grabbing the existing property and
> > > > > manipulating it, then re-setting it.
> > > >
> > > > Ah, I get it now. Very cool.
> > > >
> > > > -- Allen
> > > >
> > > >
> > > >
> > >
> > >
>
>
Re: Acegi Integration Status
Posted by Allen Gilliland <Al...@Sun.COM>.
Actually, I don't even think these should be INFO level. We use INFO as the default log level and that means that on every attempted/successful login we would be getting these messages. That will be rediculous on a 2000 user system and I don't even want to think what it would look like for the jRoller guys.
I think these messages need to be DEBUG level.
-- Allen
On Thu, 2005-12-01 at 12:35, Matt Raible wrote:
> We could take out the LoggerListener bean in security.xml. I agree
> that these should be set to INFO for successful authentications. I
> can open an issue on this if you like.
>
> Matt
>
> On 12/1/05, Allen Gilliland <Al...@sun.com> wrote:
> > Matt,
> >
> > is there any way we can cut down on these kinds of messages without having to set the logger to ERROR level or higher?
> >
> > WARN 2005-12-01 11:08:32,047 LoggerListener:onApplicationEvent - Authentication event AuthenticationFailureBadCredentialsEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@14c7cd: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5; exception: Bad credentials presented
> > WARN 2005-12-01 11:08:50,331 LoggerListener:onApplicationEvent - Authentication event AuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
> > WARN 2005-12-01 11:08:50,343 LoggerListener:onApplicationEvent - Authentication event InteractiveAuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
> >
> > why on earth would they have WARN level logging for simply indicating passed/failed authentications??
> >
> > -- Allen
> >
> >
> > On Mon, 2005-11-28 at 15:31, Allen Gilliland wrote:
> > > On Mon, 2005-11-28 at 13:23, Matt Raible wrote:
> > > > > >
> > > > > > 1. Use the ports from roller.properties to configure SSL Switching.
> > > > > >
> > > > > > This should be configurable with a PortResolverImpl - here's an example:
> > > > > >
> > > > > > http://forum.springframework.org/showthread.php?t=19903
> > > > >
> > > > > agreed.
> > > > >
> > > > > >
> > > > > > 2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
> > > > > > should be used to secure certain pages.
> > > > >
> > > > > can we do this programmatically? it would suck if users had to modify the xml file in the webapp just to enable secure logins.
> > > >
> > > > We should be able to configure everything programmatically (after
> > > > initial load). If you look at the new method I added to
> > > > RollerContext, you'll see that many beans are manipulated after the
> > > > fact.
> > > >
> > > > It should just be a matter of grabbing the existing property and
> > > > manipulating it, then re-setting it.
> > >
> > > Ah, I get it now. Very cool.
> > >
> > > -- Allen
> > >
> > >
> > >
> >
> >
Re: Acegi Integration Status
Posted by Matt Raible <mr...@gmail.com>.
I posted this to the Spring Forums.
http://forum.springframework.org/showthread.php?p=42584#post42584
On 12/1/05, Matt Raible <mr...@gmail.com> wrote:
> We could take out the LoggerListener bean in security.xml. I agree
> that these should be set to INFO for successful authentications. I
> can open an issue on this if you like.
>
> Matt
>
> On 12/1/05, Allen Gilliland <Al...@sun.com> wrote:
> > Matt,
> >
> > is there any way we can cut down on these kinds of messages without having to set the logger to ERROR level or higher?
> >
> > WARN 2005-12-01 11:08:32,047 LoggerListener:onApplicationEvent - Authentication event AuthenticationFailureBadCredentialsEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@14c7cd: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5; exception: Bad credentials presented
> > WARN 2005-12-01 11:08:50,331 LoggerListener:onApplicationEvent - Authentication event AuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
> > WARN 2005-12-01 11:08:50,343 LoggerListener:onApplicationEvent - Authentication event InteractiveAuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
> >
> > why on earth would they have WARN level logging for simply indicating passed/failed authentications??
> >
> > -- Allen
> >
> >
> > On Mon, 2005-11-28 at 15:31, Allen Gilliland wrote:
> > > On Mon, 2005-11-28 at 13:23, Matt Raible wrote:
> > > > > >
> > > > > > 1. Use the ports from roller.properties to configure SSL Switching.
> > > > > >
> > > > > > This should be configurable with a PortResolverImpl - here's an example:
> > > > > >
> > > > > > http://forum.springframework.org/showthread.php?t=19903
> > > > >
> > > > > agreed.
> > > > >
> > > > > >
> > > > > > 2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
> > > > > > should be used to secure certain pages.
> > > > >
> > > > > can we do this programmatically? it would suck if users had to modify the xml file in the webapp just to enable secure logins.
> > > >
> > > > We should be able to configure everything programmatically (after
> > > > initial load). If you look at the new method I added to
> > > > RollerContext, you'll see that many beans are manipulated after the
> > > > fact.
> > > >
> > > > It should just be a matter of grabbing the existing property and
> > > > manipulating it, then re-setting it.
> > >
> > > Ah, I get it now. Very cool.
> > >
> > > -- Allen
> > >
> > >
> > >
> >
> >
>
Re: Acegi Integration Status
Posted by Matt Raible <mr...@gmail.com>.
We could take out the LoggerListener bean in security.xml. I agree
that these should be set to INFO for successful authentications. I
can open an issue on this if you like.
Matt
On 12/1/05, Allen Gilliland <Al...@sun.com> wrote:
> Matt,
>
> is there any way we can cut down on these kinds of messages without having to set the logger to ERROR level or higher?
>
> WARN 2005-12-01 11:08:32,047 LoggerListener:onApplicationEvent - Authentication event AuthenticationFailureBadCredentialsEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@14c7cd: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5; exception: Bad credentials presented
> WARN 2005-12-01 11:08:50,331 LoggerListener:onApplicationEvent - Authentication event AuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
> WARN 2005-12-01 11:08:50,343 LoggerListener:onApplicationEvent - Authentication event InteractiveAuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
>
> why on earth would they have WARN level logging for simply indicating passed/failed authentications??
>
> -- Allen
>
>
> On Mon, 2005-11-28 at 15:31, Allen Gilliland wrote:
> > On Mon, 2005-11-28 at 13:23, Matt Raible wrote:
> > > > >
> > > > > 1. Use the ports from roller.properties to configure SSL Switching.
> > > > >
> > > > > This should be configurable with a PortResolverImpl - here's an example:
> > > > >
> > > > > http://forum.springframework.org/showthread.php?t=19903
> > > >
> > > > agreed.
> > > >
> > > > >
> > > > > 2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
> > > > > should be used to secure certain pages.
> > > >
> > > > can we do this programmatically? it would suck if users had to modify the xml file in the webapp just to enable secure logins.
> > >
> > > We should be able to configure everything programmatically (after
> > > initial load). If you look at the new method I added to
> > > RollerContext, you'll see that many beans are manipulated after the
> > > fact.
> > >
> > > It should just be a matter of grabbing the existing property and
> > > manipulating it, then re-setting it.
> >
> > Ah, I get it now. Very cool.
> >
> > -- Allen
> >
> >
> >
>
>
Re: Acegi Integration Status
Posted by Allen Gilliland <Al...@Sun.COM>.
Matt,
is there any way we can cut down on these kinds of messages without having to set the logger to ERROR level or higher?
WARN 2005-12-01 11:08:32,047 LoggerListener:onApplicationEvent - Authentication event AuthenticationFailureBadCredentialsEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@14c7cd: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5; exception: Bad credentials presented
WARN 2005-12-01 11:08:50,331 LoggerListener:onApplicationEvent - Authentication event AuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
WARN 2005-12-01 11:08:50,343 LoggerListener:onApplicationEvent - Authentication event InteractiveAuthenticationSuccessEvent: admin; details: net.sf.acegisecurity.ui.WebAuthenticationDetails@11cccce: RemoteIpAddress: 129.146.114.93; SessionId: FACEEDD1DA66AF85C817518776F193D5
why on earth would they have WARN level logging for simply indicating passed/failed authentications??
-- Allen
On Mon, 2005-11-28 at 15:31, Allen Gilliland wrote:
> On Mon, 2005-11-28 at 13:23, Matt Raible wrote:
> > > >
> > > > 1. Use the ports from roller.properties to configure SSL Switching.
> > > >
> > > > This should be configurable with a PortResolverImpl - here's an example:
> > > >
> > > > http://forum.springframework.org/showthread.php?t=19903
> > >
> > > agreed.
> > >
> > > >
> > > > 2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
> > > > should be used to secure certain pages.
> > >
> > > can we do this programmatically? it would suck if users had to modify the xml file in the webapp just to enable secure logins.
> >
> > We should be able to configure everything programmatically (after
> > initial load). If you look at the new method I added to
> > RollerContext, you'll see that many beans are manipulated after the
> > fact.
> >
> > It should just be a matter of grabbing the existing property and
> > manipulating it, then re-setting it.
>
> Ah, I get it now. Very cool.
>
> -- Allen
>
>
>
Re: Acegi Integration Status
Posted by Allen Gilliland <Al...@Sun.COM>.
On Mon, 2005-11-28 at 13:23, Matt Raible wrote:
> > >
> > > 1. Use the ports from roller.properties to configure SSL Switching.
> > >
> > > This should be configurable with a PortResolverImpl - here's an example:
> > >
> > > http://forum.springframework.org/showthread.php?t=19903
> >
> > agreed.
> >
> > >
> > > 2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
> > > should be used to secure certain pages.
> >
> > can we do this programmatically? it would suck if users had to modify the xml file in the webapp just to enable secure logins.
>
> We should be able to configure everything programmatically (after
> initial load). If you look at the new method I added to
> RollerContext, you'll see that many beans are manipulated after the
> fact.
>
> It should just be a matter of grabbing the existing property and
> manipulating it, then re-setting it.
Ah, I get it now. Very cool.
-- Allen
Re: Acegi Integration Status
Posted by Matt Raible <mr...@gmail.com>.
On 11/28/05, Allen Gilliland <Al...@sun.com> wrote:
> On Mon, 2005-11-28 at 11:57, Matt Raible wrote:
> > OK, I committed it - with Acegi 0.9.0 and Spring 1.2.6 (to support
> > Acegi). As I see it, there's a few more things we need to work on to
> > make this a polished integration:
>
> I seem to be missing the web/WEB-INF/security.xml file.
Sorry, it should be there now.
>
>
> >
> > 1. Use the ports from roller.properties to configure SSL Switching.
> >
> > This should be configurable with a PortResolverImpl - here's an example:
> >
> > http://forum.springframework.org/showthread.php?t=19903
>
> agreed.
>
> >
> > 2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
> > should be used to secure certain pages.
>
> can we do this programmatically? it would suck if users had to modify the xml file in the webapp just to enable secure logins.
We should be able to configure everything programmatically (after
initial load). If you look at the new method I added to
RollerContext, you'll see that many beans are manipulated after the
fact.
It should just be a matter of grabbing the existing property and
manipulating it, then re-setting it.
>
> >
> > 3. Add support for switching to SSL based on a header value.
>
> this one i have actually tackled in a different way which i think works better than what we have now. i have a solution which can be implemented outside of the application, so we don't need application specific modifications to support this.
>
> my guess is that Sun is the only ones using this feature, but maybe i'm wrong? anyone else using the custom header option for ssl switching?
>
> >
> > 4. Add a drop table (and indexes) statement for 2.1 for the user_cookie table.
>
> sounds reasonable, however maybe we can leave this until 3.0? the reason being that if someone deploys 2.1 and decides they need to go back to 2.0 for some reason, then that's not possible if the table is gone. 3.0 seems like a good time to do a bunch of table cleanup because i know the old rollerconfig table is obsolete now as well.
That's fine - leaving it in there shouldn't hurt anything. We should
probably use "drop table if exists" just in case people do drop it.
Matt
>
> -- Allen
>
>
> >
> > Is there anything else I'm missing? Should I enter bugs in JIRA for
> > these so we don't forget? The nice thing about using Acegi is now
> > everything is configured in
> > RollerContext.initializeSecurityFeatures(), instead of LoginServlet
> > and LoginFilter.
> >
> > Matt
> >
> > >
> > > -- Allen
> > >
> > >
> > >
> > >
>
>
Re: Acegi Integration Status
Posted by Allen Gilliland <Al...@Sun.COM>.
On Mon, 2005-11-28 at 11:57, Matt Raible wrote:
> OK, I committed it - with Acegi 0.9.0 and Spring 1.2.6 (to support
> Acegi). As I see it, there's a few more things we need to work on to
> make this a polished integration:
I seem to be missing the web/WEB-INF/security.xml file.
>
> 1. Use the ports from roller.properties to configure SSL Switching.
>
> This should be configurable with a PortResolverImpl - here's an example:
>
> http://forum.springframework.org/showthread.php?t=19903
agreed.
>
> 2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
> should be used to secure certain pages.
can we do this programmatically? it would suck if users had to modify the xml file in the webapp just to enable secure logins.
>
> 3. Add support for switching to SSL based on a header value.
this one i have actually tackled in a different way which i think works better than what we have now. i have a solution which can be implemented outside of the application, so we don't need application specific modifications to support this.
my guess is that Sun is the only ones using this feature, but maybe i'm wrong? anyone else using the custom header option for ssl switching?
>
> 4. Add a drop table (and indexes) statement for 2.1 for the user_cookie table.
sounds reasonable, however maybe we can leave this until 3.0? the reason being that if someone deploys 2.1 and decides they need to go back to 2.0 for some reason, then that's not possible if the table is gone. 3.0 seems like a good time to do a bunch of table cleanup because i know the old rollerconfig table is obsolete now as well.
-- Allen
>
> Is there anything else I'm missing? Should I enter bugs in JIRA for
> these so we don't forget? The nice thing about using Acegi is now
> everything is configured in
> RollerContext.initializeSecurityFeatures(), instead of LoginServlet
> and LoginFilter.
>
> Matt
>
> >
> > -- Allen
> >
> >
> >
> >
Re: Acegi Integration Status
Posted by Matt Raible <mr...@gmail.com>.
On 11/28/05, Allen Gilliland <Al...@sun.com> wrote:
> On Mon, 2005-11-28 at 11:10, Matt Raible wrote:
> > >
> > > I think it's very important that we continue to have settings like this come from our RollerConfig properties class. Right now this doesn't seem to be an issue because the port switching logic is done using a custom "secure" tag and our scheme enforcement filter. It's probably a little redundant to have that stuff moving forward, but until we are sure that Acegi can access the properties it needs via our RollerConfig class then I am fine with just leaving things as they are.
> >
> > Yeah, the "secure" tag can go away - I don't believe that's in my
> > patch, as well as remove it from any JSPs.
>
> I agree, we should probably remove it at some point in the future, but lets not do that yet. What I have in my workspace now is working using the RollerConfig class, so I don't want to make changes that would break that.
>
> >
> > I'll have to do some additional work to read and configure the ports
> > from roller.properties, as well as turning on secure login from
> > roller.properties. With the current patch, you can configure both of
> > these in web/WEB-INF/security.xml.
>
> I just want to clarify that it's probably more of an issue where we want the properties read from the org.roller.config.RollerConfig class rather than a file. The reason being that just reading from a file does us no good because people are expected to be overriding values from the roller.properties in their own roller-custom.properties files.
>
>
> > >
> > > Are you ready to commit that code or can I commit what I have working from your last patch and then you can update that to 0.9.0 if you want?
> >
> > I'm ready to commit the code - it's currently running on my site and I
> > haven't seen any issues.
>
> I say go ahead and commit whenever you get a chance. I plan on commiting a number of things today and I'd like to a bunch of the 2.1 code into the repository so I can begin testing.
OK, I committed it - with Acegi 0.9.0 and Spring 1.2.6 (to support
Acegi). As I see it, there's a few more things we need to work on to
make this a polished integration:
1. Use the ports from roller.properties to configure SSL Switching.
This should be configurable with a PortResolverImpl - here's an example:
http://forum.springframework.org/showthread.php?t=19903
2. Add the channelProcessFilter to the "filterChainProxy" bean if SSL
should be used to secure certain pages.
3. Add support for switching to SSL based on a header value.
4. Add a drop table (and indexes) statement for 2.1 for the user_cookie table.
Is there anything else I'm missing? Should I enter bugs in JIRA for
these so we don't forget? The nice thing about using Acegi is now
everything is configured in
RollerContext.initializeSecurityFeatures(), instead of LoginServlet
and LoginFilter.
Matt
>
> -- Allen
>
>
>
>
Re: Acegi Integration Status
Posted by Allen Gilliland <Al...@Sun.COM>.
On Mon, 2005-11-28 at 11:10, Matt Raible wrote:
> >
> > I think it's very important that we continue to have settings like this come from our RollerConfig properties class. Right now this doesn't seem to be an issue because the port switching logic is done using a custom "secure" tag and our scheme enforcement filter. It's probably a little redundant to have that stuff moving forward, but until we are sure that Acegi can access the properties it needs via our RollerConfig class then I am fine with just leaving things as they are.
>
> Yeah, the "secure" tag can go away - I don't believe that's in my
> patch, as well as remove it from any JSPs.
I agree, we should probably remove it at some point in the future, but lets not do that yet. What I have in my workspace now is working using the RollerConfig class, so I don't want to make changes that would break that.
>
> I'll have to do some additional work to read and configure the ports
> from roller.properties, as well as turning on secure login from
> roller.properties. With the current patch, you can configure both of
> these in web/WEB-INF/security.xml.
I just want to clarify that it's probably more of an issue where we want the properties read from the org.roller.config.RollerConfig class rather than a file. The reason being that just reading from a file does us no good because people are expected to be overriding values from the roller.properties in their own roller-custom.properties files.
> >
> > Are you ready to commit that code or can I commit what I have working from your last patch and then you can update that to 0.9.0 if you want?
>
> I'm ready to commit the code - it's currently running on my site and I
> haven't seen any issues.
I say go ahead and commit whenever you get a chance. I plan on commiting a number of things today and I'd like to a bunch of the 2.1 code into the repository so I can begin testing.
-- Allen
Re: Acegi Integration Status
Posted by Matt Raible <mr...@gmail.com>.
On 11/28/05, Allen Gilliland <Al...@sun.com> wrote:
> On Fri, 2005-11-18 at 12:57, Matt Raible wrote:
> > On 11/17/05, Allen Gilliland <Al...@sun.com> wrote:
> > > On Mon, 2005-11-07 at 09:10, Matt Raible wrote:
> > > > > >
> > > > > > 2. how does the port switching and scheme enforcement work? we still want to make sure that secure logins work between any 2 configurable ports and that we support the use of a custom secure login header.
> > > >
> > > > By default, 80 switches to 443 and 8080 switches to 8443. These are
> > > > configurable.
> > >
> > > how are they configurable?
> >
> > Like most things with Spring, in XML most likely. But we can set a
> > bean definition to read its properties from properties file or from
> > servlet context parameters.
> >
> > > where do you modify them?
> >
> > > can we do it via the roller.properties config?
> >
> > I'm pretty sure we can set them in WEB-INF/security.xml to override,
> > but we could also make it configurable in roler.properties. I've been
> > able to do this with a number of features (i.e. password encryption
> > and remember me). They're off by default in security.xml, and turned
> > on if roller.properties is configured that way.
>
> I think it's very important that we continue to have settings like this come from our RollerConfig properties class. Right now this doesn't seem to be an issue because the port switching logic is done using a custom "secure" tag and our scheme enforcement filter. It's probably a little redundant to have that stuff moving forward, but until we are sure that Acegi can access the properties it needs via our RollerConfig class then I am fine with just leaving things as they are.
Yeah, the "secure" tag can go away - I don't believe that's in my
patch, as well as remove it from any JSPs.
I'll have to do some additional work to read and configure the ports
from roller.properties, as well as turning on secure login from
roller.properties. With the current patch, you can configure both of
these in web/WEB-INF/security.xml.
>
> > >
> > > also, where would be be able to plugin some logic for checking a custom header? i.e. an http request with a custom header can be considered secure.
> >
> > There's a keyword property you can set - so this should be possible, I
> > just haven't done it personally. Right now, the secureLogin is a
> > setting in /WEB-INF/security.xml:
> >
> > <bean id="authenticationProcessingFilterEntryPoint"
> > class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">
> > <property name="loginFormUrl" value="/login.jsp"/>
> > <property name="forceHttps" value="false"/>
> > </bean>
> >
> > And the SSL for everything setting is just a matter of adding
> > channelProcessingFilter to the filterchain.
> >
> > <bean id="filterChainProxy"
> > class="net.sf.acegisecurity.util.FilterChainProxy">
> > <property name="filterInvocationDefinitionSource">
> > <value>
> > CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
> > PATTERN_TYPE_APACHE_ANT
> >
> > /**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter
> > </value>
> > <!-- Put channelProcessingFilter before remoteUserFilter
> > to turn on SSL switching, it's off by default -->
> > </property>
> > </bean>
> >
> > >
> > > >
> > > > > >
> > > > > > 3. how easy is it to add support for authenticating against 3rd party systems using custom dbs, ldap, etc?
> > > >
> > > > It's just a matter of writing a new Provider DAO. LDAP support is in
> > > > CVS, but they've had some issues in finding someone to support it.
> > >
> > > That's fine. I suppose a custom SSO support can work the same way correct? Just write a custom Provider DAO which talks to your SSO system and you are set.
> >
> > Yep.
> >
> > I've successfully upgraded the latest version of Roller (in the trunk)
> > to use Acegi 0.9.0. I'll upload a new patch and update the download
> > on my site.
> >
>
> Are you ready to commit that code or can I commit what I have working from your last patch and then you can update that to 0.9.0 if you want?
I'm ready to commit the code - it's currently running on my site and I
haven't seen any issues.
Matt
>
> -- Allen
>
>
> >
> > Matt
> >
> > >
> > > -- Allen
> > >
> > >
> > > >
> > > > Hope this helps,
> > > >
> > > > Matt
> > > >
> > > > > >
> > > > > > -- Allen
> > > > > >
> > > > > >
> > > > > > On Tue, 2005-10-04 at 13:33, Matt Raible wrote:
> > > > > > > Sorry it took me so long - this kinda got lost in my inbox.
> > > > > > >
> > > > > > > I've updated my local project with 2.0 from SVN and uploaded the code > to the following URL. It should have .svn folders in it so you can > diff it against the roller_2.0 branch.
> > > > > > >
> > > > > > > http://static.raibledesigns.com/downloads/roller-2.0-withacegi.tar.gz
> > > > > > >
> > > > > > > It's 47 MB.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Matt
> > > > > > >
> > > > > > > On 9/29/05, Matt Raible <mr...@gmail.com> wrote:
> > > > > > > I'll try to do that later tonight.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Matt
> > > > > > >
> > > > > > > On 9/29/05, Allen Gilliland <Al...@sun.com> wrote:
> > > > > > > > Matt,
> > > > > > > >
> > > > > > > > i think all the new files that are needed are missing. like > the WEB-INF/security.xml and the new jars, etc.
> > > > > > > >
> > > > > > > > maybe you can package that stuff up in a zip file and add > that to the wiki as well?
> > > > > > > >
> > > > > > > > -- Allen
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, 2005-09-28 at 11:26, Matt Raible wrote:
> > > > > > > > > It's attached to the proposal.
> > > > > > > > >
> > > > > > > > > > http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AcegiSecurity
> > > > > > > > >
> > > > > > > > > Please note the remaining issues listed on the wiki.
> > > > > > > > >
> > > > > > > > > Matt
> > > > > > > > >
> > > > > > > > > On 9/28/05, Allen Gilliland <Al...@sun.com> > wrote:
> > > > > > > > > > Matt,
> > > > > > > > > >
> > > > > > > > > > I wasn't able to recieve the patch you sent with this > email probably because it got caught by a spam filter or > something.
> > > > > > > > > >
> > > > > > > > > > can you possibly post it somewhere on the web so I can > grab it?
> > > > > > > > > >
> > > > > > > > > > -- Allen
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Mon, 2005-09-19 at 16:36, Matt Raible wrote:
> > > > > > > > > > > On 9/17/05, Allen Gilliland > <Al...@sun.com> wrote:
> > > > > > > > > > > > cool ... this sounds like a welcome improvement over > CMA.
> > > > > > > > > > > >
> > > > > > > > > > > > i know we've talked about using Acegi on the list > before, but is there a
> > > > > > > > > > > > proposal plan that outlines genrally how Acegi > integration works, what
> > > > > > > > > > > > new classes would be created, and how SSO would tie > in?
> > > > > > > > > > >
> > > > > > > > > > > No, I should do this. First, I wanted to prove that > it would actually
> > > > > > > > > > > work. As far as SSO, Acegi integrates with Yale's CAS > system - more
> > > > > > > > > > > information is available in Acegi's documentation.
> > > > > > > > > > >
> > > > > > > > > > > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
> > > > > > > > > > >
> > > > > > > > > > > If you look at the forum link below, you'll see I got > an answer to my
> > > > > > > > > > > question and was able to get everything working > today. I've attached
> > > > > > > > > > > a patch of what changes in existing classes.
> > > > > > > > > > >
> > > > > > > > > > > The biggest change is that a lot of the startup logic > in LoginServlet
> > > > > > > > > > > moved to RollerContext (where everything else is > initialized). Other
> > > > > > > > > > > changes include removing the secure and unsecure port > numbers in
> > > > > > > > > > > roller.properties. This is because Acegi defaults to > 8443 (when using
> > > > > > > > > > > 8080 for http://) and 443 (when using 80 for http://).
> > > > > > > > > > >
> > > > > > > > > > > The one thing I haven't done in this patch is to > remove the UserCookie
> > > > > > > > > > > object (and code from UserManager) - but this will no > longer be
> > > > > > > > > > > necessary either.
> > > > > > > > > > >
> > > > > > > > > > > I'll try to write up a proposal on the wiki in the > next day or two.
> > > > > > > > > > > Any suggestions on an existing proposal to use for a > template?
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > >
> > > > > > > > > > > Matt
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > -- Allen
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, 2005-09-17 at 08:34, Matt Raible wrote:
> > > > > > > > > > > > > FYI...
> > > > > > > > > > > > >
> > > > > > > > > > > > > I did some work yesterday to create a version of > Roller that uses
> > > > > > > > > > > > > Acegi Security for its security mechanism as an > alternative to CMA.
> > > > > > > > > > > > > It's my believe that this should be possible w/o > changing a single
> > > > > > > > > > > > > line of Java code. In fact, it should result in > deleting quite a bit
> > > > > > > > > > > > > of code (LoginServlet, LoginFilter, UserCookie, > etc.).
> > > > > > > > > > > > >
> > > > > > > > > > > > > However, I've run into one issue.
> > > > > > > > > > > > >
> > > > > > > > > > > > > <snip>
> > > > > > > > > > > > > Principal principal = request.getUserPrincipal();
> > > > > > > > > > > > > String username = principal.getName();
> > > > > > > > > > > > >
> > > > > > > > > > > > > With CMA, this returns "mraible" (my login name). > However, with Acegi,
> > > > > > > > > > > > > it returns:
> > > > > > > > > > > > >
> > > > > > > > > > > > > userName= > "net.sf.acegisecurity.providers.dao.User@a8eaf3: Username:
> > > > > > > > > > > > > mraible; Password: [PROTECTED]; Enabled: true; > AccountNonExpired:
> > > > > > > > > > > > > true; credentialsNonExpired: true; > AccountNonLocked: true; Granted
> > > > > > > > > > > > > Authorities: editor"
> > > > > > > > > > > > > </snip>
> > > > > > > > > > > > >
> > > > > > > > > > > > > I've posted this to the Acegi Security forums, but > haven't had a response yet.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > http://forum.springframework.org/viewtopic.php?t=8917
> > > > > > > > > > > > >
> > > > > > > > > > > > > I suspect it's a bug. A workaround is to use > request.getRemoteUser(),
> > > > > > > > > > > > > but I'd rather see this fixed in Acegi.
> > > > > > > > > > > > >
> > > > > > > > > > > > > To reiterate why I'm doing this little experiment: > it's because Acegi
> > > > > > > > > > > > > has more fine-grained control of security - > allowing you to get a
> > > > > > > > > > > > > user's role or information in any layer (b/c the > information is stored
> > > > > > > > > > > > > in a thread local). Furthermore, it has Remember > Me and SSL Switching
> > > > > > > > > > > > > built in.
> > > > > > > > > > > > >
> > > > > > > > > > > > > AppFuse had the same setup that Roller has at one > point. In fact, most
> > > > > > > > > > > > > of the Login/RememberMe/SSL Switching is from > AppFuse. I switched to
> > > > > > > > > > > > > Acegi in AppFuse about 6 months ago and it's > resulted in nothing but
> > > > > > > > > > > > > good things. We've been able to plug a few > security holes that
> > > > > > > > > > > > > would've been more difficult if we were using CMA.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Another good reason to switch is this will get us > away from something
> > > > > > > > > > > > > users complain about often: the redirect to > j_security_check - where
> > > > > > > > > > > > > the password is shown in the URL.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Have a good weekend,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Matt
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > >
> > >
>
>
Re: Acegi Integration Status
Posted by Allen Gilliland <Al...@Sun.COM>.
On Fri, 2005-11-18 at 12:57, Matt Raible wrote:
> On 11/17/05, Allen Gilliland <Al...@sun.com> wrote:
> > On Mon, 2005-11-07 at 09:10, Matt Raible wrote:
> > > > >
> > > > > 2. how does the port switching and scheme enforcement work? we still want to make sure that secure logins work between any 2 configurable ports and that we support the use of a custom secure login header.
> > >
> > > By default, 80 switches to 443 and 8080 switches to 8443. These are
> > > configurable.
> >
> > how are they configurable?
>
> Like most things with Spring, in XML most likely. But we can set a
> bean definition to read its properties from properties file or from
> servlet context parameters.
>
> > where do you modify them?
>
> > can we do it via the roller.properties config?
>
> I'm pretty sure we can set them in WEB-INF/security.xml to override,
> but we could also make it configurable in roler.properties. I've been
> able to do this with a number of features (i.e. password encryption
> and remember me). They're off by default in security.xml, and turned
> on if roller.properties is configured that way.
I think it's very important that we continue to have settings like this come from our RollerConfig properties class. Right now this doesn't seem to be an issue because the port switching logic is done using a custom "secure" tag and our scheme enforcement filter. It's probably a little redundant to have that stuff moving forward, but until we are sure that Acegi can access the properties it needs via our RollerConfig class then I am fine with just leaving things as they are.
> >
> > also, where would be be able to plugin some logic for checking a custom header? i.e. an http request with a custom header can be considered secure.
>
> There's a keyword property you can set - so this should be possible, I
> just haven't done it personally. Right now, the secureLogin is a
> setting in /WEB-INF/security.xml:
>
> <bean id="authenticationProcessingFilterEntryPoint"
> class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">
> <property name="loginFormUrl" value="/login.jsp"/>
> <property name="forceHttps" value="false"/>
> </bean>
>
> And the SSL for everything setting is just a matter of adding
> channelProcessingFilter to the filterchain.
>
> <bean id="filterChainProxy"
> class="net.sf.acegisecurity.util.FilterChainProxy">
> <property name="filterInvocationDefinitionSource">
> <value>
> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
> PATTERN_TYPE_APACHE_ANT
>
> /**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter
> </value>
> <!-- Put channelProcessingFilter before remoteUserFilter
> to turn on SSL switching, it's off by default -->
> </property>
> </bean>
>
> >
> > >
> > > > >
> > > > > 3. how easy is it to add support for authenticating against 3rd party systems using custom dbs, ldap, etc?
> > >
> > > It's just a matter of writing a new Provider DAO. LDAP support is in
> > > CVS, but they've had some issues in finding someone to support it.
> >
> > That's fine. I suppose a custom SSO support can work the same way correct? Just write a custom Provider DAO which talks to your SSO system and you are set.
>
> Yep.
>
> I've successfully upgraded the latest version of Roller (in the trunk)
> to use Acegi 0.9.0. I'll upload a new patch and update the download
> on my site.
>
Are you ready to commit that code or can I commit what I have working from your last patch and then you can update that to 0.9.0 if you want?
-- Allen
>
> Matt
>
> >
> > -- Allen
> >
> >
> > >
> > > Hope this helps,
> > >
> > > Matt
> > >
> > > > >
> > > > > -- Allen
> > > > >
> > > > >
> > > > > On Tue, 2005-10-04 at 13:33, Matt Raible wrote:
> > > > > > Sorry it took me so long - this kinda got lost in my inbox.
> > > > > >
> > > > > > I've updated my local project with 2.0 from SVN and uploaded the code > to the following URL. It should have .svn folders in it so you can > diff it against the roller_2.0 branch.
> > > > > >
> > > > > > http://static.raibledesigns.com/downloads/roller-2.0-withacegi.tar.gz
> > > > > >
> > > > > > It's 47 MB.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Matt
> > > > > >
> > > > > > On 9/29/05, Matt Raible <mr...@gmail.com> wrote:
> > > > > > I'll try to do that later tonight.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Matt
> > > > > >
> > > > > > On 9/29/05, Allen Gilliland <Al...@sun.com> wrote:
> > > > > > > Matt,
> > > > > > >
> > > > > > > i think all the new files that are needed are missing. like > the WEB-INF/security.xml and the new jars, etc.
> > > > > > >
> > > > > > > maybe you can package that stuff up in a zip file and add > that to the wiki as well?
> > > > > > >
> > > > > > > -- Allen
> > > > > > >
> > > > > > >
> > > > > > > On Wed, 2005-09-28 at 11:26, Matt Raible wrote:
> > > > > > > > It's attached to the proposal.
> > > > > > > >
> > > > > > > > > http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AcegiSecurity
> > > > > > > >
> > > > > > > > Please note the remaining issues listed on the wiki.
> > > > > > > >
> > > > > > > > Matt
> > > > > > > >
> > > > > > > > On 9/28/05, Allen Gilliland <Al...@sun.com> > wrote:
> > > > > > > > > Matt,
> > > > > > > > >
> > > > > > > > > I wasn't able to recieve the patch you sent with this > email probably because it got caught by a spam filter or > something.
> > > > > > > > >
> > > > > > > > > can you possibly post it somewhere on the web so I can > grab it?
> > > > > > > > >
> > > > > > > > > -- Allen
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, 2005-09-19 at 16:36, Matt Raible wrote:
> > > > > > > > > > On 9/17/05, Allen Gilliland > <Al...@sun.com> wrote:
> > > > > > > > > > > cool ... this sounds like a welcome improvement over > CMA.
> > > > > > > > > > >
> > > > > > > > > > > i know we've talked about using Acegi on the list > before, but is there a
> > > > > > > > > > > proposal plan that outlines genrally how Acegi > integration works, what
> > > > > > > > > > > new classes would be created, and how SSO would tie > in?
> > > > > > > > > >
> > > > > > > > > > No, I should do this. First, I wanted to prove that > it would actually
> > > > > > > > > > work. As far as SSO, Acegi integrates with Yale's CAS > system - more
> > > > > > > > > > information is available in Acegi's documentation.
> > > > > > > > > >
> > > > > > > > > > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
> > > > > > > > > >
> > > > > > > > > > If you look at the forum link below, you'll see I got > an answer to my
> > > > > > > > > > question and was able to get everything working > today. I've attached
> > > > > > > > > > a patch of what changes in existing classes.
> > > > > > > > > >
> > > > > > > > > > The biggest change is that a lot of the startup logic > in LoginServlet
> > > > > > > > > > moved to RollerContext (where everything else is > initialized). Other
> > > > > > > > > > changes include removing the secure and unsecure port > numbers in
> > > > > > > > > > roller.properties. This is because Acegi defaults to > 8443 (when using
> > > > > > > > > > 8080 for http://) and 443 (when using 80 for http://).
> > > > > > > > > >
> > > > > > > > > > The one thing I haven't done in this patch is to > remove the UserCookie
> > > > > > > > > > object (and code from UserManager) - but this will no > longer be
> > > > > > > > > > necessary either.
> > > > > > > > > >
> > > > > > > > > > I'll try to write up a proposal on the wiki in the > next day or two.
> > > > > > > > > > Any suggestions on an existing proposal to use for a > template?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > Matt
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > -- Allen
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Sat, 2005-09-17 at 08:34, Matt Raible wrote:
> > > > > > > > > > > > FYI...
> > > > > > > > > > > >
> > > > > > > > > > > > I did some work yesterday to create a version of > Roller that uses
> > > > > > > > > > > > Acegi Security for its security mechanism as an > alternative to CMA.
> > > > > > > > > > > > It's my believe that this should be possible w/o > changing a single
> > > > > > > > > > > > line of Java code. In fact, it should result in > deleting quite a bit
> > > > > > > > > > > > of code (LoginServlet, LoginFilter, UserCookie, > etc.).
> > > > > > > > > > > >
> > > > > > > > > > > > However, I've run into one issue.
> > > > > > > > > > > >
> > > > > > > > > > > > <snip>
> > > > > > > > > > > > Principal principal = request.getUserPrincipal();
> > > > > > > > > > > > String username = principal.getName();
> > > > > > > > > > > >
> > > > > > > > > > > > With CMA, this returns "mraible" (my login name). > However, with Acegi,
> > > > > > > > > > > > it returns:
> > > > > > > > > > > >
> > > > > > > > > > > > userName= > "net.sf.acegisecurity.providers.dao.User@a8eaf3: Username:
> > > > > > > > > > > > mraible; Password: [PROTECTED]; Enabled: true; > AccountNonExpired:
> > > > > > > > > > > > true; credentialsNonExpired: true; > AccountNonLocked: true; Granted
> > > > > > > > > > > > Authorities: editor"
> > > > > > > > > > > > </snip>
> > > > > > > > > > > >
> > > > > > > > > > > > I've posted this to the Acegi Security forums, but > haven't had a response yet.
> > > > > > > > > > > >
> > > > > > > > > > > > > http://forum.springframework.org/viewtopic.php?t=8917
> > > > > > > > > > > >
> > > > > > > > > > > > I suspect it's a bug. A workaround is to use > request.getRemoteUser(),
> > > > > > > > > > > > but I'd rather see this fixed in Acegi.
> > > > > > > > > > > >
> > > > > > > > > > > > To reiterate why I'm doing this little experiment: > it's because Acegi
> > > > > > > > > > > > has more fine-grained control of security - > allowing you to get a
> > > > > > > > > > > > user's role or information in any layer (b/c the > information is stored
> > > > > > > > > > > > in a thread local). Furthermore, it has Remember > Me and SSL Switching
> > > > > > > > > > > > built in.
> > > > > > > > > > > >
> > > > > > > > > > > > AppFuse had the same setup that Roller has at one > point. In fact, most
> > > > > > > > > > > > of the Login/RememberMe/SSL Switching is from > AppFuse. I switched to
> > > > > > > > > > > > Acegi in AppFuse about 6 months ago and it's > resulted in nothing but
> > > > > > > > > > > > good things. We've been able to plug a few > security holes that
> > > > > > > > > > > > would've been more difficult if we were using CMA.
> > > > > > > > > > > >
> > > > > > > > > > > > Another good reason to switch is this will get us > away from something
> > > > > > > > > > > > users complain about often: the redirect to > j_security_check - where
> > > > > > > > > > > > the password is shown in the URL.
> > > > > > > > > > > >
> > > > > > > > > > > > Have a good weekend,
> > > > > > > > > > > >
> > > > > > > > > > > > Matt
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> >
> >
Re: Acegi Integration Status
Posted by Matt Raible <mr...@gmail.com>.
On 11/17/05, Allen Gilliland <Al...@sun.com> wrote:
> On Mon, 2005-11-07 at 09:10, Matt Raible wrote:
> > > >
> > > > 2. how does the port switching and scheme enforcement work? we still want to make sure that secure logins work between any 2 configurable ports and that we support the use of a custom secure login header.
> >
> > By default, 80 switches to 443 and 8080 switches to 8443. These are
> > configurable.
>
> how are they configurable?
Like most things with Spring, in XML most likely. But we can set a
bean definition to read its properties from properties file or from
servlet context parameters.
> where do you modify them?
> can we do it via the roller.properties config?
I'm pretty sure we can set them in WEB-INF/security.xml to override,
but we could also make it configurable in roler.properties. I've been
able to do this with a number of features (i.e. password encryption
and remember me). They're off by default in security.xml, and turned
on if roller.properties is configured that way.
>
> also, where would be be able to plugin some logic for checking a custom header? i.e. an http request with a custom header can be considered secure.
There's a keyword property you can set - so this should be possible, I
just haven't done it personally. Right now, the secureLogin is a
setting in /WEB-INF/security.xml:
<bean id="authenticationProcessingFilterEntryPoint"
class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">
<property name="loginFormUrl" value="/login.jsp"/>
<property name="forceHttps" value="false"/>
</bean>
And the SSL for everything setting is just a matter of adding
channelProcessingFilter to the filterchain.
<bean id="filterChainProxy"
class="net.sf.acegisecurity.util.FilterChainProxy">
<property name="filterInvocationDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,remoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter
</value>
<!-- Put channelProcessingFilter before remoteUserFilter
to turn on SSL switching, it's off by default -->
</property>
</bean>
>
> >
> > > >
> > > > 3. how easy is it to add support for authenticating against 3rd party systems using custom dbs, ldap, etc?
> >
> > It's just a matter of writing a new Provider DAO. LDAP support is in
> > CVS, but they've had some issues in finding someone to support it.
>
> That's fine. I suppose a custom SSO support can work the same way correct? Just write a custom Provider DAO which talks to your SSO system and you are set.
Yep.
I've successfully upgraded the latest version of Roller (in the trunk)
to use Acegi 0.9.0. I'll upload a new patch and update the download
on my site.
Matt
>
> -- Allen
>
>
> >
> > Hope this helps,
> >
> > Matt
> >
> > > >
> > > > -- Allen
> > > >
> > > >
> > > > On Tue, 2005-10-04 at 13:33, Matt Raible wrote:
> > > > > Sorry it took me so long - this kinda got lost in my inbox.
> > > > >
> > > > > I've updated my local project with 2.0 from SVN and uploaded the code > to the following URL. It should have .svn folders in it so you can > diff it against the roller_2.0 branch.
> > > > >
> > > > > http://static.raibledesigns.com/downloads/roller-2.0-withacegi.tar.gz
> > > > >
> > > > > It's 47 MB.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Matt
> > > > >
> > > > > On 9/29/05, Matt Raible <mr...@gmail.com> wrote:
> > > > > I'll try to do that later tonight.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Matt
> > > > >
> > > > > On 9/29/05, Allen Gilliland <Al...@sun.com> wrote:
> > > > > > Matt,
> > > > > >
> > > > > > i think all the new files that are needed are missing. like > the WEB-INF/security.xml and the new jars, etc.
> > > > > >
> > > > > > maybe you can package that stuff up in a zip file and add > that to the wiki as well?
> > > > > >
> > > > > > -- Allen
> > > > > >
> > > > > >
> > > > > > On Wed, 2005-09-28 at 11:26, Matt Raible wrote:
> > > > > > > It's attached to the proposal.
> > > > > > >
> > > > > > > > http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AcegiSecurity
> > > > > > >
> > > > > > > Please note the remaining issues listed on the wiki.
> > > > > > >
> > > > > > > Matt
> > > > > > >
> > > > > > > On 9/28/05, Allen Gilliland <Al...@sun.com> > wrote:
> > > > > > > > Matt,
> > > > > > > >
> > > > > > > > I wasn't able to recieve the patch you sent with this > email probably because it got caught by a spam filter or > something.
> > > > > > > >
> > > > > > > > can you possibly post it somewhere on the web so I can > grab it?
> > > > > > > >
> > > > > > > > -- Allen
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 2005-09-19 at 16:36, Matt Raible wrote:
> > > > > > > > > On 9/17/05, Allen Gilliland > <Al...@sun.com> wrote:
> > > > > > > > > > cool ... this sounds like a welcome improvement over > CMA.
> > > > > > > > > >
> > > > > > > > > > i know we've talked about using Acegi on the list > before, but is there a
> > > > > > > > > > proposal plan that outlines genrally how Acegi > integration works, what
> > > > > > > > > > new classes would be created, and how SSO would tie > in?
> > > > > > > > >
> > > > > > > > > No, I should do this. First, I wanted to prove that > it would actually
> > > > > > > > > work. As far as SSO, Acegi integrates with Yale's CAS > system - more
> > > > > > > > > information is available in Acegi's documentation.
> > > > > > > > >
> > > > > > > > > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
> > > > > > > > >
> > > > > > > > > If you look at the forum link below, you'll see I got > an answer to my
> > > > > > > > > question and was able to get everything working > today. I've attached
> > > > > > > > > a patch of what changes in existing classes.
> > > > > > > > >
> > > > > > > > > The biggest change is that a lot of the startup logic > in LoginServlet
> > > > > > > > > moved to RollerContext (where everything else is > initialized). Other
> > > > > > > > > changes include removing the secure and unsecure port > numbers in
> > > > > > > > > roller.properties. This is because Acegi defaults to > 8443 (when using
> > > > > > > > > 8080 for http://) and 443 (when using 80 for http://).
> > > > > > > > >
> > > > > > > > > The one thing I haven't done in this patch is to > remove the UserCookie
> > > > > > > > > object (and code from UserManager) - but this will no > longer be
> > > > > > > > > necessary either.
> > > > > > > > >
> > > > > > > > > I'll try to write up a proposal on the wiki in the > next day or two.
> > > > > > > > > Any suggestions on an existing proposal to use for a > template?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > Matt
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -- Allen
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sat, 2005-09-17 at 08:34, Matt Raible wrote:
> > > > > > > > > > > FYI...
> > > > > > > > > > >
> > > > > > > > > > > I did some work yesterday to create a version of > Roller that uses
> > > > > > > > > > > Acegi Security for its security mechanism as an > alternative to CMA.
> > > > > > > > > > > It's my believe that this should be possible w/o > changing a single
> > > > > > > > > > > line of Java code. In fact, it should result in > deleting quite a bit
> > > > > > > > > > > of code (LoginServlet, LoginFilter, UserCookie, > etc.).
> > > > > > > > > > >
> > > > > > > > > > > However, I've run into one issue.
> > > > > > > > > > >
> > > > > > > > > > > <snip>
> > > > > > > > > > > Principal principal = request.getUserPrincipal();
> > > > > > > > > > > String username = principal.getName();
> > > > > > > > > > >
> > > > > > > > > > > With CMA, this returns "mraible" (my login name). > However, with Acegi,
> > > > > > > > > > > it returns:
> > > > > > > > > > >
> > > > > > > > > > > userName= > "net.sf.acegisecurity.providers.dao.User@a8eaf3: Username:
> > > > > > > > > > > mraible; Password: [PROTECTED]; Enabled: true; > AccountNonExpired:
> > > > > > > > > > > true; credentialsNonExpired: true; > AccountNonLocked: true; Granted
> > > > > > > > > > > Authorities: editor"
> > > > > > > > > > > </snip>
> > > > > > > > > > >
> > > > > > > > > > > I've posted this to the Acegi Security forums, but > haven't had a response yet.
> > > > > > > > > > >
> > > > > > > > > > > > http://forum.springframework.org/viewtopic.php?t=8917
> > > > > > > > > > >
> > > > > > > > > > > I suspect it's a bug. A workaround is to use > request.getRemoteUser(),
> > > > > > > > > > > but I'd rather see this fixed in Acegi.
> > > > > > > > > > >
> > > > > > > > > > > To reiterate why I'm doing this little experiment: > it's because Acegi
> > > > > > > > > > > has more fine-grained control of security - > allowing you to get a
> > > > > > > > > > > user's role or information in any layer (b/c the > information is stored
> > > > > > > > > > > in a thread local). Furthermore, it has Remember > Me and SSL Switching
> > > > > > > > > > > built in.
> > > > > > > > > > >
> > > > > > > > > > > AppFuse had the same setup that Roller has at one > point. In fact, most
> > > > > > > > > > > of the Login/RememberMe/SSL Switching is from > AppFuse. I switched to
> > > > > > > > > > > Acegi in AppFuse about 6 months ago and it's > resulted in nothing but
> > > > > > > > > > > good things. We've been able to plug a few > security holes that
> > > > > > > > > > > would've been more difficult if we were using CMA.
> > > > > > > > > > >
> > > > > > > > > > > Another good reason to switch is this will get us > away from something
> > > > > > > > > > > users complain about often: the redirect to > j_security_check - where
> > > > > > > > > > > the password is shown in the URL.
> > > > > > > > > > >
> > > > > > > > > > > Have a good weekend,
> > > > > > > > > > >
> > > > > > > > > > > Matt
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
>
>
Re: Acegi Integration Status
Posted by Allen Gilliland <Al...@Sun.COM>.
On Mon, 2005-11-07 at 09:10, Matt Raible wrote:
> > >
> > > 2. how does the port switching and scheme enforcement work? we still want to make sure that secure logins work between any 2 configurable ports and that we support the use of a custom secure login header.
>
> By default, 80 switches to 443 and 8080 switches to 8443. These are
> configurable.
how are they configurable? where do you modify them? can we do it via the roller.properties config?
also, where would be be able to plugin some logic for checking a custom header? i.e. an http request with a custom header can be considered secure.
>
> > >
> > > 3. how easy is it to add support for authenticating against 3rd party systems using custom dbs, ldap, etc?
>
> It's just a matter of writing a new Provider DAO. LDAP support is in
> CVS, but they've had some issues in finding someone to support it.
That's fine. I suppose a custom SSO support can work the same way correct? Just write a custom Provider DAO which talks to your SSO system and you are set.
-- Allen
>
> Hope this helps,
>
> Matt
>
> > >
> > > -- Allen
> > >
> > >
> > > On Tue, 2005-10-04 at 13:33, Matt Raible wrote:
> > > > Sorry it took me so long - this kinda got lost in my inbox.
> > > >
> > > > I've updated my local project with 2.0 from SVN and uploaded the code > to the following URL. It should have .svn folders in it so you can > diff it against the roller_2.0 branch.
> > > >
> > > > http://static.raibledesigns.com/downloads/roller-2.0-withacegi.tar.gz
> > > >
> > > > It's 47 MB.
> > > >
> > > > Thanks,
> > > >
> > > > Matt
> > > >
> > > > On 9/29/05, Matt Raible <mr...@gmail.com> wrote:
> > > > I'll try to do that later tonight.
> > > >
> > > > Thanks,
> > > >
> > > > Matt
> > > >
> > > > On 9/29/05, Allen Gilliland <Al...@sun.com> wrote:
> > > > > Matt,
> > > > >
> > > > > i think all the new files that are needed are missing. like > the WEB-INF/security.xml and the new jars, etc.
> > > > >
> > > > > maybe you can package that stuff up in a zip file and add > that to the wiki as well?
> > > > >
> > > > > -- Allen
> > > > >
> > > > >
> > > > > On Wed, 2005-09-28 at 11:26, Matt Raible wrote:
> > > > > > It's attached to the proposal.
> > > > > >
> > > > > > > http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AcegiSecurity
> > > > > >
> > > > > > Please note the remaining issues listed on the wiki.
> > > > > >
> > > > > > Matt
> > > > > >
> > > > > > On 9/28/05, Allen Gilliland <Al...@sun.com> > wrote:
> > > > > > > Matt,
> > > > > > >
> > > > > > > I wasn't able to recieve the patch you sent with this > email probably because it got caught by a spam filter or > something.
> > > > > > >
> > > > > > > can you possibly post it somewhere on the web so I can > grab it?
> > > > > > >
> > > > > > > -- Allen
> > > > > > >
> > > > > > >
> > > > > > > On Mon, 2005-09-19 at 16:36, Matt Raible wrote:
> > > > > > > > On 9/17/05, Allen Gilliland > <Al...@sun.com> wrote:
> > > > > > > > > cool ... this sounds like a welcome improvement over > CMA.
> > > > > > > > >
> > > > > > > > > i know we've talked about using Acegi on the list > before, but is there a
> > > > > > > > > proposal plan that outlines genrally how Acegi > integration works, what
> > > > > > > > > new classes would be created, and how SSO would tie > in?
> > > > > > > >
> > > > > > > > No, I should do this. First, I wanted to prove that > it would actually
> > > > > > > > work. As far as SSO, Acegi integrates with Yale's CAS > system - more
> > > > > > > > information is available in Acegi's documentation.
> > > > > > > >
> > > > > > > > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
> > > > > > > >
> > > > > > > > If you look at the forum link below, you'll see I got > an answer to my
> > > > > > > > question and was able to get everything working > today. I've attached
> > > > > > > > a patch of what changes in existing classes.
> > > > > > > >
> > > > > > > > The biggest change is that a lot of the startup logic > in LoginServlet
> > > > > > > > moved to RollerContext (where everything else is > initialized). Other
> > > > > > > > changes include removing the secure and unsecure port > numbers in
> > > > > > > > roller.properties. This is because Acegi defaults to > 8443 (when using
> > > > > > > > 8080 for http://) and 443 (when using 80 for http://).
> > > > > > > >
> > > > > > > > The one thing I haven't done in this patch is to > remove the UserCookie
> > > > > > > > object (and code from UserManager) - but this will no > longer be
> > > > > > > > necessary either.
> > > > > > > >
> > > > > > > > I'll try to write up a proposal on the wiki in the > next day or two.
> > > > > > > > Any suggestions on an existing proposal to use for a > template?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Matt
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > -- Allen
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sat, 2005-09-17 at 08:34, Matt Raible wrote:
> > > > > > > > > > FYI...
> > > > > > > > > >
> > > > > > > > > > I did some work yesterday to create a version of > Roller that uses
> > > > > > > > > > Acegi Security for its security mechanism as an > alternative to CMA.
> > > > > > > > > > It's my believe that this should be possible w/o > changing a single
> > > > > > > > > > line of Java code. In fact, it should result in > deleting quite a bit
> > > > > > > > > > of code (LoginServlet, LoginFilter, UserCookie, > etc.).
> > > > > > > > > >
> > > > > > > > > > However, I've run into one issue.
> > > > > > > > > >
> > > > > > > > > > <snip>
> > > > > > > > > > Principal principal = request.getUserPrincipal();
> > > > > > > > > > String username = principal.getName();
> > > > > > > > > >
> > > > > > > > > > With CMA, this returns "mraible" (my login name). > However, with Acegi,
> > > > > > > > > > it returns:
> > > > > > > > > >
> > > > > > > > > > userName= > "net.sf.acegisecurity.providers.dao.User@a8eaf3: Username:
> > > > > > > > > > mraible; Password: [PROTECTED]; Enabled: true; > AccountNonExpired:
> > > > > > > > > > true; credentialsNonExpired: true; > AccountNonLocked: true; Granted
> > > > > > > > > > Authorities: editor"
> > > > > > > > > > </snip>
> > > > > > > > > >
> > > > > > > > > > I've posted this to the Acegi Security forums, but > haven't had a response yet.
> > > > > > > > > >
> > > > > > > > > > > http://forum.springframework.org/viewtopic.php?t=8917
> > > > > > > > > >
> > > > > > > > > > I suspect it's a bug. A workaround is to use > request.getRemoteUser(),
> > > > > > > > > > but I'd rather see this fixed in Acegi.
> > > > > > > > > >
> > > > > > > > > > To reiterate why I'm doing this little experiment: > it's because Acegi
> > > > > > > > > > has more fine-grained control of security - > allowing you to get a
> > > > > > > > > > user's role or information in any layer (b/c the > information is stored
> > > > > > > > > > in a thread local). Furthermore, it has Remember > Me and SSL Switching
> > > > > > > > > > built in.
> > > > > > > > > >
> > > > > > > > > > AppFuse had the same setup that Roller has at one > point. In fact, most
> > > > > > > > > > of the Login/RememberMe/SSL Switching is from > AppFuse. I switched to
> > > > > > > > > > Acegi in AppFuse about 6 months ago and it's > resulted in nothing but
> > > > > > > > > > good things. We've been able to plug a few > security holes that
> > > > > > > > > > would've been more difficult if we were using CMA.
> > > > > > > > > >
> > > > > > > > > > Another good reason to switch is this will get us > away from something
> > > > > > > > > > users complain about often: the redirect to > j_security_check - where
> > > > > > > > > > the password is shown in the URL.
> > > > > > > > > >
> > > > > > > > > > Have a good weekend,
> > > > > > > > > >
> > > > > > > > > > Matt
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
Re: Acegi Integration Status
Posted by Matt Raible <mr...@gmail.com>.
Boy am I a slacker... sorry - I've been traveling for the last two
weeks. Comments below...
On 10/10/05, Matt Raible <mr...@gmail.com> wrote:
> I'm out of town on vacation right now - and it'll take me a bit of
> digging into Acegi's documentation to answer these questions. I'll
> try to do it by the end of this week. In the meantime, you could
> consult the Acegi Security documentation.
>
> http://acegisecurity.sourceforge.net/reference.html
>
> Matt
>
> On 10/6/05, Allen Gilliland <Al...@sun.com> wrote:
> > sorry this is so late, but I finally spent a little time playing with the acegi integration stuff and it has worked well for me so far. hopefully next week i can spend a little more time understanding the details.
> >
> > the few items i am still unsure of and would like to understand better are ..
> >
> > 1. how exactly does SSO work and how easy is it for users to plugin a customized SSO module assuming roller is using Acegi? i expect that lots of customers will need to integrate roller with custom SSO solutions, so we'll want this to be as flexible as possible.
For SSO, AFAIK, Acegi only directly supports Yale's Central
Authentication Service (CAS) out of the box.
http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
However, you can also use CMA with Acegi (there are adapters for the
major appservers), so I imagine that anything that works with CMA can
be configured to work with Acegi+CMA. The nice thing about Acegi is
it is extensible, so it shouldn't be too difficult for someone to
write a new SSO module. This is a big advantage over CMA IMHO, b/c
there is no API for CMA (at least not in the current servlet specs).
There is talk about adding a SPI for CMA, but it probably won't be
until Servlet 2.6 or 2.7 (or maybe they'll jump to 3.0).
FWIW, it looks like SiteMinder is supported.
http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
> >
> > 2. how does the port switching and scheme enforcement work? we still want to make sure that secure logins work between any 2 configurable ports and that we support the use of a custom secure login header.
By default, 80 switches to 443 and 8080 switches to 8443. These are
configurable.
> >
> > 3. how easy is it to add support for authenticating against 3rd party systems using custom dbs, ldap, etc?
It's just a matter of writing a new Provider DAO. LDAP support is in
CVS, but they've had some issues in finding someone to support it.
Hope this helps,
Matt
> >
> > -- Allen
> >
> >
> > On Tue, 2005-10-04 at 13:33, Matt Raible wrote:
> > > Sorry it took me so long - this kinda got lost in my inbox.
> > >
> > > I've updated my local project with 2.0 from SVN and uploaded the code > to the following URL. It should have .svn folders in it so you can > diff it against the roller_2.0 branch.
> > >
> > > http://static.raibledesigns.com/downloads/roller-2.0-withacegi.tar.gz
> > >
> > > It's 47 MB.
> > >
> > > Thanks,
> > >
> > > Matt
> > >
> > > On 9/29/05, Matt Raible <mr...@gmail.com> wrote:
> > > I'll try to do that later tonight.
> > >
> > > Thanks,
> > >
> > > Matt
> > >
> > > On 9/29/05, Allen Gilliland <Al...@sun.com> wrote:
> > > > Matt,
> > > >
> > > > i think all the new files that are needed are missing. like > the WEB-INF/security.xml and the new jars, etc.
> > > >
> > > > maybe you can package that stuff up in a zip file and add > that to the wiki as well?
> > > >
> > > > -- Allen
> > > >
> > > >
> > > > On Wed, 2005-09-28 at 11:26, Matt Raible wrote:
> > > > > It's attached to the proposal.
> > > > >
> > > > > > http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AcegiSecurity
> > > > >
> > > > > Please note the remaining issues listed on the wiki.
> > > > >
> > > > > Matt
> > > > >
> > > > > On 9/28/05, Allen Gilliland <Al...@sun.com> > wrote:
> > > > > > Matt,
> > > > > >
> > > > > > I wasn't able to recieve the patch you sent with this > email probably because it got caught by a spam filter or > something.
> > > > > >
> > > > > > can you possibly post it somewhere on the web so I can > grab it?
> > > > > >
> > > > > > -- Allen
> > > > > >
> > > > > >
> > > > > > On Mon, 2005-09-19 at 16:36, Matt Raible wrote:
> > > > > > > On 9/17/05, Allen Gilliland > <Al...@sun.com> wrote:
> > > > > > > > cool ... this sounds like a welcome improvement over > CMA.
> > > > > > > >
> > > > > > > > i know we've talked about using Acegi on the list > before, but is there a
> > > > > > > > proposal plan that outlines genrally how Acegi > integration works, what
> > > > > > > > new classes would be created, and how SSO would tie > in?
> > > > > > >
> > > > > > > No, I should do this. First, I wanted to prove that > it would actually
> > > > > > > work. As far as SSO, Acegi integrates with Yale's CAS > system - more
> > > > > > > information is available in Acegi's documentation.
> > > > > > >
> > > > > > > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
> > > > > > >
> > > > > > > If you look at the forum link below, you'll see I got > an answer to my
> > > > > > > question and was able to get everything working > today. I've attached
> > > > > > > a patch of what changes in existing classes.
> > > > > > >
> > > > > > > The biggest change is that a lot of the startup logic > in LoginServlet
> > > > > > > moved to RollerContext (where everything else is > initialized). Other
> > > > > > > changes include removing the secure and unsecure port > numbers in
> > > > > > > roller.properties. This is because Acegi defaults to > 8443 (when using
> > > > > > > 8080 for http://) and 443 (when using 80 for http://).
> > > > > > >
> > > > > > > The one thing I haven't done in this patch is to > remove the UserCookie
> > > > > > > object (and code from UserManager) - but this will no > longer be
> > > > > > > necessary either.
> > > > > > >
> > > > > > > I'll try to write up a proposal on the wiki in the > next day or two.
> > > > > > > Any suggestions on an existing proposal to use for a > template?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Matt
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > -- Allen
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, 2005-09-17 at 08:34, Matt Raible wrote:
> > > > > > > > > FYI...
> > > > > > > > >
> > > > > > > > > I did some work yesterday to create a version of > Roller that uses
> > > > > > > > > Acegi Security for its security mechanism as an > alternative to CMA.
> > > > > > > > > It's my believe that this should be possible w/o > changing a single
> > > > > > > > > line of Java code. In fact, it should result in > deleting quite a bit
> > > > > > > > > of code (LoginServlet, LoginFilter, UserCookie, > etc.).
> > > > > > > > >
> > > > > > > > > However, I've run into one issue.
> > > > > > > > >
> > > > > > > > > <snip>
> > > > > > > > > Principal principal = request.getUserPrincipal();
> > > > > > > > > String username = principal.getName();
> > > > > > > > >
> > > > > > > > > With CMA, this returns "mraible" (my login name). > However, with Acegi,
> > > > > > > > > it returns:
> > > > > > > > >
> > > > > > > > > userName= > "net.sf.acegisecurity.providers.dao.User@a8eaf3: Username:
> > > > > > > > > mraible; Password: [PROTECTED]; Enabled: true; > AccountNonExpired:
> > > > > > > > > true; credentialsNonExpired: true; > AccountNonLocked: true; Granted
> > > > > > > > > Authorities: editor"
> > > > > > > > > </snip>
> > > > > > > > >
> > > > > > > > > I've posted this to the Acegi Security forums, but > haven't had a response yet.
> > > > > > > > >
> > > > > > > > > > http://forum.springframework.org/viewtopic.php?t=8917
> > > > > > > > >
> > > > > > > > > I suspect it's a bug. A workaround is to use > request.getRemoteUser(),
> > > > > > > > > but I'd rather see this fixed in Acegi.
> > > > > > > > >
> > > > > > > > > To reiterate why I'm doing this little experiment: > it's because Acegi
> > > > > > > > > has more fine-grained control of security - > allowing you to get a
> > > > > > > > > user's role or information in any layer (b/c the > information is stored
> > > > > > > > > in a thread local). Furthermore, it has Remember > Me and SSL Switching
> > > > > > > > > built in.
> > > > > > > > >
> > > > > > > > > AppFuse had the same setup that Roller has at one > point. In fact, most
> > > > > > > > > of the Login/RememberMe/SSL Switching is from > AppFuse. I switched to
> > > > > > > > > Acegi in AppFuse about 6 months ago and it's > resulted in nothing but
> > > > > > > > > good things. We've been able to plug a few > security holes that
> > > > > > > > > would've been more difficult if we were using CMA.
> > > > > > > > >
> > > > > > > > > Another good reason to switch is this will get us > away from something
> > > > > > > > > users complain about often: the redirect to > j_security_check - where
> > > > > > > > > the password is shown in the URL.
> > > > > > > > >
> > > > > > > > > Have a good weekend,
> > > > > > > > >
> > > > > > > > > Matt
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Acegi Integration Status
Posted by Matt Raible <mr...@gmail.com>.
I'm out of town on vacation right now - and it'll take me a bit of
digging into Acegi's documentation to answer these questions. I'll
try to do it by the end of this week. In the meantime, you could
consult the Acegi Security documentation.
http://acegisecurity.sourceforge.net/reference.html
Matt
On 10/6/05, Allen Gilliland <Al...@sun.com> wrote:
> sorry this is so late, but I finally spent a little time playing with the acegi integration stuff and it has worked well for me so far. hopefully next week i can spend a little more time understanding the details.
>
> the few items i am still unsure of and would like to understand better are ..
>
> 1. how exactly does SSO work and how easy is it for users to plugin a customized SSO module assuming roller is using Acegi? i expect that lots of customers will need to integrate roller with custom SSO solutions, so we'll want this to be as flexible as possible.
>
> 2. how does the port switching and scheme enforcement work? we still want to make sure that secure logins work between any 2 configurable ports and that we support the use of a custom secure login header.
>
> 3. how easy is it to add support for authenticating against 3rd party systems using custom dbs, ldap, etc?
>
> -- Allen
>
>
> On Tue, 2005-10-04 at 13:33, Matt Raible wrote:
> > Sorry it took me so long - this kinda got lost in my inbox.
> >
> > I've updated my local project with 2.0 from SVN and uploaded the code > to the following URL. It should have .svn folders in it so you can > diff it against the roller_2.0 branch.
> >
> > http://static.raibledesigns.com/downloads/roller-2.0-withacegi.tar.gz
> >
> > It's 47 MB.
> >
> > Thanks,
> >
> > Matt
> >
> > On 9/29/05, Matt Raible <mr...@gmail.com> wrote:
> > I'll try to do that later tonight.
> >
> > Thanks,
> >
> > Matt
> >
> > On 9/29/05, Allen Gilliland <Al...@sun.com> wrote:
> > > Matt,
> > >
> > > i think all the new files that are needed are missing. like > the WEB-INF/security.xml and the new jars, etc.
> > >
> > > maybe you can package that stuff up in a zip file and add > that to the wiki as well?
> > >
> > > -- Allen
> > >
> > >
> > > On Wed, 2005-09-28 at 11:26, Matt Raible wrote:
> > > > It's attached to the proposal.
> > > >
> > > > > http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AcegiSecurity
> > > >
> > > > Please note the remaining issues listed on the wiki.
> > > >
> > > > Matt
> > > >
> > > > On 9/28/05, Allen Gilliland <Al...@sun.com> > wrote:
> > > > > Matt,
> > > > >
> > > > > I wasn't able to recieve the patch you sent with this > email probably because it got caught by a spam filter or > something.
> > > > >
> > > > > can you possibly post it somewhere on the web so I can > grab it?
> > > > >
> > > > > -- Allen
> > > > >
> > > > >
> > > > > On Mon, 2005-09-19 at 16:36, Matt Raible wrote:
> > > > > > On 9/17/05, Allen Gilliland > <Al...@sun.com> wrote:
> > > > > > > cool ... this sounds like a welcome improvement over > CMA.
> > > > > > >
> > > > > > > i know we've talked about using Acegi on the list > before, but is there a
> > > > > > > proposal plan that outlines genrally how Acegi > integration works, what
> > > > > > > new classes would be created, and how SSO would tie > in?
> > > > > >
> > > > > > No, I should do this. First, I wanted to prove that > it would actually
> > > > > > work. As far as SSO, Acegi integrates with Yale's CAS > system - more
> > > > > > information is available in Acegi's documentation.
> > > > > >
> > > > > > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
> > > > > >
> > > > > > If you look at the forum link below, you'll see I got > an answer to my
> > > > > > question and was able to get everything working > today. I've attached
> > > > > > a patch of what changes in existing classes.
> > > > > >
> > > > > > The biggest change is that a lot of the startup logic > in LoginServlet
> > > > > > moved to RollerContext (where everything else is > initialized). Other
> > > > > > changes include removing the secure and unsecure port > numbers in
> > > > > > roller.properties. This is because Acegi defaults to > 8443 (when using
> > > > > > 8080 for http://) and 443 (when using 80 for http://).
> > > > > >
> > > > > > The one thing I haven't done in this patch is to > remove the UserCookie
> > > > > > object (and code from UserManager) - but this will no > longer be
> > > > > > necessary either.
> > > > > >
> > > > > > I'll try to write up a proposal on the wiki in the > next day or two.
> > > > > > Any suggestions on an existing proposal to use for a > template?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Matt
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > -- Allen
> > > > > > >
> > > > > > >
> > > > > > > On Sat, 2005-09-17 at 08:34, Matt Raible wrote:
> > > > > > > > FYI...
> > > > > > > >
> > > > > > > > I did some work yesterday to create a version of > Roller that uses
> > > > > > > > Acegi Security for its security mechanism as an > alternative to CMA.
> > > > > > > > It's my believe that this should be possible w/o > changing a single
> > > > > > > > line of Java code. In fact, it should result in > deleting quite a bit
> > > > > > > > of code (LoginServlet, LoginFilter, UserCookie, > etc.).
> > > > > > > >
> > > > > > > > However, I've run into one issue.
> > > > > > > >
> > > > > > > > <snip>
> > > > > > > > Principal principal = request.getUserPrincipal();
> > > > > > > > String username = principal.getName();
> > > > > > > >
> > > > > > > > With CMA, this returns "mraible" (my login name). > However, with Acegi,
> > > > > > > > it returns:
> > > > > > > >
> > > > > > > > userName= > "net.sf.acegisecurity.providers.dao.User@a8eaf3: Username:
> > > > > > > > mraible; Password: [PROTECTED]; Enabled: true; > AccountNonExpired:
> > > > > > > > true; credentialsNonExpired: true; > AccountNonLocked: true; Granted
> > > > > > > > Authorities: editor"
> > > > > > > > </snip>
> > > > > > > >
> > > > > > > > I've posted this to the Acegi Security forums, but > haven't had a response yet.
> > > > > > > >
> > > > > > > > > http://forum.springframework.org/viewtopic.php?t=8917
> > > > > > > >
> > > > > > > > I suspect it's a bug. A workaround is to use > request.getRemoteUser(),
> > > > > > > > but I'd rather see this fixed in Acegi.
> > > > > > > >
> > > > > > > > To reiterate why I'm doing this little experiment: > it's because Acegi
> > > > > > > > has more fine-grained control of security - > allowing you to get a
> > > > > > > > user's role or information in any layer (b/c the > information is stored
> > > > > > > > in a thread local). Furthermore, it has Remember > Me and SSL Switching
> > > > > > > > built in.
> > > > > > > >
> > > > > > > > AppFuse had the same setup that Roller has at one > point. In fact, most
> > > > > > > > of the Login/RememberMe/SSL Switching is from > AppFuse. I switched to
> > > > > > > > Acegi in AppFuse about 6 months ago and it's > resulted in nothing but
> > > > > > > > good things. We've been able to plug a few > security holes that
> > > > > > > > would've been more difficult if we were using CMA.
> > > > > > > >
> > > > > > > > Another good reason to switch is this will get us > away from something
> > > > > > > > users complain about often: the redirect to > j_security_check - where
> > > > > > > > the password is shown in the URL.
> > > > > > > >
> > > > > > > > Have a good weekend,
> > > > > > > >
> > > > > > > > Matt
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
> >
>
>
Re: Acegi Integration Status
Posted by Allen Gilliland <Al...@Sun.COM>.
sorry this is so late, but I finally spent a little time playing with the acegi integration stuff and it has worked well for me so far. hopefully next week i can spend a little more time understanding the details.
the few items i am still unsure of and would like to understand better are ..
1. how exactly does SSO work and how easy is it for users to plugin a customized SSO module assuming roller is using Acegi? i expect that lots of customers will need to integrate roller with custom SSO solutions, so we'll want this to be as flexible as possible.
2. how does the port switching and scheme enforcement work? we still want to make sure that secure logins work between any 2 configurable ports and that we support the use of a custom secure login header.
3. how easy is it to add support for authenticating against 3rd party systems using custom dbs, ldap, etc?
-- Allen
On Tue, 2005-10-04 at 13:33, Matt Raible wrote:
> Sorry it took me so long - this kinda got lost in my inbox.
>
> I've updated my local project with 2.0 from SVN and uploaded the code > to the following URL. It should have .svn folders in it so you can > diff it against the roller_2.0 branch.
>
> http://static.raibledesigns.com/downloads/roller-2.0-withacegi.tar.gz
>
> It's 47 MB.
>
> Thanks,
>
> Matt
>
> On 9/29/05, Matt Raible <mr...@gmail.com> wrote:
> I'll try to do that later tonight.
>
> Thanks,
>
> Matt
>
> On 9/29/05, Allen Gilliland <Al...@sun.com> wrote:
> > Matt,
> >
> > i think all the new files that are needed are missing. like > the WEB-INF/security.xml and the new jars, etc.
> >
> > maybe you can package that stuff up in a zip file and add > that to the wiki as well?
> >
> > -- Allen
> >
> >
> > On Wed, 2005-09-28 at 11:26, Matt Raible wrote:
> > > It's attached to the proposal.
> > >
> > > > http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AcegiSecurity
> > >
> > > Please note the remaining issues listed on the wiki.
> > >
> > > Matt
> > >
> > > On 9/28/05, Allen Gilliland <Al...@sun.com> > wrote:
> > > > Matt,
> > > >
> > > > I wasn't able to recieve the patch you sent with this > email probably because it got caught by a spam filter or > something.
> > > >
> > > > can you possibly post it somewhere on the web so I can > grab it?
> > > >
> > > > -- Allen
> > > >
> > > >
> > > > On Mon, 2005-09-19 at 16:36, Matt Raible wrote:
> > > > > On 9/17/05, Allen Gilliland > <Al...@sun.com> wrote:
> > > > > > cool ... this sounds like a welcome improvement over > CMA.
> > > > > >
> > > > > > i know we've talked about using Acegi on the list > before, but is there a
> > > > > > proposal plan that outlines genrally how Acegi > integration works, what
> > > > > > new classes would be created, and how SSO would tie > in?
> > > > >
> > > > > No, I should do this. First, I wanted to prove that > it would actually
> > > > > work. As far as SSO, Acegi integrates with Yale's CAS > system - more
> > > > > information is available in Acegi's documentation.
> > > > >
> > > > > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas
> > > > >
> > > > > If you look at the forum link below, you'll see I got > an answer to my
> > > > > question and was able to get everything working > today. I've attached
> > > > > a patch of what changes in existing classes.
> > > > >
> > > > > The biggest change is that a lot of the startup logic > in LoginServlet
> > > > > moved to RollerContext (where everything else is > initialized). Other
> > > > > changes include removing the secure and unsecure port > numbers in
> > > > > roller.properties. This is because Acegi defaults to > 8443 (when using
> > > > > 8080 for http://) and 443 (when using 80 for http://).
> > > > >
> > > > > The one thing I haven't done in this patch is to > remove the UserCookie
> > > > > object (and code from UserManager) - but this will no > longer be
> > > > > necessary either.
> > > > >
> > > > > I'll try to write up a proposal on the wiki in the > next day or two.
> > > > > Any suggestions on an existing proposal to use for a > template?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Matt
> > > > >
> > > > >
> > > > > >
> > > > > > -- Allen
> > > > > >
> > > > > >
> > > > > > On Sat, 2005-09-17 at 08:34, Matt Raible wrote:
> > > > > > > FYI...
> > > > > > >
> > > > > > > I did some work yesterday to create a version of > Roller that uses
> > > > > > > Acegi Security for its security mechanism as an > alternative to CMA.
> > > > > > > It's my believe that this should be possible w/o > changing a single
> > > > > > > line of Java code. In fact, it should result in > deleting quite a bit
> > > > > > > of code (LoginServlet, LoginFilter, UserCookie, > etc.).
> > > > > > >
> > > > > > > However, I've run into one issue.
> > > > > > >
> > > > > > > <snip>
> > > > > > > Principal principal = request.getUserPrincipal();
> > > > > > > String username = principal.getName();
> > > > > > >
> > > > > > > With CMA, this returns "mraible" (my login name). > However, with Acegi,
> > > > > > > it returns:
> > > > > > >
> > > > > > > userName= > "net.sf.acegisecurity.providers.dao.User@a8eaf3: Username:
> > > > > > > mraible; Password: [PROTECTED]; Enabled: true; > AccountNonExpired:
> > > > > > > true; credentialsNonExpired: true; > AccountNonLocked: true; Granted
> > > > > > > Authorities: editor"
> > > > > > > </snip>
> > > > > > >
> > > > > > > I've posted this to the Acegi Security forums, but > haven't had a response yet.
> > > > > > >
> > > > > > > > http://forum.springframework.org/viewtopic.php?t=8917
> > > > > > >
> > > > > > > I suspect it's a bug. A workaround is to use > request.getRemoteUser(),
> > > > > > > but I'd rather see this fixed in Acegi.
> > > > > > >
> > > > > > > To reiterate why I'm doing this little experiment: > it's because Acegi
> > > > > > > has more fine-grained control of security - > allowing you to get a
> > > > > > > user's role or information in any layer (b/c the > information is stored
> > > > > > > in a thread local). Furthermore, it has Remember > Me and SSL Switching
> > > > > > > built in.
> > > > > > >
> > > > > > > AppFuse had the same setup that Roller has at one > point. In fact, most
> > > > > > > of the Login/RememberMe/SSL Switching is from > AppFuse. I switched to
> > > > > > > Acegi in AppFuse about 6 months ago and it's > resulted in nothing but
> > > > > > > good things. We've been able to plug a few > security holes that
> > > > > > > would've been more difficult if we were using CMA.
> > > > > > >
> > > > > > > Another good reason to switch is this will get us > away from something
> > > > > > > users complain about often: the redirect to > j_security_check - where
> > > > > > > the password is shown in the URL.
> > > > > > >
> > > > > > > Have a good weekend,
> > > > > > >
> > > > > > > Matt
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
>