[xwiki-devs] Single Sign-On project
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
Hi Markus, On Sun, Jun 29, 2008 at 4:03 PM, Markus Lanthaler <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Thomas!
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.
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).
On Mon, Jun 30, 2008 at 11:45 AM, Markus Lanthaler <[email protected]> wrote:
Hi Thomas!
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).
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.
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.
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.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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.
Seems to be OK.. at least there are no complaints :-) I updated my page (http://dev.xwiki.org/xwiki/bin/view/Design/SingleSignOn) and inserted mockups for the UI and for the architecture I'll use. There are still some open questions. I don't know what makes more sense.. Should we discuss them here or as comments on that page? -------%<-------------------------------------------------- Open Questions * Is the design of the new login/registration screen OK? * Should it be possible to associate more than one OpenID URL to a user account? * How should it be possible for a user to bind an OpenID URL to his already existing account? * 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? * 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 --------%<-------------------------------------------------- Should I elaborate something on that page? Is something missing? Cheers, Markus
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/
* 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.
Great
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?
Well, actually you don't have to remember it. With OpenID 2.0 you don't even have to input your whole OpenID. Inserting xwiki.org should be enough. I don't know of any other feature that would solve the account recycling problem.
participants (3)
-
Artem Melentyev -
Markus Lanthaler -
Thomas Mortagne