Active federation using WSTrustClient across realms with ActAs

Question

I have a scenario with a browser and web server (passive) in a one organization. The web application then needs to call a service in another organization using the end users credentials (active federation with ActAs).

Can someone point me to documentation of the call flow to the two STS's and to a good and up-to-date sample that
- shows the active part of this scenario
- uses a full-control do-it-yourself approach with the WSTrustClient and not the automagical ws2007FederationBinding
- uses ADFS v2 as STS and not a self-made STS with configuration in code or certificate validation in code

---

m_

Answer 1

Have you looked at the SDK for the IDentity Delegation sample?
Windows Identity Foundation SDK\v3.5\Samples\End-to-end\Identity Delegation
Also Samples\Extensibility\WSTrustChannel has some related active client information.

Answer 2

Thanks Rakesh. I looked at these samples. They are usefull, but unfortunately doesn't cover all the bullets described above. Seems like the ActAs feature across two domains is not supported (http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/6d955d5a-14ca-44b6-8070-cd7955ec3ad9/#18aaca4b-9ec2-451e-92bc-ee9ca5d0850d). Maybe that's why I have such a hard time finding a sample for that...

---

m_

Answer 3

ADFS does not support consuming an ActAs token that was issued by a different provider.

A custom WIF STS does not have such a limitation.

Does this blog post help? http://blogs.msdn.com/card/archive/2009/11/19/using-wif-on-a-wcf-client.aspx

Answer 4

Hi Shiung, can you elaborate on the why this is not supported in ADFS? Did you run into any issues that I should be aware of in case I decide to go down the custom WIF STS route?

For a scenario like the one described below, do you think that the customers STS can be ADFS v2 and the ISV/service provider STS can be a custom WIF STS?

• An ISV/service provider builds the core of an application as WCF services only - no UI. The service provider needs to get claims about of each customer and of each end-user on the customer side, but don't want to manage any user accounts. The service provider STS trust the customers STS.
• Each customer builds their own web front-end that accepts token from the customers STS. The customers web front-end calls the service providers services acting as the end user.

---

m_

Answer 5

The biggest drawback of going custom is that you lose all the features of ADFS. I do not know why it is not supported, but you should file a Connect bug if such a scenario is critical for you moving forward. That is one way to get the product team's attention and such feedback is always considered for future planning.

To ensure I understand your scenario, let me restate it.

1. ADFS v2 as the customer STS: this means ADFS v2 is the first STS that a browser would hit in order to authenticate to a web front end in the customer's domain.

2. Web front end will, as you describe, attempt to obtain another token from a WIF custom STS with ActAs = ADFS-issued token.

Such a scenario is certainly possible and fully supported by WIF.

Answer 6

Thanks. Yes, the restated scenario sounds right. We are currently evaluating alternatives (supporting token, custom STS, custom WCF headers (no claims), having the web application getting a token on behalf of the client using Kerberos S4U etc). I'll add "connect bug" to the list of options. Thanks again!

---

m_