[foaf-protocols] KiWi and foaf-ssl

Story Henry henry.story at bblfish.net
Tue Jun 23 17:10:22 CEST 2009


Hi Stephanie,

	welcome to the foaf-protocols community :-)

On 23 Jun 2009, at 13:36, Stephanie Stroka wrote:

> [snip]
> So, my name is Stephanie Stroka and I'm part of the core developer  
> team
> of KiWi (http://www.kiwi-project.eu). I've heard about foaf+ssl from
> Henry Story, who is also (at least intended to be :) ) part of the
> project.

:-) I am now that kiwi is doing foaf+ssl ! thanks for bringing me back  
in :-)

> KiWi suits very well as a candidate for authorization via foaf
> +ssl, as it is a platform for extensions like Wikis, Blogs and also
> Social Networks, where data is stored in RDF. As I'm personally also
> very interested in identity management, I thought the idea of
> intergrating the foaf+ssl authentication very useful, and that's what
> I've done last week:
>
> I used the following link to get my webid from the certificate and to
> redirect to a webservice that imports the data of my foaf-file into  
> the
> KiWi system.
> https://foafssl.org/srv/idp?authreqissuer=http://localhost:8080/KiWi/seam/resource/restv1/FOAFSSLAuthentication
>
> As you can probably think of, the FOAFSSLAuthentication webservice is
> not very secure, as everyone can access it with an arbitrary webid in
> the HTTP GET parameter, and may therefore be able to thieve ones
> identity. That's the first problem that we are currently facing.

Ok, that is why the https://foafssl.org/srv/idp service adds a  
validity timestamp and signs the url. So for example if I try

https://foafssl.org/srv/idp?authreqissuer=http://bblfish.net

The service  redirects my web browser to the very long URL

http://bblfish.net/?webid=http%3A%2F%2Fbblfish.net%2Fpeople%2Fhenry%2Fcard%23me&ts=2009-06-23T06%3A56%3A11-0700&sig=PbcI8qXrFvVtoAj7XNvADmxJlgJHZWkhiGy8dOwWsgqcqwzJ601v0iIKbm8CH6r%2FOHkdAdhfk3Hq4Z8wdtiC4n1m7d5d22AO%2BsEn8f3C8lnWXgc%2Fm3qmxqvXheMsOZOjGY5hUUhutO3JruS4DX4OC6muyFJoeI5ZWThFm%2BZhcM0%3D

Notice the ts= timestamp which gives the service some way of telling  
how old the request was. Clearly it should not be older than a few  
minutes.

the sig= is the signature of the URL string that comes before the ?sig=
The public key for the signature is listed on the idp service page.  
You can use that to
verify that the idp really did redirect to that URL.

Perhaps Bruno Harbulot can point you to some code to help you verify  
the URL.
If the URL is verified you have a very high degree of certainty that  
the person you are communicating with is indeed the person identified  
by that WebId.

> Another one is that KiWi is build on JBoss Seam, a very powerful (but
> sometimes also annoyingly intransparent) framework based on Java EE 5.
> Before we integrated foaf+ssl we were using Seam`s identity management
> services, which take away a lot of implementation work for  
> applications
> that want to use basic username-password authentication. Seam also
> provides services for LDAP and openid authentications (I personally
> never tried it). As we do want to use the normal user/password
> authentication as well, we have to provide an alternative  
> authentication
> mechanism that does not check for the username and password if a foaf
> certificate is available. Currently, I simply registered a method that
> is called when a user logs into the system with foaf+ssl.

I suppose what you can also do is create a map from URLs to Seam ids.  
Then when the
IDP returns with a URL you could look it up in the map. If it is in  
there you log in using the normal Seam method with the given id. If it  
is not you can ask the user if he already has an account:
  - if he answer yes, and gives you an account (and proves that he  
does indeed own it) then you map that WebId to that account, and log  
him into that account
  - if he answers no, then you create a new seam account, associate  
the WebId with that account, and log him in with that account.

(you may have to create some code to bypass the Seam authentication  
piece, since you already did that with foaf+ssl)

> This method simply returns true, as we already externally ensured  
> that the user is
> authenticated by getting redirected to the webservice. You would agree
> that this is hacking, not programming and that it probably opens up a
> lot of security holes.

Without seeing the code it would be difficult to tell if this is a  
piece of clever or bad hacking :-) But if you already have the user  
identified with foaf+ssl then indeed there is no need to authenticate  
him in another manner.

Hacking is often a very good skill :-) In this case you are getting to  
put together the
pieces to get a feel of the properties of foaf+ssl. It is better to  
get something done quickly, see if you like it, then deepen your  
knowledge of it, than avoid it because the initial perfect  
implementation would take too much time.

Furthermore as the foaf+ssl examples get to be more and more  
concincingly useful it will be easier to convince the Seam people to  
add the relevant hooks into their framework. The hack here is the  
first step in convincing them to integrate foaf+ssl into their  
libraries.

> So my intention is to integrate the authentication protocol of foaf 
> +ssl into KiWi and use KiWi as a CA.
>
> Do you think this will work or is foaf+ssl intended to be used as a
> centralised service.

foaf+ssl is intended to be used as a decentralized service. The  IDP  
is just a service to make it easy to get going.

It will be useful in many case though. Imagine for example that you  
distribute Kiwi as a binary. In order for foaf+ssl to work well, the  
user deploying Kiwi will need to buy a certificate from one of the  
CAs. I got a cheap on for something like $15, which is not much, but  
it is a bit of work, and we know what happens if something is more  
complex to install than 1click. You loose most of the user base.
   If the kiwi deployer does not have that then people arriving at the  
Kiwi instance will be told by the browser that the site they are about  
to look at could be really dangerous for them, that it might make them  
loose the ability to have children, and stuff of that sort... So  
clearly people installing Kiwi the first time around, in order to try  
it out, should not have to buy a CA signed certificate just to see  
what they can do with your software. There for example the IDP will be  
very useful.  Once they feel comfortable with Kiwi, then they should  
of course reduce their dependencies on external services, and run the  
foaf+ssl library themselves.

Anyway, all this to say that your work using the IDP, will be useful  
in any case.


> If it would work, how difficult is it to integrate
> the foaf+ssl service in another system, or maybe to use foaf+ssl as a
> Seam authentication module (which I'd prefer, because then every
> application that is build with Seam could easily use it).

You should be able to use the libraries directly on your server.  
Though as I pointed out this will require you to run your server on a  
secure socket.

the current foaf+ssl java libraries are now available as jars in on  
the Maven repositories. See the mail here:
    https://sommer.dev.java.net/servlets/ReadMsg?list=users&msgNo=362
(though I am not sure if we have documentation on how to use it handy.  
Bruno?)


> Furthermore, we have the problem that we also want to modify the foaf
> files that identify a person.

What is the use case you have for that?

> And we want it not to be done on a
> centralised place, which means that I, as a KiWi user, would not  
> like to
> go to my foafbuilder-website to add another KiWi user as a friend, but
> rather to add him as a friend on KiWi and get the foaf file
> automatically modified. How is that possible?

That kind of thing will require either the use of oAuth or for us to  
develop something similar using foaf+ssl. One way to do that would be  
for the Kiwi instance to also have its WebId, and for us to find a  
method to create services so that one can give such agents limited  
rights to write to certain resources.

For example it would really help me to have something like this work  
to allow foafssl.org/cert to add triples directly to qdos.

This is something we should add to the wiki on the list of features to  
add.

> Do we have to provide our own foaf builder?

Well it would be nice to have another foaf builder, and I am sure you  
could do an excellent job providing one.

But on the whole it would be best if every service did not require to  
build a foaf builder too. In any case Kiwi should certainly be able to  
work without implementing a foafbuilder. The point after all is that I  
should be able to keep my main profile in one place, and not have to  
create a new one for every service I want to create.

I can also think of one simple solution here:

Imagine we have a relation such as

:me foaf:addKnowsForm <https://foafbuilder.qdos.com/bblfish/addknows> .

Then when your service reads my foaf, it would know how to create a  
form and where to send the information to. So it could create a form  
that would post the relations to foafbuilder.qdos.com (or some such  
service) and since it is my browser that is posting that form (and  
since that service will be foaf+ssl identified), then when I post the  
form, then foafbuilder would know it is me who posted it, accept the  
RDF (and perhaps show me what it is I am adding to my foaf, in case  
the service posting the data is sending something else than what I  
accepted).

So I think if we can agree that the above does not sound crazy, then  
the ansswer to your question would be:
   - you don't need to build a foafbuilder
   - you can add friends or info to my foaf file if it supports that  
service

We just need to work out what that service is in more detail.


I hope that answers some of your questions,

	All the best,

		Henry Story


Social Web Architect
Sun Microsystems		
Blog: http://blogs.sun.com/bblfish



More information about the foaf-protocols mailing list