So I’ve finally been able to get around to moving the TAAC demos to their final location (on DIG’s demo server, dice) and also porting the SVN history to TAAC’s new home in a Mercurial repository.
Now, you should be able to run the demos on a permanent home, and have a much easier time hacking on TAAC if you so desire. (As before, it still needs python-openid and it requires that you check out the air-reasoner repository in the same place to a directory named “tmswap”).
My apologies for being relatively silent on this blog, but I tend to be rather close-lipped when it comes to social media (blogs, Twitter, Facebook, etc.). In any case, those of you visiting this site may be interested to know about certain projects I’ve worked on in the past (especially TAAC and/or AIR), so I’ll try to do my best to keep you up to date.
Well, that’s all I can offer for now. I may revise this post as I note other things I forgot, however, so stay tuned.
Mostly for my benefit, but here are a few examples of how cwm’s N3Rules translate into formal logic:
@prefix : <#> . @forAll. {
∀x (a(x, b) → c(x, d))
Therefore the above entails the additional statement :someValue :c :d . as is bound to :someValue on the RHS.
@prefix : <#> . @forSome
∃x (a(x, b) → c(x, d))
Therefore the above entails no additional statements.
@prefix : <#> .
{ @forAll . :a :b . } => { :c :d . } .
:someValue :a :b .
(∀x a(x, b)) → c(x, d)
Therefore the above entails no additional statements.
@prefix : <#> .
{ @forSome . :a :b . } => { :c :d . } .
:someValue :a :b .
(∃x a(x, b)) → c(x, d)
Therefore the above entails the additional statement as :c :d . is unbound on the RHS.
@prefix : <#> .
{ :someValue :a :b . } => { @forAll . :c :d . } .
:someValue :a :b .
a(someValue, b) → (∀x c(x, d))
Therefore the above entails (generally) @forAll :z . :z :c :d .
@prefix : <#> .
{ :someValue :a :b . } => { @forSome . :c :d . } .
:someValue :a :b .
a(someValue, b) → (∃x c(x, d))
Therefore the above entails the additional statement [ :c :d ] .
Finally, two trickier specific examples: “If there exists a foaf:Person that all (known) foaf:Persons foaf:know, then there exists a ” and, “any 
opularPersonfoaf:Person that is foaf:knows of all (known) foaf:Persons in a ” can’t be done properly without completely closing the world. cwm cannot do this without artificially closing the world through built-ins. opularPerson
I’ve posted three examples that utilize TAAC in some manner.
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).
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.
As I’ve been working on TAAC, I’ve started to become concerned about potential weaknesses with any FOAF-based identity authentication system (be it RDFAuth, OpenID, or FOAF+SSL) and that’s that ALL systems, with the possible exception of RDFAuth (due to its reliance on PKI), have their weakest link as the integrity of the server hosting the FOAF file. All three systems rely on data in the FOAF file to ‘authenticate’ against, but this poses problems. Take, for example, the following scenario:
Alice runs a website that accepts an OpenID+FOAF system (it works easily well with FOAF+SSL). Bob is a client of Alice, and regularly uses the authentication scheme Alice has implemented. When authenticating, he traditionally authenticates against his FOAF URI, http://www.example.com/bob.rdf#bob. The file bob.rdf has information that links to Bob’s OpenID, http://www.example.com/bob, permitting him to authenticate with his (self-run) OpenID provider.
Eve wants to see the information that Bob gets to see on Alice’s website, and thanks to some shoddy system administration, finds a security hole that allows her to get access to the filesystem. Ignoring the other private information acquired in this way, Alice silently replaces bob.rdf with her own FOAF file that has one simple change: the OpenID associated with http://www.example.com/bob.rdf#bob is now http://www.example.com/eve, which is Eve’s OpenID provider. Eve authenticates agains her own OpenID provider and gets access as Bob to Alice’s website, does her dirty work, and then quietly returns the original FOAF file so that Bob is none the wiser. There’s precious little evidence that Eve intruded, and only an alert sysadmin might note the erroneous login. Meanwhile, Alice is barely aware of any difference other than that the OpenID changed for one particular login.
In summary, as Henry Story admitted (Point 5 in the FOAF+SSL description), these methods only assert that the person accessing any protected resource has ‘write access’ to their FOAF file… But that doesn’t assert that they’re the same person.
With the common weakness of many self-hosted domains having poor security protocols, a FOAF-based Authentication System could be disastrous. The only plausible ‘stopgap measure’ might be requiring the system as a whole to cache the authentication credentials (e.g. OpenID, public key URL, or X.509 hash) and refuse access to people who present credentials that have changed. This adds a layer of complication to the mix as well, as it would require out-of-band communication to ensure that the ‘cached’ credentials are removed or replaced with new credentials manually… And even so, there is still the risk of incorrect authentication credentials being presented absent any evidence they are incorrect (e.g. Eve logs in before Bob ever does, or does so in the period where Bob’s cached credentials have been deleted, establishing her credentials in place of his own). There are ways around this, but they seem a bit kludgy to me (e.g. using the old OpenID/X.509 cert, which may not exist due to security risks, to authenticate the new one; checking against a public key server to see if there’s any indication that a public key has been revoked/replaced).
Are we sure that a FOAF-based Authentication System is secure enough? At the very least, it seems like we need proactive sysadmins maintaining the system to ensure it remains secure… And can we afford that?
So I’ve finally got a chance to return to working on TAAC, an access control mechanism for the web that integrates FOAF-based identification with access control rules. I’ve been doing some more thorough testing on the slow-down issues explained two posts back, and found that the slowdown, while significant, appears to be about 13 seconds or so, on average, on this server, a Linode virtual private server which I expect typifies an average web host (if not better than average).
Several attempts at profiling (aside from creating significantly increased processing times, up to 10x longer) led to the conclusion that, in fact, most of that time is spent in the second phase (post-authentication, during reasoning), which is where I’d EXPECT the slowdown to be. Granted, this now becomes a problem that can be solved in part by Moore’s Law, but even so, some speedups would be nice to allow it to be implemented today. I plan on running the same code on a relatively modern test server that’s dedicated to doing more or less supporting these tests, so it will likely run faster on there.
It’s worth considering that this is running on a variant of the cwm reasoner on top of a re-implemented Rete reasoner, and, seeing how it’s all in interpreted Python, rewriting it in compiled C code (or even Java) would probably see a significant speed-boost, but that’s not a terribly productive line of work (except where trying to actually push out a commercial product). It might also be worth exploring other reasoning approaches to improve the speed.
Even so, I’m going to try looking at the other authentication approaches to see what the benefits and costs of them are… I think the more RESTful approach without OpenID may have some arguments in favor of it, but I doubt they’re going to be based solely on speed.
So I’ve returned after some time at MIT where I was getting a bearing on where I’m going next with my part in the TAMI project, and I’ve come out with a few goals:
I suppose it’s about time for me to announce a status report of what I’m up to lately…
First: I’ve picked up my Pixonomy project again, and while I’ve JUST put it on hold again, I’ve progressed the library with a refactoring and I just need to do some cross-platform hacking (to get it to compile nicely on OS X as a universal binary), and implement a couple of search functions to actually get it to a state where I can actually start programming client software in GTK+ or wxWidgets (I haven’t decided which) to demo the library.
Second: I’m currently taking a break from Pixonomy to work on a nifty font for OpenTTD.  Since I noted that they finally implemented TrueType support and Unicode support in 0.5.0 (which I’d tried to implement before, but never really got around to), I figured I’d try my hand at something fun.  After I get all the lower case characters done preliminarily, I’ll start adjusting the bounds and kerning by testing in game…
Third: Been watching some of the subs for this season, and I think Allison & Lillia does seem to have some promise, but we’ll see where it goes. Â Zettai Karen Children, though, is not so much up my alley. Â We’ll see where the other series I want to check out go (namely, Library War)… Â There’s a few others that might be good, too.
It Is A Mystery… is proudly powered by
WordPress
Entries (RSS)
and Comments (RSS).
This work is licensed under a Creative Commons Attribution-Share Alike 2.5 License.
Special Thanks to pfcdayelise for the use of the foggy valley image on the left.
