Sam's Work Blog » ldap http://blogs.cetis.org.uk/sam Just another Cetis Blogs site Mon, 15 Jul 2013 13:24:39 +0000 en-US hourly 1 http://wordpress.org/?v=4.1.22 Down and dirty with OpenID http://blogs.cetis.org.uk/sam/2008/08/08/down-and-dirty-with-openid/ http://blogs.cetis.org.uk/sam/2008/08/08/down-and-dirty-with-openid/#comments Fri, 08 Aug 2008 01:59:08 +0000 http://blogs.cetis.org.uk/sam/2008/08/08/down-and-dirty-with-openid/ I’ve spent the last few hours (after getting home from a swift pint in the pub admittedly) having one of those satisfying coding experiences where the dots just start joining up… I took the very nicely written OpenIDenabled PHP library and bolted it on to the authentication routines for PROD.

The technical principles behind OpenID are simple enough: the user tells your application their openid URL, the app asks the relevant provider if everything is ok, the provider comes back and tells the app a whole bunch of stuff saying that the user is kosher (or halal or whatever it says in their profile).

The latest version of the toolkit made this a breeze – coming as it does with working examples and very well documented code. Most of the work was putting in a few new hooks in my authentication script to catch both ends of the transaction, copying and pasting some code from the example scripts to create the consumer object and set it flying and finally catching the response at the end and telling my application that the user is now logged in.

As with most quick work there is still quite a bit tidying up to do – particularly around how I associate existing users in the LDAP directory with their OpenIDs… At the moment I’m just not bothering. Useful error messages would probably be a good idea too! Testing it with a few different providers is also a must.

One gotcha I discovered was that at some point the exact recipe for doing Delegation must have changed and that the library is more fussy about this than other implementations I’ve seen and used. When testing using my own domain’s delegation which I’ve had set up for years it was consistently failing. This is not good news as there are probably thousands of people who still have it set up exactly as I did…

Another (Ubuntu specific) issue was that it was failing to authenticate against yahoo’s service because I was missing some bits of openssl… This was fixed with a quick sudo apt-get install openssl ca-certificates

Now I’ve had a few brushes in recent months with OpenID mainly around the web provision for the XCRI project – where we got OpenID working across WordPress, Mediawiki, and (through some rather cheap hacking) BBpress. It was however reliant on plugins for said apps and never really a very satisfactory experience – generating a long string of complaints from users getting very variable results depending on which provider they were using. Upgrading any particular component of the site seemed to just lead to more chaos.

Sadly I think that these variable experiences do rather detract from the potential that OpenID has to help us all better manage our online identities. That and the insistence of so many “providers” like Yahoo! and WordPress.com that they are just that, providers and not consumers. I’ve already got about 6 OpenIDs on the go without really realising – useful for testing but the exact opposite of the single authentication service goal. Tsk tsk.

Anyway… Now that I’ve actually tackled the problem at a slightly deeper level I’m feeling confident that over time we can not only iron out XCRI’s woes but also introduce OpenID across the JISC CETIS (and IEC) services in a reasonably robust way. The future looks rosy, the sky is blue, thunderclouds? What thunderclouds?

]]>
http://blogs.cetis.org.uk/sam/2008/08/08/down-and-dirty-with-openid/feed/ 0
Mediawiki LDAP headaches part 6 http://blogs.cetis.org.uk/sam/2007/02/15/mediawiki-ldap-headaches-part-6/ http://blogs.cetis.org.uk/sam/2007/02/15/mediawiki-ldap-headaches-part-6/#comments Thu, 15 Feb 2007 17:11:28 +0000 http://blogs.cetis.org.uk/sam/2007/02/15/mediawiki-ldap-headaches-part-6/ Mediawiki has a useful LDAP Plugin. We have been using it on the CETIS wikis for some months now and it has been fine. The time came when we needed to promote various staff members to the rank of administrator so they can do things like import content and protect pages. In all honesty it wasn’t a hard thing to achieve: I created a new groupofnames entry called sysop in the LDAP directory and populated it with the names of our staff members. Adding the appropriate lines to the mediawiki configuration scripts after some trial and error resulted in the groups being syncronised and the appropriate people becoming appropriately powerful.

This is fine. BUT I’m not totally satisfied. What I really wanted to do was give all members of the staff ou (organisational unit) the sysop privilage – so I don’t have to start assigning more groups to people than they already have. There isn’t an easy way as far as I can see to make a group containing all children of an ou. Or at least if you can define the ou as a member of the group, no self-respecting implementation is going to realise quite what you’re getting at.

I’m left with the prospect of adding everyone to the group (which I’ll automate I suppose) – or hacking the plugin. Or I could re-structure the whole directory putting everyone in a single ou and using groups as the primary means of differentiating people. I don’t really want to do that.

Other ideas are (of course) welcome.

]]>
http://blogs.cetis.org.uk/sam/2007/02/15/mediawiki-ldap-headaches-part-6/feed/ 0