FOAF+SSL: Secure, RESTful, Single-Sign-On Authentication

Ian Jacobi, Henry Story, Toby Inkster, Melvin Carvalho, et al.

19 February 2009

Overview

What is FOAF+SSL? Why is it needed?
Comparing FOAF+SSL and other authentication methods
How FOAF+SSL works
Building authorization on top of FOAF+SSL
Next directions

What is FOAF+SSL?

A RESTful, secure, open authentication framework
Like OpenID, with security by default and no provider
Implemented seamlessly on top of SSL

Why FOAF+SSL?

Linking common semantic representation to user token
Distributed ACLs
Protecting sensitive data on the Open Social Network

Current Alternatives: HTTP Authentication

Pros:

Supported by almost all web clients/servers
Easy to set up and maintain

Cons:

Site-specific login information (password glut)
Easy to set up insecurely (Basic over HTTP)
Shared secrets

Current Alternatives: OpenID

Pros:

Single username, single sign-on
Already deployed, many providers and provider softwares

Cons:

Security concerns (spoofing)
Not as easy to integrate or set up as HTTP authentication
An architectural hack (requires graphical browser)
Can still be implemented insecurely (HTTP provider)

Using FOAF+SSL

Pros:

Single 'username', need not remember URI
Requires SSL by default for security
Integrates with existing practice and standards
Provides link between user and semantic descriptions (for authorization)

Cons:

Self-signed client certificates may need minor workarounds on server
Implicit security of protocol unproven
Optional certificate presentation not well-supported (Safari, Chrome)

Technical Background - FOAF

"Friend of a Friend" vocabulary
A defacto RDF standard for describing a person
Semantic Web-based vocabulary
Gives an individual a URI

FOAF+SSL - The Protocol

The user requests the page and, during the establishment of an SSL connection with the server, provides a self-signed certificate containing a pointer to the user's URI. The server 'dereferences' the user's URI and attempts to verify the public key of the client certificate against information at the user's URI. If the key is properly verified, the user's URI can be trusted as 'owned' by the user.

FOAF+SSL - Adding Authorization

Only establishes control of a URI
FOAF URI and certificate allow for establishing trust (PKI/Third-parties)
Self-signing clients are okay: Web-of-Trust works better with clients than servers
Can use URI as unique identifier for policy reasoning

FOAF+SSL - Adding Authorization

Once the user's URI can is trusted as 'owned' by the user, the URI may be used to reason about whether a user is authorized to access a particular resource.

Use Cases

Single-sign-on web service user identification (as in OpenID)
Single-sign-on web service personalization (linking social networks)
Single-sign-on for other services (XMPP)
(Distributed) HTTP access control

Deployment Hurdles: Certificate Creation

Integrating in-browser SPKAC/SPKI cert creation
Several implementations of SPKAC/SPKI cert creation with FOAF+SSL
Caveat: IE doesn't support SPKAC/SPKI, but supports an equivalent

Deployment Hurdles: Ontology Design

Should the key of the certificate belong to the agent? Or should the key of the certificate belong to an account of the agent?

FOAF+SSL Implementations

TAAC

mod_python and Apache (CGI version being tested with lighttpd)
Includes reasoner for complex authorization rules
In alpha

FoafServer (in Sommer)

Java-based
Has certificate generator
Lacks authorization at this time

PHP, Perl, Openlink Virtuoso implementations, among others

Open Questions

How secure is the self-signing client?

Appears better than a self-signing server
Caveat: Establishes user as able to write to the URI, not that they ARE the person described by the URI.

Usability concerns

Some browsers poor at providing optional certificates
Some browsers don't accept client certificates

No authorization standard (out of scope)

TAAC is an example, but not representative

FOAF+SSL Resources

Up-to-date links on the ESW Wiki
FOAF+SSL Position Paper: "FOAF+SSL: Adding Security to Open Distributed Social Networks"
Ongoing discussions on the foaf-protocols mailing list
FOAF+SSL at Sun:

TAAC and Authorization:

Redistribution License

Creative Commons License