Re: Documenting Roller/LDAP setup
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
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:[EMAIL PROTECTED] Envoyé : jeudi 1 février 2007 15:33 À : [email protected] 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: 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: ldap://localhost:1389/dc=example,dc=com"/> cn=Directory Manager password 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. uid={0} true 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
Hi Dave, I've followed your instructions, and all works fine. Eric -Message d'origine- De : Dave [mailto:[EMAIL PROTECTED] Envoyé : jeudi 1 février 2007 15:33 À : [email protected] 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: 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: ldap://localhost:1389/dc=example,dc=com"/> cn=Directory Manager password 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. uid={0} true 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
On 2/1/07, Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave wrote: > On 2/1/07, Allen Gilliland <[EMAIL PROTECTED]> 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
Dave wrote: On 2/1/07, Allen Gilliland <[EMAIL PROTECTED]> 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
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
On 2/1/07, Allen Gilliland <[EMAIL PROTECTED]> 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
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:
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:
ldap://localhost:1389/dc=example,dc=com"/>
cn=Directory Manager
password
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.
uid={0}
true
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
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 <[EMAIL PROTECTED]> 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
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
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 <[EMAIL PROTECTED]> wrote: On 2/1/07, Elias Torres <[EMAIL PROTECTED]> 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
On 2/1/07, Elias Torres <[EMAIL PROTECTED]> 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
ApacheCon only takes one Roller talk a year/location and it usually is
Dave's :-)
-Elias
On 2/1/07, Matt Raible <[EMAIL PROTECTED]> wrote:
On 2/1/07, Dave <[EMAIL PROTECTED]> 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:
>
>
>
>
>
>
>
>
> 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:
>
> class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
> ldap://localhost:1389/dc=example,dc=com"/>
>
> cn=Directory Manager
>
>
> password
>
>
>
> 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.
>
> class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
>
>
>
>
> uid={0}
>
>
>
>
>
> true
>
>
>
> 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
On 2/1/07, Dave <[EMAIL PROTECTED]> 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:
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:
ldap://localhost:1389/dc=example,dc=com"/>
cn=Directory Manager
password
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.
uid={0}
true
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
