IdP and SP sharing the Same Domain Name Problem in Federation Journey

Document ID : KB000045321
Last Modified Date : 14/02/2018
Show Technical Document Details

Issue :

  Trying to access a resource at SP in Secure Cloud, the browser sends
  error 500 :

  "Internal Error occured while trying to process the request.
   Transaction ID: 18272de7-83f6d513-7ca809b2-def74a35-5e205260-f27 failed."

  and the Federation Service reports :

   [Calling authorizeEx to invoke SAML2 assertion generator.]

  because the Policy Server cannot authorize the user :

   [][][][][][][][][][][][][][** Status: Not Authorized. ]

Environment :

   Secure Cloud 1.54 RedHat 6;

Cause :

  Both IdP and SP sides share the domainname "".

  At IdP, the cspadmin user is found in the User Store A,
  which has DN :

  and at SP, the cspadmin user is found in the User Store B,
  which has different DN :


  The SMSESSION cookie created at IdP side will have the user
  DN "cn=cspadmin,ou=users,ou=mydomain,o=com". When the browser goes to the
  SP resource, the Federation service detects the presence of the
  SMSESSION cookie. Because the SMSESSION cookie has domainname
  the SP Federation Services uses it. But, it cannot authorize the
  access, because the SP User Store has different DN and as such,
  the SP Policy Server cannot apply the policy.

Resolution :

   This behavior is by design as both IdP and SP sides should be in different
   domains in order to avoid reuse of the same cookies.