IDP3/4 migration and attribute resolver configuration

[Peter Schober]

* spf via users <users at shibboleth.net> [2022-09-29 17:03]:
> Even if it's not easy to find recent configuration examples, I also found sources suggesting:

Some of those are just wrong ("mail" is not a proper attribute name;
attribute names should be URIs and MUST be URIs when the nameFormat
says they're URIs.)

And the differences not only depend on the version of the software
used but also what (more modern) features one may have migrated to
using, here specifically the (optional) Attribute Registry, which is
what allows to remove any Attribute Encoder elements from your
Attribute Definitions -- IFF your system is properly prepared for
that. Which yours won't be after upgrading from v3 -- which is fine.

>    When I checked with "aacli", I get a different output from IDP3 and IDP4.   IDP3_LEGACY:   {
> "name": "mail",
> "values": [
> "StringAttributeValue{value=test.user at my.domain}" ]
> },    IDP_3.4.9 (with any of the last two syntaxes):   {
> "name": "mail",
> "values": [
> "StringAttributeValue{value=test.user at my.domain}" ]
> },   IDP4 (with any of the last two syntaxes) : {
> "name": "mail",
> "values": [
> "test.user at my.domain"
> ]
> },

FWIW, if you only have to care about or are interested in the actual
SAML wire representation you'd use the aacli with the --saml2 option.

> Do I take a risk if I choose the less verbose syntax (without any
> AttributeEncoder)

You don't take that risk. Migrating to the new Attribute Registry is
something you can do later (if ever), once the software has been
upgraded and everything continues to work without any SPs noticing any
changes.

-peter