Ex: Re: new idp 4 Attribute Registry

[Paul B. Henson]

> From: Cantor, Scott
> Sent: Thursday, April 23, 2020 2:56 PM
> 
> I have 2 that I have encountered in 15 years that didn't simply fix it or admit
> they were lying about the requirement to start with. One was Slack and the

One of our current ones is Adobe, SAML authentication for their creative cloud. I tried passing in the standard attributes and it did not work 8-/. I was told to make it work. Arguing with the vendor for a few weeks unfortunately would not be interpreted by management as "making it work". The other one that I recall at the moment is Rapid7, a vulnerability scanning/analysis tool. It also did not work with the standard attributes. Interestingly, I believe both of these use Okta as their SP. I don't know if this issue is endemic to Otka or just the way these particular vendors decided to configure it... The goofy names do show up in their documentation quite frequently:

https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-Slack.html

> I have never had one that insisted in a specific FriendlyName.

Well, AFAICT both Adobe and Rapid7 did not work when passed the standard SAML names/friendly names, but did work with the standard name and a goofy friendly name.

> Not creating them is more efficient. There's a ton of work being done in
> comparison, relatively speaking. The condition check is basically a string
> compare after several more string compares to fetch the SP name. And that
> doesn't take into account the bloat on every single message to every single
> client every other time.

I'm not releasing them to every SP? There are still release policies in place that limit the goofy attributes, despite being created, from actually being sent to anything except the SP's that need them. But I will look at putting in activation conditions while I'm revamping the configuration during our upgrade, thanks...