alternate attribute names

[Greg Haverkamp]

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

> I found this an interesting thread. I have several times followed exactly
> the tack suggested by Nate
> (encode a specially constructed attribute with name and friendlyName to
> meet special requirements of an SP).
> So it's interesting a little concerning to read Marvin's recommendation
> for what seems a more convoluted method
> using activation conditions. Marvin or others, could you elaborate on why
> this is a superior approach?
>

We don't do consent, so I'm not sure where those wins are.  For me, the
huge win is not having to worry about filtering.  Before I shifted to using
the activation conditions, I'd create the entirely new attribute, with an
entirely new attribute ID, and then I'd have to go write add to a filter
policy to release that attribute.  But if some vendor comes along and wants
uid released as an attribute named "username" instead of
"urn:oid:0.9.2342.19200300.100.1.1", I can do that just in the resolver, in
an existing attribute definition, without a bunch of copied boilerplate in
two files.

I have some idea bubbling around in my head based on what Martin wrote, but
I probably shouldn't speculate too much.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180628/290e8856/attachment.html>