<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">I keep talking to admins at our campus, and the consensus is that vendors are actually getting worse as time goes on. If they wanted SAML integration they would download the Shibboleth SP and modify their code to read it.</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">Now vendors are implementing SAML their own way integrated in their application, and the short of it is, We keep having to do off the wall stuff that doesn't fit well with our current Shibboleth configuration philosophy.</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">This seems to be the opposite of what I would expect. Integrating used to actually be easier since Vendors would "rush" to support SAML and grabbed the easiest thing to allow that.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><font face="monospace, monospace">Jeffrey E. Crawford<br>Enterprise Service Team<a href="mailto:jeffreyc@ucsc.edu" target="_blank"></a></font><div><font face="monospace, monospace"> ^ ^</font></div><div><font face="monospace, monospace"> / \ ^ / \ ^</font></div><div><font face="monospace, monospace"> / \/ \ / \ / \</font></div><div><font face="monospace, monospace"> / \/ \/ \</font></div><div><font face="monospace, monospace">/ \</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">You have been assigned this mountain to prove to others that it *can* be moved.</font></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jan 12, 2018 at 4:12 PM, Michael Brogan <span dir="ltr"><<a href="mailto:mbrogan@uw.edu" target="_blank">mbrogan@uw.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Upon re-reading the information from Slack (<a href="https://get.slack.help/hc/en-us/articles/205168057" rel="noreferrer" target="_blank">https://get.slack.help/hc/en-<wbr>us/articles/205168057</a>), it is the attribute Name, not the attribute FriendlyName they want customized.<br>
<br>
For Name="urn:oid:0.9.2342.<wbr>19200300.100.1.3" Slack wants Name="User.Email" [required]<br>
<br>
For Name="urn:oid:0.9.2342.<wbr>19200300.100.1.1" Slack wants Name="User.Username" [optional]<br>
<br>
For Name="urn:oid:2.5.4.42" Slack wants Name="first_name" [optional]<br>
<br>
For Name="urn:oid:2.5.4.4" Slack wants Name="last_name" [optional]<br>
<br>
Just wanted to correct my mistake before this gets committed to the archives...<br>
<span class="HOEnZb"><font color="#888888"><br>
--Michael<br>
</font></span><span class="im HOEnZb"><br>
-----Original Message-----<br>
From: Michael Brogan<br>
Sent: Friday, January 12, 2018 2:45 PM<br>
To: Shib Users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>><br>
</span><span class="im HOEnZb">Subject: RE: Mail attribute for Slack<br>
<br>
Thanks all for the responses. I guess we're stuck with creating non-standard attributes, like everyone else.<br>
<br>
--Michael<br>
<br>
-----Original Message-----<br>
From: users [mailto:<a href="mailto:users-bounces@shibboleth.net">users-bounces@<wbr>shibboleth.net</a>] On Behalf Of Cantor, Scott<br>
Sent: Friday, January 12, 2018 10:20 AM<br>
To: Shib Users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>><br>
Subject: Re: Mail attribute for Slack<br>
<br>
</span><div class="HOEnZb"><div class="h5">On 1/12/18, 1:07 PM, "users on behalf of Jim Fox" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:fox@washington.edu">fox@washington.edu</a>> wrote:<br>
<br>
> I think Michael was wondering if the InCommon membership could<br>
> sometimes stand united against this sort of thing.<br>
<br>
I think Net+ was the only/obvious real vehicle for that within InCommon and they refused to given even that any teeth.<br>
<br>
I think we at least have the advantage, whether it's through InCommon or just this list, to at least share knowledge of vendors engaging in such mistakes, so that we know about it (e.g., I could tell my boss if/when it ever comes up that I can't support Slack because their implementation is not compliant) and perhaps head off purchasing decisions.<br>
<br>
But that's about it. We just don't operate together enough to exert leverage.<br>
<br>
(And no, for the record, the Shibboleth Project isn't paying them, we don't use their commercial version.)<br>
<br>
-- Scott<br>
<br>
<br>
--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</div></div></blockquote></div><br></div>