[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [imi] RE: Proposed claim encoding profile for SAML 1.1 tokens
|
Hi Mike, Can you let us know what the Higgins code does for SAML 1.1.
token encoding of claim types? Thanks, --
Mike From: Mike Jones I completed the investigation about the behavior
Microsoft’s claims implementations using SAML 1.1 tokens. For WCF,
WIF, and AD FS 2.0, as they exist today, only claim types that are URLs that do
not end with a “/”, but do contain a “/” that is not
the last character of the URL, will work. Other claim types will be
rejected. This is not likely to change in our upcoming release. http://foo.com/bar will work. http://foo.com/bar/ will be
rejected. urn:mace:dir:attribute-def:givenName will be rejected. http://bar would probably work, but is
such a chronically bad idea that I don’t even want to think about going
there. Mike (McIntosh), are there similar restrictions in the Higgins
code? What’s your view on the correct way to encode non-URL-valued
claim types?
-- Mike From: John Bradley [mailto:jbradley@mac.com]
The IMI spec specifies the claim URI for p-cards only. Nothing about normalization. I think we should stick with claims must be a exact match
for the selector with no normalization other than ignoring trailing blanks. The STS as it must unfortunately parse the URI needs to have
rules for: 1 no "/" in the URI 2 trailing "/" with empty last path subsegment. 3 URI with a "/" after the authority segment but
no path. Perhaps others I haven't thought of. So how about any URI that ends with an empty path segment
gets encoded as if it were a URN as an assertion with the entire URI in the
attributeName. John B. On 31-Aug-09, at 1:38 PM, Anthony Nadalin wrote: Well not sure that the IMI spec actually points that out (could
not find it), also the IMI spec only deals with personal cards. Many folks end UIRs
with a “/” just go and look at various postings, may not be right
but this stuff happens and ignoring it does no good From: Mike
Jones We made it clear both during the OSIS tests and in the IMI spec
that claim names are to be matched as-is, with no case folding, normalization,
etc. John’s right – trying to “fix things” for
people usually makes things worse. In practice, I’m not aware of any claim URIs that end with
a slash, so I don’t see this as being a big problem. Are any of you
aware of any? (It probably is worth figuring out how to best encode such
claims if they do arise. Suggesting the use of the urn:oasis:names:tc:SAML:2.0:attrname-format:uri convention is one possibility, since
these are not “normal” claim URLs.
-- Mike From: John
Bradley [mailto:jbradley@mac.com] The ida is to keep it consistent
with the p-cards. That is an interesting question.
Do the selectors all recognize the
p-card claims with or without the "/". I know they do without. What the selector matches,
is it normalized? Given that the selector copies the
claims from the RP's policy directly. (this is fudged for the object tag ver) The selector probably shouldn't
modify the requested URI. What should the matching rules be
for a IP/STS? Should both the p-card and IP STS
normalize assertions to remove trailing "/". In some ways my preference is to
not mess with it too much. A claim is an opaque URI (except
for the bit where it isn't) if the RP adds trailing "/" then they
shouldn't match unless the actual claim has a trailing "/". Trying to automatically fix things
for people leads to HTML. John B. On 31-Aug-09, at 12:18 PM, Anthony
Nadalin wrote: Yea it’s those nasty shares that I have to mount hereJ. I
agree with the SAML 1.1 Managed cards, I assumed that this would apply to both
managed and non-managed cards. My point is that we have seen some with the
trailing “/” and some w/o and this needs to be clarified. From: John
Bradley [mailto:jbradley@mac.com] At the moment we have nothing for
SAML 1.1 managed cards. That is an even bigger potential
interoperability issue. This at least gives us something
to discuss. I am guessing that you mean
"/" as a terminating character. This MS gig has really gotten
to you. None of the claims in the ICF
catalog have trailing "/" nor do the p-card claims eg If you are under some different
impression that makes documenting this more important. I would be OK with just
documenting the current behavior based on the p-card STS. We could say the SAML 1.1 profile
only supports http scheme URI that have one or more one path segments. That is basically where we are
anyway. Less code to rewrite for MS. People who need more functionality
should use the SAML 2.0 profile. Fixing IMI SAML 1.1 code to
deal with URNs and other things may not be worth the effort. We do however need something
written down! John B. On 28-Aug-09, at 1:10 PM, Anthony
Nadalin wrote:
I think there are a few problems, as it does not explicitly
state that the “\” at the end is required. Also the language is too
laxed for interoperability, this seems to be caused by the desire to have some
level of co-existence with the SAML 2.0 profile, which may not be the best
thing to do From: Mike
Jones [mailto:Michael.Jones@microsoft.com] I’ve run the attached proposed claim encoding profile for
SAML 1.1 tokens by John and Drummond, as well as Paul Trevithick. I
believe it does what we need (while still being a one-pager). It’s
intended to maximize interoperability. This issue is tracked as IMI-23.
-- Mike |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]