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
