roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Gilliland <Allen.T.Gillil...@Sun.COM>
Subject Re: Acegi Integration Status
Date Thu, 06 Oct 2005 23:55:47 GMT
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 <mraible@gmail.com> wrote:
>         I'll try to do that later tonight.
>         
>         Thanks,
>         
>         Matt
>         
>         On 9/29/05, Allen Gilliland <Allen.T.Gilliland@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 <Allen.T.Gilliland@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 >         <Allen.T.Gilliland@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 
>         > > > > >
>         > > > > >
>         > > >
>         > > >
>         >
>         >
> 


Mime
View raw message