Splitting up a Driver to Increase Functionality: A Narrative

The Premier IDM Blog Add comments

Trying to determine the best layout for an identity and access management suite application driver can sometimes be tricky, and occasionally the standard model just doesn’t fit the requirements you need to meet. So when I recently got documentation for an application that a client needed a connector for, I was a taken aback by the requirements this IDM suite application seemed to layout. I was looking down at a business analysis done on ~45 database tables with not a stored procedure in sight. So of course I began laying out the SQL calls I would need to make to do some standard operations such as, creating a user, modifying that user, disabling, re-enabling, renaming etc. 

As I began encountering what seemed like redundant information, I learned that this application was one part of a identity management suite and that in the future the client wanted other applications from this identity and access management suite serviced. With this information, I began combing through the data and looking for mutual end points for the suite.  What I found were 7 SQL tables that were shared by the IDM suite that needed operations performed on them such as “INSERT” and “UPDATE” calls whenever an event, such as a new user being created, came across. Out of a collection of approximately 10-15 operations, I found this to be quite inefficient. 

Usually this client, and myself in practice, prefer to compartmentalize driver functionality in order to keep things more secure and organized. I found that in that in this case, an overarching driver targeting all functionality common to the suite would serve us well. This allowed for the actual application drivers to minimize the amount of work it had to do. It also allowed us to implement functionality for the other applications in the suite more rapidly, with only a stipulation of granting the applications entitlement only when the general service driver had completed its operations. 

Has anyone else used this method? For the same reason, or did your circumstances require it? 

I hope you have enjoyed reading this blog entry. Feel free to ask questions or leave comments below, I look forward to responding to them. To learn more about Action Identity, visit our website at http://www.actionidentity.com

Wondering what is IDM? Learn more here

Interested in learning more about Drivers? Check out these other entries:

http://www.actionidentity.com/blog/post.cfm/making-direct-soap-calls-within-the-novell-idm-soap-driver

http://www.actionidentity.com/blog/post.cfm/messaging-protocols-soap-vs-rest-which-one-s-better

http://www.actionidentity.com/blog/post.cfm/unique-delimited-text-driver-solved

http://www.actionidentity.com/blog/page.cfm/archives

 

0 responses to “Splitting up a Driver to Increase Functionality: A Narrative”

Leave a Reply

Leave this field empty:

Powered by Mango Blog. Design and Icons by N.Design Studio