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
Does this solve your problem?
docs.appian.com/.../Appian_Administration_Console.html
Not quite. We've proposed this solution and the user only wants a single click to redirect to the correct site. Instead of a click to SSO and then another click to go to the specific site, but we appreciate your response.
Sorry, I meant this: docs.appian.com/.../Appian_Administration_Console.html
Thank you for the response Stefan. User start pages won't quite work for our use case as a user may have access to multiple sites. When the user logs into Appian through SSO it will log them in to the site with the highest priority in "User Start Pages" in the Admin Console instead of the application they click in our user sign in app.
To clarify here.
The goal here is to see whether or not we can include additional properties (i.e. site requested) on the SAML Auth request from Appian that would allow the IdP to better handle generating the claims. As of now, we use “InResponseTo” which has been beneficial for redirecting to the correct Appian site. The issue is knowing which site the user is requesting when the SP request reaches the IdP.
So the question is whether we can alter the “Appian’s SP request” rather than the “IdP Response” so we could potentially include the site requested.
Can you verify what you're saying is that the user is redirected to their default "user start page" site after SAML authentication, even if they clicked a URL to a different site? I haven't had a chance to test this very much so up til now I wasn't all that sure how it would behave.
If it really does behave that way, maybe you could move the selection to be Appian internal? IE, have a higher-priority User Start Page aimed at users who have access to more than one site (per creative use of group assignments etc), which then provides them a simple "landing page" which only contains links to the sites they have access to. The benefit here is that you could use on-form logic to show/hide many different site links and thus potentially use the same form for all such users.
I know it's sort of a work-around to what you were really asking, but at the end of the day it could accomplish the same level of end-user convenience IMHO, without asking Appian to implement something that would require potentially significant product-level changes (if it's even possible for them).
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.
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.