[foaf-protocols] KiWi and foaf-ssl
henry.story at bblfish.net
Tue Jun 23 17:10:22 CEST 2009
welcome to the foaf-protocols community :-)
On 23 Jun 2009, at 13:36, Stephanie Stroka wrote:
> So, my name is Stephanie Stroka and I'm part of the core developer
> 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
:-) I am now that kiwi is doing foaf+ssl ! thanks for bringing me back
> 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
> KiWi system.
> 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
The service redirects my web browser to the very long URL
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
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
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
> 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
> 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
> 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
the current foaf+ssl java libraries are now available as jars in on
the Maven repositories. See the mail here:
(though I am not sure if we have documentation on how to use it handy.
> 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
> 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
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
We just need to work out what that service is in more detail.
I hope that answers some of your questions,
All the best,
Social Web Architect
More information about the foaf-protocols