With the expected influx of new applications to build our emerging Web2.0 structure, more and more demans will be placed on the existing structural provisioning framework. We’re planning trials of Elgg and Sakai, linked via Shibbleth but the current Just In Time Provisioning (JITP) model doesn’t fit with how tutors use these types of applications. So I’ve published my vision of the next generation provisioning framework for UHI. It utilises SOA, JBI and BPEL among other things.

You can read the document on our Confluence.

I see Siva2 as being composed of 3 parts:

• Backend engine that handles all the account processing and data source integration. Conversion of native schema to IMS etc.
• Frontend Status and Reporting engine that lets users see what the backend’s been up to. Querying account status etc. Reporting problems
• Frontend Control engine. Full web control over the backend engine. Start/Stop/Reload etc.

I can see the Control engine being somehow tied in with Guanxi as only certain users will be allowed to control it. In fact, you don’t want any of the frontend engines to be visible outside UHI, so Guanxi will probably control access to all of them. Of course, the access policies will determine your level of access to each function in each engine.

The Grungwise stuff will have to sit on a Windows machine until Novell come out with the new Java enabled Postoffices but it will be behind a web service, so it can be controlled from the Unix engines. Might even bung Guanxi onto it to control access to the services it offers for Grungewise accounts.

Siva2 is now a Struts application, which saves a lot of time working out the flow, as Struts is superb for keeping you within the MVC framework.

For persistence, Hibernate will probably be bolted on to the backend to save state.

Also, web services for status/control stuff, although this is probably not a priority as the whole shebang is on the web, accessible via any browser but protected by Guanxi.

Siva2 is progressing. I’ve implemented a Struts front end, where a Bootstrap PlugIn initialises things and stores a controller for JSPs to use. Got some funny behaviour from the PlugIn though, which a quick trip into log4j land shed some light on.

Consider the following PlugIn from struts-config.xml:

<plug-in className=”org.Siva.Core.Bootstrap”>
  <set-property property=”logFile” value=”/WWW/siva/WEB-INF/logs/bootstrap.log” />
  <set-property property=”configFile” value=”/WEB-INF/config/siva.xml” />
</plug-in>

Now, there are two bean type methods to be called on the Bootstrap class by struts:

setLogFile(String)
setConfigFile(String)

now, I know I should just set the logfile in the config file but I’m doing this to illustrate the order of calling the PlugIn methods.

It seems that struts will call the methods in the Bootstrap.class in the following order:

• setConfigFile
• setLogFile
• init

i.e. in the reverse order in which they appear in struts-config.xml and where init() of course is the standard PlugIn::init()

So, if you plan on logging from the bean setter methods, you’ll have to do some jiggery pokery ordering in struts-config.xml but that’s a bad idea. Best to let the setters do their work and do all config/initialisation in init

Seems that the userPassword attribute in Novell NDS is case sensitive. Adding, for example, “firstname”, NDS transforms this to “firstName” when the account is created but setting the password with “userpassword” fails with the error:

NDS error: no such entry (-601)

Although the account does get created, it’s not authenticable as you just get the error:

16 : No such attribute

as userPassword hasn’t been set correctly. Seems that NDS doesn’t transform “userpassword” to “userPassword”

I’ve been playing around with LDAP authentication inside the Bodington VLE, which we use as CLAN. Sometimes it can seem to take ages to let you in. So, I made 3 enhancements to the code, one which was staring me in the face all the time and the other two a bit less obvious to the un-coffeed and pizza-less

• I’ve been storing the DN of the user in Bodington as an AliasEntry, so when they log in for the first time and Siva creates their account, it also effectively gives them another ID – their DN, e.g. cn=Test User,ou=Test Site,ou=Test Org. What the LDAP authenticator has been doing, is binding to the LDAP store as a privileged user, with enough rights to browse for the CN attribute and doing a lookup to find the user’s DN. Efficiency here was easy. If the user exists in the Bodington database, get their DN direct from their AliasEntry. Then, it’s a trade-off – Will the user and alias lookups withing Bodington be quicker than the LDAP lookup? More than likely
• The next efficiency gain was to replace an attribute compare operation with a straight bind operation. Attribute comparisons seem to be around 5-10 times slower than binding. This, of course, is of no help if you want to compare, say, names, or email addresses but I was using it to do a compare on the userPassword attribute. It’s much much faster just to bind using the user’s DN and let the exception catch a failed authentication, rather than constructing an LDAPAttribute object with the userPassword and comparing it with what’s on the server
• The final efficiency gain was a little less obvious. It seems that when you do an LDAP search, the server doesn’t return all the results at the same time. Rather, you have to cycle through the result object, until it reports that it’s done. It also involves a round trip to the LDAP server to get each result object in the chain. Again, this can’t be helped if you have multiple search results to take into account but when we’re searching for a user DN and nothing else, then we can be sure that if the search succeeded, the our DN will already be local, having come back from the server in the first result object. So, there’s no need to go looking for more. Even if there are multiple DNs returned, that means there is something wrong with the user info in the LDAP store as the same CN should never point to more than one DN

So, hopefully, these little changes will make a big difference, especially at times of high network load, when the traffic to the server can be kept to a minimum

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.

Welcome to the Siva weblog

Just started the Siva weblog.
Over the past month I’ve being converting the first iteration to a Java toolkit. The first version was exploratory, involving much running about and coding while my backside was in flames!
Took a load of research to find out what was supported in the way of remote programmatic account maintenance on Novell systems such as NDS and Groupwise.
Most CNA/CNE folk you speak to only know about the API gateway on groupwise and Console1 on NDS so it’s a hoot trying shoehorn LDAP and NDAP into the system, not to mention COM. A veritable soup of interesting technologies and in the case of COM, completely undocumented! Loads of strong coffee, a copy of dumpbin.exe and a Novell header file. Luvvly Jubbly!
Anyway, there’s now a sourceforge site, ready and waiting for the code and javadocs.
Almost finished the docs and I’m just turfing out some remnants of v1.0 which are going to be replaced by configurable XML/XSLT for the account definitions.
Next job is to think long and hard about the extension interfaces – how best to allow folk to contribute and add their own handler classes to interface with exotic systems we’ve never heard of.
The Guanxi project will make use of Siva to interface with Attribute Stores in the Shibboleth protocol and in fact, Guanxi will be adding shibboleth extensions to Siva.