URL link inside pushlished application not working

Is the web service an interactive browser-based process? What you want to be looking for is the initial web service request to APM. Does it send an MRHSession cookie? And the immediate response. Is it a 302 redirect to /my.policy?

In the strictest sense, APM SAML is still relatively new and currently only supports the "passive requester" method (HTTP GET/POST) and not the SOAP-based interaction that a true web service might need. I'm assuming though, since you're actually calling the web service from within the browser session, that we're referring to something more like an Ajax call - a semi-non-interactive process that silently returns data to be displayed in the browser. If that's more or less the case, we need to look at how the web service is interacting with APM.

The web service returns a JSON formatted file from the request. In the APM I see that it creates a new session for each call to the web service as we have another virtual server for the web service using SAML as well. And yes, it silently returns some data to the browser.

In the APM I see that it creates a new session for each call to the web service as we have another virtual server for the web service using SAML as well.

Okay, so we've established that the web service call goes to another VIP and that the web service calls are failing. Correct? Can you look at client side captures and see what's happening between the client (browser) and the web service VIP? Does the initial request send an APM session cookie to the VIP? Does this request get redirected to the IdP or to /my.policy?

Captured the client traffic and I see that it's a 302 result from the web service call:

HTTP/1.0 302 Found Connection: Close Location: /my.policy

It's also setting the cookie: Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/ Set-Cookie: MRHSession=ec00443b07717a45b91cd0c6eb6d4235;path=/;secure Set-Cookie: LastMRH_Session=eb6d4235;path=/;secure

And so does it just fail after that? As in it doesn't redirect to /my.policy? One other option would be to define the application's session token as a domain cookie. In the access policy for both the application and the web service, second tab, set the domain cookie field (ex. company.com). This should allow the web service call to send the session cookie from the application session and not get re-prompted for authentication.

I think the biggest problem here is the redirection. The web service call is not handling the redirection. If I change it to a session cookie instead of SAML, it will still redirect me to the another page to get the session cookie and redirect back to the original URL.

I'm referring to adding a cookie domain attribute to the individual access policies. A client initiates an access session, and subsequently gets redirected off to /my.policy or the IdP, in the absence of the session cookie. If the web service call carries this session cookie to the web service APM VIP, and that VIP is configured accordingly, it will not try to initiate a new access session.

Hi  ,

​

I have the same issue with my integration that I'm working on now.

1) First request goes to app1.domain.com (bogus fqdn) that runs an SP, redirected to idpX.

2) Login with username/password at idpX and gets redirected to app1 SP.

3) APM SP Accept the token and send the request to the application.

4) The application is configured with another idp. Redirect is sent to that url sso.domain.com.

5) Browser send a new request to sso.domain.com that is behind another VS with SP to idpX.

6) Request is redirected to /my.policy, at this point that request is canseled.

​

If I copy the link to sso.domain.com and open it in a new tab, the policy is successful. The idpX see that I have done a valid authentication already and allow my request.

​

The difference between the requests as I see it, the original redirect contains "Request header Origin and Referer to app1.domain.com.

​

Any thought about this?

​

Br

Andréas