soa provisioning project update soa project 2

Thu, Nov 6, 2008

After some thought and conversations it seems that LDAP triggers are no use as you can’t guarantee the triggered code will be run (it might be offline). Also, I investigated LDAP listeners in eDirectory but they only live for the life of the listener connection, so again they’re not much use for reliable messaging. So I’ve modified the original architecture a bit, to feed the broker directly from IDM and hive off the LDAP server into someone else’s space. There’s a bit of a debate about how it should be structured internally. Should CNs have long lists of memberships or should there be huge lists of group objects? Not a topic I have much interest in to be frank. Decisions like that should be based on how the container is going to be used. At the moment, the current eDirectory is used mainly for authentication and extracting attributes for a known CN. AFAIK there are no requests to find everyone on module MOD101. Those queries are the preserve of SITS. So here’s the new architecture:

SOA provisioning project

It’s basically a messaging system that is fed from Novell Identity Manager via its JMS driver. Doing it this way manages to avoid writing hefty cache implementations in all applications as IDM will handle reliable delivery of messages via the driver. Whether to use pub/sub or point to point messaging in Apache MQ is the next big question but I have a meeting next week to get access to a development instance of IDM so we can start wiring things up to see how they might work together.

The plan is to bring this up to speed and run it in parallel with the IDM trial to see if it’s a viable provisioning solution. The interesting thing that comes out of it however, is an attribute cloud. The big pipe marked “attributes” is basically a messaging route into the “cloud” of applications that hang off the queues. The Shibboleth Identity Provider (IdP) could send a message into the cloud asking for attributes for a defined user account. All connected applications within the cloud could pick this message up and respond accordingly. So rather than duplicate all that information in the LDAP server, each application is responsible for its own data set. The beauty of this is, when a user’s local profile changes in an application, e.g. Elgg, the IdP has instant access to that new profile should it require to be used in federated access management.

comments powered by Disqus