Environment
NetIQ Access Manager 3.2 Support Pack 2 applied
Siteminder SAML2 Identity Server
SAML2 enabled back end application acting as a SAML2 Service Provider
SAML2 enabled back end application accelerated by the Access Gateway
NetIQ Access Manager 3.2 Identity Server configured as a SAML2 SP server to Siteminder
NetIQ Access Manager 3.2 Identity Server configured as a SAML2 IDP server to SAML enabled application
Siteminder SAML2 Identity Server
SAML2 enabled back end application acting as a SAML2 Service Provider
SAML2 enabled back end application accelerated by the Access Gateway
NetIQ Access Manager 3.2 Identity Server configured as a SAML2 SP server to Siteminder
NetIQ Access Manager 3.2 Identity Server configured as a SAML2 IDP server to SAML enabled application
Situation
Access Manager setup and working fine ie. users can authenticate to the NAM Identity Server and single sign on (SSO) to back end Web applications accelerated by the Access Gateway.
The administrator was asked to integrate a new SAML enabled application within this NAM environment where users accessed the application via the Access Gateway. This application expects a SAML assertion for SSO purposes (cannot SSO using formfill or identity injection) but when injecting the SAML assertion with an Identity injection policy, it fails. This is because the assertion injected is actually the Liberty and non SAML assertion. ANother limitation of the SAML enabled application is that it cannot generate an AUthnRequest ie. there is no support for SP enabled SSO.
The administrator was asked to integrate a new SAML enabled application within this NAM environment where users accessed the application via the Access Gateway. This application expects a SAML assertion for SSO purposes (cannot SSO using formfill or identity injection) but when injecting the SAML assertion with an Identity injection policy, it fails. This is because the assertion injected is actually the Liberty and non SAML assertion. ANother limitation of the SAML enabled application is that it cannot generate an AUthnRequest ie. there is no support for SP enabled SSO.
Resolution
A number of steps are required here:
a) build a trust relationship between the NAM IDP server and the SAML enabled application
b) define an intersite transfer URL that users will access to initially SSO to the NAM IDP server and then send the assertion to the SAML enabled application. This NAM intersite transfer URL usually referenced the SAML SP id, and a target URL. By referencing the SAML SP id, we know what URL to send the SAML assertion to (Assertion Consumer Service URL), and the target includes the URL that users will be redirected to after the SAML SP successfully consumes the assertion.
In the example below:
https://nam-idp.novell.com/nidp/saml2/idpsend?id=nformtest&TARGET=https://app.novell.com
the NAM IDP server will
- initially authenticate the user and assuming successful
- redirect the user to send the SAML assertion to the Assertion Consumer Service URL of the SAML SP defined in NAM with the id of nformtest, and include a RelayState parameter of https://app.novell.com with this assertion. app.novell.com is a protected resource behind the Access Gateway.
If the SAML SP consumes the assertion successfully, it takes the incoming RelayState from above and redirects the user to the target URL ie. https://app.novell.com accelerated by the Access Gateway (AG). The AG processes the request, redirects the user back to the IDP server in the case where no existing valid session exists on the AG but since the user has just authenticated to the IDP server, a Liberty assertion is sent to the AG from the IDP server for SSO to the AG.
This particular customer had one additional requirement after getting this going. Some users accessing this SAML enabled application were authenticating to either a NAM SAML2 Identity server or a SiteMinder SAML2 Identity server and wanted to SSO all the way through to the application. To handle this scenario with minimal changes to the existing setup, the following URL was crafted for those users accessing the SAML enabled application via SiteMinder after the SAML trust relationship between Siteminder and NAM was created:
https://sm.novell.com/idp/startSSO.ping?PartnerSpId=https://nam-idp.novell.com/nidp/saml2/metadata&TARGET=https://nam-idp.novell.com/nidp/saml2/idpsend?id=nformtest&TARGET=https://app.novell.com
The users hit the Siteminder intersite transfer URL at https://sm.novell.com/idp/startSSO.ping
and pass in the Partner SP details that simply include the NAM metadata link (which is the NAM entity ID used for validation purposes). It also includes a target of the NAM intersite transfer URL we created above. When the users successfully authenticate to the Siteminder Identity server, the assertion is POSTed to the NAM Identity Server (acting as a SAML2 Servicve provider) along with the target where SSO to NAM will take place. When NAM then consumed the assertion successfully, it will redirect the user to the target URL defined ... which is the NAM local intersite transfer service for SSO to the SAML enabled application.
a) build a trust relationship between the NAM IDP server and the SAML enabled application
b) define an intersite transfer URL that users will access to initially SSO to the NAM IDP server and then send the assertion to the SAML enabled application. This NAM intersite transfer URL usually referenced the SAML SP id, and a target URL. By referencing the SAML SP id, we know what URL to send the SAML assertion to (Assertion Consumer Service URL), and the target includes the URL that users will be redirected to after the SAML SP successfully consumes the assertion.
In the example below:
https://nam-idp.novell.com/nidp/saml2/idpsend?id=nformtest&TARGET=https://app.novell.com
the NAM IDP server will
- initially authenticate the user and assuming successful
- redirect the user to send the SAML assertion to the Assertion Consumer Service URL of the SAML SP defined in NAM with the id of nformtest, and include a RelayState parameter of https://app.novell.com with this assertion. app.novell.com is a protected resource behind the Access Gateway.
If the SAML SP consumes the assertion successfully, it takes the incoming RelayState from above and redirects the user to the target URL ie. https://app.novell.com accelerated by the Access Gateway (AG). The AG processes the request, redirects the user back to the IDP server in the case where no existing valid session exists on the AG but since the user has just authenticated to the IDP server, a Liberty assertion is sent to the AG from the IDP server for SSO to the AG.
This particular customer had one additional requirement after getting this going. Some users accessing this SAML enabled application were authenticating to either a NAM SAML2 Identity server or a SiteMinder SAML2 Identity server and wanted to SSO all the way through to the application. To handle this scenario with minimal changes to the existing setup, the following URL was crafted for those users accessing the SAML enabled application via SiteMinder after the SAML trust relationship between Siteminder and NAM was created:
https://sm.novell.com/idp/startSSO.ping?PartnerSpId=https://nam-idp.novell.com/nidp/saml2/metadata&TARGET=https://nam-idp.novell.com/nidp/saml2/idpsend?id=nformtest&TARGET=https://app.novell.com
The users hit the Siteminder intersite transfer URL at https://sm.novell.com/idp/startSSO.ping
and pass in the Partner SP details that simply include the NAM metadata link (which is the NAM entity ID used for validation purposes). It also includes a target of the NAM intersite transfer URL we created above. When the users successfully authenticate to the Siteminder Identity server, the assertion is POSTed to the NAM Identity Server (acting as a SAML2 Servicve provider) along with the target where SSO to NAM will take place. When NAM then consumed the assertion successfully, it will redirect the user to the target URL defined ... which is the NAM local intersite transfer service for SSO to the SAML enabled application.