Release one or the other attribute

[Peter Schober]

* sherrera <sherrera at bradley.edu> [2019-11-05 23:13]:
> You are absolutely correct. It is the same kind of data just a different
> format. Basically this is what we are needing to resolve. We have an SP that
> if you are staff is listening for email of @bradley.edu
> (sherrera at bradley.edu) and if you are a student listening for
> @mail.bradley.edu (sherrera at mail.bradley.edu). A person here is only in one
> or the other, never both. The email attribute in LDAP for staff has
> @fsmail.bradley.edu (sherrera at fsmail.bradley.edu) and for students it is
> correct with @mail.bradley.edu. As a staff person the attribute with the
> correct information is held in eduPersonPrincipalName.

OK. If you get what you need from an existing (though different)
attribute that's easiest, otherwise I'd first have pulled in the staff
email attribute into an intermediate attribute def and massaged the
content with a Mapped attribute into the expected form (s/@fsmail\./@/),
then depend on the intermediate attribute instead, plus the student one.

> Is this what you meant by single attribute pulling both in as a dependancy?
>     <AttributeDefinition xsi:type="Simple" id="crowdStrikeEmail">
>         <InputDataConnector ref="crowdStrikeStaffAccess" attributeNames="eduPersonPrincipalName"/>
>         <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />
>         <InputDataConnector ref="crowdStrikeStudentAccess" attributeNames="mail"/>
>         <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />
>     </AttributeDefinition>

I think you're potentially confusing yourself by the ordering of the
elements. Order the InputDataConnectors and the AttributeEncoder
together and it will become more clear: You'll have two input
dependencies, going into a single internal attribute def, that's
fine. But why the two different encoders?
(I don't know what the above would do, add the attribute as both mail
and eppn attributes?)

The whole idea is to produce a single mail attribute (and provide
recieving systems with a consistent, sane result), no matter where the
data came originally, no?
So I'd drop the ePPN encoder and only leave mail.

If you didn't want to procude just the mail attribute I must have
misread your original post?

-peter