First step on the road to Guanxi-dom was to build a webapp and build Apache Axis into it, rather than have the Guanxi system sitting inside Axis as a JWS or normal web service. To install Axis is simple. To build it into an existing webapp is just as simple. Doing this gives you complete control over your site, with separate apps for SOAP/SAML and reporting/monitoring and admin.
Along the way, I read the sample chapter from Java Development with Ant, on calling web services from Ant. Impressive. Knocked me socks off so it did! You can use a build.xml to call a remote service to get it’s WSDL, download it and feed it into Axis tools to generate Java stubbs to call the service. You then just tie it together with a few lines of code and you’ve got an instant web service client.
I’ve listed some interesting resources at the end of this entry.
The next step is to integrate the Internet2 openSAML implementation into Siva to make it Guanxi.
Some interesting resources:
shibb 1.3 is on the way: Shibboleth 1.3 draft
The point of Guanxi, from a Siva perspective is to shibbolethise Siva. What does that mean? At the moment, Siva is a toolkit that can be downloaded and plugged in to an institution’s development infrastructure. It’s a jar that provides all the functionality that’s needed, among other things, to manage and query various directories, such as Novell NDS. It can only be used by a compiled app using the jar directly.
What if the attribute part of Siva were SAMLised and made into a web service? Using the Internet2 implementation of the SAML protocol, extending if necessary and using that to accept shibb-type attribute requests, the point being to aggregate attributes from various stores within an institution and resolve namespace conflicts.
Public keys are the key. Automatic registration of an institution’s key on the Siva side would allow that institution to then sign attribute requests and send SAML messages direct to another institution’s Siva.
It could be extended to allow inter-institutional account maintenance, if that’s pratical or indeed needed. Haven’t really thought out the use cases yet so I can’t dismiss it out of hand.
Where would a lightweight profile fit within shibboleth? Here’s a use case:
- joebloggs@uhi logs in to a remote Bodington instance at Leeds. There’s a potential clash of users here as there’s already a joebloggs enrolled at Leeds and with an account on the Leeds Bodington instance
- joebloggs@uhi must append his domain to the his local username : Login = firstname.lastname@example.org
- Leeds Bodington, which has the Siva authenticator module installed, detects the presence of the domain on the username
- The Leeds Siva authenticator then negotiates attributes via SAML from the UHI lightweight “origin” web service
- Attribute requests are signed, so I would propose that each service at an institution that is Siva enabled should have it’s own public/private key pair. This would allow finer control of what services can request attributes and can allow an institution to prevent rogue systems from contacting remote Siva instances. Well, they could still contact but the remote Siva would refuse as the registered key would not match what was presented.
- Using SAML signed assertions, the two Sivas would communicate to provide Leeds with attributes about the UHI student
- These attributes could then be stored temporarily within the Bodington session as XML, ready to be passed to the authoriser which checks to see if the student has enough attribute defined privileges to continue
It’s shibboleth compliant in that a Siva SAML web service will accept signed attribute requests from either a remote Siva or a standard shibboleth system.
Siva can handle creating users and, if AD is set up correctly, their home directories. It all works nicely. However, AD states that you can’t set a user’s password at creation time, you have to go back in and modify it. Also, it’s not as easy as Novell, where you can just connect using plain text and set the password. Well, you can set the password at creation time on Novell eDirectory, so you don’t have to worry about going back in to change it.
In AD, you have to connect over SSL, using a root certificate issued by the server and the password must be quoted and Base64 encoded into the bargain. That’s some amount of security considering it’s Microsoft!
Normally this wouldn’t be a problem but we’re talking about Microsoft here and there’s a bug that stops this dead in it’s tracks:
JNDI fails to work for AD
The same code that works on Novell, to connect and bind, fails on AD. Sheesh, what does a man have to do get open source to talk to Microsoft products?
You can see what’s happening in the dump:
Thread-2, WRITE: SSLv2 client hello message, length = 98
Thread-2, received EOFException: error
Thread-2, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
Thread-2, SEND TLSv1 ALERT: fatal, description = handshake_failure
Thread-2, WRITE: TLSv1 Alert, length = 2
Thread-2, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
Thread-1, called close()
Thread-1, called closeInternal(true)
AD gets a hello message during a handshake and it blows up.
I don’t hold out much hope for the fix that Microsoft recommond on the AD side as one of the admins has tried it apparently and it’s still not working.
Most of the LDAP and Novell funtionality of SivaUtils is controlled by XML. I’ve now created schema documents for all the XML documents that LDAP and Novell accept. You can see them here
Had to upgrade to Xerces 2.6.2 to get the JAXP 1.2 validation features.
After much gnashing of teeth and pulling of hair, finally got the origin running under Apache 2 and Tomcat 5 on MAC OS X. One of the prerequisites is to build opensaml. It’s very easy, just use Ant on the build.xml it comes with.
Pity the same can’t be said for the origin. I had to comment out all the test targets from build.xml as the file is full of syntax errors. Perhaps an Ant version problem, not sure at the moment.
Anyway, that gives you shibboleth.war in the /dist directory. Now, this gave me mucho trouble:
they must go in TOMAT_HOME/common/endorsed.
I thought I’d done that as I found them there but they were actually older versions! Jeez, what a mess that caused. All sorts of class loader problems centred around org.opensaml.XML.parserPool.registerSchema. It necessitated a trip into class loader land and how tomcats sets up parent/child loaders.
Anyway, I’m now trying to figure out what a defaultRelyingParty is as it’s now barfing on that configuration element in origin.xml – but at least it’s a configuration problem now and not some horrendous build/deply mess