Symantec Access Management

I have a Siteminder protected application that calls a Federation login process.  After it completes the Federation process it needs to end up on the page originally requested. In Federation it hits the redirect.jsp and is then forwarded to the Login.fcc.  I need to get the ""TARGET" value from the URL POST  and append the TARGET value as the RelayState=value to the POST to the login.fcc POST.

I can get the TARGET value with JavaScript in the login.fcc.   How do I append the RelayState=value to the POST within the login.fcc?

POST https://server.foo.com/affwebservices/ldap/redirect.jsp?SPID=myapp&TARGET=$SM$https://server2.foo2.com

POST https://server.foo.com/affwebservices/ldap/login.fcc?SPID=myapp&RealyState=https://server2.foo2.com&TARGET=$SM$https://server2.foo2.com

Thanks

Hi Ron.

I was contact with my fellow senior colleague Joe and found out he had a support issue with you.

As Joe mentioned, 

The above question requires Knowledge in Coding but Joe knows it is feasible as Joe has seen a client do it before. 

If you need assistance for custom solution, you can always engage CA services through your Account manager that can get them on board and we pretty sure they will code a page for you to achieve the same . 

Now you can wait for  ca services to respond here in communities  and see what they say.

Here was Joe's answer in the  support issue

Question --> I have a SiteMinder protected application that is using the SAML Federation login process to affwebservices/redirect.jsp. 
How can I pull the target value and insert it in the redirection URL as the relaystate? It is not clear how the redirect.jsp works. Is this process documented? 

Answer --> First to clarify the usage of RelayState for FWS, it can be used in the below Manner 

https://server.foo.com/affwebservices/public/saml2sso?SPID=your_SPID&RelayState=encodedURL 
or 
https://server.foo.com/affwebservices/public/saml2sso?SAMLRequest=fdefefefef.....&RelayState=encodedURL 

What you have done in your Setup is that you defined your Auth Scheme to redirect you to a hardcoded IDP initiated link where the agent will generate the below URL that include the TARGET of the protected Resource 


· This is the GET to the redirect.jsp. 
https://server.foo.com/affwebservices/redirect.jsp?SPID=idp&TYPE=33554433&REALMOID=06-000e4dff-779a-1b47-b47a-676bac18f0d1&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=$SM$lCsOuBLEJTqnvvLdb2QjIIWeFuRpGiUjhPzqiZQK5mZ0iNPrFiEo1OA%2bZ4T57t2K&TARGET=$SM$http%3a%2f%2fdev%2serverone%2efoo%2ecom%2fsystem%2f&SMPORTALURL=https%3A%2F%2Fserver.foo.com%2Faffwebservices%2Fpublic%2Fsaml2sso&SAMLTRANSACTIONID=2058fbfc-525a5662-e1de3c3f-731d5306-9a75a582-377 HTTP/1.1 


Having said so, we do not have any out of the Box Instructions nor we document Officially what you have done above. 
Not saying that you cannot do it however it is not the usual way of doing it . 

For this, My recommendation to you is to write your Own custom Solution to read the TARGET Header from the URL because we do not have such Functionality or even need to do such thing in normal setup . 
My recommendation to you was as follows : (and this is from me not from CA to give you some Ideas on how it can be done) 

- Rather then redirecting to the Auth Scheme with a IDP initiated hardoce link, you can write your own jsp page (custom page) that can Fetch the TARGET header from URL and issue a Redirect to IDP hardcoded link with the Relay State build from the TARGET header. 

Joe's  first instinct would be to set the RelayState before the saml authentication, not during it

.

Agree Terry

Ron,

You should not have to tinker with TARGET and RELAYSTATE in the login.fcc with what you want to achieve as an end goal.

There is a provision on the IdP Initiated flow to specify RELAYSTATE (Example listed by Terry). To be honest IdP does not know much about the internals of the SP deep links.

Anything to do with RelayState has to be set by the SP with the SAML REQUEST (Example listed by Terry). Because SP knows what page the URL the user was on OR needs to be on; that info needs to be send within the RELAYSTATE.

Bottemline, RELAYSTATE must be set outside the login process. Even if we stick to the basic concepts of SAML and usage of RELAYSTATE as per SAML protocols, the entire login process will handle RELAYSTATE within the federated URL and pass it back to SP unchanged. By doing what is being done here, we are adding unwanted custom code at the login.fcc, which will only further the pain in future.

Ron RonChavez

Let me break your statement "I have a Siteminder protected application that calls a Federation login process.  After it completes the Federation process it needs to end up on the page originally requested".

I believe the CA SSO protected application is on IdP end. The link on this protected app should be ideally the SP URL. So the request get redirected to SP and then SP can make a SAML REQUEST (with RELAYSTATE) to IdP.  CA SSO as IdP will handle the entire SAML REQUEST (With RelayState) throughout the login process. Once login process is completed, CA SSO federation services would handle the SAML REQUEST (With RelayState) and generate a SAML Response / Assertion (With RelayState). Then send the SAML Response / Assertion (With RelayState) back to SP. Throughout this entire flow the login.fcc MUST not tinker OR alter the RelayState. This is as per SAML Specification https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf.

Hi Dennis,

The connection starts with a SiteMinder protected application so there is no RelayState set, only a Target. After the Federation process completes I need to send the client back to the SiteMinder application and support deep linking. Is there a way to add a relaystate when the SiteMinder agent calls the Federation Service?  I have the Federation login process setup in the Authentication Scheme of the SiteMinder protected app.

Ron RonChavez

Am kind of lost now (After the Federation process completes I need to send the client back to the SiteMinder application and support deep linking), who is the IdP and who is SP ? My apologies, trying to visually what is being done here.

Is the siteminder application which is starting the connection AND the siteminder application to which you need to send the client back to within the same CA SSO ENV ? OR are they two different CA SSO ENV ? 

I feel we need to step back, this needs a design review and thought process check. Seems like there is some gap in understanding the product functions VS what we want to achieve VS how we achieve it.

A login.fcc needs 3 values to process the request

• Username.
• Password.
• Target (MUST be protected resource).

I would create a JSP page (not use redirect.jsp) OR use the sample 'unsolicited.jsp' page. Protect that JSP page.

I'd POST to login.fcc

• Username.
• Password.
• TARGET=https://server.foo.com/affwebservices/customjsp/protected.jsp

Within protected.jsp include,

Option-A ( * PoC needed)

the logic to POST to https://server.foo.com/affwebservices/public/saml2sso; with the following POST data

SPID=myapp

ProtocolBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

RelayState=XXXXXXXXXXXXXXXXXXX

OR

Option-B  ( * PoC needed)

(what Joe suggested) the logic that can Fetch the TARGET header from URL and issue a Redirect to IDP hardcoded link with the Relay State build from the TARGET header. https://server.foo.com/affwebservices/public/saml2sso?SPID=your_SPID&RelayState=encodedURL

How we capture the TARGET and translate that into RELAYSTATE is all custom code logic. But again my honest thought is we need to review this in detail. We can provide tips and insights over a communities thread; but designing a E2E solution, is not a viable option via a communities thread.

Regards

Hubert