Cardinus SAML2 integration

Mark Cairney Mark.Cairney at
Fri Nov 15 07:49:05 EST 2019

Hi Peter,

Thanks for your detailed response. It broadly matches what I suspected.

I didn't know about the REFEDS lookup tool, good to know.

Kind regards,


On 15/11/2019 11:09, Peter Schober wrote:
> * 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">
>     <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
>     <NameIDFormat>urn:oid:</NameIDFormat>
>     <AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location=""/>
>   </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/ --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:
> 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
> scratch.
> -peter


Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: Mark.Cairney at
PGP: 0x435A9621


The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

More information about the users mailing list