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 - 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
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
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
Redistribution License
