Pass argument from Identity Provider back to Relying Party after WSFed login

Question

Is there a way to pass a value back to a relying party after login? e.g. on the querystring?

Background:

What we want to do is inform the relying party what action the user took, e.g. sign in or register, so that the relying party can display the appropriate confirmation message to the user. Because the relying party might link to a Sign Up page, but then instead of signing up the user signs in, so the relying party shouldn't display a "thanks for joining us" notification panel.

I tried adding &lastaction=signup to the returnUrl but that gets lost when the form is posted through Azure ACS.

Next attempt was to try to add lastaction to the wreply, like so:

WSFederationMessage message;
WSFederationMessage.TryCreateFromUri(uri, out message);
var signinMessage = wsFederationMessage as SignInRequestMessage;
if (signinMessage != null)
{    
    signinMessage.Reply += "?lastaction=hello";
    ...

In Fiddler I can see that the next POST to ACS posts to https://xxxxx.accesscontrol.windows.net/v2/wsfederation?lastaction=hello But the lastaction is not passed on to my relying party.

Answer 1

We had a related problem: we wanted to let the RP know which authentication methods the user used when signing in. We solved this by creating a new "system" claim with our namespace, and put the information in there.

In our TokenService implementation, in the AddSecurityClaims method:

 claimsIdentity.AddClaim(
            new Claim(
                String.Format("{0}/{1}", WellKnownConfiguration.TokenService.ClaimsNamespace,
                    ClaimsAuthenticationMethods), ((int) userAuthenticationMethods)));

Update You mentioned you thought about using cookies. In that case, I would do the following. I would implement setting a cookie (e.g. when registration page) and then create one more "action" that would return the value of that cookie. When the app gets the POST request with the credentials, you'd perform a redirect (immediately) to that relaying action with a return url. That action would then append the value of the cookie and call the original RP, but a custom action, that would then properly display the view.

Think of it as a cookie proxy. To summarize, the process is as follows:

1. User hits the RP, action requires authentication
2. The RP redirects the user to the STS as per WS-Federation
3. STS issues a token, and also adds a cookie to its own domain
4. RP gets the authenticated user, redirects to STS Cookie Reader
5. STS redirects to RP's second screen that can handle the login properly

All in all, one more hop, but like I said, it's probably fast enough for the user to not notice and/or care.