You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave <sn...@gmail.com> on 2007/02/01 15:33:29 UTC
Documenting Roller/LDAP setup
We gained some SSO options back in the 3.0 timeframe, but we never got
any documentation (please correct me if I am wrong) about how to setup
Roller to take advantage of those options.
By using those SSO options and tweaking the LDAP configuration in
Acegi security.xml, it is possible to get Roller working with LDAP.
With this setup, when a new user registers for Roller we are able to
pull her user information from LDAP and setup a new Roller account for
her. We authentication against LDAP (where passwords are stored) and
keep user info info Roller.
With our current setup, I believe here's how things should work:
1) Enable SSO option
Define a roller-custom.properties file, override the users.sso.enabled
option like so:
users.sso.enabled=true
2) Uncomment the LDAP section in Acegi security.xml
Uncomment the section that begins with:
<!-- Sample LDAP/RollerDB hybrid security configuration
3) Protect the user registration page via Acegi security.xml
In the XML for the filterInvocationInterceptor bean, add the user
registration page to the list of URL patterns in the
objectDefinitionSource as shown below. The new line is the one that
reads " /roller-ui/user.do*=register".
What does this do? It requires the user to have the role "register" in
order to view the user registration page. Therefore he user is shown
the login page and expected to enter their LDAP username and password
-- but we don't tell them that so it's pretty confusing. Once the
login, we know their user info so we are able to pre-populate the user
registration form with information from LDAP.
<bean id="filterInvocationInterceptor"
class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
<property name="authenticationManager" ref="authenticationManager"/>
<property name="accessDecisionManager" ref="accessDecisionManager"/>
<property name="objectDefinitionSource">
<value>
PATTERN_TYPE_APACHE_ANT
/roller-ui/login-redirect.jsp=admin,editor
/roller-ui/yourProfile**=admin,editor
/roller-ui/createWebsite**=admin,editor
/roller-ui/yourWebsites**=admin,editor
/roller-ui/authoring/**=admin,editor
/roller-ui/admin/**=admin
/roller-ui/user.do*=register
/rewrite-status*=admin
</value>
</property>
</bean>
4) Enable LDAP authentication provider via security.xml
In the XML for the authenticationManager bean, comment out the DAO
provider and add in the LDAP provider, as shown below:
<bean id="authenticationManager"
class="org.acegisecurity.providers.ProviderManager">
<property name="providers">
<list>
<!-- <ref local="daoAuthenticationProvider"/> -->
<ref local="ldapAuthProvider"/>
<ref local="anonymousAuthenticationProvider"/>
<!-- rememberMeAuthenticationProvider added programmatically -->
</list>
</property>
</bean>
But that's not all I had to do. I also had to do this:
5) Add LDAP username and password to Acegi security.xml
I've got my LDAP server (OpenDS - https://opends.dev.java.net/ ) setup
to require authentication. So I had to add two new properties to the
initialDirContextFactory bean, as shown below:
<bean id="initialDirContextFactory"
class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
<constructor-arg value="ldap://localhost:1389/dc=example,dc=com"/>
<property name="managerDn">
<value>cn=Directory Manager</value>
</property>
<property name="managerPassword">
<value>password</value>
</property>
</bean>
6) Change LDAP user search to use uid instead of email in Acegi security.xml
In the ldapUserSearch bean, I changed mail={0} to uid={0}. Not sure,
but maybe uid is a better default than mail for most users.
<bean id="ldapUserSearch"
class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
<constructor-arg index="0">
<value></value>
</constructor-arg>
<constructor-arg index="1">
<value>uid={0}</value>
</constructor-arg>
<constructor-arg index="2">
<ref local="initialDirContextFactory" />
</constructor-arg>
<property name="searchSubtree">
<value>true</value>
</property>
</bean>
7) Java code change in
Added "request.getSession().invalidate();" after line 186 in
NewUserAction, as shown below. Without this change, the user will
remain logged in, but with only the role "register". The user will
have to close his browser and restart before being able to login with
their new account.
} else {
// User registered, so go to welcome page
request.setAttribute("contextURL",
RollerRuntimeConfig.getAbsoluteContextURL());
request.getSession().invalidate();
return mapping.findForward("welcome.page");
}
To solve those problems above, I'd like to change security.xml to
include a comments explaining what needs to be done. I'd like to make
that code change in #7 and I'd like to write up a nice friendly wiki
page explaining how to configure Roller and LDAP.
Any comments or suggestions?
- Dave
Re: Documenting Roller/LDAP setup
Posted by Dave <sn...@gmail.com>.
And I should also mention that for #3, I don't want to change the
security.xml to always protect the registration page -- I just want to
document what you need to do to make our existing LDAP integration to
work.
- Dave
Re: Documenting Roller/LDAP setup
Posted by Dave <sn...@gmail.com>.
On 2/1/07, Allen Gilliland <al...@sun.com> wrote:
> Dave wrote:
> > On 2/1/07, Allen Gilliland <al...@sun.com> wrote:
> >> Comments inlin
> >> This part sounds wacky to me. The idea that you are already logged in
> >> but you have to register just seems wrong to me. I think that most of
> >> the time when you have many systems sharing a common authentication/sso
> >> service but want local copies of profile data then that should be done
> >> behind the scenes. I think that in Roller's case the sso account data
> >> can automatically be used to create/update a Roller account.
> >>
> >> If you look at the data we keep for user profiles then I think it makes
> >> sense that all the data can be automatically synced from the sso session
> >> data ... username, password, fullname, email, locale, timezone.
> >
> > In this case there is no SSO session, I'm talking only of LDAP
> > authentication -- not SSO. That's why we have to ask them to login
> > up-front -- they are not already logged in anywhere.
>
> Okay, but technically the situation is the same. Someone who doesn't
> have a Roller account is coming into the system having authenticated
> against some other 3rd party system already, right? So as soon as the
> person has logged in we know what we need to provision an account for them.
Right. As soon as they've logged in. That's is why my instructions say
to add the registration page to the list of protected pages.
Protecting them page forces them to login and then New User Action is
able to fetch their profile info.
Keep in mind, I am describing how Roller's current LDAP/SSO
integration is implemented. I'm not proposing how it should work in
the future. I'm only trying to document it and make it useful as it
stands today.
> So a more complete use case might be this. Assuming a corporate type of
> situation where a company maintains a single ldap directory of all their
> employees and you have setup Roller and want it tied into that directory
> so that Roller just uses their existing ldap profile. Now, employee XXX
> is going to login to Roller for the first time ...
>
> 1. Registration is disabled on Roller because the company ldap directory
> is the real registry.
> 2. The user comes to Roller, clicks the login link, then submits the
> login form with their company ldap username/password.
> 3. Assuming authentication succeeded (against ldap), we now know who the
> user is and have the ability to query ldap for their profile info but
> they have no Roller account in the rolleruser table yet.
> 4. We auto provision their Roller account using data from their ldap
> profile, plugging in all info we can gather and using defaults for the
> rest. The user now has a Roller account based on their ldap account
> details.
> 5. The user is landed on the Main Menu page where all users go after
> just logging in and having no weblogs.
>
> That's how I would expect things to work when authenticating against a
> 3rd party system.
Except for your steps #1 and #2 that is exactly how things work now.
Adding new user logic to the login process is a good RFE for our
LDAP/SSO integration.
> I don't think you should need (or want?) to send these users to the
> registration page. For example, what happens if a user named 'foo' is
> logged in via ldap and gets dumped to the Roller registration page as
> you described, then hacks their username to something different like
> 'blah' before saving? Wouldn't that break the linkage between the ldap
> account and the Roller account?
When the users.enable.sso option is true, a different user form is
shown, one that does not allow the user to set or change the username.
> > The absence of of #7 is a bug that prevents our current LDAP
> > integration from working properly. And adding that invalidate call is
> > completely harmless. We expect users to be in a logged out state after
> > registration anyway.
>
> I am mostly objecting to #7 on principle, I realize that it's not likely
> to cause any problems, but that still doesn't mean it should be in the
> code. To me it doesn't seem like it's really solving anything because
> you shouldn't have to invalidate a persons session after they register,
> so something else in the process is the real problem.
That's how it works now. So technically #7 is a bug fix.
- Dave
Re: Documenting Roller/LDAP setup
Posted by Allen Gilliland <al...@sun.com>.
Dave wrote:
> On 2/1/07, Allen Gilliland <al...@sun.com> wrote:
>> Comments inlin
>> This part sounds wacky to me. The idea that you are already logged in
>> but you have to register just seems wrong to me. I think that most of
>> the time when you have many systems sharing a common authentication/sso
>> service but want local copies of profile data then that should be done
>> behind the scenes. I think that in Roller's case the sso account data
>> can automatically be used to create/update a Roller account.
>>
>> If you look at the data we keep for user profiles then I think it makes
>> sense that all the data can be automatically synced from the sso session
>> data ... username, password, fullname, email, locale, timezone.
>
> In this case there is no SSO session, I'm talking only of LDAP
> authentication -- not SSO. That's why we have to ask them to login
> up-front -- they are not already logged in anywhere.
Okay, but technically the situation is the same. Someone who doesn't
have a Roller account is coming into the system having authenticated
against some other 3rd party system already, right? So as soon as the
person has logged in we know what we need to provision an account for them.
So a more complete use case might be this. Assuming a corporate type of
situation where a company maintains a single ldap directory of all their
employees and you have setup Roller and want it tied into that directory
so that Roller just uses their existing ldap profile. Now, employee XXX
is going to login to Roller for the first time ...
1. Registration is disabled on Roller because the company ldap directory
is the real registry.
2. The user comes to Roller, clicks the login link, then submits the
login form with their company ldap username/password.
3. Assuming authentication succeeded (against ldap), we now know who the
user is and have the ability to query ldap for their profile info but
they have no Roller account in the rolleruser table yet.
4. We auto provision their Roller account using data from their ldap
profile, plugging in all info we can gather and using defaults for the
rest. The user now has a Roller account based on their ldap account
details.
5. The user is landed on the Main Menu page where all users go after
just logging in and having no weblogs.
That's how I would expect things to work when authenticating against a
3rd party system.
I don't think you should need (or want?) to send these users to the
registration page. For example, what happens if a user named 'foo' is
logged in via ldap and gets dumped to the Roller registration page as
you described, then hacks their username to something different like
'blah' before saving? Wouldn't that break the linkage between the ldap
account and the Roller account?
>
>
>> > To solve those problems above, I'd like to change security.xml to
>> > include a comments explaining what needs to be done. I'd like to make
>> > that code change in #7 and I'd like to write up a nice friendly wiki
>> > page explaining how to configure Roller and LDAP.
>>
>> I definitely agree with adding comments in the security.xml on what
>> needs to be done, and I agree that we should have a wiki page describing
>> the process. I'm not really onboard with #3 and #7 though.
>
> I'm not saying that we can't come up with something better, but If you
> want the current LDAP setup to work, then you have to be on board with
> #3 and #7.
Hmmm. I want to make it work, but I guess I am still not understanding
how #3 and #7 are required.
>
> The absence of of #7 is a bug that prevents our current LDAP
> integration from working properly. And adding that invalidate call is
> completely harmless. We expect users to be in a logged out state after
> registration anyway.
I am mostly objecting to #7 on principle, I realize that it's not likely
to cause any problems, but that still doesn't mean it should be in the
code. To me it doesn't seem like it's really solving anything because
you shouldn't have to invalidate a persons session after they register,
so something else in the process is the real problem.
-- Allen
>
> - Dave
Re: Documenting Roller/LDAP setup
Posted by Dave <sn...@gmail.com>.
On 2/1/07, Allen Gilliland <al...@sun.com> wrote:
> Comments inlin
> This part sounds wacky to me. The idea that you are already logged in
> but you have to register just seems wrong to me. I think that most of
> the time when you have many systems sharing a common authentication/sso
> service but want local copies of profile data then that should be done
> behind the scenes. I think that in Roller's case the sso account data
> can automatically be used to create/update a Roller account.
>
> If you look at the data we keep for user profiles then I think it makes
> sense that all the data can be automatically synced from the sso session
> data ... username, password, fullname, email, locale, timezone.
In this case there is no SSO session, I'm talking only of LDAP
authentication -- not SSO. That's why we have to ask them to login
up-front -- they are not already logged in anywhere.
> > To solve those problems above, I'd like to change security.xml to
> > include a comments explaining what needs to be done. I'd like to make
> > that code change in #7 and I'd like to write up a nice friendly wiki
> > page explaining how to configure Roller and LDAP.
>
> I definitely agree with adding comments in the security.xml on what
> needs to be done, and I agree that we should have a wiki page describing
> the process. I'm not really onboard with #3 and #7 though.
I'm not saying that we can't come up with something better, but If you
want the current LDAP setup to work, then you have to be on board with
#3 and #7.
The absence of of #7 is a bug that prevents our current LDAP
integration from working properly. And adding that invalidate call is
completely harmless. We expect users to be in a logged out state after
registration anyway.
- Dave
Re: Documenting Roller/LDAP setup
Posted by Allen Gilliland <al...@sun.com>.
Comments inline below ...
Dave wrote:
> We gained some SSO options back in the 3.0 timeframe, but we never got
> any documentation (please correct me if I am wrong) about how to setup
> Roller to take advantage of those options.
>
> By using those SSO options and tweaking the LDAP configuration in
> Acegi security.xml, it is possible to get Roller working with LDAP.
> With this setup, when a new user registers for Roller we are able to
> pull her user information from LDAP and setup a new Roller account for
> her. We authentication against LDAP (where passwords are stored) and
> keep user info info Roller.
>
> With our current setup, I believe here's how things should work:
>
> 1) Enable SSO option
> Define a roller-custom.properties file, override the users.sso.enabled
> option like so:
> users.sso.enabled=true
>
> 2) Uncomment the LDAP section in Acegi security.xml
> Uncomment the section that begins with:
> <!-- Sample LDAP/RollerDB hybrid security configuration
>
> 3) Protect the user registration page via Acegi security.xml
> In the XML for the filterInvocationInterceptor bean, add the user
> registration page to the list of URL patterns in the
> objectDefinitionSource as shown below. The new line is the one that
> reads " /roller-ui/user.do*=register".
>
> What does this do? It requires the user to have the role "register" in
> order to view the user registration page. Therefore he user is shown
> the login page and expected to enter their LDAP username and password
> -- but we don't tell them that so it's pretty confusing. Once the
> login, we know their user info so we are able to pre-populate the user
> registration form with information from LDAP.
This part sounds wacky to me. The idea that you are already logged in
but you have to register just seems wrong to me. I think that most of
the time when you have many systems sharing a common authentication/sso
service but want local copies of profile data then that should be done
behind the scenes. I think that in Roller's case the sso account data
can automatically be used to create/update a Roller account.
If you look at the data we keep for user profiles then I think it makes
sense that all the data can be automatically synced from the sso session
data ... username, password, fullname, email, locale, timezone.
The main gotcha that I currently see is that Roller publicizes the
account username for some things, but in various cases that is not
desirable. So IMO the way that Roller should be working, and which
solves this problem, is if we add a new "screen name" field to the user
profile and use that as what gets displayed on the site. This way the
username stays hidden and only used for login and screen name can be
whatever the user wants to be known as publicly. We would allow users
to change their screen name whenever they like, which is something that
I know some people have asked for in the past.
So instead of having to force registration for users and deal with that
extra "register" role, we would simply use the provisioning code that
already exists and autosync all profile data when the user first logs in
or is transferred in. Then after the sync has happened the user can be
put on the profile edit page if we need them to choose options for
Roller specific fields.
>
> <bean id="filterInvocationInterceptor"
> class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
> <property name="authenticationManager" ref="authenticationManager"/>
> <property name="accessDecisionManager" ref="accessDecisionManager"/>
> <property name="objectDefinitionSource">
> <value>
> PATTERN_TYPE_APACHE_ANT
> /roller-ui/login-redirect.jsp=admin,editor
> /roller-ui/yourProfile**=admin,editor
> /roller-ui/createWebsite**=admin,editor
> /roller-ui/yourWebsites**=admin,editor
> /roller-ui/authoring/**=admin,editor
> /roller-ui/admin/**=admin
> /roller-ui/user.do*=register
> /rewrite-status*=admin
> </value>
> </property>
> </bean>
>
> 4) Enable LDAP authentication provider via security.xml
> In the XML for the authenticationManager bean, comment out the DAO
> provider and add in the LDAP provider, as shown below:
>
> <bean id="authenticationManager"
> class="org.acegisecurity.providers.ProviderManager">
> <property name="providers">
> <list>
> <!-- <ref local="daoAuthenticationProvider"/> -->
> <ref local="ldapAuthProvider"/>
> <ref local="anonymousAuthenticationProvider"/>
> <!-- rememberMeAuthenticationProvider added
> programmatically -->
> </list>
> </property>
> </bean>
>
> But that's not all I had to do. I also had to do this:
>
> 5) Add LDAP username and password to Acegi security.xml
> I've got my LDAP server (OpenDS - https://opends.dev.java.net/ ) setup
> to require authentication. So I had to add two new properties to the
> initialDirContextFactory bean, as shown below:
>
> <bean id="initialDirContextFactory"
> class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
> <constructor-arg value="ldap://localhost:1389/dc=example,dc=com"/>
> <property name="managerDn">
> <value>cn=Directory Manager</value>
> </property>
> <property name="managerPassword">
> <value>password</value>
> </property>
> </bean>
>
> 6) Change LDAP user search to use uid instead of email in Acegi
> security.xml
> In the ldapUserSearch bean, I changed mail={0} to uid={0}. Not sure,
> but maybe uid is a better default than mail for most users.
>
> <bean id="ldapUserSearch"
> class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
> <constructor-arg index="0">
> <value></value>
> </constructor-arg>
> <constructor-arg index="1">
> <value>uid={0}</value>
> </constructor-arg>
> <constructor-arg index="2">
> <ref local="initialDirContextFactory" />
> </constructor-arg>
> <property name="searchSubtree">
> <value>true</value>
> </property>
> </bean>
>
> 7) Java code change in
> Added "request.getSession().invalidate();" after line 186 in
> NewUserAction, as shown below. Without this change, the user will
> remain logged in, but with only the role "register". The user will
> have to close his browser and restart before being able to login with
> their new account.
>
> } else {
> // User registered, so go to welcome page
> request.setAttribute("contextURL",
> RollerRuntimeConfig.getAbsoluteContextURL());
> request.getSession().invalidate();
> return mapping.findForward("welcome.page");
> }
This one also seems wacky to me. I don't see why you need to remove the
users session in order to fix their login state. And why would the user
need to login again anyways, I thought their session was transferred?
>
> To solve those problems above, I'd like to change security.xml to
> include a comments explaining what needs to be done. I'd like to make
> that code change in #7 and I'd like to write up a nice friendly wiki
> page explaining how to configure Roller and LDAP.
I definitely agree with adding comments in the security.xml on what
needs to be done, and I agree that we should have a wiki page describing
the process. I'm not really onboard with #3 and #7 though.
-- Allen
>
> Any comments or suggestions?
>
> - Dave
RE: Documenting Roller/LDAP setup
Posted by Er...@sanofipasteur.com.
Hi again,
Some of my users (the contractors in fact) are not able to log in.
I think it is due do their CN that does include a "/EXT" string.
Ex : CN=Beausseron\, Julien (sanofi pasteur/EXT)
Do you know if the "/" character can be a cause of the error?
Thanks
Eric
-----Message d'origine-----
De : Dave [mailto:snoopdave@gmail.com]
Envoyé : jeudi 1 février 2007 15:33
À : roller-dev@incubator.apache.org
Objet : Documenting Roller/LDAP setup
We gained some SSO options back in the 3.0 timeframe, but we never got any documentation (please correct me if I am wrong) about how to setup Roller to take advantage of those options.
By using those SSO options and tweaking the LDAP configuration in Acegi security.xml, it is possible to get Roller working with LDAP.
With this setup, when a new user registers for Roller we are able to pull her user information from LDAP and setup a new Roller account for her. We authentication against LDAP (where passwords are stored) and keep user info info Roller.
With our current setup, I believe here's how things should work:
1) Enable SSO option
Define a roller-custom.properties file, override the users.sso.enabled option like so:
users.sso.enabled=true
2) Uncomment the LDAP section in Acegi security.xml Uncomment the section that begins with:
<!-- Sample LDAP/RollerDB hybrid security configuration
3) Protect the user registration page via Acegi security.xml In the XML for the filterInvocationInterceptor bean, add the user registration page to the list of URL patterns in the objectDefinitionSource as shown below. The new line is the one that reads " /roller-ui/user.do*=register".
What does this do? It requires the user to have the role "register" in order to view the user registration page. Therefore he user is shown the login page and expected to enter their LDAP username and password
-- but we don't tell them that so it's pretty confusing. Once the login, we know their user info so we are able to pre-populate the user registration form with information from LDAP.
<bean id="filterInvocationInterceptor"
class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
<property name="authenticationManager" ref="authenticationManager"/>
<property name="accessDecisionManager" ref="accessDecisionManager"/>
<property name="objectDefinitionSource">
<value>
PATTERN_TYPE_APACHE_ANT
/roller-ui/login-redirect.jsp=admin,editor
/roller-ui/yourProfile**=admin,editor
/roller-ui/createWebsite**=admin,editor
/roller-ui/yourWebsites**=admin,editor
/roller-ui/authoring/**=admin,editor
/roller-ui/admin/**=admin
/roller-ui/user.do*=register
/rewrite-status*=admin
</value>
</property>
</bean>
4) Enable LDAP authentication provider via security.xml In the XML for the authenticationManager bean, comment out the DAO provider and add in the LDAP provider, as shown below:
<bean id="authenticationManager"
class="org.acegisecurity.providers.ProviderManager">
<property name="providers">
<list>
<!-- <ref local="daoAuthenticationProvider"/> -->
<ref local="ldapAuthProvider"/>
<ref local="anonymousAuthenticationProvider"/>
<!-- rememberMeAuthenticationProvider added programmatically -->
</list>
</property>
</bean>
But that's not all I had to do. I also had to do this:
5) Add LDAP username and password to Acegi security.xml I've got my LDAP server (OpenDS - https://opends.dev.java.net/ ) setup to require authentication. So I had to add two new properties to the initialDirContextFactory bean, as shown below:
<bean id="initialDirContextFactory"
class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
<constructor-arg value="ldap://localhost:1389/dc=example,dc=com"/>
<property name="managerDn">
<value>cn=Directory Manager</value>
</property>
<property name="managerPassword">
<value>password</value>
</property>
</bean>
6) Change LDAP user search to use uid instead of email in Acegi security.xml In the ldapUserSearch bean, I changed mail={0} to uid={0}. Not sure, but maybe uid is a better default than mail for most users.
<bean id="ldapUserSearch"
class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
<constructor-arg index="0">
<value></value>
</constructor-arg>
<constructor-arg index="1">
<value>uid={0}</value>
</constructor-arg>
<constructor-arg index="2">
<ref local="initialDirContextFactory" />
</constructor-arg>
<property name="searchSubtree">
<value>true</value>
</property>
</bean>
7) Java code change in
Added "request.getSession().invalidate();" after line 186 in NewUserAction, as shown below. Without this change, the user will remain logged in, but with only the role "register". The user will have to close his browser and restart before being able to login with their new account.
} else {
// User registered, so go to welcome page
request.setAttribute("contextURL",
RollerRuntimeConfig.getAbsoluteContextURL());
request.getSession().invalidate();
return mapping.findForward("welcome.page");
}
To solve those problems above, I'd like to change security.xml to include a comments explaining what needs to be done. I'd like to make that code change in #7 and I'd like to write up a nice friendly wiki page explaining how to configure Roller and LDAP.
Any comments or suggestions?
- Dave
-------------------------------------------------------------------------------------------
"Cette communication (y compris les pieces jointes) est reservee a l'usage exclusif du destinataire (des destinataires) et peut contenir des informations privilegiees, confidentielles, exemptees de divulgation selon la loi ou protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute utilisation, divulgation, distribution, reproduction, examen ou copie (totale ou partielle) est non-autorisee et peut etre illegale. Tout message electronique est susceptible d'alteration et son integrite ne peut etre assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of the addressee(s) and may contain confidential information including trade secrets which are privileged, confidential, exempt from disclosure under applicable law and/or subject to copyright. If you are not an intended recipient, any use, disclosure, distribution, reproduction, review or copying (either whole or partial) is unauthorized and may be unlawful. E-mails are susceptible to alteration and their integrity cannot be guaranteed.Sanofi Pasteur shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Thank you."
**********************************************************************
Re: Documenting Roller/LDAP setup
Posted by rob <ro...@gmail.com>.
Matt Raible wrote:
> So, does this mean that Roller is more portable (between servers) when
> using Acegi, but if you want to leverage all the features of an app
> server, CMA is better?
I think that's right, but the problem is that Tomcat doesn't have a huge
amount of flexibility when it comes to LDAP support, so the bigger
question here is what is the preferred container for Roller. If it is
tomcat then I think Roller still needs Acegi for the features that are
in Acegi and not in Tomcat.
> 1. How are you doing remember me? I'm guessing SSO handles this?
yup, SSO for enterprises is a whole business unto itself, so we don't
worry about implementing something like remember me in the app itself.
> 2. How do you handle SSL Switching?
This is handled by the apache server in front of the app server. In
general we build all apps to be just deployed on http without any
switching. We then detail the redirect rules that should be in the
apache server.
> 3. Do you allow admins to manage users from the UI - or did you
> disable that feature completely?
disabled it completely
Rob
Re: Documenting Roller/LDAP setup
Posted by Matt Raible <mr...@gmail.com>.
So, does this mean that Roller is more portable (between servers) when
using Acegi, but if you want to leverage all the features of an app
server, CMA is better?
Using Acegi in Roller allowed us to delete a lot of code within
Roller, so I have a couple questions:
1. How are you doing remember me? I'm guessing SSO handles this?
2. How do you handle SSL Switching?
3. Do you allow admins to manage users from the UI - or did you
disable that feature completely?
Thanks,
Matt
On 2/1/07, rob <ro...@gmail.com> wrote:
> Dave wrote:
> > Hi Elias,
> >
> > I'm curious: are you guys using Acegi in your Roller sites/products or
> > did you switch back to container manged authentication?
> >
> We switched back to container managed security, which we unfortunately
> needed to do to integrate with all the security possibilities that
> Websphere offers,
>
> Rob
>
--
http://raibledesigns.com
Re: Documenting Roller/LDAP setup
Posted by rob <ro...@gmail.com>.
Dave wrote:
> Hi Elias,
>
> I'm curious: are you guys using Acegi in your Roller sites/products or
> did you switch back to container manged authentication?
>
We switched back to container managed security, which we unfortunately
needed to do to integrate with all the security possibilities that
Websphere offers,
Rob
Re: Documenting Roller/LDAP setup
Posted by Elias Torres <el...@torrez.us>.
Ironically, we had to stop using Acegi because of SSO. Basically,
there are many products that integrate with WebSphere to provide SSO
and because Lotus Connections has more than one component, we switched
back to container managed authentication so we wouldn't be the only
odd one trying to fit into WebSphere with Acegi.
-Elias
On 2/1/07, Dave <sn...@gmail.com> wrote:
> On 2/1/07, Elias Torres <el...@torrez.us> wrote:
> > ApacheCon only takes one Roller talk a year/location and it usually is
> > Dave's :-)
>
> Hi Elias,
>
> I'm curious: are you guys using Acegi in your Roller sites/products or
> did you switch back to container manged authentication?
>
> - Dave
>
Re: Documenting Roller/LDAP setup
Posted by Dave <sn...@gmail.com>.
On 2/1/07, Elias Torres <el...@torrez.us> wrote:
> ApacheCon only takes one Roller talk a year/location and it usually is
> Dave's :-)
Hi Elias,
I'm curious: are you guys using Acegi in your Roller sites/products or
did you switch back to container manged authentication?
- Dave
Re: Documenting Roller/LDAP setup
Posted by Elias Torres <el...@torrez.us>.
ApacheCon only takes one Roller talk a year/location and it usually is
Dave's :-)
-Elias
On 2/1/07, Matt Raible <mr...@gmail.com> wrote:
> On 2/1/07, Dave <sn...@gmail.com> wrote:
> >
> > We gained some SSO options back in the 3.0 timeframe, but we never got
> > any documentation (please correct me if I am wrong) about how to setup
> > Roller to take advantage of those options.
> >
> > By using those SSO options and tweaking the LDAP configuration in
> > Acegi security.xml, it is possible to get Roller working with LDAP.
> > With this setup, when a new user registers for Roller we are able to
> > pull her user information from LDAP and setup a new Roller account for
> > her. We authentication against LDAP (where passwords are stored) and
> > keep user info info Roller.
> >
> > With our current setup, I believe here's how things should work:
> >
> > 1) Enable SSO option
> > Define a roller-custom.properties file, override the users.sso.enabled
> > option like so:
> > users.sso.enabled=true
> >
> > 2) Uncomment the LDAP section in Acegi security.xml
> > Uncomment the section that begins with:
> > <!-- Sample LDAP/RollerDB hybrid security configuration
> >
> > 3) Protect the user registration page via Acegi security.xml
> > In the XML for the filterInvocationInterceptor bean, add the user
> > registration page to the list of URL patterns in the
> > objectDefinitionSource as shown below. The new line is the one that
> > reads " /roller-ui/user.do*=register".
> >
> > What does this do? It requires the user to have the role "register" in
> > order to view the user registration page. Therefore he user is shown
> > the login page and expected to enter their LDAP username and password
> > -- but we don't tell them that so it's pretty confusing. Once the
> > login, we know their user info so we are able to pre-populate the user
> > registration form with information from LDAP.
> >
> > <bean id="filterInvocationInterceptor"
> > class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
> > <property name="authenticationManager"
> > ref="authenticationManager"/>
> > <property name="accessDecisionManager"
> > ref="accessDecisionManager"/>
> > <property name="objectDefinitionSource">
> > <value>
> > PATTERN_TYPE_APACHE_ANT
> > /roller-ui/login-redirect.jsp=admin,editor
> > /roller-ui/yourProfile**=admin,editor
> > /roller-ui/createWebsite**=admin,editor
> > /roller-ui/yourWebsites**=admin,editor
> > /roller-ui/authoring/**=admin,editor
> > /roller-ui/admin/**=admin
> > /roller-ui/user.do*=register
> > /rewrite-status*=admin
> > </value>
> > </property>
> > </bean>
> >
> > 4) Enable LDAP authentication provider via security.xml
> > In the XML for the authenticationManager bean, comment out the DAO
> > provider and add in the LDAP provider, as shown below:
> >
> > <bean id="authenticationManager"
> > class="org.acegisecurity.providers.ProviderManager">
> > <property name="providers">
> > <list>
> > <!-- <ref local="daoAuthenticationProvider"/> -->
> > <ref local="ldapAuthProvider"/>
> > <ref local="anonymousAuthenticationProvider"/>
> > <!-- rememberMeAuthenticationProvider added
> > programmatically -->
> > </list>
> > </property>
> > </bean>
> >
> > But that's not all I had to do. I also had to do this:
> >
> > 5) Add LDAP username and password to Acegi security.xml
> > I've got my LDAP server (OpenDS - https://opends.dev.java.net/ ) setup
> > to require authentication. So I had to add two new properties to the
> > initialDirContextFactory bean, as shown below:
> >
> > <bean id="initialDirContextFactory"
> > class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
> > <constructor-arg value="ldap://localhost:1389/dc=example,dc=com"/>
> > <property name="managerDn">
> > <value>cn=Directory Manager</value>
> > </property>
> > <property name="managerPassword">
> > <value>password</value>
> > </property>
> > </bean>
> >
> > 6) Change LDAP user search to use uid instead of email in Acegi
> > security.xml
> > In the ldapUserSearch bean, I changed mail={0} to uid={0}. Not sure,
> > but maybe uid is a better default than mail for most users.
> >
> > <bean id="ldapUserSearch"
> > class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
> > <constructor-arg index="0">
> > <value></value>
> > </constructor-arg>
> > <constructor-arg index="1">
> > <value>uid={0}</value>
> > </constructor-arg>
> > <constructor-arg index="2">
> > <ref local="initialDirContextFactory" />
> > </constructor-arg>
> > <property name="searchSubtree">
> > <value>true</value>
> > </property>
> > </bean>
> >
> > 7) Java code change in
> > Added "request.getSession().invalidate();" after line 186 in
> > NewUserAction, as shown below. Without this change, the user will
> > remain logged in, but with only the role "register". The user will
> > have to close his browser and restart before being able to login with
> > their new account.
> >
> > } else {
> > // User registered, so go to welcome page
> > request.setAttribute("contextURL",
> > RollerRuntimeConfig.getAbsoluteContextURL());
> > request.getSession().invalidate();
> > return mapping.findForward("welcome.page");
> > }
> >
> > To solve those problems above, I'd like to change security.xml to
> > include a comments explaining what needs to be done. I'd like to make
> > that code change in #7 and I'd like to write up a nice friendly wiki
> > page explaining how to configure Roller and LDAP.
>
>
> Any comments or suggestions?
>
>
> Sounds like a great idea. If you include instructions on how to
> setup/populate a sample LDAP directory, I'd be happy to test the
> instructions. Maybe even write an article on Roller and its security
> flexibility. ;-)
>
> Even though my Roller Tutorial didn't get accepted for ApacheCon, I'm still
> interested in writing an article on it - and getting Roller to work with
> OpenID and OpenSSO.
>
> Matt
>
>
> - Dave
> >
>
>
>
> --
> http://raibledesigns.com
>
>
Re: Documenting Roller/LDAP setup
Posted by Matt Raible <mr...@gmail.com>.
On 2/1/07, Dave <sn...@gmail.com> wrote:
>
> We gained some SSO options back in the 3.0 timeframe, but we never got
> any documentation (please correct me if I am wrong) about how to setup
> Roller to take advantage of those options.
>
> By using those SSO options and tweaking the LDAP configuration in
> Acegi security.xml, it is possible to get Roller working with LDAP.
> With this setup, when a new user registers for Roller we are able to
> pull her user information from LDAP and setup a new Roller account for
> her. We authentication against LDAP (where passwords are stored) and
> keep user info info Roller.
>
> With our current setup, I believe here's how things should work:
>
> 1) Enable SSO option
> Define a roller-custom.properties file, override the users.sso.enabled
> option like so:
> users.sso.enabled=true
>
> 2) Uncomment the LDAP section in Acegi security.xml
> Uncomment the section that begins with:
> <!-- Sample LDAP/RollerDB hybrid security configuration
>
> 3) Protect the user registration page via Acegi security.xml
> In the XML for the filterInvocationInterceptor bean, add the user
> registration page to the list of URL patterns in the
> objectDefinitionSource as shown below. The new line is the one that
> reads " /roller-ui/user.do*=register".
>
> What does this do? It requires the user to have the role "register" in
> order to view the user registration page. Therefore he user is shown
> the login page and expected to enter their LDAP username and password
> -- but we don't tell them that so it's pretty confusing. Once the
> login, we know their user info so we are able to pre-populate the user
> registration form with information from LDAP.
>
> <bean id="filterInvocationInterceptor"
> class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
> <property name="authenticationManager"
> ref="authenticationManager"/>
> <property name="accessDecisionManager"
> ref="accessDecisionManager"/>
> <property name="objectDefinitionSource">
> <value>
> PATTERN_TYPE_APACHE_ANT
> /roller-ui/login-redirect.jsp=admin,editor
> /roller-ui/yourProfile**=admin,editor
> /roller-ui/createWebsite**=admin,editor
> /roller-ui/yourWebsites**=admin,editor
> /roller-ui/authoring/**=admin,editor
> /roller-ui/admin/**=admin
> /roller-ui/user.do*=register
> /rewrite-status*=admin
> </value>
> </property>
> </bean>
>
> 4) Enable LDAP authentication provider via security.xml
> In the XML for the authenticationManager bean, comment out the DAO
> provider and add in the LDAP provider, as shown below:
>
> <bean id="authenticationManager"
> class="org.acegisecurity.providers.ProviderManager">
> <property name="providers">
> <list>
> <!-- <ref local="daoAuthenticationProvider"/> -->
> <ref local="ldapAuthProvider"/>
> <ref local="anonymousAuthenticationProvider"/>
> <!-- rememberMeAuthenticationProvider added
> programmatically -->
> </list>
> </property>
> </bean>
>
> But that's not all I had to do. I also had to do this:
>
> 5) Add LDAP username and password to Acegi security.xml
> I've got my LDAP server (OpenDS - https://opends.dev.java.net/ ) setup
> to require authentication. So I had to add two new properties to the
> initialDirContextFactory bean, as shown below:
>
> <bean id="initialDirContextFactory"
> class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
> <constructor-arg value="ldap://localhost:1389/dc=example,dc=com"/>
> <property name="managerDn">
> <value>cn=Directory Manager</value>
> </property>
> <property name="managerPassword">
> <value>password</value>
> </property>
> </bean>
>
> 6) Change LDAP user search to use uid instead of email in Acegi
> security.xml
> In the ldapUserSearch bean, I changed mail={0} to uid={0}. Not sure,
> but maybe uid is a better default than mail for most users.
>
> <bean id="ldapUserSearch"
> class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
> <constructor-arg index="0">
> <value></value>
> </constructor-arg>
> <constructor-arg index="1">
> <value>uid={0}</value>
> </constructor-arg>
> <constructor-arg index="2">
> <ref local="initialDirContextFactory" />
> </constructor-arg>
> <property name="searchSubtree">
> <value>true</value>
> </property>
> </bean>
>
> 7) Java code change in
> Added "request.getSession().invalidate();" after line 186 in
> NewUserAction, as shown below. Without this change, the user will
> remain logged in, but with only the role "register". The user will
> have to close his browser and restart before being able to login with
> their new account.
>
> } else {
> // User registered, so go to welcome page
> request.setAttribute("contextURL",
> RollerRuntimeConfig.getAbsoluteContextURL());
> request.getSession().invalidate();
> return mapping.findForward("welcome.page");
> }
>
> To solve those problems above, I'd like to change security.xml to
> include a comments explaining what needs to be done. I'd like to make
> that code change in #7 and I'd like to write up a nice friendly wiki
> page explaining how to configure Roller and LDAP.
Any comments or suggestions?
Sounds like a great idea. If you include instructions on how to
setup/populate a sample LDAP directory, I'd be happy to test the
instructions. Maybe even write an article on Roller and its security
flexibility. ;-)
Even though my Roller Tutorial didn't get accepted for ApacheCon, I'm still
interested in writing an article on it - and getting Roller to work with
OpenID and OpenSSO.
Matt
- Dave
>
--
http://raibledesigns.com
RE: Documenting Roller/LDAP setup
Posted by Er...@sanofipasteur.com.
Hi Dave,
I've followed your instructions, and all works fine.
Eric
-----Message d'origine-----
De : Dave [mailto:snoopdave@gmail.com]
Envoyé : jeudi 1 février 2007 15:33
À : roller-dev@incubator.apache.org
Objet : Documenting Roller/LDAP setup
We gained some SSO options back in the 3.0 timeframe, but we never got any documentation (please correct me if I am wrong) about how to setup Roller to take advantage of those options.
By using those SSO options and tweaking the LDAP configuration in Acegi security.xml, it is possible to get Roller working with LDAP.
With this setup, when a new user registers for Roller we are able to pull her user information from LDAP and setup a new Roller account for her. We authentication against LDAP (where passwords are stored) and keep user info info Roller.
With our current setup, I believe here's how things should work:
1) Enable SSO option
Define a roller-custom.properties file, override the users.sso.enabled option like so:
users.sso.enabled=true
2) Uncomment the LDAP section in Acegi security.xml Uncomment the section that begins with:
<!-- Sample LDAP/RollerDB hybrid security configuration
3) Protect the user registration page via Acegi security.xml In the XML for the filterInvocationInterceptor bean, add the user registration page to the list of URL patterns in the objectDefinitionSource as shown below. The new line is the one that reads " /roller-ui/user.do*=register".
What does this do? It requires the user to have the role "register" in order to view the user registration page. Therefore he user is shown the login page and expected to enter their LDAP username and password
-- but we don't tell them that so it's pretty confusing. Once the login, we know their user info so we are able to pre-populate the user registration form with information from LDAP.
<bean id="filterInvocationInterceptor"
class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
<property name="authenticationManager" ref="authenticationManager"/>
<property name="accessDecisionManager" ref="accessDecisionManager"/>
<property name="objectDefinitionSource">
<value>
PATTERN_TYPE_APACHE_ANT
/roller-ui/login-redirect.jsp=admin,editor
/roller-ui/yourProfile**=admin,editor
/roller-ui/createWebsite**=admin,editor
/roller-ui/yourWebsites**=admin,editor
/roller-ui/authoring/**=admin,editor
/roller-ui/admin/**=admin
/roller-ui/user.do*=register
/rewrite-status*=admin
</value>
</property>
</bean>
4) Enable LDAP authentication provider via security.xml In the XML for the authenticationManager bean, comment out the DAO provider and add in the LDAP provider, as shown below:
<bean id="authenticationManager"
class="org.acegisecurity.providers.ProviderManager">
<property name="providers">
<list>
<!-- <ref local="daoAuthenticationProvider"/> -->
<ref local="ldapAuthProvider"/>
<ref local="anonymousAuthenticationProvider"/>
<!-- rememberMeAuthenticationProvider added programmatically -->
</list>
</property>
</bean>
But that's not all I had to do. I also had to do this:
5) Add LDAP username and password to Acegi security.xml I've got my LDAP server (OpenDS - https://opends.dev.java.net/ ) setup to require authentication. So I had to add two new properties to the initialDirContextFactory bean, as shown below:
<bean id="initialDirContextFactory"
class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
<constructor-arg value="ldap://localhost:1389/dc=example,dc=com"/>
<property name="managerDn">
<value>cn=Directory Manager</value>
</property>
<property name="managerPassword">
<value>password</value>
</property>
</bean>
6) Change LDAP user search to use uid instead of email in Acegi security.xml In the ldapUserSearch bean, I changed mail={0} to uid={0}. Not sure, but maybe uid is a better default than mail for most users.
<bean id="ldapUserSearch"
class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
<constructor-arg index="0">
<value></value>
</constructor-arg>
<constructor-arg index="1">
<value>uid={0}</value>
</constructor-arg>
<constructor-arg index="2">
<ref local="initialDirContextFactory" />
</constructor-arg>
<property name="searchSubtree">
<value>true</value>
</property>
</bean>
7) Java code change in
Added "request.getSession().invalidate();" after line 186 in NewUserAction, as shown below. Without this change, the user will remain logged in, but with only the role "register". The user will have to close his browser and restart before being able to login with their new account.
} else {
// User registered, so go to welcome page
request.setAttribute("contextURL",
RollerRuntimeConfig.getAbsoluteContextURL());
request.getSession().invalidate();
return mapping.findForward("welcome.page");
}
To solve those problems above, I'd like to change security.xml to include a comments explaining what needs to be done. I'd like to make that code change in #7 and I'd like to write up a nice friendly wiki page explaining how to configure Roller and LDAP.
Any comments or suggestions?
- Dave
-------------------------------------------------------------------------------------------
"Cette communication (y compris les pieces jointes) est reservee a l'usage exclusif du destinataire (des destinataires) et peut contenir des informations privilegiees, confidentielles, exemptees de divulgation selon la loi ou protegees par les droits d'auteur. Si vous n'etes pas un destinataire, toute utilisation, divulgation, distribution, reproduction, examen ou copie (totale ou partielle) est non-autorisee et peut etre illegale. Tout message electronique est susceptible d'alteration et son integrite ne peut etre assuree. Sanofi Pasteur decline toute responsabilite au titre de ce message s'il a ete modifie ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur de l'erreur de distribution et de la destruction du message. Merci.
This transmission (including any attachments) is intended solely for the use of the addressee(s) and may contain confidential information including trade secrets which are privileged, confidential, exempt from disclosure under applicable law and/or subject to copyright. If you are not an intended recipient, any use, disclosure, distribution, reproduction, review or copying (either whole or partial) is unauthorized and may be unlawful. E-mails are susceptible to alteration and their integrity cannot be guaranteed.Sanofi Pasteur shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Thank you."
**********************************************************************