alternate attribute names

[Marvin Addison]

On Thu, Jun 28, 2018 at 3:30 PM IAM David Bantz <dabantz at alaska.edu> wrote:

> Marvin or others, could you elaborate on why this is a superior approach?
>

Scott said it's a matter of style, and I suppose that's true to some
extent, but the real driver for us is policy. I would characterize Virginia
Tech as very conservative with data handling and as such we have a lot of
policy around attribute release. Consent is one policy aspect, but
approvals and documentation are equally if not more important. Since I'm
not a bookkeeper I need as few policy enforcement points as possible, and
minimizing the number of attributes and defining named bundles have been
two strategies we've adopted to keep things simple. Our clients request a
couple bundles, and we release them with signals in the metadata (entity
attributes). That keeps my hands out of the configuration as much as
possible. Yay!

I have learned to be very strict about attribute bundles, which precludes
adding or subtracting from them in order to meet the unique requirements of
poorly implemented SAML in some SPs. Our workaround is to add encoders to
existing attribute definitions and enable/disable via activation
conditions. That keeps our policy points invariant under the wonky demands
of the integrations we get with what seems like increasing regularity.

Best,
Marvin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180712/fd2450c5/attachment.html>