Tuesday, April 27, 2010

Novell IDM XSL to Global Find/Replace

I heavily use Novell IDM if you haven't noticed from my other blog articles.  Recently, I needed to use Novell IDM to do a global find/replace.  Typically, this can be done in policy very quickly by just replacing all instances of a character with another character (or series of characters).

I hit an issue where the characters that I was doing the replacement with were special characters in the context of the IDM, so they were not output correctly.  In order to get the replacement done correctly, I needed to do it in the Output Transformation policy so they didn't get fubar'd while passing the text around.

So, what I did was make an XSL Template to do a global find/replace, then call the function.  I was pretty proud of my code, its pretty elegant the way it was implemented.

    <xsl:template name="globalReplace">
        <xsl:param name="outputString"/>
        <xsl:param name="target"/>
        <xsl:param name="replacement"/>
        <xsl:choose>
            <xsl:when test="contains($outputString,$target)">
                <xsl:value-of select="concat(substring-before($outputString,$target),$replacement)"/>
                <xsl:call-template name="globalReplace">
                    <xsl:with-param name="outputString" select="substring-after($outputString,$target)"/>
                    <xsl:with-param name="target" select="$target"/>
                    <xsl:with-param name="replacement" select="$replacement"/>
                </xsl:call-template>
            </xsl:when>
            <xsl:otherwise>
                <xsl:value-of select="$outputString"/>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:template>

So, we pass this function our information.  If the target isn't present, it just throws back the string unmodified.  If the target is present, it takes the substring up to that string, tacks on the replacement, then recursively calls itself until all replacements are done.

Nice little piece of code for XSL to hold on to.

Cisco VPN Client for 64-bit Windows 7

So, I've stumbled upon a VPN client that I can use for a 64-bit windows OS.  Someone posted this and I thought I'd pass it along because it works!  Its called Shrew VPN, frmo a company called Shrew Soft Inc.  I downloaded it for free and am using it on 64-bit Windows 7 Ultimate and it seems to be working like a champ!

http://www.shrew.net/software

Enjoy!

3DES Encrypt data with Novell IDM

If you check the blog prior to this one, I developed a method to call a web service URL from within any driver for Novell IDM.  This is all good, but what happens if we need to pass sensitive data in this URL.  We can't just do a GET operation with a URL that has a password in clear text, that's just asking for trouble.

What we do to protect this data is to throw some 3DES encryption on it before we throw the args on the end.  With the 3DES encryption, we also need a function to URLEncode the contents so the URL is written in a language the browser can send across.  Once again, I used some ECMAScript and code to get this done.

Please note, you will need to generate your own encryption key, then also use this key and similar code on the remote side to decrypt the contents to read it.

Here is the code.  The first portion is two functions.  The first function encrypts the data string passed to it, then passes it to the second function which will URLEncode it.

importPackage(Packages.javax.crypto);
importPackage(Packages.javax.crypto.spec);
importPackage(Packages.java.security.spec);
importPackage(Packages.java.io);
importPackage(Packages.sun.misc);
importClass(java.net.URLEncoder);

function DESEncrypt(theString) {
    try {
            var secretKey   = new SecretKeySpec(new Packages.sun.misc.BASE64Decoder().decodeBuffer(new java.lang.String("thisiswhereyouputyourkey")), "DESede");
            var ecipher = new Cipher.getInstance("DESede");
            ecipher.init(Cipher.ENCRYPT_MODE, secretKey);
            var utf8 = new java.lang.String(theString).getBytes("UTF8");
            var enc = ecipher.doFinal(utf8);
            return EncodeURLString(new Packages.sun.misc.BASE64Encoder().encode(enc));
        } catch (e) {
            return e.toString();
        }
       
        return null;
}

function EncodeURLString(theContents) {
    try {
        return new URLEncoder.encode(theContents, "UTF8");
    } catch (e) {
        return e.toString();
    }
    return null;
}

Once this ECMAScript is saved, pushed up, then called into your IDM, you can call it like this:

            <do-set-local-variable name="lv.EncryptedArgs" scope="policy">
                <arg-string>
                    <token-xpath expression="es:DESEncrypt($myArgs)"/>
                </arg-string>
            </do-set-local-variable>

Now, you have your encrypted arguments stored in a local variable, all nice and URL encoded.  Just tack it on the end of a URL and call it with the code defined in the previous blog article and you have now sent encrypted data across the wire.

Web Services with Novell IDM

So I have a pretty unique request.  A customer asked me to integrate IDM with a system that doesn't have a standard interface that I could use to integrate.  It did, however, have an API that we could use to create our own interface.  The customers programmer decided that the easiest way to implement this would be to setup a web service for me to call. 

While initially, I thought this was a candidate for the SOAP driver, I realized that this driver is overkill for the simplicity of this implementation.  This is a sample of how we would be creating a user in the system from IDM:

http://www.server.com/addUser?username=testuser&fname=test&lname=user&password=Passw0rd&othreattribute=other1&....

SOAP is complete overkill, I just need to construct a simlpe URL and call a linux wget on that URL.  The resulting status message would be returned instead of a typical HTML page when the API code processed the request.

I did some research and decided the easiest way to implement this would be to use ECMAScript to call some custom code that would very easily call my URL and return the result for me.  I would shove the result into a local variable in policy then jam that sucker into an attribute on the user object in eDirectory.  Seems like a very simple implementation, here is how I was able to do it.

Below is the ECMAScript for the function that I wrote.  Its a simple function, urlGet. You pass it the URL and it returns whatever is returned when a GET operation is performed on that URL.

importClass(java.net.URL);
importClass(java.io.InputStreamReader);
importClass(java.lang.StringBuilder);

function urlGet(urlString) {
try {
var url = new java.net.URL(String(urlString));
var stream = url.openStream();
var reader = new java.io.InputStreamReader(stream, "UTF-8");
var sb = new java.lang.StringBuilder();
var c;
while ((c = reader.read()) != -1) {
sb.append(String.fromCharCode(c));
}
return sb.toString();
} catch(e) {
return e.toString();
}
}

Now, we post that ECMAScript and use it in our driver with the following.  It will use the URL that is stored in the Local Variable myURL and return the results back to lv.URLResult.

            <do-set-local-variable name="lv.URLResult" scope="policy">
                <arg-string>
                    <token-xpath expression="es:urlGet($myURL)"/>
                </arg-string>
            </do-set-local-variable>

Program some logic to store the result in some sort of status attribute, then business logic to construct the correct URL and your can very easily IDM enable a web service based system.