Re: Authentication workflow draft.

On 4/12/11 9:36 AM, Andrei Sambra wrote:
> After a chat with Henry today, we decided to draft a "workflow" to
> describe how the authentication process takes place from the moment a
> user is accessing the service.
> We are assuming the user possesses a client certificate which is
> installed in his browser, as well as a publicly accessible WebID on the
> web. The URI of the webid is found in the certificate's subjectAltName.

What happens when the SAN URI (WebID) isn't "http:" scheme based? That's 
a critical test.

> Note: GOTO is used for the sake of simplicity and should not be
> generally used! :-)
> Feel free to comment/add/change stuff if you consider it important.
> -----------
> Step 0. Init / no authentication / authentication failed (implementation
> independent)
> Step 1. The user connects to the authentication server (service) and is
> asked to provide a certificate.
> Step 2. The user selects the certificate and clicks the submit button.
> If the user does not provide a certificate, GOTO Step 0.
> Step 3. Using TLS, the server verifies that the public key found in the
> certificate matches the user's private key. If the keys do not match,
> (print an error maybe) GOTO Step 0.
> Step 4. The server verifies the validity date of the certificate. If the
> certificate has expired, GOTO Step 0.
> Step 5. The server extracts any URI found in the certificate's
> subjectAltName field, ignoring everything else (like email, etc.). If no
> URIs are found, (print an error maybe) GOTO Step 0.
> Step 6. For each URI found, the server fetches and parses the profile
> file located at that particular URI, looking for resources pointing to a
> public key (i.e. rsa#RSAPublicKey?). If no resources are found, (print
> an error maybe) GOTO Step 0.
> Step 7. If a public key resource is found, the server will try to check
> if the contents of "cert:identity" match the WebID's owner. If no match
> is found for any URI, then GOTO Step 0.
> Step 8. If the identity matches the WebID, the server will try to match
> the WebID's modulus and exponent values to the ones provided by the
> user's certificate. It is possible to have multiple modulus values
> (belonging to several keys) therefore the server should cycle through
> all of them. If no match is found for any modulus/exponent of any URI,
> GOTO Step 0.
> Step 9. If the modulus values match, the client is authenticated.
> ---------------
> Andrei



Kingsley Idehen 
President&  CEO
OpenLink Software
Twitter/ kidehen

Received on Tuesday, 12 April 2011 14:48:28 UTC