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.  Extra decryption needed within Assertion

    Posted Mon May 03, 2021 09:39 AM
    Hello,

    Regarding a new SAML connection we are receiving an assertion where part of it is, is extra encrypted. However it is unclear how we can let ISAM handle this extra step of decryption. Can be clarified how this can be handled?

    Below is an example of the extra encrypted information:

    <saml2:EncryptedID>
    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    Id="_e5f3842a84e2765a2035b5d86da91333"
    Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:RetrievalMethod Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"
    URI="#_27918fabe23432b0fc61e7b8c7b0b222"/>
    </ds:KeyInfo>
    <xenc:CipherData>
    <xenc:CipherValue>**********************************************</xenc:CipherValue>
    </xenc:CipherData>
    </xenc:EncryptedData>
    <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    Id="_27918fabe23432b0fc61e7b8c7b0b222"
    Recipient="urn:***************************">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
    <ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    </xenc:EncryptionMethod>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:KeyName>***************************</ds:KeyName>
    </ds:KeyInfo>
    <xenc:CipherData>
    <xenc:CipherValue>**********************************************************************</xenc:CipherValue>
    </xenc:CipherData>
    <xenc:ReferenceList>
    <xenc:DataReference URI="#_e5f3842a84e2765a2035b5d86da91333"/>
    </xenc:ReferenceList>
    </xenc:EncryptedKey>
    </saml2:EncryptedID>

    ------------------------------
    Henk Molema
    ------------------------------


  • 2.  RE: Extra decryption needed within Assertion

    Posted Tue May 04, 2021 07:32 AM
    Hi Henk,

    I haven't set this up for a while but answering based on my understanding of how this works.

    Verify Access supports decryption of encrypted data in received SAML assertions as long as it is encrypted with a supported algorithm and the XMLENC format is used.
    Looking at the example you have pasted, it looks like XMLENC was used.  I can see AES-256 and RSA-OEAP mentioned.  Pretty sure we support both of those.

    In order for the decryption to work, the Identity Provider must be encrypting the data with a public key for which Verify Access holds the private key.

    The private key that Verify Access will use for decryption is selected during federation configuration under "Encryption Options" (a bit confusing given it is for decryption).  The associated public key will be included in generated metadata.

    [There is also a key specified under "Encryption Options" for a federation partner.  This is the public key that will be used to encrypt data for that partner.  This isn't related to decryption of incoming data.  It is usually imported from received metadata].

    No specific configuration is required to enable decryption - it should be done automatically when encrypted data is received.

    Are you receiving an error when receiving this encrypted data?  If so, please have a look in the federation runtime message.log to see what the exception says is the reason for the failure.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 3.  RE: Extra decryption needed within Assertion

    Posted Mon May 10, 2021 01:33 AM

    Hi Jon,

    It looks to me that your explanation is abought the incoming encrypted SOAP message.

    In this case we have no problem with the fully encrypted SOAP message but with a  extra encryption on 1 attribute in the SOAP response/ Artifact response that we need to decrypt.



    ------------------------------
    jasper teuben
    ------------------------------



  • 4.  RE: Extra decryption needed within Assertion

    Posted Mon May 10, 2021 04:31 AM
    Hi Jasper,

    I'm a bit confused about the relationship between SOAP and SAML here.  When you refer to the SOAP message, do you mean the SAML 2.0 response/SAML 2.0 assertion within response?  In any case, I think you're saying that you have an encrypted SAML 2.0 response/token but within that you have another encryption block for a single attribute?

    I don't know for sure but I wouldn't be surprised if we don't support nested encryption of this kind.  Do you receive an error or is the attribute value simply being set to the entire encrypted XML element?

    If you're getting back the encrypted XML element, then either we don't support the nested encryption and/or we don't support the way it is being presented.

    Perhaps someone else on the forum knows the answer to this - otherwise you might need to open a support ticket to get confirmation on this.  Sorry I don't have the answers right here.

    If it turns out that nested encryption is not supported, you might be able to perform the decryption yourself within the SP Mapping rule.  I seem to remember we have added some crypto helper classes in the most recent releases.  Again, perhaps someone else can comment on that?

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 5.  RE: Extra decryption needed within Assertion

    Posted Tue May 11, 2021 02:50 AM
    Hi Jon,

    I for my part would be very surprised if ISAM doesn't support it as it is supported on the IdP side:

    Specify which pieces of messages to this partner should be encrypted:
    - Name Identifiers
    - Assertions
    - Assertion Attributes

    ------------------------------
    Laurent LA Asselborn
    ------------------------------