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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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= "[EMAIL PROTECTED]: 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 > > > > > > > >
