Building a composite attribute from sets of attributes

[Etienne Dysli Metref]

On 06/08/2019 17.06, Cantor, Scott wrote:
> Either way, if you really want JSON, just deal with it as a string
> value. Build a scripted attribute that pulls in everything else and
> cooks up the JSON you want to pass out as a single string value.

We have an internal attribute like this already that builds a list of
affiliations for the affiliation chooser intercept flow to display. At
first, we used a Template attribute definition, but ended up building a
"soft template" in a Scripted attribute to fail more gracefully when
source attributes don't have the same number of values. This is terribly
ugly because it relies on an ordering we have no guarantees over. The
script does this:

  for (i = 0; i < swissEduPersonUniqueID.getValues().size(); i++) {
    var valueParts = [swissEduPersonUniqueID.getValues().get(i),
      swissEduIDAttributeProviderIdentifier.getValues().get(i),
      swissEduPersonHomeOrganization.getValues().get(i),
      swissEduPersonHomeOrganizationType.getValues().get(i)];
    currentAffiliations.addValue(valueParts.join("!"));
  }

Values for the four used attributes are assembled by the resolver from a
LDAP subtree query under ou=affiliations with filter (swissEduID=XXXX).
The corresponding DataConnector also has maxResultSize="0". Where the
LDAP data looks like:

swissEduPersonUniqueID=1234 at uniA.example.org,ou=affiliations,...
  swissEduID: XXXX
  swissEduPersonUniqueID: 1234 at uniA.example.org
  swissEduIDAttributeProviderIdentifier: <uniA's IdP>
  swissEduPersonHomeOrganization: uniA.example.org
  swissEduPersonHomeOrganizationType: university

swissEduPersonUniqueID=5678 at uniB.example.org,ou=affiliations,...
  swissEduID: XXXX
  swissEduPersonUniqueID: 5678 at uniB.example.org
  swissEduIDAttributeProviderIdentifier: <uniB's IdP>
  swissEduPersonHomeOrganization: uniB.example.org
  swissEduPersonHomeOrganizationType: university

Correct me if I'm wrong, but the IdP's resolver groups all found
attribute values without any particular ordering guarantee. Moreover,
LDAP doesn't provide an ordering on returned attribute values. So this
happens to work by chance and we get:

1234 at uniA.example.org!<uniA's IdP>!uniA.example.org!university
5678 at uniB.example.org!<uniB's IdP>!uniB.example.org!university

but it could totally blow up on us and instead produce

1234 at uniA.example.org!<uniB's IdP>!uniB.example.org!university
5678 at uniB.example.org!<uniA's IdP>!uniA.example.org!university

any day... :O

  Etienne

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/dev/attachments/20190807/4a624f5e/attachment.sig>