Releasing mail as scoped sAMAccoutName for a specific SP

Wed Jun 16 15:17:44 UTC 2021

Hi Peter,

Thanks for the prompt and detailed reply. I was only given the task late last week and the deadline was yesterday and so as my fudge seems to work I stuck with it. I certainly like the idea of "in a simpler to use/understand/maintain way" that you suggested, so I will look at testing that in dev and if I still get the same result then push that to production.

Thanks
Nilan
________________________________
From: users <users-bounces at shibboleth.net> on behalf of Peter Schober <peter.schober at univie.ac.at>
Sent: 15 June 2021 15:56
To: users at shibboleth.net <users at shibboleth.net>
Subject: Re: Releasing mail as scoped sAMAccoutName for a specific SP

CAUTION: This e-mail originated outside the University of Southampton.

* 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsp.idoxgroup.com%2Fshibboleth&data=04%7C01%7Cn.morjaria-patel%40soton.ac.uk%7Cba4680713f6740b8dcbc08d9300dd49a%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637593658278820121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tfAFrCvOx3GEnycxZnfj7DtBbSSlLGv3DetEuHvcNQw%3D&reserved=0" />
  </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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsp.idoxgroup.com%2Fshibboleth&data=04%7C01%7Cn.morjaria-patel%40soton.ac.uk%7Cba4680713f6740b8dcbc08d9300dd49a%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637593658278830076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=imWN3YnJiBN%2FOJZVN2TDB2ttVZ9CSzWERGHqjKA4OuY%3D&reserved=0">

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
--
For Consortium Member technical support, see https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=04%7C01%7Cn.morjaria-patel%40soton.ac.uk%7Cba4680713f6740b8dcbc08d9300dd49a%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637593658278830076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nlo08TqaunK%2FpYjWliRUzqjSgO7CuqecUM72XNVrL%2Fo%3D&reserved=0
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210616/4e1516b7/attachment.htm>