About Relying Party STSs (a.k.a, what is RequireFederatedIdentityProvisioning?)

re: About Relying Party STSs (a.k.a, what is RequireFederatedIdentityProvisioning?)

kingbing — Tue, 18 Dec 2007 15:21:59 GMT

Wow. Great post, thanks. Between this and Vittorio's post, I'm all sorted on IP and RP STSes.

Unfortunately, it now raises a couple of questions about RequiresFederatedIdentityProvisioning. This is something I'm finding difficult to wrap my head around. I wonder if you there's another post needed just for this subject.

Let me try and talk through what I think happens. If the policy for STS1 states it requires an IssuedToken from STS2, CardSpace (or an alternative WS stack, such as WCF) will retrieve the policy for STS2. If that policy states it needs an IssedToken for STS3, the policy for STS3 is retrieved.

Is RequireFederatedIdentityProvisioning an indication that the WS stack should stop retrieving policies and prompt the user to resolve the current policy? Or is it really an indication that this STS requires a managed card? (Are they the same thing?)

Thinking out loud, I could simply keep resolving policies until I reached an STS policy that no longer required an IssuedToken but a username token, X059 cert or Kerberos ticket. I could then display the identity selector to resolve the current policy, picking a card that matches the current issuer and required claims (if one exists), and getting prompted for username, smart card, etc. And the current STS might well be the self-issued card STS.

Why would I need a policy element to tell me to prompt the user when I can just keep resolving until I hit the last STS?

The only reasons I can think of are:

1. Using an alternative stack, I wouldn't know to display CardSpace, but would prompt the user myself. But then the RequireFederatedIdentityProvisioning becomes DisplayCardSpaceIdentitySelector, which is a little specific...

2. The algorithm relies of a known set of "final", unresolvable tokens (username, x509, etc) Future expansion is made more difficult

3. Picking a different identity earlier in the chain. If I'm trying to log onto my bank, and they give me a managed card backed by a self-issued card, would I want to pick the managed card from my bank, or the self-issued card I'd backed it with? In my simple algorithm, I'd have to select the self-issued card. What happens if I have 2 managed cards? What if both managed cards are backed by the same self-issued card?

I think this last one is the clincher for me. If the bank's STS specifies RequireFederatedIdentityProvisioning, I know that the user has a managed card, and should let them choose which one. If that choice then requires more resolving, I do so after the choice.

Am I anywhere near right?

Sorry for rambling, but this is a subtle topic that I'm finding difficult to properly understand. Plus it's really interesting. Great post, please keep them coming!

Cheers

Matt

PS. The docs for <useManagedPresentation> are a bit poor: "Represents a binding element that specifies that managed presentation to be used. This element has no attribute and is present as an empty switch." Nowhere near as useful as this post...

re: About Relying Party STSs (a.k.a, what is RequireFederatedIdentityProvisioning?)

CardSpaceBlog — Wed, 19 Dec 2007 11:21:21 GMT

Thanks for asking the clarifying questions, I’ll add a new post to try and explain RequireFederatedIdentityProvisioning. To quickly answer some of your questions.

First, you say ‘CardSpace (or an alternative WS stack, such as WCF)’. I understand what you are saying here, but just to be clear, CardSpace is not a WS stack. In the browser case, it contains the logic to follow the policy chain, but it sits upon WCF when it does it, making WCF calls to retrieve policy and make the token requests.

I’d say RequireFederatedIdentityProvisioningis really a hint that the STS that has this element in its policy should be accessed via a pre-provisioned card, and in most cases this means user interaction as well. So the user needs to have a managed card to use the STS (by use I mean get a token from the STS that can be used to auth to another STS or RP).

Say the policy ends by requiring a Kerberos ticket. Even in a WCF scenario, there is no guarantee that CardSpace should be called without the RequireFederatedIdentityProvisioning element being present. It could be that auth is done with no user interaction, in many cases inside an organization this might be desirable. Similarly for username/password and X509 auth, the WCF application could provide a custom UI for collecting credentials, so again, no CardSpace should show.

In all of these cases, when called from the browser and CardSpace follows the chains, it could ignore the elements and behave as you suggest. But there is a nice architectural consistency to have the same behavior in both cases.

Now for the self-issued backed card case, I think the element is critical even in the browser scenario, since it differentiates between the RP STS and IP STS scenario ( I explain this one in more detail in the post when I introduce RequireFederatedIdentityProvisioning)

Yep absolutely want to avoid any reference in the protocol that is CardSpace specific. So DisplayCardSpaceIdentitySelector is out, maybe UseInformationCardIdentitySelector would probably work, but without a major need to rename it probably won’t happen now.

You are right on with your second point, it makes additions in the future easier.

Your point 3 is good to, similar to the one I was making about wanting to be able to have a difference between a RP STS that accepts a self-issued card and an IP STS that accepts a self-issued card.

I very much appreciate the questions. It is subtle, I’ve explained in several times both inside and outside of MS, so really want to get the post to be as helpful as possible.

thanks,

Caleb

re: About Relying Party STSs (a.k.a, what is RequireFederatedIdentityProvisioning?)

Pedro Felix — Thu, 20 Dec 2007 02:29:19 GMT

Hello

This is a very interesting post, dealing with some questions for which I don’t have a clear answer.

First of all, when does the “chase” of the policy chain ends? The specs, namely [1], don’t deal with this issue and I’ve seen different answers to this question, namely:

a) http://blogs.msdn.com/vbertocci/archive/2007/09/24/the-resource-sts-r-sts-rp-sts-a-sts-the-other-face-of-token-issuing.aspx

“When the selector encounters such an element, it will fetch (via WS-MetadataExchange) the policy of the resource STS. If that policy happen to be satisfied by one or more cards (...) owned by the user, the identity selector will pop up”

b) http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1668019&SiteID=1

“The policy traversal ends when either of following is seen:

1. The IssuedToken being asked for has issuer as self (http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self), anonymous, or not specified

2. issuedtoken whose mex address is unavailable or not specified

3. credential being asked for is not a issued-token (like username/X509/Kerberos) in managed card case”

Does the policy chain “chase” stops when exists a card “satisfying” the policy requirements?

Shouldn’t this behavior be *clearly* described in the infocard specs ([1]) for all identity selectors? Or is this an issue that can be handled differently by each identity selector?

Thanks

Pedro

[1] “A Guide to the Identity Selector Interoperability Profile V1.0“, April, 2007

re: About Relying Party STSs (a.k.a, what is RequireFederatedIdentityProvisioning?)

Pedro Felix — Thu, 20 Dec 2007 03:10:23 GMT

Hello again.

I’ve a couple of comments regarding your statement “by choosing to trust the RP site, the user indirectly trusts the services that site chooses to use”

Consider the following scenario:

1) An RP requires a token issued by a third party “age STS” (similar to the one at Identity Lab), containing an “age” claim. However, the organizations running the RP and the “age STS” are not the same.

2) This third party “age STS” requires a token issued from an IP, containing a “DateOfBirth” claim.

3) A user U has a managed token from this IP.

When the CardSpace requests the disclosure authorization from the user U, it presents the following information: the claim is “DateOfBirth” and the requesting site is RP.

However, the trust relation that U has with RP and with “age STS” can be very different.

Namely, consider the scenario where user U “trusts” “age STS” enough to reveal its date of birth but do not “trusts” RP enough to disclosure the same type of information. In this situation, the information presented by the CardSpace UI will be misleading.

In my opinion, this problem arises because the “age STS” is not really a “RP STS”. Instead, its role is of a “third party claim transformer”, which isn’t necessarily the same: a “RP STS” is an RP-side implementation detail (they are inside the same boundary); a “third party claim transformer” cannot be considered an implementation detail and must be explicitly considered on the user’s trust decision.

Am I missing something here?

Thanks

Pedro

re: About Relying Party STSs (a.k.a, what is RequireFederatedIdentityProvisioning?)

CardSpaceBlog — Mon, 07 Jan 2008 20:22:18 GMT

Thanks for the good questions Pedro. I'm just getting back in after the holidays, but will write another post soon to try and address them.

Thanks,

Caleb

CardSpace: Behind The Code : About Relying Party STSs (a.k.a, what is RequireFederatedIdentityProvisioning?)

Weddings — Thu, 05 Jun 2008 18:16:14 GMT

A useful, yet sparsely documented feature of Windows CardSpace is its support for resource side Security Token Services (STSs) &#8211; STSs that are used by relying parties rather than Identity Providers. Vittorio has done an excellent job helping