[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [imi] Token profile issue with AppliesTo and AudienceRestriction
So the parameters on the RST MAY be returned on the RSTR (which means that the STS may have not honored the RST), so I don’t see anything in the IMI profile that would profile this allowed behavior, so right now an STS could override anything that is in the RST and still be within bounds, the RSTR should be checked to see if what is requested is what is returned. You can have the case where the entity requested a Kerberos Token for Application X and sends the RST over to the STS and the STS knows the policy (Application X MEX Endpoint) from Application X and Application X does not support Kerberos only UNP so does the STS fail the request or return a UPN token and allow the entity to continue From: John Bradley [mailto:jbradley@mac.com] Tony, I think that is reasonable. However with cards we have introduced another expectation. If the selector cant count on the STS respecting what it has put in the card it has given to the user, then the ability of the selector to act as a privacy tool is compromised. I can see WS-Fed giving the selector more latitude. The question is should the IMI profiles constrain that by saying if the issuer puts RequireAppliesto in the card and it receives it in the RST it MUST respect the request. To be fair because of some feedback from Vittorio the ICAM profile in Sec 3.5 is specific about what the STS MUST do when it receives WSP:AppliesTo. What is perhaps underspecified is restricting the STS from sending claims that are requested, we had that in openID but thought it was unnecessary for IMI. We also made the assumption the STS would always return the token type from the request. I can't do anything about WS-Fed, so unless the IMI profiles specify the STS behaviour, it will need to be clarified in the ICAM profile. Are there other things that the STS might override the selector on? John B. On 2009-12-16, at 12:33 PM, Anthony Nadalin wrote: Not sure what a well behaved STS really is, as you can take the case where an entity requests a token with a life span of 100 days, but the STS policy is max life span at 50 day, does the STS fault and return nothing or return a RSTR with a token that has a life span of 50 days? WS-Trust was made flexible to abide by policy that can be used to guide the RST and RSTR. From: John Bradley [mailto:jbradley@mac.com] So if a Issuer gives a user a SAML 1.1 auditing mode card and the selector properly sends the RequiresAppliesTo, it would be OK for the STS to ignore that and perhaps send a different token type than requested eg SAML 2.0 with no audience restriction? I can see the server ignoring a token type in the RST if it doesn't support that token type and the user agent is broken. Completely disregarding the meta-data from the card seems a touch excessive. It probably makes more sense in the WS-Fed case. The ICAM profile assumes the STS is well behaved, and attempted not to duplicate the spec itself. If the specs don't require the STS to honour the RST then we will need to revisit the IMI profile, unless the SAML 1.1 profile covers it. John B. On 2009-12-15, at 9:53 PM, Anthony Nadalin wrote: The STS (WS-Trust) is under the model that the Server Makes Right, just because the RST has it there is ZERO guarantee that the RSTR will reflect any of the RST From: John Bradley [mailto:jbradley@mac.com] The wsp:AppliesTo element in the RST is set by the user agent based on the card. The issuer has three choices 11.7 The Issuer has complete control over everything but the optional case. I think if the issuer has issued a Auditing or Auditing optional card they MUST honour the ic:RequireAppliesTo in the RST. If that is not a requirement of the SAML 1.1 tokens I will need to revisit the ICAM profile. We would need to make it a requirement if it is not covered in the IMI spec. We say the card must have the ic:RequireAppliesTo, I don't think we called out that the STS must honour it. If the RP issues unscoped tokens it shouldn't issue cards that say they support scoped tokens. John B. On 2009-12-15, at 3:13 PM, Mike Jones wrote: The SAML 2.0 token profile currently says: If the request contains a <wsp:AppliesTo> element, then a <saml:AudienceRestriction> containing a <saml:Audience> element MUST be included with the value of that element. As part of the review of the draft SAML 1.1 token profile, Arun Nanda commented: “This is overkill IMO. If an IdP is an open IdP that issues ‘unscoped’ tokens for consumption by any RP, it should not be forced to encode an audience in the issued token just because the request included it. So, may be SHOULD is preferred here…” I tend to agree with Arun. I think we should make this change. That’s the language I’m using in the 1.1 profile. After discussion, I’ll file an issue about this too. -- Mike |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]