Cardinus SAML2 integration

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Cardinus SAML2 integration

Mark Cairney
Hi,

It's a bit of a long shot but has anyone ever set up Shibboleth to
interoperate with Cardinus (www.cardinus.com)?

We've been asked to however we've been told that they only support
IdP-initiated SSO.
At this point my reaction was "OK, a bit weird but not the end of the
world" so we've asked for their metadata and they've responded saying
they don't supply metadata files:

"
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


(I've censored out some of the values).

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?

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

Kind regards,
Mark
--
/****************************

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: [hidden email]
PGP: 0x435A9621

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

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Cardinus SAML2 integration

Peter Schober
* Mark Cairney <[hidden email]> [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
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> [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: [hidden email]
PGP: 0x435A9621

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

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]