www.openlinksw.com
docs.openlinksw.com

Book Home

Contents
Preface

Web Services

SOAP
WSDL
FOAF+SSL Support
x.509 certificate Setting up Virtuoso HTTPS Setting Up Firefox Configuring ODS Account to use FOAF+SSL Testing the setup FOAF+SSL ACLs SPARQL-SSL based Endpoint CA Keys Import using Conductor Set Up X.509 certificate issuer, HTTPS listener and generate ODS user's certificates FOAF+SSL ODBC Login
OAuth Support
WS-Security (WSS) Support in Virtuoso SOAP Server
Web Services Routing Protocol (WS-Routing)
Web Services Reliable Messaging Protocol (WS-ReliableMessaging)
Web Services Trust Protocol (WS-Trust)
XML for Analysis Provider
XML-RPC support
SyncML
UDDI
Exposing Persistent Stored Modules as Web Services
Testing Web Published Web Services
BPEL Reference
XSQL

15.3. FOAF+SSL Support

FOAF+SSL is an authentication and authorization protocol that links a "Web ID" or "Personal URI" to a public key to create a global, decentralized, distributed, and secure authentication system that functions with existing browsers.

FOAF+SSL uses PKI standards - usually thought of as hierarchical trust management tools - in a decentralized web-of-trust way. The web of trust is built using semantic web vocabularies (particularly FOAF) published in RESTful manner to form Linked Data.

Based on well known existing standards, FOAF+SSL is currently in development, and is being discussed on the FOAF protocols mailing list.

For the most recent description of the protocol, read the one-page "FOAF+SSL: Adding Security to Open Distributed Social Networks". For a more detailed explanation of how the authentication works, see "FOAF+SSL: Creating a Web of Trust without Key Signing Parties".

Automatic discovery of interpersonal trust relationships enables automatic application of appropriate permissions.

In other words, data owners can set fuzzy permissions like "only let my friends see this" or "only let my family edit this." Applications can discover the relationships between the data owner and the data requester/user, and permit (or disallow) any attempted actions, without needing the data owner to explicitly set permissions for each potential user.

One example might be a parent setting permissions on a photo gallery, to permit viewing only by "immediate family". The parent need not list each and every such relative specifically for this application - and need not add new permissions for a new family member (whether by marriage, birth, or otherwise), though they do need to be added to the owner's FOAF. When a new user comes and asks to see the pictures, the gallery application would check the relationships declared by each person (the owner and the visitor), and if they matched up (in other words, the visitor could not get in simply by claiming a family relationship; the relationship must be confirmed by the owner's FOAF data), the pictures would be shown.

15.3.1. x.509 certificate

The FOAF+SSL consumer needs an x509 certificate with v3 extension "Subject Alternate Name". This attribute is used for the owner's Web ID. For testing purposes we used OpenSSL demo CA to generate such certificates. If you are not using the OpenSSL demo CA, you must first setup a self-signed CA; read OpenSSL documents on how to do this.

  1. Add the following line to the [usr_cert] section of the openssl.cnf file:
    subjectAltName=$ENV::ALTNAME
    
  2. Set the environment variable ALTNAME to the owner's Web ID, e.g.,
    export ALTNAME=URI:http://localhost/dataspace/person/myname#this
    
  3. Make a self-signed certificate, e.g.,
    $ CA.pl -newreq (follow the dialog)
    $ CA.pl -sign
    
  4. When asked to commit the certificate, make sure you see several lines above, like:
     X509v3 Subject Alternative Name:
                    URI:http://localhost/dataspace/person/myname#this
    
  5. If your browser wants a PKCS#12 bundle, you must make one:
    $ openssl pkcs12 -export -in newcert.pem -inkey newkey.pem -out mycert.p12
    
  6. Rename newcert.pem and newkey.pem, to mycert.pem and mykey.pem for example. The PEM format of the certificate will be needed below.

15.3.2. Setting up Virtuoso HTTPS

To enable the HTTPS listener, you will need another certificate. Existing certificates may not have Subject Alternate Name, so you may want to generate one as in the previous section.

  1. The next step is to move newcert.pem, newkey.pem, and cacert.pem into the server's working directory. In our test case, we put the keys in a 'keys' sub-directory, and added the following lines to the [HTTPServer] section of the Virtuoso INI file, virtuoso.ini:
    SSLPort                     = 4443
    SSLCertificate              = ./keys/localhost.cert.pem
    SSLPrivateKey               = ./keys/localhost.key.pem
    X509ClientVerifyCAFile      = ./keys/localhost.ca.pem
    X509ClientVerify            = 1
    X509ClientVerifyDepth       = 15
    
  2. Also in the Virtuoso INI file, in the [URIQA] section, DefaultHost (localhost:8890 below) must be edited to correspond to the DNS-resolvable host name ("CNAME") of the Virtuoso host, combined with the ServerPort as set in the [HTTPServer] section of the same INI file.
    [URIQA]
    DynamicLocal = 1
    DefaultHost  = localhost:8890
    

    For instance, if the CNAME of the host is virtuoso.example.com, and the ServerPort is 4321, the DefaultHost should be set to virtuoso.example.com:4321

    [URIQA]
    DynamicLocal = 1
    DefaultHost  = virtuoso.example.com:4321
    
  3. Start the Virtuoso server, and look at the log file. Once HTTPS is up, you should see something like:
    HTTPS Using X509 Client CA ....
    HTTPS/X509 server online at 4443
    

15.3.3. Setting Up Firefox

  1. Setting Up Firefox
    Figure: 15.3.3.1. Setting Up Firefox
  2. Click the "Add exception" button and enter the address of the HTTPS server you've just configured, i.e., https://virtuoso.example.com:4443/
  3. Click OK, and confirm the exception.
    Setting Up Firefox
    Figure: 15.3.3.1. Setting Up Firefox
  4. Click to the "Your Certificates" tab, and import mycert.p12.

15.3.4. Configuring ODS Account to use FOAF+SSL

  1. Log in to your ODS account, and edit your profile.
  2. Click to the Security Tab, and scroll to the bottom, where you will find the X.509 certificate entry area.
  3. Copy and paste the PEM format of the certificate (i.e., the content of mykey.pem, from earlier).
  4. Press "Save Certificate" button, and you are set.

15.3.5. Testing the setup

To test, we recommend Firefox v3 with the Tabulator extension. Firefox must be set to ask for RDF, as instructed in the Tabulator documentation.

  1. Enter an ODS user's URI in the address bar.
  2. You should see a protected document's URI. Note that there is no specific "address" data seen:
    Testing the setup
    Figure: 15.3.5.1. Testing the setup
  3. When clicked, the browser will ask the user to select a certificate (note: certificate details are erased in the picture below).
    Testing the setup
    Figure: 15.3.5.1. Testing the setup
  4. Now the protected document includes the private address data alongside the previously visible public data!
    Testing the setup
    Figure: 15.3.5.1. Testing the setup

15.3.6. FOAF+SSL ACLs

You can set FOAF+SSL ACLs from the Virtuoso Authentication Server UI.


15.3.7. SPARQL-SSL based Endpoint

See details how to create and use a SPARQL-SSL based Endpoint.


15.3.8. CA Keys Import using Conductor

The Virtuoso Conductor allows easy import of user-level CA (Certificate Authority) Keys through System Admin -> User Accounts -> Edit.

The dba user (typically) or other users may need CA keys to execute different services.

For ODS, the dba user must import a certificate with primary key and with name id_rsa. The process takes the following steps:

  1. A signing authority (e.g., RSA Labs) generates a site certificate.
  2. The site certificate is used to generate certificates for ODS users.
  3. The site certificate is imported with name id_rsa for user dba using the Conductor.
    Conductor CA Keys Import
    Figure: 15.3.8.1. Conductor CA Keys Import
  4. As a result, the ODS user certificates can be authenticated against the site certificate.

If there is a service that requires a different key, the Conductor can be used to import another certificate for the relevant user.

You can use a Key from a global signing authority or produce a self-signed key using the ODS Identity Manager.

Details and more information how to generate the key see in the next section.


15.3.9. Set Up X.509 certificate issuer, HTTPS listener and generate ODS user's certificates

The following Step-by-Step guide walks you through set up of an X.509 certificate issuer and HTTPS listener, and generation of ODS user certificates.

  1. Install ODS and Identity manager VAD packages.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  2. Go to the http://cname:port/identity_manager URL, enter the DBA user credentials in the dialog presented.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  3. Enter the Issuer details and click generate.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  4. Go to Conductor -> Web Application Server -> Virtual Domains & Directories, and add a new listener.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  5. Edit the new listener, and generate new key.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  6. Go to Packages list and select Configure for ODS Framework.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  7. Select Create New Endpoint.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  8. Enter the home path for ODS, and save.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  9. The new endpoint should now appear in the endpoint list.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  10. Go to the HTTPS site, e.g., https://cname:port/ods; in our example, https://localhost:4433/ods/. If Firefox is used, it will complain that the certificate is not valid, so we must register the site's certificate.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  11. In Firefox certificate manager, in Site's certificates, add an exception.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  12. Confirm exception.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  13. Return to ODS site, and register new user.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  14. Edit the user's profile and enter his/her name(s). If this step is skipped, the certificate will not have a human readable name.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  15. Open the Security tab in the Profile Editor, and generate the client key.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  16. If all is set up correctly, you should see this message. It means Firefox has the private key, and has obtained a new certificate from the server.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  17. Refresh the Security tab by clicking on same tab.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  18. Select automatic login option, and save.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  19. Log out from ODS and refresh browser to simulate opening the ODS site. The browser will ask for a certificate; select the one generated in the steps above.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  20. ODS presents your card, and asks to login with certificate. Confirm it.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA
  21. You should now be logged in to ODS via FOAF+SSL.
    Setting-Up issuer CA
    Figure: 15.3.9.1. Setting-Up issuer CA

15.3.10. FOAF+SSL ODBC Login

See details and examples here.