Boy am I a slacker... sorry - I've been traveling for the last two
weeks.  Comments below...

On 10/10/05, Matt Raible <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > >         I'll try to do that later tonight.
> > >
> > >         Thanks,
> > >
> > >         Matt
> > >
> > >         On 9/29/05, Allen Gilliland <[EMAIL PROTECTED]> 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 <[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
> > >         > > > > >
> > >         > > > > >
> > >         > > >
> > >         > > >
> > >         >
> > >         >
> > >
> >
> >
>

Reply via email to