Cardinus SAML2 integration

[Mark Cairney]

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,

Mark

On 15/11/2019 11:09, Peter Schober wrote:
> * 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
> 

-- 
/****************************

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

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

*******************************/

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