X

Tips and HowTos for Single Sign-On & Federation Oracle Identity Management Integrations

  • September 5, 2014

Crypto Settings in OIF

In this article, I will cover the various crypto configuration properties in OIF that are used to affect the Federation SSO exchanges, including:

  • Hashing algorithm used for signatures
    • SHA-1
    • SHA-256
  • Which outgoing SAML messages will be signed
  • Which incoming SAML messages will require to be signed
  • Whether or not to include the X.509 signing certificate in the outgoing signed XML message
  • Whether or not to encrypt SAML 2.0 messages:
    • Assertion
    • NameID
    • Attribute

Enjoy the reading!

Hashing Algorithms


OIF supports the consumption and issuance of SAML messages signed with

  • Either the SHA-1 hashing algorithm
  • Or the SHA-256 hashing algorithm

By default, OIF uses SHA-1 when signing outgoing messages.

Messages are signed differently, based on the binding being used:

  • XML Digital signatures when HTTP-POST or Artifact bindings are used
  • Query signatures when the HTTP-Redirect binding is used

SHA-1

An example of a signed AuthnRequest message sent via the HTTP-Redirect binding would be:

https://acme.com/idp/saml20?SAMLRequest=hVPLbtswEPwVgT1LpB6tY8JyoNZ1q9ZujVgJ3N4Yio5ZSKTMpaz470v5ESQB4gA8LWZ2ZnaXo%2BvHuvJ2woDUKkVhQJAnFNelVA8pui2m%2FhXywDJVskorkaK9AHQ9HgGrq4Zmrd2oG7FtBVjPNVJAS5COuLG2oRh3XRd0caDNA44IIZgMsUP1kA%2FohHdib8BDTJIe7hBP6F42Ra1RVDOQQBWrBVDL6TKbz2gUEMoAhLEuzHNKc5nTGG0119WZ8viRkHcZa1m5IrPWyPvWCrpypKcGIN8MtZrPlnwjauZL1Q%2BWC%2BQtTgY%2BS3Uc%2FCXt%2ByMI6PeiWPiL38sCefkkRbL0V7ff2m0mok1e%2BoP4x66bbdlPGFgYtpP5n09f%2Fbn%2Fb9CqKfLuzhuP%2Bo3nAK3ID3asK5Ew8Yl7cREmNLmiJP6LvInbsVTMHlinbKzkhDRiG7TgAjJeiYDrmg6S4RCvRYll2eB%2B%2FruIoOPN0IOU8aba1MxeDtpXXKj1AeoOxUq7R%2BMX0py%2Fko5iQiKsWd3rj%2FAzyfPN%2FnJd88lCV5Lv37URBuFrGzWTVVaWRgAgL6sq3X0xgln3NaxpBcLjo%2BrLzzH%2BDw%3D%3D&RelayState=id-AkgTE5PMRAZTaKRcZHT-2rIse-oPhCxyI00Xycbf&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=rjZFsFuaFKv77JbspdDwT2wGV366iL3zvWc%2B1aybu%2FW%2BpFwLOfTJBtVsKfwJre1nGCU5SEvFD%2FBBURkxOG1KhR3k%2FrOw%2Bj7g7RlHfSaHKaAO3p6aAGQYPCpz%2Fd0%2BKArDAL%2FDNoH46G6Pnf7VWSb6a2COUiTV6118KaPbexrnJtE%3D

An example of a SAML 2.0 Assertion sent via the HTTP-POST binding would be:

<samlp:Response ...<samlp:Response ...>
  <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">...</saml:Issuer>
  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
  <saml:Assertion ID="id-BgLUimKUWYyS3JQbf2geeP9EwS-eGKxOPTuPvxgJ" ...>
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">...</saml:Issuer>
    <dsig:Signature>
      <dsig:SignedInfo>
        <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <dsig:Reference URI="#id-BgLUimKUWYyS3JQbf2geeP9EwS-eGKxOPTuPvxgJ">
          <dsig:Transforms>
            <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
            <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          </dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
          <dsig:DigestValue>uS85cIFf4z9KcHH/z60fNRPLoyo=</dsig:DigestValue>
        </dsig:Reference>
      </dsig:SignedInfo>
      <dsig:SignatureValue>NiTyPtOEjyG...SpVjbhKxY=</dsig:SignatureValue>
    </dsig:Signature>
    <saml:Subject>
      ...
    </saml:Subject>
    <saml:Conditions ...>
      ...
    </saml:Conditions>
    <saml:AuthnStatement ...>
      ...
    </saml:AuthnStatement>
  </saml:Assertion>
</samlp:Response>

SHA-256

An example of a signed AuthnRequest message sent via the HTTP-Redirect binding would be:

https://acme.com/idp/saml20?SAMLRequest=hVNdb9owFP0rkfec%2BCbAVixClY2hIdGWDui6vhnbFEuOndoOKfv1c%2Fio2kqlkp%2BuzrnnnHuvB5fPpYq2wjppdI7SBFAkNDNc6sccLRfj%2BAJFzlPNqTJa5GgnHLocDhwtVUWK2m%2F0b%2FFUC%2Bej0Eg7wp0MxI33FcG4aZqk6STGPuIMADD0cUC1kC%2FoiA9iH8BTDN0WHhAv6FY2R7XVxFAnHdG0FI54RubF1ZRkCRDqnLA%2BhHlNqc5zKmu8YUadKM89gE8Za6lCkXpv5ar2gtwH0ksDJz8MdX81nbONKGksdTtYJlA0Oxr4LvVh8Oe0VweQI78Wi1k8u5kvUDQZ5Ujy%2BC80RSY7d9BQc7tKR5kxD0td9LYXN9M%2FFR%2F%2FFLDswb9bFN2dNp61G584V4vJ3o4PJUi7MYTXWaRd0vtKoP%2BAolHYsdTU71nHbJQzgEo8JbULASlTImGmJN%2B6%2FT5eC44lr3A7%2F20G6HAzZC9lo7GxJfXng7aVEGq9h4ZD8dLv0PCNNGPvpLMOQIYNLVv9AX4lebrZ69B1MpoZJdnuUxtpkr63UVKpCs6tcA5FhVKm%2BWEF9eFreFsLhIcH1befY%2Fgf&RelayState=id-BiQreMi9cMY3oFI9PKMNKtuOjpuFS2PrW4R8KKvd&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=PvyMUD%2FKXnCc0drlN1pvoK171znJkajEHLgtzE4I7YFQIvP4wp3M%2FV7y08x0Qkv0jwo9K4VBG%2BQUBFtXr41ZDp%2BHOb7GlmaY973n7X2UDlbUbVlrJX%2FqS1GyyNY6MSMcO5K0J7VJcQXf8CvGEcVHr%2FZhPjihnAO2vi%2Bej3fbfgo%3D

An example of a SAML 2.0 Assertion sent via the HTTP-POST binding would be:

<samlp:Response ...<samlp:Response ...>
  <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">...</saml:Issuer>
  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
  <saml:Assertion ID="id-5B4KZ-PeUzikxtC-Cr9g6uFQ-muwj3ZmC4PUW4wT" ...>
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">...</saml:Issuer>
    <dsig:Signature>
      <dsig:SignedInfo>
        <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
        <dsig:Reference URI="#id-5B4KZ-PeUzikxtC-Cr9g6uFQ-muwj3ZmC4PUW4wT">
          <dsig:Transforms>
            <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
            <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          </dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
          <dsig:DigestValue>Ppx/...L9ooHtsvgxvI=</dsig:DigestValue>
        </dsig:Reference>
      </dsig:SignedInfo>
      <dsig:SignatureValue>G6yppQXy...SzHz2oa+zA=</dsig:SignatureValue>
    </dsig:Signature>
    <saml:Subject>
      ...
    </saml:Subject>
    <saml:Conditions ...>
      ...
    </saml:Conditions>
    <saml:AuthnStatement ...>
      ...
    </saml:AuthnStatement>
  </saml:Assertion>
</samlp:Response>

WLST Command

OIF can be configured to use SHA-1 or SHA-256 in SAML signatures:

  • At a Partner level
  • At a Partner Profile level, where all partners referencing this profile will be affected, unless they were configured at a partner level for SHA-1/SHA-256 signatures

The OIF WLST configureFedDigitalSignature() command is used to configure how OIF should compute a signature:

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Navigate to the Domain Runtime branch:
    domainRuntime()
  • Execute the configureFedDigitalSignature() command:
    configureFedDigitalSignature(partner="", partnerProfile="", partnerType="", default="false", algorithm="SHA-256", displayOnly="false", delete="false")
    • The following parameters can be set:
      • partner would be used to configure a specific partner
      • partnerProfile would be used to configure a specific partner profile
      • partnerType would indicate the type of partner/partner profile (idp or sp)
      • algorithm indicates which hashing algorithm to use (SHA-1 or SHA-256)
      • displayOnly indicates whether or not the command should display the setting on this partner/partner profile instead of setting it. If set to true, this command will not modify the configuration (true or false)
      • delete indicates whether or not the command should delete the setting on this partner/partner profile instead of setting it. If set to true, this command will delete the configuration and the parent configuration (partner profile or global) will be used (true or false)
    • An example would be:
      configureFedDigitalSignature(partner="AcmeIdP", partnerType="idp", algorithm="SHA-256")
  • Exit the WLST environment:
    exit()

Signing Outgoing Messages


OOTB Configuration

Below are the OOTB boolean settings that indicate when OIF needs to sign outgoing SAML messages (if true, OIF will sign the outgoing messages):

  • Global level
    • saml20sendsignedauthnrequest: SAML 2.0 AuthnRequest (true)
  • SAML 1.1 IdP Partner Profile
    • sendsignedrequestsoap: SAML 1.1 Request via the Artifact/SOAP binding (true)
  • SAML 1.1 SP Partner Profile
    • sendsignedassertion: SAML 1.1 Assertion (true)
    • sendsignedresponseassertionpost: SAML 1.1 Response containing an Assertion over the HTTP-POST binding (false)
    • sendsignedresponseassertionsoap: SAML 1.1 Response containing an Assertion over the Artifact/SOAP binding (false)
    • sendsignedresponsesoap: SAML 1.1 Response not containing an Assertion over the Artifact/SOAP binding  (true)
  • SAML 2.0 IdP Partner Profile
    • sendsignedrequestpost: SAML 2.0 Request over the HTTP-POST binding (true)
    • sendsignedrequestquery: SAML 2.0 Request over the HTTP-Redirect binding (true)
    • sendsignedrequestsoap: SAML 2.0 Request over the Artifact/SOAP binding (true)
    • sendsignedresponsepost: SAML 2.0 Response not containing an Assertion over the HTTP-POST binding (true)
    • sendsignedresponsequery: SAML 2.0 Response not containing an Assertion over the HTTP-Redirect binding (true)
    • sendsignedresponsesoap: SAML 2.0 Response not containing an Assertion over the Artifact/SOAP binding (true)
  • SAML 2.0 SP Partner Profile
    • sendsignedassertion: SAML 2.0 Assertion (true)
    • sendsignedrequestpost: SAML 2.0 Request over the HTTP-POST binding (true)
    • sendsignedrequestquery: SAML 2.0 Request over the HTTP-Redirect binding (true)
    • sendsignedrequestsoap: SAML 2.0 Request over the Artifact/SOAP binding (true)
    • sendsignedresponseassertionpost: SAML 2.0 Response containing an Assertion over the HTTP-POST binding (false)
    • sendsignedresponseassertionsoap: SAML 2.0 Response containing an Assertion over the Artifact/SOAP binding (false)
    • sendsignedresponsepost: SAML 2.0 Response not containing an Assertion over the HTTP-POST binding (true)
    • sendsignedresponsequery: SAML 2.0 Response not containing an Assertion over the HTTP-Redirect binding (true)
    • sendsignedresponsesoap: SAML 2.0 Response not containing an Assertion over the Artifact/SOAP binding (true)

Configuration

I will assume that you are already in the WLST environment and connected using:

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Navigate to the Domain Runtime branch:
    domainRuntime()

SAML 2.0 AuthnRequest

To configure OIF to sign an outgoing SAML 2.0 AuthnRequest, execute one of the following commands:    

  • To configure at a global level, execute:
    putBooleanProperty("/spglobal/saml20sendsignedauthnrequest", "true/false")
    • Set the value to true to have OIF sign the outgoing AuthnRequest
    • An example would be
      putBooleanProperty("/spglobal/saml20sendsignedauthnrequest", "true")
  • To configure at a SAML 2.0 IdP Partner Profile level, execute:
    putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/sendsignedauthnrequest", "true/false")
    • Replace PARTNER_PROFILE by a SAML 2.0 IdP Partner Profile name
    • Set the value to true to have OIF sign the outgoing AuthnRequest
    • An example would be
      putBooleanProperty("/fedpartnerprofiles/saml20-idp-partner-profile/sendsignedauthnrequest", "true")
  • To configure at a SAML 2.0 IdP Partner level, execute:
    updatePartnerProperty("PARTNER", "idp", "sendsignedauthnrequest", "true/false", "boolean")
    • Replace PARTNER by a SAML 2.0 IdP Partner name
    • Set the value to true to have OIF sign the outgoing AuthnRequest
    • An example would be
      updatePartnerProperty("AcmeIdP", "idp", "sendsignedauthnrequest", "false", "boolean")

Other Settings

To configure the properties defined at the SP/IdP Partner Profiles above, execute one of the following commands:

  • To configure at a Partner Profile level, execute:
    putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/PROPERTY_NAME", "true/false")
    • Replace PARTNER_PROFILE by a Partner Profile name
    • Replace PROPERTY_NAME by the name of the property to set
    • Set the value to true or false
    • An example would be
      putBooleanProperty("/fedpartnerprofiles/saml20-idp-partner-profile/sendsignedrequestquery", "true")
  • To configure at a Partner level, execute:
    updatePartnerProperty("PARTNER", "PARTNER_TYPE", "PROPERTY_NAME", "true/false", "boolean")
    • Replace PARTNER by a Partner name
    • Replace PARTNER_TYPE by the type of the specified Partner (idp or sp)
    • Replace PROPERTY_NAME by the name of the property to set
    • Set the value to true or false
    • An example would be
      updatePartnerProperty("AcmeSP", "sp", "sendsignedrequestquery", "true", "boolean")

Metadata

Changing the saml20sendsignedauthnrequest property at a global level would change the SAML 2.0 Metadata generated by OIF, as:

  • The AuthnRequestsSignedattribute in the SPSSODescriptor element is set based on saml20sendsignedauthnrequest

A sample SAML 2.0 Metadata would show those two attributes:

<md:EntityDescriptor ...>
  <dsig:Signature>
  ...
  </dsig:Signature>
  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" ...>
  ...
  </md:IDPSSODescriptor>
  <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" ...>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Requiring Messages to be Signed


OOTB Configuration

Below are the OOTB boolean settings that govern when OIF needs to require incoming SAML messages to be signed (if true, OIF requires the incoming message to be signed):

  • Global level
    • saml20requiresignedauthnrequest: SAML 2.0 AuthnRequest (false)
    • saml11requiresignedassertion: SAML 1.1 Assertion contained in a Response message (true)
    • saml20requiresignedassertion: SAML 2.0 Assertion contained in a Response message (true)
  • SAML 1.1 IdP Partner Profile
    • requiresignedresponseassertionpost: SAML 1.1 Response via the HTTP-POST binding (false)
    • requiresignedresponseassertionsoap: SAML 1.1 Response via the Artifact/SOAP binding (false)
  • SAML 1.1 SP Partner Profile
    • requiresignedrequestsoap: SAML 1.1 Request via the Artifact/SOAP binding (false)
  • SAML 2.0 IdP Partner Profile
    • requiresignedrequestpost: SAML 2.0 Request over the HTTP-POST binding (false)
    • requiresignedrequestquery: SAML 2.0 Request over the HTTP-Redirect binding (false)
    • requiresignedrequestsoap: SAML 2.0 Request over the Artifact/SOAP binding (false)
    • requiresignedresponseassertionpost: SAML 2.0 Response containing an Assertion over the HTTP-POST binding (false)
    • requiresignedresponseassertionsoap: SAML 2.0 Response containing an Assertion over the Artifact/SOAP binding (false)
    • requiresignedresponsepost: SAML 2.0 Response not containing an Assertion over the HTTP-POST binding (false)
    • requiresignedresponsequery: SAML 2.0 Response not containing an Assertion over the HTTP-Redirect binding (false)
    • requiresignedresponsesoap: SAML 2.0 Response not containing an Assertion over the Artifact/SOAP binding (false)
  • SAML 2.0 SP Partner Profile
    • requiresignedrequestpost: SAML 2.0 Request over the HTTP-POST binding (false)
    • requiresignedrequestquery: SAML 2.0 Request over the HTTP-Redirect binding (false)
    • requiresignedrequestsoap: SAML 2.0 Request over the Artifact/SOAP binding (false)
    • requiresignedresponsepost: SAML 2.0 Response not containing an Assertion over the HTTP-POST binding (false)
    • requiresignedresponsequery: SAML 2.0 Response not containing an Assertion over the HTTP-Redirect binding (false)
    • requiresignedresponsesoap: SAML 2.0 Response not containing an Assertion over the Artifact/SOAP binding (false)

Important Note: if an incoming message is signed, OIF will verify it and return an error if signature validation failed, even if OIF does not require that type of message to be signed.

Configuration

I will assume that you are already in the WLST environment and connected using:

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Navigate to the Domain Runtime branch:
    domainRuntime()

SAML 2.0 AuthnRequest

To configure OIF to require or not incoming AuthnRequest messages to be signed, execute one of the following commands:    

  • To configure at a global level, execute:
    putBooleanProperty("/idpglobal/saml20requiresignedauthnrequest", "true/false")
    • Set the value to true to have OIF require incoming AuthnRequest to be signed
    • An example would be
      putBooleanProperty("/idpglobal/saml20requiresignedauthnrequest", "true")
  • To configure at a SAML 2.0 SP Partner Profile level, execute:
    putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/requiresignedauthnrequest", "true/false")
    • Replace PARTNER_PROFILE by a SAML 2.0 SP Partner Profile name
    • Set the value to true to have OIF require incoming AuthnRequest to be signed
    • An example would be
      putBooleanProperty("/fedpartnerprofiles/saml20-sp-partner-profile/requiresignedauthnrequest", "true")
  • To configure at a SAML 2.0 SP Partner level, execute:
    updatePartnerProperty("PARTNER", "sp", "requiresignedauthnrequest", "true/false", "boolean")
    • Replace PARTNER by a SAML 2.0 SP Partner name
    • Set the value to true to have OIF require incoming AuthnRequest to be signed
    • An example would be
      updatePartnerProperty("AcmeSP", "sp", "requiresignedauthnrequest", "false", "boolean")

SAML 1.1 Assertion contained in a Response message

To configure OIF to require or not incoming SAML 1.1 Assertions to be signed, execute one of the following commands:

  • To configure at a global level, execute:
    putBooleanProperty("/spglobal/saml11requiresignedassertion", "true/false")
    • Set the value to true to have OIF require incoming SAML 1.1 Assertions to be signed
    • An example would be
      putBooleanProperty("/spglobal/saml11requiresignedassertion", "true")
  • To configure at a SAML 1.1 IdP Partner Profile level, execute:
    putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/requiresignedassertion", "true/false")
    • Replace PARTNER_PROFILE by a SAML 1.1 IdP Partner Profile name
    • Set the value to true to have OIF require incoming SAML 1.1 Assertions to be signed
    • An example would be
      putBooleanProperty("/fedpartnerprofiles/saml11-idp-partner-profile/requiresignedassertion", "true")
  • To configure at a SAML 1.1 IdP Partner level, execute:
    updatePartnerProperty("PARTNER", "idp", "requiresignedassertion", "true/false", "boolean")
    • Replace PARTNER by a SAML 1.1 IdP Partner name
    • Set the value to true to have OIF require incoming SAML 1.1 Assertions to be signed
    • An example would be
      updatePartnerProperty("AcmeSP", "sp", "requiresignedassertion", "false", "boolean")

SAML 2.0 Assertion contained in a Response message

To configure OIF to require or not incoming SAML 2.0 Assertions to be signed, execute one of the following commands:

  • To configure at a global level, execute:
    putBooleanProperty("/spglobal/saml20requiresignedassertion", "true/false")
    • Set the value to true to have OIF require incoming SAML 2.0 Assertions to be signed
    • An example would be
      putBooleanProperty("/spglobal/saml20requiresignedassertion", "true")
  • To configure at a SAML 2.0 IdP Partner Profile level, execute:
    putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/requiresignedassertion", "true/false")
    • Replace PARTNER_PROFILE by a SAML 2.0 IdP Partner Profile name
    • Set the value to true to have OIF require incoming SAML 2.0 Assertions to be signed
    • An example would be
      putBooleanProperty("/fedpartnerprofiles/saml20-idp-partner-profile/requiresignedassertion", "true")
  • To configure at a SAML 2.0 IdP Partner level, execute:
    updatePartnerProperty("PARTNER", "idp", "requiresignedassertion", "true/false", "boolean")
    • Replace PARTNER by a SAML 2.0 IdP Partner name
    • Set the value to true to have OIF require incoming SAML 2.0 Assertions to be signed
    • An example would be
      updatePartnerProperty("AcmeSP", "sp", "requiresignedassertion", "false", "boolean")

Other Settings

To configure the properties defined at the SP/IdP Partner Profiles above, execute one of the following commands:

  • To configure at a Partner Profile level, execute:
    putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/PROPERTY_NAME", "true/false")
    • Replace PARTNER_PROFILE by a Partner Profile name
    • Replace PROPERTY_NAME by the name of the property to set
    • Set the value to true or false
    • An example would be
      putBooleanProperty("/fedpartnerprofiles/saml20-idp-partner-profile/requiresignedrequestquery", "true")
  • To configure at a Partner level, execute:
    updatePartnerProperty("PARTNER", "PARTNER_TYPE", "PROPERTY_NAME", "true/false", "boolean")
    • Replace PARTNER by a Partner name
    • Replace PARTNER_TYPE by the type of the specified Partner (idp or sp)
    • Replace PROPERTY_NAME by the name of the property to set
    • Set the value to true or false
    • An example would be
      updatePartnerProperty("AcmeSP", "sp", "requiresignedrequestquery", "true", "boolean")

Metadata

Changing the saml20requiresignedauthnrequest or saml20requiresignedassertion properties at a global level would change the SAML 2.0 Metadata generated by OIF, as:

  • The WantAuthnRequestsSigned attribute in the IDPSSODescriptor element is set based on saml20requiresignedauthnrequest
  • The WantAssertionsSigned attribute in the SPSSODescriptor element is set based on saml20requiresignedassertion

A sample SAML 2.0 Metadata would show those two attributes:

<md:EntityDescriptor ...>
  <dsig:Signature>
  ...
  </dsig:Signature>
  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" ...>
  ...
  </md:IDPSSODescriptor>
  <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" ...>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

X.509 Certificate in Message


OIF can be configured to send the X.509 signing certificate in the outgoing XML SAML message sent via the HTTP-POST or SOAP bindings.

The includecertinsignature boolean property indicates whether or not the certificate will be added to the message.

To configure OIF to send the X.509 signing certificate in the outgoing message, execute one of the following commands to set the includecertinsignature boolean property:

  • To configure at a Partner Profile level, execute:
    putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/includecertinsignature", "true/false")
    • Replace PARTNER_PROFILE by a Partner Profile name
    • Set the value to true or false
    • An example would be
      putBooleanProperty("/fedpartnerprofiles/saml20-sp-partner-profile/includecertinsignature", "true")
  • To configure at a Partner level, execute:
    updatePartnerProperty("PARTNER", "PARTNER_TYPE", "includecertinsignature", "true/false", "boolean")
    • Replace PARTNER by a Partner name
    • Replace PARTNER_TYPE by the type of the specified Partner (idp or sp)
    • Set the value to true or false
    • An example would be
      updatePartnerProperty("AcmeSP", "sp", "includecertinsignature", "true", "boolean")

SAML 2.0 Encryption


The SAML 2.0 protocol defines a way to encrypt various data in messages:

  • Assertions
  • NameIDs
  • Attributes

OIF allows an administrator to indicate which types of data should be encrypted.

OOTB Configuration

Below are the OOTB boolean settings that indicate when OIF needs to encrypt outgoing SAML messages (if true, OIF will encrypt the outgoing data):

  • SAML 2.0 IdP Partner Profile
    • sendencryptednameid: indicates if NameID contained in LogoutRequest messages should be encrypted (false)
  • SAML 2.0 SP Partner Profile
    • sendencryptedattribute: indicates if each attribute contained in a SAML Assertion should be encrypted (false)
    • sendencryptednameid: indicates if NameID contained in LogoutRequest, Assertion messages should be encrypted (false)

When creating a new SP Partner, the configuration for that Partner will indicate that the OIF/IdP should not encrypt the Assertion:

  • sendencryptedassertion on the partner entry: indicates if the Assertionshould be encrypted (false)

Encrypted Assertion

To configure OIF/IdP to encrypt the outgoing Assertion for an SP Partner via the OAM Administration Console, perform the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Identity Federation -> Identity Provider Administration
  • Open the SP Partner
  • In the Advanced section, check the "Encrypt Assertion" checkbox
  • Save

To configure the SP Partner via WLST, perform the following steps:

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Navigate to the Domain Runtime branch:
    domainRuntime()
  • Execute the updatePartnerProperty() command:
    updatePartnerProperty("PARTNER", "sp", "sendencryptedassertion", "true/false", "boolean")
    • Replace PARTNER by a Partner name
    • Set the value to true or false
    • An example would be
      updatePartnerProperty("AcmeSP", "sp", "sendencryptedassertion", "true", "boolean")
  • Exit the WLST environment:
    exit()

Encrypted NameID/Attributes

To configure the properties, perform the following steps:

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Navigate to the Domain Runtime branch:
    domainRuntime()
  • Execute one of the following commands:
    • To configure at a Partner Profile level, execute:
      putBooleanProperty("/fedpartnerprofiles/PARTNER_PROFILE/PROPERTY_NAME", "true/false")
      • Replace PARTNER_PROFILE by a Partner Profile name
      • Replace PROPERTY_NAME by the name of the property to set
      • Set the value to true or false
      • An example would be
        putBooleanProperty("/fedpartnerprofiles/saml20-sp-partner-profile/sendencryptedattribute", "true")
    • To configure at a Partner level, execute:
      updatePartnerProperty("PARTNER", "PARTNER_TYPE", "PROPERTY_NAME", "true/false", "boolean")
      • Replace PARTNER by a Partner name
      • Replace PARTNER_TYPE by the type of the specified Partner (idp or sp)
      • Replace PROPERTY_NAME by the name of the property to set
      • Set the value to true or false
      • An example would be
        updatePartnerProperty("AcmeSP", "sp", "sendencryptedattribute", "true", "boolean")
  • Exit the WLST environment:
    exit()

Encryption Algorithm

The encryption algorithm can be defined at the Partner level or Partner Profile level, by setting the defaultencryptionmethod string property to one of the following values:

  • http://www.w3.org/2001/04/xmlenc#aes128-cbc for AES-128 CBC
  • http://www.w3.org/2001/04/xmlenc#aes192-cbc for AES-192 CBC
  • http://www.w3.org/2001/04/xmlenc#aes256-cbc for AES-256 CBC
  • http://www.w3.org/2001/04/xmlenc#tripledes-cbc for 3DES CBC

By default, that property is set to http://www.w3.org/2001/04/xmlenc#aes128-cbc (AES-128 CBC).

To configure the defaultencryptionmethod property, perform the following steps:

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Navigate to the Domain Runtime branch:
    domainRuntime()
  • Execute one of the following commands:
    • To configure at a Partner Profile level, execute:
      putStringProperty("/fedpartnerprofiles/PARTNER_PROFILE/defaultencryptionmethod", "ALGORITHM")
      • Replace PARTNER_PROFILE by a Partner Profile name
      • Replace ALGORITHM by one of the above algorithm values
      • An example would be
        putStringProperty("/fedpartnerprofiles/saml20-sp-partner-profile/defaultencryptionmethod", "http://www.w3.org/2001/04/xmlenc#tripledes-cbc")
    • To configure at a Partner level, execute:
      updatePartnerProperty("PARTNER", "PARTNER_TYPE", "defaultencryptionmethod", "ALGORITHM", "string")
      • Replace PARTNER by a Partner name
      • Replace PARTNER_TYPE by the type of the specified Partner (idp or sp)
      • Replace ALGORITHM by one of the above algorithm values
      • An example would be
        updatePartnerProperty("AcmeSP", "sp", "defaultencryptionmethod", "http://www.w3.org/2001/04/xmlenc#tripledes-cbc", "string")
  • Exit the WLST environment:
    exit()

In the next article, I will show how to configure a WebGate SSO Agent as a HTTP Reverse Proxy for the OAM/OIF services, with the WebGate communicating with the servers over the secure OAM NAP protocol.
Cheers,

Damien Carru

Join the discussion

Comments ( 2 )
  • Divya Tuesday, August 25, 2015

    Hi Damien

    We are facing issues while integrating OIF 11.1.2.2 as SP with IBM tivoli IDP. During artifact resolution process , IBM is suggesting that the namespace format in the XML might be incorrect.

    in OIF 11.1.2.2 , we declare the namespace in the ancestor element instead of

    individual nodes. Is it possible to change this ? Will this cause any issue ? PLease assist.

    Instead of sending like this and referencing the namespace in the header

    -<samlp:ArtifactResolve>

    we need to send like this

    <samlp:ArtifactResolve xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

    Thanks

    divya


  • Damien Sunday, October 4, 2015

    Hi,

    The SAMLP Namespace can be declared in any XML parent of the sample:ArtifactResolve element or in the sample:ArtifactResolve element itself, which is valid XML.

    It seems that the Tivoli implementation has limitations and should be fixed by IBM, as the namespace declaration should be inherited by the XML children elements.

    Damien


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.