In my enterprise, we use CryptoCard as one of our two-factor authentication providers, which has always been a hands off system for ILM integration. I believe it was always because the underpinnings of the CryptoAdmin system were never quite understood, and there were other ways to manage the token definitions, that it was never thought it be a target system for ILM integration.
After a quick discussion this week, I decided to investigate what it would actually take to connect ILM to view and possibly manage the tokens in the CryptoAdmin server. It turns out, my instance is running on MySQL 4.x, which out of the box ILM does not provide a MA for connectivity.
I figured now would be a good time to investigate the possible usage of an Extensible MA (XMA), as I have always meant to dig deeper into how they function, and what is needed to implement them, but never had the task at hand to need to implement it. It was a real “Aha!” moment seeing how simple it really was, after all this time of being hands off.
It turns out, that The(now ILMexperts?!) have posted for use with MySQL which sounded like it would fit the bill, and offer me insight on how a working XMA has been coded.
I have to say, after downloading the MySQL .NET connector, and compiling the MySQL XMA code, it was pretty straight forward in implementing it on ILM to connect to the back end MySQL CryptoAdmin database. Be sure to set your import template as an AVP source, because that is what the XMA will output the file as, and I was not able to change this without deleting and recreating the MA.
The only issue I had was the XMA defaulted to text encoding codepage other than UNICODE, which gave me the the stopped-file-embedded-null error. Setting the file codepage to Unicode resolved my issue immediately, and Full Imports had succeeded.
So far, I am impressed with the ability to develop an XMA for the target system, even when Microsoft does not provide one out of the box. For me, giving the ability to resolve my problem, and extend the platform to meet my business needs really adds allot of value to this implementation. I don’t know why I had not focused on the XMA before, but I already can think of many other situations where the XMA can be implemented to provide integration.
Next steps will be working on export logic for managing CryptoCard entries, but I think the big hurdles of not knowing how to implement the XMA are over, and it’s just like any MA with coding the management logic.
Thanks to Alex Tcherniakhovski for his posting on a Walkthrough: How to build an extensible management agent for MIIS for implementing the XMA which was really helpful in visualizing the process.