ldap attributes

Peter Schober peter.schober at univie.ac.at
Thu Sep 1 12:08:22 EDT 2016


* 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


More information about the users mailing list