ctrep fedora trust architecture

Tue, Oct 23, 2007

I’ve sorted the problem I had with specifying truststores in Axis2. I don’t have to use the crude method of specifying the location and password in System properties. Instead, I’ve combined the Guanxi SSL Layer probing functionality with a custom ProtocolSocketFactory that makes use of the truststore that the Guanxi SSL probing populates.

The basic flow is thus:

I might have done it slightly more simply (technically speaking) by not using the probing layer and instead importing the Fedora certificates directly into the main truststore. However, I won’t be doing that, users will and I haven’t met a user yet who knows (or cares) what either a certificate or truststore is, not to mention how to use keytool from a terminal window! So let’s just forget that avenue completely. By probing whenever a Fedora is mounted or when a refresh is made in the resources tool (haven’t decided what that means yet), the probing layer goes off and gets the latest certificate from each mounted Fedora. That way no-one has to bother with updating expired certificates.

But what about security? Well, there are two levels of security when accessing a Fedora API-M endpoint (API-A endpoints are normally not https). First you have option of using client authentication at the Fedora end of the connection. This of course is ludicrous as it would stop all browsers accessing the interfaces unless those users were issued with trusted certificates. Even if this was enforced by a particular Fedora, the custom ProtocolSocketFactory can handle this as it can be issued with a trusted certificate which it will use, from its keystore.

The next level of security is the main one, the Fedora admin username and password and this has nothing to do with certificates. It’s a plain text credential, protected (in the case of API-M) by https. The user will supply this information in the mountpoint XML file. The only information that Sakai is divulging about the user, to Fedora, is the username. This is to associate digital objects with their correct owners.

So the choice is between full metadata and policy trust, where, before a Fedora can be mounted, a document exchange must be made between Sakai and Fedora people, much in the same was as the UK Shibboleth Federation, or an ad-hoc auto-trust mechanism where Sakai chooses to trust all mounted Fedoras. Perhaps an unscrupulous individual has crafted a fake API-M service that hoovers up Sakai usernames but metadata and policy won’t stop that either. There’s nothing stopping that individual from registering their fake Fedora with a Sakai administrator. So it’s all about trust and objective threats. Either make it easy for users to integrate their Fedoras with Sakai or make them go through a full process of arranging to have the certificates imported and documents signed. In the latter case, they just won’t bother.

So the probin/auto-trust architecture strikes a balance between ease of use/adoption and security based on perceived levels of threat. Suck it and see…

comments powered by Disqus