Cardinus SAML2 integration

Peter Schober peter.schober at
Fri Nov 15 06:09:23 EST 2019

* Mark Cairney <Mark.Cairney at> [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:*********
> 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.

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">
    <AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location=""/>

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/ --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
<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:

Always also check the REFEDS Metadata Explorer
as often another federation will have registered a service so you'll
find more complete metadata to start from than building it from


More information about the users mailing list