Manipulate Response Going to IDP with Site

Certified Lead Developer

Hello Appian Community,

We are facing an interesting issue with SAML SSO where we are trying to return the Site the user is trying to access in the IdP response.

The reason for this is we have an application with two sites in Appian. Based on user permissions they might have access to one or both sites. 

In the scenario they have access to two sites we want them to navigate to the site they click. The issue is Appian can only have one IdP per entityId specified in the MetaData so when the response is returned to the IdP they aren't sure which site it is the user wants to access.

Our hopeful solution is to have Appian return, in the response to the IdP, the site the user is trying to access so the IdP can redirect. Is there any possible Appian solution to edit the IdP response?

Thank You,

Kevin

  Discussion posts and replies are publicly visible

Parents Reply
  • 0
    Certified Lead Developer
    in reply to Mike Schmitt

    Thanks Mike.

    Coincidentally enough we did implement the solution you suggested above that is a "Master" User Start Page with cards that are links to the sites the user has access to. The user is "OK" with it, but does want us to implement an alternative solution. 

    If it's not possible in Appian to edit the Appian SP request it's not possible. We have thought of a few alternatives (recording the site the user clicks in session variables, and some enhanced back-end routing), but wanted to check if the Appian solution was not possible first as this would be the "easiest" solution.

Children
  • For the record I just opened an arbitrary site URL in one of my environments, through an incognito window (forcing a new SAML authentication), and Appian resolved to the original site I'd pasted the URL for after the authentication cleared.

    That would suggest it should at least be possible to allow users to click-through external links to specific sites and end up on the clicked site after authenication is done; unless perhaps the redirect is getting screwed up on the SAML provider end?  This might be something better worked out through a support case, unless someone more knowledgable about the back-end workings of SAML authentication happens to see this and wants to chime in.