29 Jun
2008
29 Jun
'08
4:03 p.m.
Hi!
I just created the page
http://dev.xwiki.org/xwiki/bin/view/Design/SingleSignOn where I'll document
everything regarding my Single Sign-On project.
Since I didn't get any feedback the last time I asked this question I'll ask
it again:
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 a big framework like OpenSSO?
Wouldn't it be better to implement OpenID support for example with a
dedicated OpenID
library? We should also consider the fact that ESOE for example simple uses
the OpenID4Java library and OpenSSO doesn't support OpenID (authentication)
at all.
I think it's much easier for the user if everything is bundled with XWiki so
that he doesn't need to install any other component or complex service like
ESOE or OpenSSO.
If it's OK for you I would start creating the architecture and describe
detailed how I would like to implement OpenID support with a OpenID library
the next days. Then ask for some feedback on that and finally begin to
implement this. My last exam is next Monday (July, 7th) so afterwards I'm
finally free to work exclusively for XWiki :-)
Cheers,
Markus
30 Jun
30 Jun
11:19 a.m.
Hi Markus,
On Sun, Jun 29, 2008 at 4:03 PM, Markus Lanthaler
<mark_lanthaler(a)gmx.net> wrote:
Hi!
I just created the page
http://dev.xwiki.org/xwiki/bin/view/Design/SingleSignOn where I'll document
everything regarding my Single Sign-On project.
Since I didn't get any feedback the last time I asked this question I'll ask
it again:
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?
I would say if OpenID is turned off then users created for OpenID or
attached to OpenId are unusable to authenticate if they don't have any
XWiki password. The default authenticator does not allows users to log
with empty passwords, this is enough to protect them I think. This
could be used when the administrator want to easily disable wiki
modifications for maintenance for example.
Should we really start with the integration of a big framework like OpenSSO?
Wouldn't it be better to implement OpenID support for example with a
dedicated OpenID
library? We should also consider the fact that ESOE for example simple uses
the OpenID4Java library and OpenSSO doesn't support OpenID (authentication)
at all.
I think it's much easier for the user if everything is bundled with XWiki so
that he doesn't need to install any other component or complex service like
ESOE or OpenSSO.
If we want to support only OpenID, OpenID4Java seems the better way to
do that in the short term for you to be sure to finish your GSOC. Now
in the long term we would surely choose one of the framework available
to easily add other supports latter I think... I seen that ESOE
provide a generic Confluence / Jira Integrator but can't find any
source/description.
If it's OK for you I would start creating the architecture and describe
detailed how I would like to implement OpenID support with a OpenID library
the next days. Then ask for some feedback on that and finally begin to
implement this. My last exam is next Monday (July, 7th) so afterwards I'm
finally free to work exclusively for XWiki :-)
OK great.
Cheers,
Markus
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
11:45 a.m.
New subject: [xwiki-devs] [gsoc] Re: Single Sign-On project
Hi Thomas!
Just to be sure: Does that means that it is OK to start with OpenID
integration using OpenID4Java? Or do you prefer Netmesh? As far as I know
OpenID4Java is kind of the standard library used. On the other side Netmesh
supports also LID (a similar protocol to OpenID created by Netmesh).
I would say if OpenID is turned off then users created
for OpenID or
attached to OpenId are unusable to authenticate if they don't have any
XWiki password. The default authenticator does not allows users to log
with empty passwords, this is enough to protect them I think. This
could be used when the administrator want to easily disable wiki
modifications for maintenance for example.
Well, but that's not the only consequence. If you issue OpenID URLs (so that
XWiki acts as the OpenID provider).. The users loose also access to all
other websites where they used the XWiki OpenID URL. So we have to be very
very careful about a "switch-off feature". I would suggest to enable/disable
OpenID support during setup. If someone then really wants to turn it off he
has to do that somehow manually (not through a GUI).
If we want to support only OpenID, OpenID4Java seems
the better way to
do that in the short term for you to be sure to finish your GSOC. Now
in the long term we would surely choose one of the framework available
to easily add other supports latter I think... I seen that ESOE
provide a generic Confluence / Jira Integrator but can't find any
source/description.
Yes that's clear. The thing that I don't understand is how exactly you would
see support of one of these frameworks!? Does that mean that such a
framework will be bundled and shipped with XWiki by default or that it is
just an option? The frameworks are quite complex and setting them up
properly isn't so easy as it seems at the first moment.
If it's OK
for you I would start creating the architecture and describe
detailed how I would like to implement OpenID support with a OpenID
library
the next days. Then ask for some feedback on that and finally begin to
implement this. My last exam is next Monday (July, 7th) so afterwards I'm
finally free to work exclusively for XWiki :-)
OK great.
11:56 a.m.
New subject: [xwiki-devs] [gsoc] Re: Single Sign-On project
On Mon, Jun 30, 2008 at 11:45 AM, Markus Lanthaler
<mark_lanthaler(a)gmx.net> wrote:
Just to be sure: Does that means that it is OK to start with OpenID
integration using OpenID4Java? Or do you prefer Netmesh? As far as I know
OpenID4Java is kind of the standard library used. On the other side Netmesh
supports also LID (a similar protocol to OpenID created by Netmesh).
In the context of the GSOC, I think you should run with OpenID4Java.
But I'm not an expert of SSO/OpenId so it would be great to have
others comments on that, especially Sergiu.
Hi Thomas!
Agree that no ones should be able to do that using some GUI but anyway
at least now to switch authenticator you have to edit xwiki.cfg et
restart XWiki.
I would say if OpenID is turned off then users
created for OpenID or
attached to OpenId are unusable to authenticate if they don't have any
XWiki password. The default authenticator does not allows users to log
with empty passwords, this is enough to protect them I think. This
could be used when the administrator want to easily disable wiki
modifications for maintenance for example.
Well, but that's not the only consequence. If you issue OpenID URLs (so that
XWiki acts as the OpenID provider).. The users loose also access to all
other websites where they used the XWiki OpenID URL. So we have to be very
very careful about a "switch-off feature". I would suggest to enable/disable
OpenID support during setup. If someone then really wants to turn it off he
has to do that somehow manually (not through a GUI). If we want to support only OpenID, OpenID4Java
seems the better way to
do that in the short term for you to be sure to finish your GSOC. Now
in the long term we would surely choose one of the framework available
to easily add other supports latter I think... I seen that ESOE
provide a generic Confluence / Jira Integrator but can't find any
source/description.
Yes that's clear. The thing that I don't understand is how exactly you would
see support of one of these frameworks!? Does that mean that such a
framework will be bundled and shipped with XWiki by default or that it is
just an option? The frameworks are quite complex and setting them up
properly isn't so easy as it seems at the first moment.
If
it's OK for you I would start creating the architecture and describe
detailed how I would like to implement OpenID support with a OpenID
library
the next days. Then ask for some feedback on that and finally begin to
implement this. My last exam is next Monday (July, 7th) so afterwards I'm
finally free to work exclusively for XWiki :-)
OK great.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
1 Jul
1 Jul
11:36 p.m.
New subject: [xwiki-devs] [gsoc] Re: Single Sign-On project
Just to be
sure: Does that means that it is OK to start with OpenID
integration using OpenID4Java? Or do you prefer Netmesh? As far as I know
OpenID4Java is kind of the standard library used. On the other side
Netmesh
supports also LID (a similar protocol to OpenID created by Netmesh).
In the context of the GSOC, I think you should run with OpenID4Java.
But I'm not an expert of SSO/OpenId so it would be great to have
others comments on that, especially Sergiu. 
2 Jul
2 Jul
2:01 p.m.
New subject: [xwiki-devs] [gsoc] Re: Single Sign-On project
Markus Lanthaler wrote:
...
* How should the issued OpenID URLs look like?
http://www.xwiki.org/xwiki/bin/view/XWiki/UserName seems to be to long for
me. Something like http://www.xwiki.org/user/UserName would be much better
in my opinion. What do you think? Would that be possible with the existing
architecture?
Yes. We can simply map these url to openid servlet in web.xml, I think.
Also I think we can provide openid account per virtual xwiki for it's
owner. So for example wiki owners at myxwiki.org will get openid
accounts like servername.myxwiki.org
(And I want openid account amelentev.myxwiki.org :))
* What about user recycling, i.e. if a user (Alice)
deletes his account and
another one (Bob) creates an account with the same user name afterwards what
should happen? Bob would be able to log-in to all sites on which Alice used
her XWiki account. Yahoo for example solves this by appending a fragment
like #fk32j to each OpenID. So the OpenID URL
http://www.xwiki.org/user/UserName would become
http://www.xwiki.org/user/UserName#fragment
-1
It dirties a clean openid url. And I don't want to memorize this
fragment. :)
Maybe there is some other way to resolve this problem? I think it is.
For example store some key in openid account and openid consumers also
check this key when signin. When openid account recreated, key is
changed. Maybe there is something similar in openid standard?
--
Artem Melentyev / http://marting.myopenid.com/
2:29 p.m.
New subject: [xwiki-devs] [gsoc] Re: Single Sign-On project
* How should
the issued OpenID URLs look like?
http://www.xwiki.org/xwiki/bin/view/XWiki/UserName seems to be to long
for
me. Something like http://www.xwiki.org/user/UserName would be much
better
in my opinion. What do you think? Would that be possible with the
existing
architecture?
Yes. We can simply map these url to openid servlet in web.xml, I think. Also I think we can provide openid account per virtual
xwiki for it's
owner. So for example wiki owners at myxwiki.org will get openid
accounts like servername.myxwiki.org
(And I want openid account amelentev.myxwiki.org :))
I would say that's just another "mapping". It would be nice to have all
OpenIDs as subdomains but I don't know if this is feasible. I think a lot of
users of XWiki can't create subdomains easily or don't even possess a
domain!?
* What about
user recycling, i.e. if a user (Alice) deletes his account
and
another one (Bob) creates an account with the same user name afterwards
what
should happen? Bob would be able to log-in to all sites on which Alice
used
her XWiki account. Yahoo for example solves this by appending a fragment
like #fk32j to each OpenID. So the OpenID URL
http://www.xwiki.org/user/UserName would become
http://www.xwiki.org/user/UserName#fragment
-1
It dirties a clean openid url. And I don't want to memorize this
fragment. :)
Maybe there is some other way to resolve this problem? I think it is.
For example store some key in openid account and openid consumers also
check this key when signin. When openid account recreated, key is
changed. Maybe there is something similar in openid standard?
5920
days inactive
5923
days old
6 comments
3 participants
participants (3)
-
Artem Melentyev -
Markus Lanthaler -
Thomas Mortagne