<div dir="ltr">Yes, this would be a custom extension. This is a situation where the IDP has control over the SP metadata so the "mess" will be kept internal.<br><br>The idea is to add something to the SP metadata to signal which LDAP attribute is the source of which SAML assertion attribute.<br><br>This could be done by adding to the RequestedAttribute element, e.g. something like<br><br><md:RequestedAttribute Name="emailAddress" Source="mail" /><br><br>Or through creating a new extension attribute like<br><br><saml:Attribute Name="<a href="http://shibboleth.net/ns/profiles/AttributeEncoder/mail">http://shibboleth.net/ns/profiles/AttributeEncoder/mail</a>"<br>    NameFormat="urn:oasis:names:tc:SAML:2.0:attr-name-format:uri"><br>    <saml:AttributeValue xsi:type="xsd:string">emailAddress</samlAttributeValue><br></saml:Attribute><br><br>Can one of the above or something similar be wired up in Shibboleth? Or would custom development work be needed? And either way, how would you recommend going about that?<br><br>Thanks,<br>Joshua Dachman</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 14, 2019 at 8:28 AM Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Joshua Dachman <<a href="mailto:jdachman@gmail.com" target="_blank">jdachman@gmail.com</a>> [2019-07-14 06:46]:<br>
> I would like to have a block in the sp metadata that does the same<br>
> thing (defines a mapping between the LDAP attribute name and the<br>
> name of the attribute that will be sent in the SAML assertion /<br>
> response).<br>
<br>
I don't follow. The attribute names in metadata should be abstract in<br>
the sense that they're not software-, system-, or deployment specific.<br>
They're unique and standardised to enable interoperability.<br>
<br>
Therefore any "mapping" only happens when and where those standard<br>
attribute names need to be connected to locally available/meaningful<br>
data sources and data structures.<br>
<br>
I.e., the on-the-wire and in-metadata attribute names are abstractions<br>
from concrete data structures so that your (or mine) internal mess<br>
stays internal.<br>
<br>
Also, what's possible to express in SAML 2.0 Metadata is detailed in<br>
its specification. Which is the short answer, I guess. (Feel free to<br>
invent your own extension, though.)<br>
<br>
-peter<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>