0
votes

we are using Azure ACS with MVC4 and successfully authenticate our Relying Party (RP) via our Identity Provider (IP). Then, I must access the same IP via an existing interface that has no knowledge of ACS: it requires the original SSO token provided to ACS during the protocol handshake.

When I Fiddle the scenario, I see precisely this SSO-token being sent to our RP several times during the initial phases of the authentication handshake with ACS, but when I access the Thread.CurrentPrincipal.Identity after login in my MVC Controller, there is no trace of the original SSO-token anywhere in my request context, even if I set ACS to preserve all bootsrapTokens. The ACS has replaced the initial tokens with FedAuth cookies. I'm too late :-)

So it looks like I'll need to access one of the early phases of the WS-Federation pipeline (WSFAM or SAM) to extract the original IP sso-token from the request headers and preserve it for later.

Can anyone give us a hint of how to best access the appropriat early phases of the ACS handshake in our MVC4 server?

Many thanks! R

1

1 Answers

0
votes

OK, I got to the bottom of this by setting up an MVC-client (RP) to use WIF-WS-Federation without Azure-ACS. At that point, I noticed that there were several claims name-spaces being transmitted in the claims package. It was all there: ACS was doing a nice job of filtering all but the standard name-spaces out for me. So, after the namespaces and claim tags were known, I went back to the ACS management portal and simply configured them into the input and output rules and then they were passed on through to my RPs.