On Fri, 2005-11-18 at 12:57, Matt Raible wrote: > On 11/17/05, Allen Gilliland <[EMAIL PROTECTED]> 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 <[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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
