ldap attributes

[John Morrison]

On Thu, 2016-09-01 at 18:08 +0200, Peter Schober wrote:
> * John Morrison <john.morrison at uadm.uu.se> [2016-09-01 16:55]:
> > I have a ldap data connector that returns subclass attributes with
> > semi-colon;lang-sv and lang-eng.
> > 
> > data Connector 'myLDAPpeople': produced the following 12 attributes
> > during resolution [registeredAddress, registeredAddress;lang-sv,
> > telephoneNumber, postalAddress;lang-en, postalAddress,
> > postalAddress;lang-sv, registeredAddress;lang-en, title;lang-en, mobile,
> > title, title;lang-sv
> > 
> > How can I pass these values onto the SP?
> 
> The values are not the issue (AFAIU), but what to name those
> attributes on the wire, and how: At least with URI naming you'd not
> use "postalAddress" as the attribute name, but urn:oid:2.5.4.16 (for
> example, reusing the RFC4519 definition of that attribute type).
> Which poses the question of how to keep the attribute options intact:
> That's not generally a solved problem, IMO. SAML/XML can provide the
> structure for data that's not just flat strings (cf. NameID elements,
> for example), but software support for that on the recieving end is
> generally lacking/non-existant (cf. scoped attributes with the
> separate Scope XML-attribute with a SAML AttributeValue element).
> 
> So stuffing them into separate attributes (i.e., separate attribute
> names/URIs) would be one option
> (e.g. https://uu.se/attrs/postalAddress#sv
> vs. https://uu.se/attrs/postalAddress#en etc.). Giving up on the
> attribute options and using the same urn:oid for postalAddress another
> (i.e., creating a multi-valued attribute where each value corresponds
> to one attribute option, but not easily programmically determinable by
> the recipient).
> 
> So your options will mostly be limited by the recipients' software,
> willingness and ability to access whatever you manage to put into the
> SAML.
> -peter


Big thanks Peter!


//John