Cardinus SAML2 integration
Mark.Cairney at ed.ac.uk
Fri Nov 15 07:49:05 EST 2019
Thanks for your detailed response. It broadly matches what I suspected.
I didn't know about the REFEDS lookup tool, good to know.
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.
> 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="https://online.cardinus.com/SSO/SAML2/..."/>
> 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
> <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 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
ITI Enterprise Services
University of Edinburgh
Tel: 0131 650 6565
Email: Mark.Cairney at ed.ac.uk
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
More information about the users