We have an issue with identity mapping with federation. We are actiing as SAML 2.0 IDP and we use SP initiated flow to access partner app.
On IDP side, we have a situation where user with existing smsession (with default home page that is protected using LDAP1) trying to access federated app (using SP init flow) that is protected using LDAP2 on IDP side.
We did set up LDAP1 -> LDAP2 identity mapping and enabled it for a realm that contains auth URL specified in IDP -> SP partnership.
But this identity mapping is not triggered in federation case as it seems auth URL is not being invoked as there is existing smsession and fed end point is rejectng this session immediately due to invalid DN as identity mapping is not happening.
12.52 Identity mapping doesn't get invoked in federation use case ?
We are using 12.52 SP1 CR0 version.
There is an idea for this below. Please vote if that matches what you are trying to achieve.
Identity mapping for Federation
I don't thinks this is going to help as in this particular use case, there is no redirection to authentication URL on IDP side so there is no question of identity mapping.
Just a suggestion that may worth trying:
If the existing user session is with protection level 5, increase the partnership federation (IdP-> SP) authentication level and authentication URL protection level to level 6 and above, so that the user get re-challenge for authentication again.
[NOTE: partnership federation authentication level should match the authentication URL protection level]
There's a known issue pertain to IWA step-up authentication with R12.52 SP1 release, so please try protect the authentication URL with other authentication schemes.
I already tried that work around. It didn't work.
Here is the use case.
I accessed home page that is protected by IWA auth (level-5) with Dir1.
With above smsession, tried to access federated partner (that has redirectjsp protected with form auth with level-15 and parrtship config also level-15 and used Dir2 for partnership). It looks like as Directory/user DN in existing smsession doesn't match the federated partnership user directory/DN, policy server is simply throwing "not authorized" to FSS. So, auth level and auth scheme of federation (redirectjsp) doesn't come into play.
We don't want to protect SM IDP end point URL "***/affwebservices/public/saml2sso" as we need to use same end point to support federations that use both Directories (Dir1 & Dir2). So, we are using two different redirectjsps in two types of federations and protecting those redirectjsps with two different directories.
I tried another work around by creating intermediate redirect page as IDP end point URL and protecting that intermediate page realm with Dir2 and attaching Dir1 -> Dir2 Identity mapping so that smsession gets converted to Dir2 based (if there is Dir1 based smsession already) before this intermdiate page redirects to standard SM end point URL "***/affwebservices/public/saml2sso" with SAMLRequest and RelayState params.
This solution will work for IDP initiated federations. But, in SP initiated federations, the challenge with this work around is "Destination" value in AuthNRequest that SP is passing to IDP (SM) contains this intermediate page and SM is unable to match Destination value "intermediate page" with standard destination value "affwebservices/public/saml2sso".
Is there an option in SM (as IDP) not to validate destination value coming in AuthNRequest in SP init flow ?
Just to clarify, the intermediate page URL is specified as Target in partnership federation or as RelayState?
Neither of them as per the description. It must have been specified as "SSO Service URL" in SP partnership.
Please confirm @Kishore
IDP intermediate page URL (that has identity mapping enabled) is specified as "SSO service URL" on SP side so that SP will redirect to this intermediate page (in SP init flow) and smsession gets converted to Dir2 (if there is existing session with Dir1) due to identity mapping and then this intermediate page redirects to SM "saml2sso" with SAMLRequest and RelayState,
But, this flow is failing due to Destination (in AuthnRequest) validation check.
So, in SM being in IDP role, how can we make SP initiated federation flow work if federation uses one directory and there is already existing smsession that use another user dir ?
Adding to above update..
Destination validation is mandatory as per SAML specifications, Hence we can not disable.
Where do you see that Sharan? I was looking for the same and found that the "Destination" is not even a mandatory field for AuthNRequest.
How can the validation be a mandatory for an optional field? My guess is this is CA SSO specific.
According to the SAML Specification, the Destination attribute is mandatory for signed AuthnRequests. Please refer Security considerations sections 220.127.116.11 and 18.104.22.168 of saml-bindings-2.0 document.I found from below link. Kindly check.https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
Thanks Sharan for that.
So that means the validation is necessary for signed AuthNrequest.
From the specs:
"If the message is signed, the Destination XML attribute in the root SAML element of the protocol message MUST contain the URL to which the sender has instructed the user agent to deliver the message. The recipient MUST then verify that the value matches the location at which the message has been received."
Are you using signed AuthNRequest ? Can you try unsigned AuthNRequest and see if there is any difference ?
We have clients that does both signed and unsigned authnrequests. Irrespective of whether it is signed or not, I think, SM does validate 'Destination' value in authnrequest. Atleast, Is there a option in SM to change the destination value (<>/affwebservices/public/saml2sso) to some thing else ? or "Destination" value in authnrequest must be (<>/affwebservices/public/saml2sso) ?
If the destination value in authnrequest doesn't contain <BaseURL>/affwebservices/public/saml2sso, SM (acting as IDP) policy server is throwing the error "Destination does not match local URL".
"Destination" value in authnrequest must be (<BaseURL>/affwebservices/public/saml2sso) or is it configurable in SM ?
There is no such thing that partnership only works when destination url only with saml2sso url. I have configured few partnerships with different destination url other than saml2sso url, where i have used IDP initiated url (which is something like .aspx or .jsp), and they are working perfectly fine. I was referring to SP initiated transaction only. You could do this by modifying IDP metadata SSO end points before uploading to SP end. Export the metadata from your partnership and go to the SSO end points section in metadata, modify the saml2sso service url with your idp initiated url and import the updated metadata on SP end. Hope this helps.
Thanks for the imply. This is not a challenge in IDP init flow where in we can have intermediate page like "idp.jsp" as IDP end point URL and this idp.jsp page can be protected and assigned with Dir mapping. I assume,This idp.jsp will redirect to "xx/affwebservices/public/saml2sso for SM to generate SMResponse.
In SP init flow, if SP redirects to this page "idp.jsp" with SAMLRequest and AuthnRequest sent by SP in this case contains this "idp.jsp" as "destination" value as we have given "idp.jsp" as IDP end point URL in metadata file. When "idp.jsp" in turn redirects to "saml2sso" with original SAMLRequest by SP, request will on SM (IDP) end as "destination" value in authnrequest (in this case "idp.jsp") doesn't match local value ("xx/affwebserice/public/saml2sso")
I meant, When "idp.jsp" in turn redirects to "saml2sso" with original SAMLRequest by SP, request will FAIL on SM (IDP) end as "destination" value in authnrequest (in this case "idp.jsp") doesn't match local value ("xx/affwebserice/public/saml2sso")
Ideally the destination URL attribute should have Remote SSO url configured at SP (Service Provider) end. Hence Siteminder will try to match the destination url with local IDP SSO Url which is hardcoded. If it not matching then you will get an error saying "doesn't match local value ("xx/affwebserice/public/saml2sso")".
/affwebserice/public/saml2sso is hardcoded, hence you can not change to something else.