Ipsilon attribute mapping and filtering

A SAML assertion can contain one or more attributes. These are basically pieces of information about the authenticated user. It is important to remember that they are only provided when the user logs in. So, for example, if a user logs in, then you change their e-mail address, the SAML assertion will reflect the original value until that user logs out and back in again.

Ipsilon provides two ways to control what attributes are sent in an assertion and what those attributes are named. This is called attribute mapping and allowed attributes.

Ipsilon supports two levels of mapping and attribute visibility:

  • global level configuration
  • per-SP configuration

These are not additive. If an SP provides its own mapping or list of allowed attributes then that overrides the global setting. It is, though, possible to mix one or the other. So you can have a global mapping and a SP-specific set of allowed attributes.

Info Plugins

It all begins with Info plugins. These retrieve the attributes from the identity source and the available attributes depend entirely on the capabilities of the info plugin. The nss plugin, for example, is limited to those things in <tt>/etc/passwd</tt>. The ldap plugin on the other hand can retrieve any attribute from LDAP.

The list of attributes available from theĀ  SSSD info plugin is configured differently than other info plugins because root is required to manage the SSSD configuration file (<tt>/etc/sssd/sssd.conf</tt>).

The list of attributes is controlled by two variables: ldap_user_extra_attrs and user_attributes. ldap_user_extra_attrs tells sssd what extra attributes to request when it gets a user over LDAP (like in the IPA case). user_attributes controls what extra attributes are available over the SSSD info pipe (D-bus). See sssd-ldap(5) and sssd-ifp(5) for more details.

By default SSSD is configured to retrieve: mail, street, locality, postalCode, telephoneNumber, givenname and surname (sn).

Mapping and Filtering

Mapping allows you to rename an info variable to match the needs of your environment. For example, the user’s e-mail address is defined as mail by Ipsilon but your application may require it to be email. This can be managed via mapping.

Note that mapping an attribute does not remove the original. So if you were to create a mapping from mail -> email you would end up with the following attributes on the SP:

  • MELLON_MAIL=tuser@example.com
  • MELLON_EMAIL=tuser@example.com
  • MELLON_MAIL_0=tuser@example.com
  • MELLON_EMAIL_0=tuser@example.com

To remove the mail version you would need to use the Allowed Attributes setting to select only those attributes you want sent in the assertion.

The current filtering is a bit limited, providing only a white list of attributes. You can specify all attributes (*) or provide a discrete list of the attributes you want. You cannot specify negative attributes (e.g. all but mail) or a regular expression.

Leave a Reply