Cardinus SAML2 integration

[Peter Schober]

* Mark Cairney <Mark.Cairney at ed.ac.uk> [2019-11-15 11:38]:
> "We do not supply Metadata files however, the below is all the details
> generally used when setting up IDP initiated SSO.
> 
> End point URL: https://online.cardinus.com/SSO/SAML2/*********
> Relying Party Identifier: *******
> Relay State / Target App: Healthy working
> EntityID: ********
> UidIdentifier: NameID

OK. No idea what "Relying Party Identifier" should be other than their
entityID, but then you also list an "EntityID" item above?

> How do I proceed from here? Is it a case of hand-crafting a stub
> metadata file and praying to the SAML gods that it works?

The former. Instead of the latter you just post here.
https://wiki.shibboleth.net/confluence/display/CONCEPT/MetadataForSP

That will end up being rather mininaml, something like:

<EntityDescriptor entityID="THE-SPs-ENTITYID" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
  <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
    <NameIDFormat>urn:oid:1.3.6.1.4.1.5923.1.1.1.6</NameIDFormat>
    <AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://online.cardinus.com/SSO/SAML2/..."/>
  </SPSSODescriptor>
</EntityDescriptor>

The SP wanting to use a NameID (instead of attributes) as identifier
is not a surprise given most commercial or on-off SAML
implementations. Neither is the fact that they don't call out a NameID
*format* they expect from you. So maybe just send them a persistent
NameID (if that matches the deployment and you have those available)
or try sending them an attribute of your chosing (the example above
assumes you've set up your saml-nameid.xml to generate a NameID
version of the ePPN attribute).

Test all this with the aacli using the --saml2 parameter, so you'll
also see the NameIDs (not) being generated:

$ /opt/shibboleth-idp/bin/aacli.sh --saml2 -n SOME-USERID -r THE-SPs-ENTITYID

Since they don't shared a public key or X.509 certificate with you
that means you'll have to disable encryption for the SP, too, via one
of the many means the IDP offers for that, including listing the SP in
your relying-party.xml in the RelyingPartyOverrides that disable
encryption:
<bean parent="SAML2.SSO" p:encryptAssertions="false" />

> I've checked and they don't appear to be in our Federation metadata.

Pro tip, though doesn't yield anything in this case:
https://met.refeds.org/met/search_service/?entityid=cardinus.com

Always also check the REFEDS Metadata Explorer https://met.refeds.org/
as often another federation will have registered a service so you'll
find more complete metadata to start from than building it from
scratch.

-peter