IZ48248: SAML 2.0 IDP incorrectly process unspecified nameid format and always treats unspecified as a persistent id.

IBM Tivoli Federated Identity Manager 6.2.0 fix pack 3 (6.2.0-TIV-TFIM-FP0003)
Tivoli Federated Identity Manager 6.2.0 Fixpack 8 (6.2.0-TIV-TFIM-FP0008)
IBM Tivoli Federated Identity Manager Business Gateway v6.2.0, Fix Pack 8, 6.2.0-TIV-TFIMBG-FP0008
Tivoli Federated Identity Manager 6.2.0 Fixpack 9 (6.2.0-TIV-TFIM-FP0009)
Tivoli Fed Id Mgr Business Gateway v6.2.0, Fix Pack 9, 6.2.0-TIV-TFIMBG-FP0009
Tivoli Federated Identity Manager 6.2.0 Fixpack 13 (6.2.0-TIV-TFIM-FP0013)
Tivoli Fed Id Mgr Business Gateway v6.2.0, Fix Pack 13, 6.2.0-TIV-TFIMBG-FP0013

APAR status

• Closed as program error.

Error description

• This defect was discovered as part of integration work with
  Google Apps, which always sends the following Requested NameID
  format in AuthnRequest messages:
      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
  
  The SAML 2.0 IDP has a list of "supported" nameid formats. The
  default list includes:
    urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted
  
  These can be added to via the CLI, and by way of example,
  Google Apps acting as a service provider sends this value as
  it's RequestedNameIDFormat:
      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
  
  The current behaviour if you add the
  urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified format
  to the list of supported formats is that the IDP will try and
  build a NameID by looking up the alias service (just like a
  persistent NameID), and if none is found and the allowCreate
  policy is true, it will use a transient nameid which is a
  randomly generated UUID.
  
  The appropriate behaviour if the RequestedNameIDFormat is
  unspecified is to use the value of the existing property:
    SAML2.DefaultNameIDFormat
  to determine which approach to take.
  
  One way to reproduce the scenario is to perform an SSO
  integration with GoogleApps, documented here:
  https://www-951.ibm.com/blogs/sweeden/entry/
  tivoli_federated_identity_manager_and_googleapps
  

Local fix

• The workaround (which is not workable in all scenarios) is to
  manually add a persistent alias to the alias service (LDAP
  or database) for the partner with the alias value set to the
  provided name identifier.
  

Problem summary

• Logic already existed to use the SAML2.DefaultNameIDFormat
  however the constant to match against the "unspecified" format
  was incorrectly defined to be:
    urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
  instead of:
    urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
  
  The fix allows either value to be sent, and when
  received the SAML2.DefaultNameID property is consulted,
  first using the per-partner setting of this parameter, and if
  no value the federation level setting of the parameter.
  
  If no value is found for either, it defaults to persistent.
  

Problem conclusion

• The fix for this APAR will be contained in the following
  maintenance packages:
  | fix pack | 6.2.0-TIV-TFIM-FP0003 |
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  TIV FED ID MGR

• Fixed component ID

  5724L7300

Applicable component levels

• R620 PSY

     UP