[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [thread on X.500/LDAP attribute values in SAML 2.0 profile]
As background, a thread among some of us on this topic. I'll be posting proposed resolution shortly. - RL "Bob"
--- Begin Message ---
- From: RL 'Bob' Morgan <rlmorgan@washington.edu>
- To: Prateek Mishra <pmishra@netegrity.com>
- Date: Thu, 8 Jul 2004 13:48:39 -0700 (PDT)
I'm not sure who cares about this issue, so I'll start with y'all since I'm still poking at it. As discussed in Toronto (according to the minutes), Prateek's language (I assume it was his), now incorporated into section 9.3 of profiles-draft-12, about attribute values, says that since in the LDAP protocol an attribute value is always syntactically an octet string, that these attribute values, when put into the content of SAML AttributeValue elements, will always use the XML hexbinary primitive type. This is obviously simple, but has the drawback that even LDAP/X.500 attributes whose values are just (UTF-8) strings would have their values encoded in hexbinary. This may not be a showstopper, but it's the sort of thing that makes implementors either get it wrong (I mean, cmon, just send the string) or will cause folks to redefine their LDAP attributes for use in SAML (as we did with eduperson, more or less) so as to avoid the lossage. I observe that DSML 2.0 defines attribute values with: <!-- **** DSML Value **** --> <xsd:simpleType name="DsmlValue"> <xsd:union memberTypes="xsd:string xsd:base64Binary xsd:anyURI"/> </xsd:simpleType> So a value can be a string, or base64Binary (which I suppose I would suggest rather than hexBinary), or a URI. DSML doesn't offer any guidance (that I can see) about how or why an implementation would pick one of these types to use in any particular situation. Presumably the idea was that strings could be sent as strings, and other stuff could be sent as binary (and certs as URIs ...). A lofty goal in this space would be for the semantics of attribute types defined for LDAP/X.500 to be made available as XML schema so use of attributes in XML could be fully schema-supported. This is among the goals of the XED work, http://www.xmled.info/, and many I-Ds: draft-legg-xed-schema-02.txt draft-legg-xed-glue-02.txt draft-legg-xed-rxer-02.txt draft-legg-xed-asd-02.txt draft-legg-xed-protocols-02.txt draft-legg-xed-roadmap-03.txt by Steven Legg et al. The RXER draft in particular covers encoding in XML of ASN.1 objects (especially those used in X.500?), in such as a way as to make the resulting values XML-Schema-compatible (or something like that). This is vast and fine work, but is still work-in-progress, and it's not clear whether the IETF has any interest in standardizing it (hmm, maybe another OASIS TC ...). It would be nice to leave wiggle room to permit the encodings define by this work to be used easily in SAML at some later date. So at the moment I'm interested in seeing whether the DSML approach (minus the URI thing) can be enhanced slightly to make clear when to use strings and when not, in some fashion that wouldn't require several pages of text. But I don't have time to go into it more right now, and I'm headed on a two-day vacation shortly, so let me toss out these ideas for your reaction. Obviously this needs to be wound up quickly if it's to be included in SAML 2.0. - RL "Bob"--- End Message ---
--- Begin Message ---
- From: Scott Cantor <cantor.2@osu.edu>
- To: "'RL 'Bob' Morgan'" <rlmorgan@washington.edu>, "'Prateek Mishra'" <pmishra@netegrity.com>
- Date: Thu, 08 Jul 2004 17:26:55 -0400
> I'm not sure who cares about this issue, so I'll start with > y'all since I'm still poking at it. I'm about to start work on the attribute profiles, so good timing. > I observe that DSML 2.0 defines attribute values with: > > <!-- **** DSML Value **** --> > <xsd:simpleType name="DsmlValue"> > <xsd:union memberTypes="xsd:string xsd:base64Binary > xsd:anyURI"/> > </xsd:simpleType> I think that's generally speaking a reasonable approach following the 80/20 or maybe 90/10 rule. > by Steven Legg et al. The RXER draft in particular covers encoding in XML > of ASN.1 objects (especially those used in X.500?), in such as a way as to > make the resulting values XML-Schema-compatible (or something like that). I'm not sure schema-specified and "expressed in the way most palatable by XML processors and attribute consumers" are the same goal, however. > So at the moment I'm interested in seeing whether the DSML approach (minus > the URI thing) can be enhanced slightly to make clear when to use strings > and when not, in some fashion that wouldn't require several pages of text. I can try and come up with something suitable vague, I guess. -- Scott--- End Message ---
--- Begin Message ---
- From: Scott Cantor <cantor.2@osu.edu>
- To: "'RL 'Bob' Morgan'" <rlmorgan@washington.edu>, "'Prateek Mishra'" <pmishra@netegrity.com>
- Date: Thu, 08 Jul 2004 18:24:11 -0400
I think this language sucks, but it's all I could do on short notice. We can play with it in last call. Since I don't know much about LDAP syntaxes, I can't say for sure how wiggly "easily be expressed" really is. -- Scott "The canonical representation for X.500/LDAP attribute syntaxes is an octet string. However, to simplify the job of the attribute consumer, any X.500/LDAP attribute syntax that can easily be expressed in string form SHOULD be passed as a string, with no additional whitespace. In such cases, the xsi:type XML attribute MUST be set to xsd:string. Examples of such attribute syntaxes are those with string, numeric, or date/time values. Date/time values MUST be expressed in UTC form. Any attribute value (particularly those without a reasonable string form, such as binary data) MAY be passed by base64-encoding the octet string and specifying an xsi:type XML attribute of xsd:base64Binary. The xsi:type XML attribute MUST be present in such cases. As additional standards in the expression of X.500/LDAP attribute syntaxes in XML form develop, this profile may evolve to incorporate such approaches."--- End Message ---
--- Begin Message ---
- From: Jeff Hodges <Jeff.Hodges@Sun.COM>
- To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
- Date: Mon, 12 Jul 2004 22:55:07 -0700
RL 'Bob' Morgan wrote: > I'm not sure who cares about this issue, so I'll start with y'all since > I'm still poking at it. I've done a little bit of research on it too. mucho thanks for putting this all together, and especially for the refs to the xed stuff. fwiw, IMHO, your msg should simply be sent to the sstc list, as should my forthcoming response(s) to Scott's responses. > As discussed in Toronto (according to the minutes), Prateek's language (I > assume it was his), now incorporated into section 9.3 of > profiles-draft-12, about attribute values, says that since in the LDAP > protocol an attribute value is always syntactically an octet string, given careful reading of RFCs 2251 and 2252, that assertion.. "an (LDAP) attribute value is always syntactically an octet string" ..is only sorta correct. > that > these attribute values, when put into the content of SAML AttributeValue > elements, will always use the XML hexbinary primitive type. This is > obviously simple, but has the drawback that even LDAP/X.500 attributes > whose values are just (UTF-8) strings would have their values encoded in > hexbinary. agreed that this is likely a lose. > This may not be a showstopper, but it's the sort of thing that > makes implementors either get it wrong (I mean, cmon, just send the > string) or will cause folks to redefine their LDAP attributes for use in > SAML (as we did with eduperson, more or less) so as to avoid the lossage. hm, AFAICT that should be "..potential for lossage." AFAICT, "hexbinary" should work just fine in the XML/SOAP/HTTP world. It appears from reading of RFC2045 and such that base64 was invented for the (edge) cases where (SMTP) data was handled, and perhaps translated into local charset form and then back to ASCII, by arcane systems whose native string encoding scheme was not ASCII (read: EBCDIC-based systems) and in which conveyance context record lengths were sometimes fixed (can you say "RECL=80"?) Anyway, hexbinary would yield shorter encoded stings than base64binary, and there likely isn't any great difference in xlation performance. If anything I'd think it'd be faster. But, there's perhaps some edge case I'm not seeing here that'd make base64binary work "better" overall? eg shipping SOAP msgs over SMTP? (how many folks are gonna do that?) > I observe that DSML 2.0 defines attribute values with: > > <!-- **** DSML Value **** --> > <xsd:simpleType name="DsmlValue"> > <xsd:union memberTypes="xsd:string xsd:base64Binary > xsd:anyURI"/> > </xsd:simpleType> > > So a value can be a string, or base64Binary (which I suppose I would > suggest rather than hexBinary), or a URI. DSML doesn't offer any guidance > (that I can see) about how or why an implementation would pick one of > these types to use in any particular situation. Presumably the idea was > that strings could be sent as strings, and other stuff could be sent as > binary (and certs as URIs ...). If ya dig thru RFC2251 & 2252, one can conclude that in most cases one'd simply take LDAP attr values that're based entirely on Directory Strings (which indicate's they're UTF-8 encoded) -- one has to unwrap them from their ASN.1 OCTET STRING wrapper first -- and then stuff that directly into the SAML XML-based element at hand, and ship it. For LDAP attr values that have more complex internal structure with non-Directory String(-based) components, or are simply arbitary (binary) blobs (eg "Certificate"), one'd then need to use some form of encoding (eg hexbinary) of the entire LDAP attr value (probably easiest to just encode the entire ASN.1 OCTET STRING-wrapped blob), and stuff that into the SAML XML-based element at hand. I've hacked up a build on Scott's suggested language that I'll send out. HTH, JeffH--- End Message ---
--- Begin Message ---
- From: Jeff Hodges <Jeff.Hodges@Sun.COM>
- To: Scott Cantor <cantor.2@osu.edu>
- Date: Mon, 12 Jul 2004 22:58:02 -0700
Scott Cantor wrote: > I think this language sucks, but it's all I could do on short notice. We can > play with it in last call. Since I don't know much about LDAP syntaxes, I > can't say for sure how wiggly "easily be expressed" really is. I think this is in the correct direction based on my research on this topic, so thanks for hacking it up. I have the following builds on the proposed text. no time right now to include elaborate rationale, altho it is all in the LDAP RFCs, but it is somewhat confusing at first glance (eg very roughly speaking there are several layers of "string"s in the LDAP world that are built on each orther and/or wrap each other). HTH, JeffH > "The canonical representation for X.500/LDAP attribute syntaxes is an octet > string. However, to simplify the job of the attribute consumer, any > X.500/LDAP attribute syntax that can easily be expressed in string form > SHOULD be passed as a string, with no additional whitespace. In such cases, > the xsi:type XML attribute MUST be set to xsd:string. The canonical on-the-wire encoding of X.500/LDAP attribute values, as conveyed via the LDAP protocol [RFC2251], is as ASN.1 OCTET STRINGs. However, X.500/LDAP attribute values are not necessarily stored in LDAP servers in the same form as they are transferred in LDAP protocol, and they also may have arbitarily complex internal structure, as described by their corresponding attribute syntaxes [RFC2252]. Thus, in order to simplify the job of SAML attribute consumers, X.500/LDAP attributes whose LDAP attribute syntax is that of Directory String (OID: 1.3.6.1.4.1.1466.115.121.1.15), or is constructed from a collection of subparts of syntax Directory String, SHOULD be passed in SAML as XML string values, with no additional whitespace. In such cases, the xsi:type XML attribute MUST be set to xsd:string. > Examples of such attribute syntaxes are those with string, numeric, or > date/time values. Date/time values MUST be expressed in UTC form. [the above para is covered, it seems to me, by the language in the above two suggested paragraphs. ie string, numeric, or date/time values in the LDAP world are typically based sytactically on Directory String. so I'd delete that para.] > Any attribute value (particularly those without a reasonable string form, > such as binary data) MAY be passed by base64-encoding the octet string and > specifying an xsi:type XML attribute of xsd:base64Binary. The xsi:type XML > attribute MUST be present in such cases. LDAP Attribute values whose LDAP syntax is either not based entirely on Directory String, and/or are not explicitly noted as a "human readable string" (e.g. "Certificate") [RFC2252] SHOULD be conveyed in SAML by base64-encoding [RFC2045] the encompassing ASN.1 OCTET STRING-encoded LDAP attribute value and specifying an xsi:type XML attribute of xsd:base64Binary. > As additional standards in the expression of X.500/LDAP attribute syntaxes > in XML form develop, this profile may evolve to incorporate such > approaches." [no suggested builds on this para] --- end--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]