Releasing mail as scoped sAMAccoutName for a specific SP

[Peter Schober]

* Nilan Morjaria-Patel <N.Morjaria-Patel at soton.ac.uk> [2021-06-15 16:18]:
> I did attempt to do that with the output of aacli being
> 
>  "name": "mailFromSAMAccountName",
>     "values": [
>         "ScopedStringAttributeValue{value=nmp1u14, scope=soton.ac.uk}"
>     ]
> 
> however the sp could not pick up the scope for some reason.

That's not quite what I suggested (I literally meant not defining an
attribute only for this weird combo) but looks OK, I think.
(It's much more obvious if you supply the --saml2 parameter to your
aacli command invocation as that'll give you the actual SAML.)

> So I resorted to using a script

I meant something like this, assuming below you're populating the
eduPersonPrincipalName attribute from sAMAccoutName + @ + scope and
that you already have a Simple attribute for sAMAccoutName defined.

I.e., the (assumed) deviation is only in adding one extra Encoder that
names this attribute differently (mail) for the referenced SP only:

  <AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" scope="%{idp.scope}">
    <InputAttributeDefinition ref="sAMAccoutName" />
    <AttributeEncoder xsi:type="SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonPrincipalName" encodeType="false" />
    <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" encodeType="false" />
    <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" relyingParties="https://sp.idoxgroup.com/shibboleth" />
  </AttributeDefinition>

The details differ depending on how your existing config looks like
and how much you've cleaned your resolver from AttributeEncoder
elements (i.e., whether you've updated from v3 or migrated to using
the new-with-v4 attribute registry), etc.

>     <AttributeDefinition id="mailFromSAMAccountName" xsi:type="ScriptedAttribute" relyingParties="https://sp.idoxgroup.com/shibboleth">

FWIW, I don't think the relyingParties XML-attribute will do anything
useful on the AttributeDefinition XML-element. (It belongs on the
Encoder you want to make specific for those relyingParties, as shown
above and in The Fine Documentation.)

> Not sure if this is the "best" way but it works.

I'd be surprised if your two methods produced different output when
using aacli with the --saml2 parameter. (I.e., the wire representation
should be the same, I'd expect) in which case your change is possibly
not what made it work.

The changes you made from my suggestion are:

* create a specific attribute when you possibly could have re-used an
  existing defintion and simply made the nameing of the attribute
  SP-specific

* used a Script where the appropriate AttributeDefintion should do the
  same, in a simpler to use/understand/maintain way

* releasing your now custom attribute to that SP (instead of ePPN, in
  my example), therefore not noticing that the relyingParties
  restriction you misplaced didn't actually do anything useful.

HTH,
-peter