Configuring Slack to use Shibboleth

[David Langenberg]

We have slack + shib working (IdPv3):

relying-party.xml

<bean id="slack" parent="RelyingPartyByName"
            c:relyingPartyIds="#{{'https://uchicago-psd.slack.com'
         }}">
            <property name="profileConfigurations">
                <list>
                    <bean id="b7" parent="SAML2.SSO"
                            p:postAuthenticationFlows="context-check" <!-- this is uchicago-specific nothing to do with slack ignore -->
                            p:encryptAssertions="false"
                            p:includeAttributeStatement="true"
                            p:signAssertions="true"
                            p:proxyCount="0"
                            p:assertionLifetime="PT1M"
                            p:encryptNameIDs="false"
                            p:nameIDFormatPrecedence="#{{'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'}}"
                            p:signResponses="true" />
                </list>
            </property>
        </bean>

saml-nameid.xml:

       <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
            p:attributeSourceIds="#{ { 'uid' } }" />


You need to create & release a User.Email attribute.
attribute-resolver.xml:

 <resolver:AttributeDefinition id="User.Email" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
        <resolver:Dependency ref="scriptedEmail"/>


        <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                   name="User.Email" friendlyName="mail"/>
    </resolver:AttributeDefinition>

attribute-filter.xml:

<afp:AttributeFilterPolicy id="Slack.com">
    <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://uchicago-psd.slack.com" />
    <afp:AttributeRule attributeID="User.Email">
        <afp:PermitValueRule xsi:type="basic:ANY" />
    </afp:AttributeRule>
    <afp:AttributeRule attributeID="uid">
        <afp:PermitValueRule xsi:type="basic:ANY" />
    </afp:AttributeRule>
    <afp:AttributeRule attributeID="givenName">
        <afp:PermitValueRule xsi:type="basic:ANY" />
    </afp:AttributeRule>
    <afp:AttributeRule attributeID="sn">
        <afp:PermitValueRule xsi:type="basic:ANY" />
    </afp:AttributeRule>
    <afp:AttributeRule attributeID="eduPersonTargetedId"> <!-- probably don't need this -->
        <afp:PermitValueRule xsi:type="basic:ANY" />
    </afp:AttributeRule>
</afp:AttributeFilterPolicy>

--
David Langenberg
Identity & Access Management Architect
University of Chicago


On April 29, 2016 at 10:15:01 AM, Matt Brennan (brennanma at gmail.com<mailto:brennanma at gmail.com>) wrote:

Did you guys get this to work? I'm trying to set it up, but every time I hit "Save" it authenticates me through the IdP and brings me back to the default chat room. I can't seem to find any log messages (on either side) that actually give a hint what's going on.

-Matt

On Thu, Apr 14, 2016 at 5:37 PM, Nate Klingenstein <ndk at sudonym.me<mailto:ndk at sudonym.me>> wrote:
> They provide documentation for their custom SAML process here:
> https://get.slack.help/hc/en-us/articles/205168057

I was just reviewing this last night.  Beyond the typical custom implementation stuff, one thing that jumped out at me is the Required for both:

<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="TEAMDOMAIN.slack.com<http://TEAMDOMAIN.slack.com>" SPNameQualifier="https://slack.com/">Your Unique Identifier</saml:NameID>

and

<saml:Attribute Name="User.Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
 <saml:AttributeValue xsi:type="xs:anyType">testuser at youremail.com<mailto:testuser at youremail.com>
 </saml:AttributeValue>
 </saml:Attribute>

I haven’t played with it to see what happens if one, the other, neither, both, or a changed value gets sent.  It’s my next step, so if anyone knows anything, it would be helpful.

My hope is that they just use the persistentId as an identifier and email as email.  I have lots of hope in life, though.
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

--
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/20160429/153a0be3/attachment-0001.html>