If you need to contact me, e-mail to ian at iay.org.uk is probably quickest. If you're bored, you might like to look at my personal web site or even my blog.

You can find the instructions for emergency metadata signing for the SDSS federation at SigningKit.

Random Stuff In Preparation

To-do List

Some things I'd like to get back to at some point. Some of these ought to be filed as bugzilla reports against shibboleth once they are tracked down.

  • I believe the IdP crypto strength is limited by default by J2SE 1.4, and that there is a way to extend this by an extra download from Sun. We should look into that at some point.
  • The certificate format used by the siterefresh program is very brittle: it just takes all lines of the file that don't look like PEM boundary lines and assumes they are BASE64. This means that if you have any extraneous text in the file, or put in a certificate bundle rather than just the one certificate, bad things will happen. The diagnostics in this case are not very helpful. The application should be a lot pickier, and it might also be worth having it check that the key it gets out is the same key as the one in the signature.
  • It looks like siterefresh always writes a normalised version of the retrieved metadata, even when the metadata is unsigned. My preference would be for it to always write the retrieved file verbatim, even when it is signed. This would mean that one could use something like md5sum to verify the metadata if a signature wasn't available.
  • It is possible to write trust metadata files in which there are multiple elements associated with the same KeyName. This would be useful if, for instance, you had one CA that directly signed certificates and another that signed through intermediaries. You'd want to express that information in the metadata and that would require multiple elements at that level. However, it looks like in practice only the first such element is used; the later ones are ignored.
  • SDSS Federation policy should probably include strong guidelines on Apache SSL crypto suite choices.
  • Need some kind of automatic restart of the bodach suite (tomcat, shar, apache) when bodach is rebooted (every few months!).
  • I think the AAs should always be verifying SSL client, not just optionally.
  • We need to understand revocation in this context, including making some suggestions as to best practice. Which parts of Shibboleth understand revocation? How is it configured? Revocation is also an issue in Apache.
  • Investigate federation metadata as an RPM.

Federation Audit

It is easy to set things up badly, and quite hard to tell if that has happened. Some sort of (perhaps centralised) tools to help with this are needed.

  • I think it should be possible to audit SSL endpoint strength automatically by making attempted connections to them and looking at the crypto suites offered.
  • Similarly, we could audit NTP clocks at federation sites under certain circumstances.
  • We can see who is doing metadata refresh and who isn't, at least in IP terms, by looking at the Apache logs for the sdss.ac.uk server. After mapping IP addresses to federation entities (one IP address may represent several entities) we could tell how long it has been since the metadata used by that entity has been updated. If that got to be too large a number, we might want to remind the site administrator.
  • We should be auditing the logs that come out of Shibboleth in particular and perhaps Apache in general to look for attacks.

OpenLDAP Installation on Solaris

Current attempt: 

 ./configure --prefix=$HOME/shibb12/openldap --disable-bdb

Resulted in: 

 configure: warning: Could not locate TLS/SSL package
 configure: warning: TLS data protection not supported!

Add: 

 --with-openssl=$HOME/shibb12/openssl

Doesn't help.

Also, note no back-end enabled. Need Berkeley DB; ldbm variant doesn't work either.