DataPower

 View Only
  • 1.  dp:decrypt-data() not returning anything to the variable in xsl

    Posted Tue October 04, 2022 09:16 AM
    I am trying to decrypt password string using dp:decrypt-data() xsl function however it is not returing anything even though log says "Data decryption succeeded".

    If the issue is with shared screet key it usally throws Data decryption failed: *NULL decryption result* error.

    Below is xslt code for decrypt data:
    <xsl:variable name="DecryptionAlgorithm" select="'http://www.w3.org/2001/04/xmlenc#aes256-cbc'"/>
    <xsl:variable name="Decryptionkey" select="'name:EncryptDecryptKey'"/>
    <xsl:variable name="CipherData" select="$ldap_pwd"/>

    <xsl:variable name="decrypttext">
    <xsl:value-of select="dp:decrypt-data($DecryptionAlgorithm,$Decryptionkey,$CipherData)"/>
    </xsl:variable>

    After the decryption I am using $decrypttext varibale to pass it as bind password in dp:ldap-authen but $decrypttext is empty its failing at ldap authetication.

    Please help me.

    Thanks 
    Gopi




    ------------------------------
    Gopi Sirasapalli
    ------------------------------


  • 2.  RE: dp:decrypt-data() not returning anything to the variable in xsl

    Posted Wed October 05, 2022 03:14 AM
    Edited by Avinash Mohan Vundale Wed October 05, 2022 03:25 AM

    Hi Gopi,

    Firstly I would sugges you to check the key, token has some values in it and they are valid data in appropriate format mainly the string text is in the base64 format.

    key
    The xs:string that identifies the session key the algorithm uses to decrypt the text. Use one of the following prefixes to specify a shared secret key.
    • name:key, such as name:alice, that specifies an already configured shared secret key object named alice.
    • key:base64 specifies a base-64-encoded literal that is the shared secret key. If you enter base64 without the key: prefix, the function uses base64 as the key.
    • hex:hex specifies a hex-encoded literal that is the shared secret key.

    The session key was generated with the decrypt-key() extension function.

    text
    The xs:string that contains the base-64-encoded data to decrypt.


    Then you try to extract the value in normailse string may be then you might be able to get the values.

    <xsl:variable name="decrypttext">
    <xsl:value-of select="
    normalize-space(dp:decrypt-data($DecryptionAlgorithm,$Decryptionkey,$CipherData))"/>
    </xsl:variable>​



    Thanks 

    Avinash




    ------------------------------
    Avinash Mohan Vundale
    ------------------------------



  • 3.  RE: dp:decrypt-data() not returning anything to the variable in xsl

    Posted Fri October 07, 2022 11:20 AM
    Edited by Gopi Sirasapalli Fri October 07, 2022 12:35 PM
    Hi Avinash,

    Thanks for the response.

    I tried with normalize-space (), but no luck.
    The scenario we are trying to implement here is we get the user id and plaintext password from the LDAP team. Then, we encrypt the plaintext password using AES 256 encryption, and we use that encrypted password to call DataPower(SOAP call). We add the user id and encrypted password WS-Security header.

    In AAA policy, I use a custom xsl to decrypt the password and, in the same XSL making a call to LDAP using ladp-authen($ldap_filter,$decrypttext, $serverAddress, $sslProfileName,''), but its failing in LDAP with below error however in DataPower I see Data Decryption succeeded.

    Binding to LDAP server  as 'uid=user1, ou=People, dc=thirdparty, dc=tn, dc=com' failed: Unable to process the simple bind request because it contained a bind DN but no password, which is forbidden by the server configuration.

    Thanks
    Gopi

    ------------------------------
    Gopi Sirasapalli
    ------------------------------



  • 4.  RE: dp:decrypt-data() not returning anything to the variable in xsl

    IBM Champion
    Posted Fri October 07, 2022 11:57 AM
    So, with that explanation, it now sounds as though maybe something has gone wrong and the decrypted text is, indeed, blank.

    Do you have instrumentation in place to verify the received plaintext password, the one you received from the LDAP team, is not blank, or not somehow being blanked out prior to you encrypting it?



    ------------------------------
    Joseph Morgan
    ------------------------------