TAAC Examples
I’ve posted three examples that utilize TAAC in some manner.
- https://dice.csail.mit.edu/taac/juliette-protected-location.n3 requires you to merely access it with a properly encoded certificate.
- https://dice.csail.mit.edu/taac/foaf-only.n3 limits access to only those who are friends, or friends of friends of http://dice.csail.mit.edu/taac/juliette.n3#juliette (via foaf:knows). Unfortunately, this rule is a bit slow, and may take upwards of 30-60 seconds to process. I’m looking into why this is the case.
- https://dice.csail.mit.edu/taac/friending-me.n3 limits access to only those who have listed http://dice.csail.mit.edu/taac/juliette.n3#juliette as a friend (via foaf:knows).
You can test any of these yourself if you present the proper client certificate linked to your FOAF file (otherwise, without a client certificate, you won’t be able to authenticate with FOAF+SSL.) If you don’t have a properly configured certificate or FOAF file, Henry Story has a short description of how you can set this up in Firefox 3 with some utilities in the sommer repository. In addition, this server requires you to explicitly provide a certificate (as client certificates are optional).
So How Does TAAC Work?
As mentioned previously, Henry Story has some excellent descriptions of how the FOAF+SSL protocol works in general. TAAC is merely an implementation of this, but goes further to implement an authorization framework. How does this work though? The following diagram goes a ways toward explaining TAAC’s design (especially with regard to authorization) in general.
TAAC acts as a proxy for any URI access within the directory it’s set up in (thanks to mod_python). On every access, it will check the requested URI against the list of URIs having an rein:access-policy (as populated from the file specified in the POLICY_FILE variable). If no access policy exists, TAAC gladly permits normal access without any needed authentication.
If an access policy exists, however, TAAC will immediately attempt to properly reach a successful completion of the FOAF+SSL authentication protocol. I won’t go into significant details here, as Henry Story gives an excellent overview of the protocol (in a somewhat earlier state, though the same principles still apply) on his blog.
Following this, TAAC takes the successfully authenticated URI-token and logs the attempted access to a log file (specified by LOG_FILE). Taking this generated resource describing the access, and the AIR policy attached with the rein:access-policy triple, TAAC then proceeds to run an AIR reasoner over the policy with the given log resource. If the resource describing the access is concluded to be air:compliant-with the associated access-policy, the fact that access was granted according to the policy is logged, and access is granted. Otherwise, the fact that access was denied is logged, and access is denied with a 403 response.
Tags: authorization, taac
