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 <[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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
