IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
  • 1.  Strange behavior with string length in Mapping Rules

    Posted 09/24/20 09:33 AM
    Yesterday, I was dealing with a situation where a number in one system drops the leading zero, while the other system keeps it. This agent number could be 5 or 6 digits, depending on leading zero or not. The project required me to ensure the number was always 6 digits before setting this as the Principal. In the javascript, I tried using string.length, but it wasn't working. After trying several different ways and troubleshooting, I was able to convert the string to an array and use the .length property the way I needed. Has anyone else encountered this issue? Is this a bug in the interpreter, or is this by design for some strange reason?

    Snippet of how it's done at the moment=========================

    // re-write Principal name with type as email nameid format
    // If user is agent, use 'agentnumber', else use 'uid'
    var principalName = stsuu.getAttributeValueByName("agentnumber");

    // If agentnumber is not null, check for length, pad to 6 and set as principalName
    if (principalName){
    // Agent number is not null, user is agent - pad value and set agentnumber
    var arr = principalName.split("");
    if (arr.length < 6){
       principalName = "0".concat(principalName);
    }
    } else {
       principalName = stsuu.getAttributeValueByName("uid");
    }

    stsuu.getPrincipalAttributeContainer().clear();
    stsuu.addPrincipalAttribute(new Attribute("name", "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", principalName));
    =========================================================

    Originally, I tried to use principalName.length, but that if statement was never true, and skipped. I then built a concatenated string to spit out all the values as the principalName to see what was being returned. I was shocked at the result.

    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">14617_function length() {/*
    int length()
    */}
    _14617</saml:NameID>

    This was intended to be the principalName.length_principalName as the return value. It should have been 5_14617 when principalName.length was used. Instead, I ended up splitting the string in to a character array and using the length property on that (works). Still, it shouldn't have been that difficult. Any ideas?

    FYI, this is ISAM 9.0.7.0 running as a virtual appliance on VMWare.


    ------------------------------
    David Gianetti
    ------------------------------


  • 2.  RE: Strange behavior with string length in Mapping Rules

    Posted 09/25/20 03:55 AM
    Hi David,

    I believe you problem relies with the fact that the principalName in your code is not a JavaSript String variable, instead it is a Java String variable.
    You need to remember that ISAM runtime works on Rhino engine, which interfaces with both Java and Javasript; and that all objects and built-in functionalities provided with ISAM are actually pure Java objects and interfaces, therefore their output will also be a Java object. 

    This mixture can often be confusing and cause unexpected behaviors, because sometimes the implicit casting will work fine, and sometimes will not.

    In your case principalName is a Java String object, and since in Java the length is a method (invoked with "string".length()), by doing "string".length you are just accessing a reference to the length method.

    Easy fix for your code is just to cast principalName to Javascript string var principalName = String(stsuu.getAttributeValueByName("agentnumber"));
    With that added, you initial code should be working fine. Otherwise, if you prefer keep using the Java String, then the same result would be to call pricipalName.length().

    Best,
    Dean


    ------------------------------
    Dean Ivosevic
    ------------------------------



  • 3.  RE: Strange behavior with string length in Mapping Rules

    Posted 09/25/20 08:56 AM
    Wonderful! You have no idea how much confusion you just cleared up. My colleague and I had often encountered issues where the Mapping Rules would sometimes behave like Java and (most) other times behaved like Javascript. That makes perfect sense. 

    So, when dealing with the built in objects, we should treat them as Java, and our own code would be treated as Javascript? That's great to know!

    Thanks for your speedy reply!

    ------------------------------
    David Gianetti
    ------------------------------