Cherwell application (on-prem)

[Garmer, Jack - garmercj]

I wanted to follow up on this because we were able to resolve this issue between the code Peter posted, some digging in the Shib wiki and good ole' fashioned trial and error.

As stated previously, in our environment, we use an on-prem version of the Cherwell ITSM tool. The product resides on a Windows server and the SAML configuration is handled entirely through a GUI. The GUI spits out SP metadata which we consume locally on our IdP server. I assume Cherwell does some kind of checking to the SP metadata on its end because ANY modification I've attempted to make on the SP metadata resulted in a failed authentication. This is a total guess, we haven't been able to get any clarity from Cherwell directly on the deeper functions of the SP other than to say manual configs outside of the GUI aren't supported. That said, the Cherwell SP wants to be passed an attribute in either e-mail format, which doesn't work for us because we use two different domains, or Kerberos format. Passing any other format or modifying the SP metadata to accept another fomat results in the standard SAML nameID failed error.

The documentation we had to work with for the IdP side is the following (we've notified them their documentation is out of date):
https://cherwellsupport.com/WebHelp/en/9.0/content/mapps_and_integrations/csm_intergrations/configure_csm_with_shibboleth.html

As I am still green in the world of Shib, it took a bit to recognize the suggested configuration is written for version (<?)2.x. Longer still to figure out how to translate the 2.x config to 3.x. While I'm well aware that the answer is TECHNICALLY in the Cherwell documentation and we could TECHNICALLY run legacy code on Shib IdP, I'm also aware this is bad practice, the 2.x method is deprecated,  and I'm not interested in fixing it again when IdP 4.0 rolls out.

What eventually solved it was a modified version of Peter's code added to the saml-nameid.xml:

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
    p:omitQualifiers="true"
    p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos"
    p:attributeSourceIds="#{ {<userId attribute>} }" >
            <property name="activationCondition">
                <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidates="#{{<EntityID>}}" />
            </property>
</bean>

Replace <userIdAttribute> with whatever attribute you use to the common user identifier for AD/OUD. In our case, we only wanted to pass the 'garmercj' not 'DOMAIN\garmercj' or 'garmercj at domain.edu'.

No additional configurations were necessary to the other config files outside of the norm for adding a new SP. More importantly, we did not need to modify OUR metadata as suggested in the Cherwell documentation. LDAP was already configured. The cn attribute is all Cherwell needs as it is also connected to our ldap environment and will handle authorization. We were primarily placing Cherwell behind Shibboleth for the purposed of giving the users a consistent login interface and ease of MFA configuration.

It sounds like there are others who have tried putting Cherwell behind Shib and threw their hands up in the air. I hope this helps the next group down the line!

--
Jack Garmer
Linux Systems Administrator
James Madison University
o. 540-568-4235