IP-STS JWT exchange token for ACS JWT token

Question

I have an azure ACS service that trusts IP-STS.
For the active scenario, I first get the JWT token from my IP-STS using the username and password. There is an Oauth2 endpoint, and everything works very well. Can I exchange this IP-STS token with a JWT token issued by my azure ACS? If yes, then there is an example code that does this. (To make things worse, all my code is in JavaScript (actually TypeScript), but that doesn't really matter).

Update: I am working on your tooltip with the endpoint of the ACS OAuth2 project.
I do the following: I ask my custom STS (ThinkTecture STS) to give me a JWT token for the "ACS OAuth2 draft 13 endpoint" area. This requires the oAuth client identifier and secret, which are global in TT STS, and I assume they are irrelevant. In the TT STS control, I have a symmetric key configured for this area: key1. I get a three-point JWT token. The token signature is indeed made with the key1. Then I pass this token to ACS with client ID and secret service identifier and parameters specified

var form = new FormUrlEncodedContent(new Dictionary<string, string> { { "grant_type", "http://oauth.net/grant_type/jwt/1.0/bearer" }, { "assertion", rawtoken (the header dot body dot signature form TT STS }, { "scope", "http://localhost"} }); 

Unfortunately, now I get {"error": "invalid_client", "error_description": "ACS50027: JWT token is not valid. \ R \ nTrace ID: b107cda5-393b-4b50-b14a-ebaa0ac41913 \ r \ nTimestamp: 2012-12- 05 08:58: 10Z "}

I understand that the JWT is in beta, and therefore the ACS50027 is not yet documented. The hard part is that there is no known way to debug this. Thanks for the help.

Answer 1

Well, I finally found a way to do this. Your hint was critical to success. The (very) tricky part is that IP-STS uses a symmetric key to sign the JWT token. I had to programmatically (using odata api) insert this key into the back-office ACS under the Identity provider. (the management console does not show this key anywhere). Everything is almost normal. The only problem is that ACS is copying the audience ("aud") from the source token, and I am requesting a token for another audience ("scope"). Any ideas?

Answer 2

It is definitely possible, but I don’t think that none of the existing ACS samples does this, so you are a little uncharted.

The approach I would recommend is to use the endpoint of the ACS OAuth2 draft 13 project (as in this example , but instead of JWT instead of SAML and IdP service identity). The query will look something like this:

grant_type = http://oauth.net/grant_type/jwt/1.0/bearer& assertion = (JWT) & scope = (RP scope).

You will need a JWT issuer to match the registered credential provider, as well as the associated signature key, as well as the rules for transferring or changing any requirements as necessary, and RP for a JWT token.

Answer 3

Nope, you cannot exchange tokens in ACS. The only possible way to do this is if you can register your IP-STS as IdP in ACS (you can do this if your IP-STS supports WS-TRUST). This will throw you into a passive scenario.

The only possible way for the active scenario is to get the JWT token directly from ACS using Username / Password authentication using service identifiers . The required service identifiers in ACS do not manage the ASP.NET membership provider this way, but it does have a management API .

Possible authentication methods with a service identifier are password, symmetric key, X.509 certificate. So, if you just twist your original IP-STS enough to provide you with a symmetric key as an application in its JWT token, you can get the JWT token from ACS using Service Identity authentication with this symmetric key.

But if you already have a JWT token, why do you need another from ACS?

UPDATE

Well, complaint conversions are only an option in Passive mode. For the active mode, the only way (which I know) is to use service identifiers, thus, no claim transformations.

The problem with passive is that, for security reasons, ACS will create a hidden POST form so that POST passes the converted token to your Relying Party (RP) application. Thus, there is no way to actively get passive behavior. What you could only do for the sake of testing, and this will fail due to passive POST in a hidden form, is as follows: If you are willing to experiment (and I have not tested, and I absolutely do not know the result), you can try to simulate an action wsignin1.0 providing the original JWT token. You can view the WS-Federation Member Passive Request Profile , section 3.1 on how to create a login request. You can also use Fiddler to fully track the chain of events with a passive script. The one you are trying to recover is the wsignin1.0 request, which goes from the registered IdP back to ACS.

At some point, you will have the HTML code that contains the FORM element. This form will have two hidden fields - wa with the value wsignin1.0 and wresult , which will contain the URL <t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">.... This is what you want.

If you can recreate the original SignIn request in ACS from your IdP, this will work.