SAManage with Shibboleth 3?

[Losen, Stephen C. (scl)]

Hi,

Maybe you need to add WantAssertionsSigned="true" to the SPSSODescriptor element in the SAManage SP metadata file.

The response from the IDP has a Response XML element that encloses the Assertion element.  By default the IDP signs the Response (which includes the Assertion) and does not sign the Assertion. However some SPs expect the Assertion to be signed, so that might explain the error you see.

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
scl at virginia.edu    434-924-0640


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Tom Scavo
Sent: Monday, April 16, 2018 4:04 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: SAManage with Shibboleth 3?

On Mon, Apr 16, 2018 at 2:49 PM, Mark Cairney <Mark.Cairney at ed.ac.uk> wrote:
>
> From the information I've received from the user:
>
> "
> Hello,
> This link would show what visible in your instance's metada:
> https://edin.samanage.com/saml/metadata.  However, as mentioned previously
> we are looking for the token signing certificate to be included in the saml
> request as it would be compared with the certificate you have pasted under
> Setup -> SSO for validity.
> "
>
> Does this make sense to you given they themselves don't provide any
> certificates for signing/encryption (the metadata file they provided is
> literally 4 lines of XML!) and the only certificates I'm aware of that are
> routinely transferred during a SAML conversation are one or more of these?

No, that doesn't make much sense but let me take a stab at it. Did you
in fact paste your IdP signing certificate into their web interface as
they claim? If so, then that's all they should need to verify the
signature on the response but apparently they want/need more. I
suppose you'll need to get to the bottom of that. Why do they need
more than the certificate you pasted into their UI?

> Also at least one piece of the few bits of documentation say to disable
> encryption and signing?

XML security goes both ways and you're getting confused (which is
contributing to the overall confusion). The SP does not have a
certificate in its metadata so the SP does not support outbound
signing nor inbound encryption. You OTOH MUST support outbound signing
so I assume you have a signing certificate in your metadata, right?
That's the same certificate you apparently pasted into their UI. Okay
then, case closed :-)

> I was under the impression that signing/encryption had to be mutually
> declared between both parties?

No, I don't know what you mean. The only thing that's absolutely for
sure is that the IdP signs the response, so you have to provide them
with your trusted signing certificate. That's it. Nothing else is
strictly required in either direction.

Hope this helps,

Tom

> On 16/04/18 17:01, Peter Schober wrote:
>
> * Mark Cairney <Mark.Cairney at ed.ac.uk> [2018-04-16 15:47]:
>
> The docs I've been following are:
> https://community.samanage.com/message/6116
> and
> https://wiki.shibboleth.net/confluence/display/SHIB2/SAManage
>
> From those two I gather that your question actually is:
> How do I release the subject's email address as an emailAddress-format
> NameID in Shibboleth IDPv3?
>
> relying-party.xml:
>      <bean parent="RelyingPartyByName" c:relyingPartyIds="SAManage.com">
>         <property name="profileConfigurations">
>             <list>
>               <bean parent="SAML2.SSO" p:encryptAssertions="never"
> p:signAssertions="always" p:encryptNameIDs="never"
> p:signResponses="always"
> p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
>             </list>
>         </property>
>     </bean>
>
> FYI, you can drop p:nameIDFormatPrecedence from there and instead
> simply add that format as the first (or only) NameIDFormat element to
> the locally-managed SAML metadata you load from
> %{idp.home}/metadata/samanage-metadata.xml
>
> attribute-resolver.xml:
>
> No need to touch the resolver for IDPv3. Instead just add this to your
> conf/saml-nameid.xml (and remove your previous attempts while you#re
> there) to the util:list with id="shibboleth.SAML2NameIDGenerators":
>
>   <!-- email as NameID -->
>   <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>       p:omitQualifiers="true"
>       p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
>       p:attributeSourceIds="#{ {'mail'} }" />
>
> and release the 'mail' attribute to the SP in your
> attribute-filter.xml, as usual.
>
> Done.
>
> -peter
>
>
>
> 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
> users-unsubscribe at shibboleth.net
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net