15 Jun
2008
15 Jun
'08
7:03 p.m.
Hi,
after evaluating possible frameworks I would propose to use OpenSSO [1] for
my GSOC SSO project.
It has full SAML 2.0 support, but lacks a bit regarding OpenID which isn't
supported by default. There is an extension which allows OpenSSO to act as a
OpenID 1.1 OP, but doesn't have RP support. OpenSSO has a very active and
large community (which maybe is the strongest argument to use it). There are
several requests for better OpenID support so I think that's a hot topic for
them and maybe it's possible to find some other developers with whom I can
add full OpenID 2.0 support.
So now I'll start implementing RP support (authentication). As far as I
understand the code I have to implement a XWikiAuthService analogous to the
XWikiLDAPAuthServiceImpl, right?
I also have some more questions :-) Let's start with OpenID (I'll start with
that):
1.) I need to modify the login screen because I just need a field where the
user can enter his OpenID URL, no password field. Then the user is redirect
to his OpenID provider. How should/can I implement that?
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?
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.
Cheers,
Markus
--
[1] http://opensso.dev.java.net
16 Jun
16 Jun
10:02 a.m.
Hi Markus,
On Sun, Jun 15, 2008 at 7:03 PM, Markus Lanthaler
<mark_lanthaler(a)gmx.net> wrote:
Hi,
after evaluating possible frameworks I would propose to use OpenSSO [1] for
my GSOC SSO project.
It has full SAML 2.0 support, but lacks a bit regarding OpenID which isn't
supported by default. There is an extension which allows OpenSSO to act as a
OpenID 1.1 OP, but doesn't have RP support. OpenSSO has a very active and
large community (which maybe is the strongest argument to use it). There are
Agree on the "strongest argument".
several requests for better OpenID support so I think
that's a hot topic for
them and maybe it's possible to find some other developers with whom I can
add full OpenID 2.0 support.
So now I'll start implementing RP support (authentication). As far as I
understand the code I have to implement a XWikiAuthService analogous to the
XWikiLDAPAuthServiceImpl, right?
Yes I guess It will be very similar to XWikiLDAPAuthServiceImpl
except that XWikiLDAPAuthServiceImpl don't need to touch login panel.
I also have some more questions :-) Let's start
with OpenID (I'll start with
that):
1.) I need to modify the login screen because I just need a field where the
user can enter his OpenID URL, no password field. Then the user is redirect
to his OpenID provider. How should/can I implement that?
As far as I know this part of XWiki is pretty static (But I'm not the
one who know it the best so maybe there is something).
If think here is an occasion to improve the modularity of this window.
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?
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 ?
Cheers,
Markus
--
[1] http://opensso.dev.java.net
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
3:03 p.m.
Hi, Markus.
Markus Lanthaler wrote:
after evaluating possible frameworks I would propose
to use OpenSSO [1] for
my GSOC SSO project.
It has full SAML 2.0 support, but lacks a bit regarding OpenID which isn't
supported by default. There is an extension which allows OpenSSO to act as a
OpenID 1.1 OP, but doesn't have RP support. OpenSSO has a very active and
large community (which maybe is the strongest argument to use it). There are
several requests for better OpenID support so I think that's a hot topic for
them and maybe it's possible to find some other developers with whom I can
add full OpenID 2.0 support.
So now I'll start implementing RP support (authentication). As far as I
understand the code I have to implement a XWikiAuthService analogous to the
XWikiLDAPAuthServiceImpl, right?
I also have some more questions :-) Let's start with OpenID (I'll start with
that):
1.) I need to modify the login screen because I just need a field where the
user can enter his OpenID URL, no password field. Then the user is redirect
to his OpenID provider. How should/can I implement that?
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.
Relation can be contained in new property of XWikiUsers class. ("ssourl"
string property for example. or dblist property in case of 1:n relation)
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?
This is very useful for users which want simply add some comment and
don't want to full register.
Please consider that XWiki should
also be able to act as a provider, i.e. act as an OpenID server.
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.
--
Artem Melentyev
3:27 p.m.
Artem Melentyev wrote:
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.
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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi, Markus.
Markus Lanthaler wrote:
> after evaluating possible frameworks I would propose to use OpenSSO [1] for
> my GSOC SSO project.
> It has full SAML 2.0 support, but lacks a bit regarding OpenID which isn't
> supported by default. There is an extension which allows OpenSSO to act as a
> OpenID 1.1 OP, but doesn't have RP support. OpenSSO has a very active and
> large community (which maybe is the strongest argument to use it). There are
> several requests for better OpenID support so I think that's a hot topic for
> them and maybe it's possible to find some other developers with whom I can
> add full OpenID 2.0 support.
>
> So now I'll start implementing RP support (authentication). As far as I
> understand the code I have to implement a XWikiAuthService analogous to the
> XWikiLDAPAuthServiceImpl, right?
> I also have some more questions :-) Let's start with OpenID (I'll start with
> that):
>
> 1.) I need to modify the login screen because I just need a field where the
> user can enter his OpenID URL, no password field. Then the user is redirect
> to his OpenID provider. How should/can I implement that?
You can change the login page (templates/login.vm). About the UI (both design and
implementation) we
can have a more detailed discussion later.
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.
Relation can be contained in new property of XWikiUsers class. ("ssourl"
string property for example. or dblist property in case of 1:n relation) 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?
This is very useful for users which want simply add some comment and
don't want to full register.
Please consider that XWiki should
also be able to act as a provider, i.e. act as an OpenID server.
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. 
3:35 p.m.
On Mon, Jun 16, 2008 at 3:27 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
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.
+1 with this.
--
Jean-Vincent Drean
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.
Relation can be contained in new property of XWikiUsers class. ("ssourl"
string property for example. or dblist property in case of 1:n relation)
3:48 p.m.
Jean-Vincent Drean wrote:
On Mon, Jun 16, 2008 at 3:27 PM, Sergiu Dumitriu
<sergiu(a)xwiki.com> wrote:
>>> 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.
>> Relation can be contained in new property of XWikiUsers class.
("ssourl"
>> string property for example. or dblist property in case of 1:n relation)
> 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.
+1.
By analogue: SAMLAccount and others SSOAccounts per sso system.
--
Artem Melentyev
4:04 p.m.
On Mon, Jun 16, 2008 at 3:35 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
On Mon, Jun 16, 2008 at 3:27 PM, Sergiu Dumitriu
<sergiu(a)xwiki.com> wrote:
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.
+1 with this.
+1 too.
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.
Relation can be contained in new property of XWikiUsers class. ("ssourl"
string property for example. or dblist property in case of 1:n relation)
--
Jean-Vincent Drean
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
17 Jun
17 Jun
6:06 p.m.
New subject: [xwiki-devs] [gsoc] Re: SSO framework integration
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 ? 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. 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.
5988
days inactive
5990
days old
7 comments
5 participants
participants (5)
-
Artem Melentyev -
Jean-Vincent Drean -
Markus Lanthaler -
Sergiu Dumitriu -
Thomas Mortagne