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
