Freshdesk SSO

[Peter Schober]

* emmar <emmar at ecboces.org> [2019-04-13 15:15]:
> Freshdesk requests a SAML1.1 emailAddress name format.
> I already have a custom nameId referencing the email attribute working with
> Zoom SSO.  So, I thought it would be better to use the same custom nameId
> because I thought I read somewhere that you should not reference the same
> attribute with two different resolvers.  (Please correct me if I am wrong)

No idea what this means. In general you don't (or shouldn't) define
data structures (e.g. Attribute Definitions) specific to any SP: An
email address is an email address.
If different SPs need to recieve that email addresss in different SAML
Attributes then you can add AttributeEncoder elements that have a
'relyingParties' XML attribute to make that encoder specific to the
given SPs listed as that attribute's values.
That's not even the case here, though, as the SPs you mention seem to
require NameIDs, not Attributes.

So if a given SP expects to recieve a subject's email address in an
emailAdress-format NameID you make a NameID of that type available in
your configuration and let the NameID selection process deal with
making sure the right SP gets the right NameID.

Nothing in your config is specific to any SP in this case, and none of
this affects the resolver in any way other than having the email
address available in an attribute definition (e.g. your 'mail' one).

> So, I have added this to the attribute resolver:
>
> <resolver:AttributeDefinition id="zoomLogin" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="mail">
>   <resolver:Dependency ref="siteLDAP"/>
>   <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:email" />
>   <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />

None of this is needed.
Also I think the former NameID format doesn't exist in the spec.
Not sure what having two encoders for the same protocol defined would
actually achieve, but whatever.

> I have uncommented this in the saml-nameid.xml and pointed it to my custom
> nameid:
> 
>   <bean parent="shibboleth.SAML1AttributeSourcedGenerator"
>     p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
>     p:attributeSourceIds="#{ {'zoomLogin'} }" />

Depending on where specifically in saml-nameid.xml you put that that
may or may not work. I'd expect this to only work when using the SAML1
protocol but I don't know.

Personally I'd remove all of the above and put the following within
the <util:list id="shibboleth.SAML2NameIDGenerators"> in your
saml-nameid.xml:

 <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
     p:omitQualifiers="true"
     p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
     p:attributeSourceIds="#{ {'mail'} }" />

That uses your 'mail' attribute defintion (not the 'zoomLogin' one
derived from that, which IMO is mostly broken and unnecessary anyway)
and makes its value available as a NameID of the standard format for
email addresses. 
That's all and would be usable by any SP that expects to recieve this
NameID format.

The documentation explains how the NameID format selection process works:
https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration#NameIDGenerationConfiguration-FormatSelectionFormatSelection

If you manage SAML Metadata for those SPs locally then the easiest way
to set the desired NameID format is to add it as NameIDFormat element
to each SP's SAML Metadata:
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
(e.g. after a SingleLogoutService element or before an
AssertionConsumerService element)

> I have uncommented the following two lines in saml-nameid.properties:
> # Comment out to disable legacy NameID generation via Attribute Resolver
> idp.nameid.saml2.legacyGenerator = shibboleth.LegacySAML2NameIDGenerator
> idp.nameid.saml1.legacyGenerator = shibboleth.LegacySAML1NameIdentifierGenerator

Why?

> Somewhere along the way, I added this to relying-party.xml:
>                     <bean parent="SAML2.SSO"
>                          
> p:includeAttributeStatement="$profileConfig.includeAttributeStatement"
>                          
> p:assertionLifetime="$profileConfig.assertionLifetime"
>                          
> p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:email"
>                         #if ($profileConfig.signResponses == 'conditional')
>                           p:signResponses-ref="SignNoIntegrity"

No reason to do that.

-peter