RelyParty redirect URL

[Christopher Bongaarts]

On 6/18/2020 11:52 AM, Joseph Fischetti wrote:
> We’re discussing the implementation of a flow that will send a user to a specific page (at a predefined SP) prior to allowing them to continue on to the SP that they were trying to get to.  The flow part is easy and done, but what I’m looking for is a url that I can send to the predefined SP so it knows where the user was trying to get.  The flow would look like:
>
> User tries to get to SP-A
> Bounce to Shibboleth
> Log in to Shibboleth
> Flow intercept sends user to SP-B+redirect=SP-A
> SP-B does it’s thing
> SP-B sends the user to SP-A
>
> I had considered using the entityID, but that wont work for obvious reasons.
>
> Can someone point me in the direction of the documentation that might include what I need to expose various RelyingParty endpoints/urls in a velocity template?  I’m hoping there’s something consistent between SAML and CAS services that would be [the url that the IdP would be sending the user to after logging in].

As written that won't work, but here is a slightly different approach 
that might get you close:

SP-A sends user and SAMLRequest to IdP
IdP user login as usual
Flow intercept sends user to SP-B, including an indicator to redirect 
the user to the $flowExecutionUrl (i.e. back to the IdP to continue 
processing)
SP-B sends user and SAMLRequest to IdP (as a new request separate from 
SP-A; the Spring framework keeps them logically separate)
IdP user login (probably SSO will kick in here so the user won't need to 
retype passsword etc.)
IdP sends user with SAML response to SP-B's ACS URL
SP-B accepts SAML response and "does its thing"
SP-B redirects user to $flowExecutionUrl (i.e. back to IdP to continue 
SP-A flow)
Flow intercept resumes, verifies SP-B processing has occured*, and sends 
user with SAML response to SP-A's ACS URL
SP-A accepts SAML response and sets up session for user or whatever it 
would normally do

There are two big gotchas lurking here.  First, SP-B needs to be set up 
to allow the redirect back to the IdP based on a URL submitted to it.  
If not carefully controlled, this can be abused by Bad People.  It 
implies that you have a certain degree of control/leverage over SP-B.

Second, in order to ensure that SP-B actually handles the request and 
the user doesn't just click the back button, it needs to have a way to 
communicate to the IdP that it was actually invoked successfully.  I've 
modeled this roughly on how we handle "expired" passwords - users can 
still authenticate, but the IdP only allows auth to the SP that handles 
password changes (corresponding to SP-B) to actually complete; other SPs 
are trapped by an intercept that puts them in a "Go change your 
password" view.  After the user changes their password, the password 
change SP clears the expired password flag in LDAP, so when the user is 
returned to the SP-A flow, the intercept re-reads LDAP and confirms that 
the password is no longer expired, thus allowing the user to proceed to 
SP-A.

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%