44

I'm trying to create something like: Client authenticates and gets token from custom STS1, next client authorizes with machine key and is issued token on custom STS2 and gets another token. With last token, client requests methods on RP service.

All services are hosted on IIS and are using active federation scenario. Both STS's have endpoints with ws2007Federation and ws2007Http bindings, and RP use ws2007FederationBinding with STS2 as an issuer.

If I create channel with CreateChannelWithIssuedToken I can see only token from STS1 and can't get token from STS2.

So I decided to pass token from STS1 as ActAs RST's property on request to STS2 token. And that failed - cannot decrypt token.

  1. How can I pass both tokens to STS2 and merge up claims in them?
  2. Is it a bad idea - to send with RST just extracted claims from STS1 token?
curls
  • 382
  • 1
  • 3
  • 16
myrx
  • 451
  • 3
  • 7
  • 1
    What you probably need is, that STS2 trusts STS1 for authentication and your app trusts STS2 – TGlatzer Jun 09 '15 at 06:56
  • 1
    @TGlatzer yes, both STSs trust each other, but accept tokens with different audience's uri. STS1 creates tokens only with claims about user, STS2 accepts token with machine key and must provide claims for user+machine. RP service trust only STS2 – myrx Jun 09 '15 at 07:46
  • Where exactly do you get the "cannot decrypt token" error message - on the client or on STS2? – Adrian Hofman Jul 06 '15 at 01:46
  • What are the STS's in your scenario (e.g., ADFS 2.0?) – Adrian Hofman Jul 06 '15 at 01:48
  • @AdrianHofman "cannot decrypt" throws on STS2 and i've realized why. I passed token with actingas extension with setting the same property, but wstrust doesn't write references with token in request, so handlers cannot validate token without referenced keys (token was genericxml with references). For 2nd question - no i don't use adfs or acs, but I want to create something like kerberos logic only with custom services. Both STSs are custom and for now I realized scenario 2 from my question but still don't like this solution, because I think it isn't secure pass parameters/claims in header... – myrx Jul 06 '15 at 05:44

1 Answers1

1

Generally you will only want to utilize one token at each step. So if you need to merge up claims, you will want to do that at the claims transformation step of the second STS.

So the flow would be authenticate with STS1, then authenticate with STS2 with the token from STS1. At that point you would pass through the claims and transform to add additional claims as needed. Then the resulting Token would be ready to consume from the RP application.

I have actually started a blog series about a really similar scenario that we recently architected. Not to be overly self promoting, but it doesn't make me any money, so I'll post it in case it is helpful.

http://www.livingthearchitecture.com/mixing-sso-with-existing-technologies/

I would be glad to go more in depth, but depending on the specifics of your scenario, the specifics of the solution will change greatly. I think the above expresses the general approach you will want. Let me know if I can help any more.

Tim
  • 2,878
  • 1
  • 14
  • 19
  • thanks for answer. Actually i want to keep both tokens - token1 from IdS (STS1) required to get token2 from STS2 and lives until session ends. btw token2 can be generated multiple times with different claims in the session lifetime until token1 is valid Yes, STS2 transforms token1, but i still don'k know how to pass additional lcaims/properties with token1 without breaking security principles because additional parameters aren't encrypted/signed with certificate as a generated token body. – myrx Sep 24 '15 at 05:26