metadata-driven attribute definition

[Joshua Dachman]

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.

The idea is to add something to the SP metadata to signal which LDAP
attribute is the source of which SAML assertion attribute.

This could be done by adding to the RequestedAttribute element, e.g.
something like

<md:RequestedAttribute Name="emailAddress" Source="mail" />

Or through creating a new extension attribute like

<saml:Attribute Name="
http://shibboleth.net/ns/profiles/AttributeEncoder/mail"
    NameFormat="urn:oasis:names:tc:SAML:2.0:attr-name-format:uri">
    <saml:AttributeValue
xsi:type="xsd:string">emailAddress</samlAttributeValue>
</saml:Attribute>

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?

Thanks,
Joshua Dachman

On Sun, Jul 14, 2019 at 8:28 AM Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Joshua Dachman <jdachman at gmail.com> [2019-07-14 06:46]:
> > I would like to have a block in the sp metadata that does the same
> > thing (defines a mapping between the LDAP attribute name and the
> > name of the attribute that will be sent in the SAML assertion /
> > response).
>
> I don't follow. The attribute names in metadata should be abstract in
> the sense that they're not software-, system-, or deployment specific.
> They're unique and standardised to enable interoperability.
>
> Therefore any "mapping" only happens when and where those standard
> attribute names need to be connected to locally available/meaningful
> data sources and data structures.
>
> I.e., the on-the-wire and in-metadata attribute names are abstractions
> from concrete data structures so that your (or mine) internal mess
> stays internal.
>
> Also, what's possible to express in SAML 2.0 Metadata is detailed in
> its specification. Which is the short answer, I guess. (Feel free to
> invent your own extension, though.)
>
> -peter
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> 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/20190714/d762c540/attachment.html>