[xwiki-devs] foaf+ssl on XWiki
Hi, foaf+ssl [1] is a very simple protocol for distributed authentication. It essentially does what OpenId does, but in a RESTful manner. It works with most desktop browsers since X509v3 came out (which is a long time ago). It only uses open standards and protocols - it just uses them in a more distributed way. It is also very easy to implement, and here is what would be needed to implement in XWiki. I can help out here. 1. Profile Creation ------------------- Take any user home page URL. 1. You can either have that page link to an rdf/xml representation of a foaf graph, or you can add RDFa directly to the home page by marking up the page with foaf. It depends on how much those pages are templated. If they are very templated then the rdfa solution can be very neat, as there is less risk that the user will mess something up. 2. Add a certification creation servlet that knows how to deal with the keygen tag, and the microsoft activeX component. We have the code for this available open source in Java. What we need in addition is a little database to keep track of the different public keys used by the profile owner, so that he can delete a key if he looses his computer, or add a new one if he wishes to use someone else's. The above should be very little work, and should allow people to log into other services in one click. You can try a test case out by going to http://foaf.me/ but clearly generating rdf/xml for users to play around with is not a good idea. Also foaf.me only allows one to have one certificate per profile. Ok, so you will say there are not a lot of services for the moment. True. We are in boot strapping mode. But with one tiny little trick you can get one useful service going. http://openid4.me/ gives anyone an openid automatically and allows them to log in using foaf+ssl. (There are just a few lines of code that you need to add to get that to work at the top of the profile page) 2. Authentication ----------------- There is one super easy way to get authentication working and that is to use https://foafssl.org/srv/idp The details of how that works is explained there. (and the source code is also available at https://sommer.dev.java.net/ ) With that service you can get someone's WebID in a few lines of code. See the login link at the top of http://foaf.me/ . Setting up an xwiki server so that it asks the user for his Client certificate is a bit more advanced, as it requires a hack to the SSL layer on the server (so that authentication does not fail if it cannot find the Certificate Authority). (By the way this should not be the only means of authentication. OpenId and username passwords are good fallback solutions) 3. Possible services to build ------------------------------ With the previous pieces in place some very nice services should be buildable. But those could be left to groovy developers. 1. Improve comment management on blogs. (if someone logs in with an OpenId that points to a foaf, or with a webid, you can get links to images of the person, their blog, and other accounts, friends perhaps, etc... This can help the person who is going to validate the post to get some contextual information on the person posting the blog (and perhaps add him to a contact list). Verification can be done automatically by the server by GETing a blog page and finding a link there back to the foaf) 2. Allow people from other XWiki instances (and indeed any foaf file) access to another wiki. So one could specify things like: allow only my friends or friends of my friends access to this wiki page. Or the colleagues of my friends, ... ) But one should start simple... We have written out a list of use cases here: http://esw.w3.org/topic/foaf+ssl/UseCases There are bound to be a lot more. But for us and everyone to try them, we need to have some basics in place. Henry [1] see the introductory material here http://esw.w3.org/topic/foaf+ssl Social Web Architect http://bblfish.net/
On 1 Feb 2010, at 19:22, Story Henry wrote:
There is one super easy way to get authentication working and that is to use https://foafssl.org/srv/idp The details of how that works is explained there. (and the source code is also available athttps://sommer.dev.java.net/ )
And we just had a new release of the Java code on github today: http://lists.foaf-project.org/pipermail/foaf-protocols/2010-February/001555.... Henry Social Web Architect http://bblfish.net/
Hi Henry, On Feb 1, 2010, at 7:22 PM, Story Henry wrote:
Hi,
foaf+ssl [1] is a very simple protocol for distributed authentication. It essentially does what OpenId does, but in a RESTful manner. It works with most desktop browsers since X509v3 came out (which is a long time ago). It only uses open standards and protocols - it just uses them in a more distributed way.
It is also very easy to implement, and here is what would be needed to implement in XWiki. I can help out here.
Cool!
1. Profile Creation -------------------
Take any user home page URL.
1. You can either have that page link to an rdf/xml representation of a foaf graph, or you can add RDFa directly to the home page by marking up the page with foaf. It depends on how much those pages are templated. If they are very templated then the rdfa solution can be very neat, as there is less risk that the user will mess something up.
Here's an example of a profile right now in XWiki: <div id="profilePane" class="vertical-pane"><h1 class='hidden'>Profile of Administrator</h1><div class="vcard"> <span class="fn hidden">Administrator</span> <div class="dashboard"> <div class="dashboardleft"> <div class="userInfo"> <h1>Personal Information</h1> <dl> <dt class="label"><label>First name</label></dt> <dd class="given-name">Administrator</dd> <dt class="label"><label>Last name</label></dt> <dd class="family-name"></dd> <dt class="label"><label>Company</label></dt> <dd class="org">XWiki.org</dd> <dt class="label"><label>About</label></dt> <dd class="note"><p>Admin is the default Wiki Admin.</p></dd> </dl> <h1>Contact Information</h1> <dl> <dt class="label"><label>Phone</label></dt> <dd class="tel"></dd> <dt class="label"><label>Address</label></dt> <dd class="adr"></dd> </dl> <h1>External Links</h1> As you can see we're already using microformats. What would need to be changed to support RDFa?
2. Add a certification creation servlet that knows how to deal with the keygen tag, and the microsoft activeX component. We have the code for this available open source in Java.
We = ? Do you have a URL for the code you mention? Is it released code? Under what license?
What we need in addition is a little database to keep track of the different public keys used by the profile owner, so that he can delete a key if he looses his computer, or add a new one if he wishes to use someone else's.
So you're saying that we should add a field in a user's profile to put public keys, right? This is easy to do in XWiki.
The above should be very little work, and should allow people to log into other services in one click. You can try a test case out by going to http://foaf.me/ but clearly generating rdf/xml for users to play around with is not a good idea. Also foaf.me only allows one to have one certificate per profile.
Ok, so you will say there are not a lot of services for the moment. True. We are in boot strapping mode. But with one tiny little trick you can get one useful service going. http://openid4.me/ gives anyone an openid automatically and allows them to log in using foaf+ssl. (There are just a few lines of code that you need to add to get that to work at the top of the profile page)
2. Authentication -----------------
There is one super easy way to get authentication working and that is to use https://foafssl.org/srv/idp
That links doesn't seem to work.
The details of how that works is explained there. (and the source code is also available at https://sommer.dev.java.net/ )
With that service you can get someone's WebID in a few lines of code. See the login link at the top of http://foaf.me/ .
Setting up an xwiki server so that it asks the user for his Client certificate is a bit more advanced, as it requires a hack to the SSL layer on the server (so that authentication does not fail if it cannot find the Certificate Authority).
(By the way this should not be the only means of authentication. OpenId and username passwords are good fallback solutions)
Re authentication xwiki has an interface to implement to provide alternative implementations. See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication and more specifically: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HCustomAu... Let us know if you think this can be done easily. Would you have time to work on such an implementation?
3. Possible services to build ------------------------------
With the previous pieces in place some very nice services should be buildable. But those could be left to groovy developers.
1. Improve comment management on blogs. (if someone logs in with an OpenId that points to a foaf, or with a webid, you can get links to images of the person, their blog, and other accounts, friends perhaps, etc... This can help the person who is going to validate the post to get some contextual information on the person posting the blog (and perhaps add him to a contact list). Verification can be done automatically by the server by GETing a blog page and finding a link there back to the foaf)
2. Allow people from other XWiki instances (and indeed any foaf file) access to another wiki. So one could specify things like: allow only my friends or friends of my friends access to this wiki page. Or the colleagues of my friends, ... ) But one should start simple...
Sounds cool. This is all good. What we need to know I think is how much time and work you can devote to implement what you mentioned. On the XWiki committer side, we can provide support to you for sure and we can work with you to get your code in committed. BTW we have a sandbox to which we can give you access right away (commit mails go to this list). To get access just give me your user id on xwiki.org (go there and register) - please use a unix like name for your id something like hstory since this is going to be your svn login). Thanks a lot for suggesting this Henry. I'm curious to see what others think too but on my side I find it very interesting (the more ways to access xwiki the better IMO). -Vincent
We have written out a list of use cases here: http://esw.w3.org/topic/foaf+ssl/UseCases There are bound to be a lot more. But for us and everyone to try them, we need to have some basics in place.
Henry
[1] see the introductory material here http://esw.w3.org/topic/foaf+ssl
Social Web Architect http://bblfish.net/
On 2 Feb 2010, at 18:11, Vincent Massol wrote:
Hi Henry,
On Feb 1, 2010, at 7:22 PM, Story Henry wrote:
Hi,
foaf+ssl [1] is a very simple protocol for distributed authentication. It essentially does what OpenId does, but in a RESTful manner. It works with most desktop browsers since X509v3 came out (which is a long time ago). It only uses open standards and protocols - it just uses them in a more distributed way.
It is also very easy to implement, and here is what would be needed to implement in XWiki. I can help out here.
Cool!
1. Profile Creation -------------------
Take any user home page URL.
1. You can either have that page link to an rdf/xml representation of a foaf graph, or you can add RDFa directly to the home page by marking up the page with foaf. It depends on how much those pages are templated. If they are very templated then the rdfa solution can be very neat, as there is less risk that the user will mess something up.
Here's an example of a profile right now in XWiki:
Here is how I think we could adapt. (one would need to test, this is a first draft) -------8<------------------------------------------------ <div id="profilePane" class="vertical-pane" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#" xmlns:cert="http://www.w3.org/ns/auth/cert#" xmlns:rsa="http://www.w3.org/ns/auth/rsa#" about="#me" typeof="foaf:Person"> <h1 class='hidden'>Profile of Administrator</h1> <div class="vcard"> <span class="fn hidden">Administrator</span> <div class="dashboard"> <!-- bblfish: ils sont pas fermé ? --> <div class="dashboardleft"> <div class="userInfo"> <h1>Personal Information</h1> <dl> <dt class="label"><label>First name</label></dt> <dd property="foaf:firstName" class="given-name">Administrator</dd> <dt class="label"><label>Last name</label></dt> <dd property="foaf:familyName" class="family-name"></dd> <dt class="label"><label>Company</label></dt> <dd property="class="org">XWiki.org</dd> <dt class="label"><label>About</label></dt> <dd class="note"><p>Admin is the default Wiki Admin.</p></dd> </dl> <h1>Contact Information</h1> <dl "> <dt rel="foaf:phone" href="tel:+1.64225952" class="label"><label>Phone</label></dt> <dd class="tel"></dd> <dt class="label"><label>Address</label></dt> <dd class="adr"></dd> </dl> <h1>External Links</h1> .... <h1>Public Keys</h1> <!-- A list of public keys, can have more than one, one for each browser for example !--> <div typeof="rsa:RSAPublicKey"> <h2 property="rdfs:label">My RSA Public Key</h2> <dl> <dt>Identifies</dt> <dd rel="cert:identity"> <a about="#me" href="/"> </a><!-- not quite right --> </dd> <dt>Modulus (hexadecimal)</dt> <dd rel="rsa:modulus"> <span property="cert:hex"> b0fb6fb2d2f08df9ef892e99587f820ef0646c24cae8a23965a1d208331c f7ebdafaed90e3f2c8504b27cba16552c2bbc6c4469959d84ef12c4ff2a8 e46be7a6eeb0a629c14a219c036a41d3ce1fb7cf28d81c073748310a7672 b3bfc8ad20efcec2236a97634f93ea37a7c4a7a7db8713bd3ff2fc221507 d24aae2fe7dd973b</span> </dd> <dt>Exponent (decimal)</dt> <dd rel="rsa:public_exponent"> <span property="cert:decimal">65537</span> </dd> </dl> </div> -------8<------------------------------------------------ Something like the above. There are a few errors and a few relations that would need to be found, such as that between a person and the company he works for, but I don't think it would take long. Is that page public?
As you can see we're already using microformats. What would need to be changed to support RDFa?
2. Add a certification creation servlet that knows how to deal with the keygen tag, and the microsoft activeX component. We have the code for this available open source in Java.
We = ?
The group working on foaf+ssl. But for this more particularly Bruno Harbulot and me.
Do you have a URL for the code you mention? Is it released code? Under what license?
I pretty sure it is all under the BSD licence. See: http://lists.foaf-project.org/pipermail/foaf-protocols/2010-February/001555....
What we need in addition is a little database to keep track of the different public keys used by the profile owner, so that he can delete a key if he looses his computer, or add a new one if he wishes to use someone else's.
So you're saying that we should add a field in a user's profile to put public keys, right? This is easy to do in XWiki.
I imagine so. I added something of that above to the template.
The above should be very little work, and should allow people to log into other services in one click. You can try a test case out by going to http://foaf.me/ but clearly generating rdf/xml for users to play around with is not a good idea. Also foaf.me only allows one to have one certificate per profile.
Ok, so you will say there are not a lot of services for the moment. True. We are in boot strapping mode. But with one tiny little trick you can get one useful service going. http://openid4.me/ gives anyone an openid automatically and allows them to log in using foaf+ssl. (There are just a few lines of code that you need to add to get that to work at the top of the profile page)
2. Authentication -----------------
There is one super easy way to get authentication working and that is to use https://foafssl.org/srv/idp
That links doesn't seem to work.
It does now. Sometimes it is slow. It's on a "cloud" server. But I need to get my own server to put this on.
The details of how that works is explained there. (and the source code is also available at https://sommer.dev.java.net/ )
With that service you can get someone's WebID in a few lines of code. See the login link at the top of http://foaf.me/ .
Setting up an xwiki server so that it asks the user for his Client certificate is a bit more advanced, as it requires a hack to the SSL layer on the server (so that authentication does not fail if it cannot find the Certificate Authority).
(By the way this should not be the only means of authentication. OpenId and username passwords are good fallback solutions)
Re authentication xwiki has an interface to implement to provide alternative implementations. See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication
and more specifically: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HCustomAu...
Some guy called Skol, who looks like a playmobile character, tells me that is off line... Will look at it tomorrow, ...
Let us know if you think this can be done easily. Would you have time to work on such an implementation?
yes. The first part to generate certs should be especially easy, and I think could be reused in a lot of other java apps.
3. Possible services to build ------------------------------
With the previous pieces in place some very nice services should be buildable. But those could be left to groovy developers.
1. Improve comment management on blogs. (if someone logs in with an OpenId that points to a foaf, or with a webid, you can get links to images of the person, their blog, and other accounts, friends perhaps, etc... This can help the person who is going to validate the post to get some contextual information on the person posting the blog (and perhaps add him to a contact list). Verification can be done automatically by the server by GETing a blog page and finding a link there back to the foaf)
2. Allow people from other XWiki instances (and indeed any foaf file) access to another wiki. So one could specify things like: allow only my friends or friends of my friends access to this wiki page. Or the colleagues of my friends, ... ) But one should start simple...
Sounds cool.
This is all good. What we need to know I think is how much time and work you can devote to implement what you mentioned. On the XWiki committer side, we can provide support to you for sure and we can work with you to get your code in committed.
Ok, I detect a bit of enthusiasm :-) So I'll be happy to work on it. I don't think it should take long frankly.
BTW we have a sandbox to which we can give you access right away (commit mails go to this list). To get access just give me your user id on xwiki.org (go there and register) - please use a unix like name for your id something like hstory since this is going to be your svn login).
bblfish of course ;-)
Thanks a lot for suggesting this Henry. I'm curious to see what others think too but on my side I find it very interesting (the more ways to access xwiki the better IMO).
The most fun comes when projects from two wikis can start working together...
-Vincent
We have written out a list of use cases here: http://esw.w3.org/topic/foaf+ssl/UseCases There are bound to be a lot more. But for us and everyone to try them, we need to have some basics in place.
Henry
[1] see the introductory material here http://esw.w3.org/topic/foaf+ssl
Social Web Architect http://bblfish.net/
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 2 Feb 2010, at 19:57, Story Henry wrote:
The details of how that works is explained here https://foafssl.org/srv/idp (and the source code is also available at https://sommer.dev.java.net/ )
With that service you can get someone's WebID in a few lines of code. See the login link at the top of http://foaf.me/ .
Setting up an xwiki server so that it asks the user for his Client certificate is a bit more advanced, as it requires a hack to the SSL layer on the server (so that authentication does not fail if it cannot find the Certificate Authority).
(By the way this should not be the only means of authentication. OpenId and username passwords are good fallback solutions)
Re authentication xwiki has an interface to implement to provide alternative implementations. See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication
and more specifically: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HCustomAu...
Some guy called Skol, who looks like a playmobile character, tells me that is off line... Will look at it tomorrow, ...
It is up again. It looks from the Oracle SSO example http://bodez.wordpress.com/2008/10/15/xwiki-user-authentication-with-oracle-... that one just needs to implement public XWikiUser checkAuth(XWikiContext context) throws XWikiException { For an initial implementation using an IDP this could be just a few lines of code. A fuller implementation would not be much larger as we have the BSD libraries for it, but it would mostly require more work setting up (because one needs to set up an ssl connection). Next one needs to create a user with this it seems: context.getWiki().createEmptyUser("beppe", "edit", context); One may in our situation not want to create a user for every authenticated person accessing the wiki, if creating a user means setting up a home page for them, giving them a special local nickname, etc... All you may want to know about them is their WebID (A URL) But perhaps that is something to leave for later development... To make this smoother, it may be worth adding a WebID field to the database, as a primary key for a person. I imaginer there are more methods for creating users though.... Henry
On Wed, Feb 3, 2010 at 19:59, Story Henry <[email protected]> wrote:
On 2 Feb 2010, at 19:57, Story Henry wrote:
The details of how that works is explained here https://foafssl.org/srv/idp (and the source code is also available at https://sommer.dev.java.net/ )
With that service you can get someone's WebID in a few lines of code. See the login link at the top of http://foaf.me/ .
Setting up an xwiki server so that it asks the user for his Client certificate is a bit more advanced, as it requires a hack to the SSL layer on the server (so that authentication does not fail if it cannot find the Certificate Authority).
(By the way this should not be the only means of authentication. OpenId and username passwords are good fallback solutions)
Re authentication xwiki has an interface to implement to provide alternative implementations. See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication
and more specifically: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Authentication#HCustomAu...
Some guy called Skol, who looks like a playmobile character, tells me that is off line... Will look at it tomorrow, ...
It is up again.
It looks from the Oracle SSO example http://bodez.wordpress.com/2008/10/15/xwiki-user-authentication-with-oracle-...
Sorry if what I'm about to say has nothing to do with your conversation (i did not looked closely at the thread, i just seen "Oracle SSO" and my mind called me ;)): i did a Sun SSO (more or less the same thing than Open SSO if i understood well ) authenticator you can find on http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-authenticator-sunss...
that one just needs to implement
public XWikiUser checkAuth(XWikiContext context) throws XWikiException {
For an initial implementation using an IDP this could be just a few lines of code. A fuller implementation would not be much larger as we have the BSD libraries for it, but it would mostly require more work setting up (because one needs to set up an ssl connection).
Next one needs to create a user with this it seems:
context.getWiki().createEmptyUser("beppe", "edit", context);
One may in our situation not want to create a user for every authenticated person accessing the wiki, if creating a user means setting up a home page for them, giving them a special local nickname, etc... All you may want to know about them is their WebID (A URL) But perhaps that is something to leave for later development... To make this smoother, it may be worth adding a WebID field to the database, as a primary key for a person. I imaginer there are more methods for creating users though....
Henry
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (3)
-
Story Henry -
Thomas Mortagne -
Vincent Massol