3.) What about
user registration? Should it be possible for users to
create
accounts without password and just OpenID? Please consider that XWiki
should
also be able to act as a provider, i.e. act as an OpenID server.
XWikiLDAPAuthServiceImpl create the XWiki local user the first time
it's authenticate (filling the user page with LDAP informations).
Can't it be something like that ?
Well, it depends.. normally LDAP contains just "verified" accounts
(employees or whatever) and so they are already somehow valid users. An
OpenID URL in contrast can be created by anyone and in the worst case you
get back just that URL (no email address, no name, ...). So if it's OK to
create users of which we just know their OpenID URL it can be done in that
way - otherwise we have to create a registration process or enhance the
existing one.
OpenID supports attribute exchange which means that a user can store his
name, email addresss and so on on his OpenID provider (OP). So when the user
wants to create account on a XWiki system he just enters his OpenID URL, is
redirected to the OP where he needs to log in and authorize the request and
is the redirected back to the XWiki system we could prefill the registration
form with the user data. I think that would be the best way to do it. What
do you think?
Should it be possible for an existing user to add his OpenID URL to his
already existing XWiki account?
You can change the login page (templates/login.vm).
About the UI (both
design and implementation) we
can have a more detailed discussion later.
Yeah of course but indeed we need to discuss that. OpenID for example is
just an option (at least I think it should be). The same applies to SAML I
guess. If the admin turns off OpenID or SAML support the login form should
reflect those changes. Or should it be impossible to disable OpenID?
2.) OpenIDs
have to be bound to local user accounts (1:n relations, allow
more OpenIDs per account) - how should this happen? In the admin GUI? Who
should be allowed to do it?
I think 1:1 relation is sufficient. No special need for 2 sso accounts
for the same local user.
Well the reason for it is that the OP could be down and it would then be
impossible to access the system until the OP is up again. By adding support
for more OpenID URLs you could prevent that problem. But it's true.. it's
arguable if it is really needed.
I wouldn't add a new property to the XWikiUsers
class; this leads to very
thick classes, like
XWikiPreferences, with properties used only in specific cases. I'd rather
add a new XClass, for
example XWiki.OpenIdAccount, and user profiles will have this kind of
objects attached.
OK
>> 3.) What about user registration? Should it be
possible for users to
>> create
>> accounts without password and just OpenID?
>
> Yes. This is one of major advantages of sso. Isn't it?
Right, so we have to prevent logins for accounts without password.
> I think that provide new xwiki sso account for
already sso users is
> useless :)
> We should not provide xwiki sso accounts for sso users without password
> in their xwiki user profile.
OK
Well, I think this is about the other way around:
provide SSO accounts for
XWiki users, so that
other applications can connect to XWiki. And I'm in favor of that.
Of course, as Artem said, there's no point in "mirroring" an external SSO
provider, at least not yet.
Yes, but we have to limit those SSO accounts to XWiki users WITH password.
Another question. Just looking at OpenID now. What are the plans for it?
Should it be enabled by default? Should it be possible to turn it off?
I would like to see OpenID support out of the box. I don't know if it makes
sense to turn it off.. What happens with existing OpenID users if someone
turns it off?
Should we really start with the integration of OpenSSO (which is my choice,
but feel free to choose another one if you prefer another one)? Wouldn't it
be better to implement OpenID support for example with a dedicated OpenID
library? I think that would be much easier.. but I haven't looked yet in
detail how the integration of OpenSSO has to be done.