We have a requirement to set the incoming RelayState attribute either as a Cookie / Request Header in the federation connection (where we act as the SP). This is needed for our in-house portal application (protected by CA SSO) to redirect the user back to the requested resource based on this value.
1. Client user initiates a SP-initiated federation request with RelayState set as App A. This App A is protected by CA SSO.
2. The incoming assertion is validated & the request is redirected to App A.
3. Policy configurations in CA SSO for App A redirects the user to a page in App B (protected by the same CA SSO) to complete additional formalities.
4. Ideally, after completing the formalities, the user needs to get redirected to the original requested resource - App A. Since the web page in App B does not have the info of the original requested resource (App A), user lands on to App B.
We are therefore planning to set the RelayState that contains the final destination URL either in a Cookie / Request Header in the federation connection so that the cookie is made available to App A & App B, based on which the web page in App B can redirect the user back to App A after completing the additional processing.
Kindly let us know how can this be configured in the federation connection please.
Other than programmatic way to capture the relaystate and use it as you want, did you think of asking IdP to put relaystate value as an assertion attribute to store it in session store via assertion attribute persistence and retrieve it for which ever app want to use it (granted that other apps are configured for session store) or you can simply set the attributes as cookie or header mode with appropriate redirect mode set.https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/partnership-federation/application-integration-at-the-relying-party/redirect-a-user-to-the-target-application-relying-party
Thanks for replying. The Target application URL is dynamic & can come from multiple IdPs. So, it can neither be included as an attribute in the assertion from the IdP nor configured as the Default Target in the federation connection at SP side.
Can you provide more insights on how can it be captured using APIs please.
https://communities.ca.com/thread/241813698-relaystate check out the post. its discussed in detail
Not sure if this works for your setup.
For the redirection of App A to App B, are you using something like onAuthAccept event to trigger the redirect? And the response is in an onAcceptRedirect to https://app-b.com/somepage
How about setting the final redirection as a query string for app-b URL?
so in the onAcceptRedirect, use https://app-b.com/somepage?finalredirecturi=https://app-a.com/someotherpage
if you make onAcceptRedirect response within domain scope instead of global scope, you can potentially set many different finalredirecturi depending on the situation in multiple rules. then your App B can read from the request header to know where to redirect back to after it completed its "formalities" as you call it.
you can make the query strings dynamic values by using Variables (Request Context). If the above is something of what you're looking for, we can discuss more about using Variables/expression to construct the redirect url.
I must state for the record that VAPT testers may flag the redirect URL in query string as an issue. but this can be mitigated as long as there is some sort of checking mechanism in App B which only accepts values that matches against a list of approved domains within the organisation. Once I did that, the issue is considered remedied.
Yes, we did had the App A's URL configured as the redirectURL (query string) in App B's endpoint in the Auth Responses. But with this configuration, every user was landing on to App A's static URL. But this landing page would be dynamic in our case.
So, if there is a way for setting up dynamic redirect URLs in the Auth Accept Response, this would ideally cater to our requirement.
Kindly provide more details on this please.
Thanks in advance !!!
Then let me introduce you to Variables and Expressions.
open up and modify your App A's domain. click on Variables tab.
Using the Request context variables allows you to "store" into variables the URL that is being attempted for access, as long as the URL falls within the realm that uses the rule and response.
Create these 2 variables. Note that the names for request context variables must start with "%"
Variable Type: Request Context
Definition: Property - Server
Definition: Property - Resource
then for your WebAgent-OnAccept-Redirect , configure the value to be in this format.
I like the first format cos then I can run the redirectserver value through a list of whitelisted domains. This is to satisfy pentesters. But the page that receives these query strings will need to join the two parameters to form the full URL to redirect back.
See which suits you and let us know how it goes.
Your pointers catered to our requirements exactly. We are now able to redirect the user to the requested resource (dynamic) on App A after completing the required processing on App B.
Thanks a lot for your inputs.
No worries. glad to help