alternate attribute names

[Greg Haverkamp]

On Thu, Jun 28, 2018 at 11:44 AM Marvin Addison <marvin.addison at gmail.com>
wrote:

> On Mon, Jun 18, 2018 at 5:51 PM Greg Haverkamp <gahaverkamp at lbl.gov>
> wrote:
>
>> I haven't decided if it's better or worse, but I've lately started using
>>> activation conditions for these requests.
>>>
>>
> We've tried many solutions and I'm comfortable saying that activation
> conditions are the way to go for one-off attribute names. We're seeing an
> uptick in the number of integrations that require specific (and in many
> cases non-standard) attribute names, and activation conditions allow us to
> focus on these quirks by adding additional attribute encoders that are
> toggled with an activation condition as your example demonstrates. If
> you're doing consent or other flows that work on attribute sets, you'll
> appreciate the benefit of this approach even more.
>

Well, I'll have to admit much of the reason that I questioned the value of
them is because I apparently can't read.  I viewed the conditions as a
"service", and I've been operating under the impression that any time I
added a new predicate, I had to restart the IdP, because there was no
reloadable service.  But just now, I re-read the ReloadableServices page,
and realized that those beans get loaded by the services themselves, and so
now I feel stupid.  (With local sessions, I can gracefully restart the IdP,
but it takes a while, as I wait for the load balancer's sticky sessions to
eventually drain everyone who's mid-login to switch.  And so I made the
last user of an integrated application wait 2 or 3 days for me to
restart...)

So, the only reason I saw a completely new attribute as a potentially
better approach was because I could reload the service.

Greg



> Marvin at Virginia Tech
>
> --
> 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/20180628/b7122198/attachment.html>