Understanding SimpleSAML_Error_Exception: Neither the assertion nor the response was signed.

1,259 views
Skip to first unread message

Akin

unread,
May 27, 2014, 3:54:53 PM5/27/14
to simple...@googlegroups.com
I'm working on setting up SimpleSAMLphp as a service provider.  I've setup a client's IdP as an authentication source.  However my SP is throwing an exception when handling the IdP response.

SimpleSAML_Error_Error: UNHANDLEDEXCEPTION

Backtrace:
0 /usr/share/simplesamlphp/www/module.php:180 (N/A)
Caused by: SimpleSAML_Error_Exception: Neither the assertion nor the response was signed.
Backtrace:
3 /usr/share/simplesamlphp/modules/saml/lib/Message.php:548 (sspmod_saml_Message::processAssertion)
2 /usr/share/simplesamlphp/modules/saml/lib/Message.php:518 (sspmod_saml_Message::processResponse)
1 /usr/share/simplesamlphp/modules/saml/www/sp/saml2-acs.php:96 (require)
0 /usr/share/simplesamlphp/www/module.php:135 (N/A)
From what I understand of the problem Olav's response from a previous post I quote

There is no <ds:Signature> element at all in this response (neither in 
the <samlp:Response> element nor in the <saml:Assertion> element), so 
we have no way to verify that is issued by the IdP.

It seems like this is an IdP issue since neither of these elements are in the client's IdP response (see attached xml file).

I'm quite new to this so my question is what is the IdP using to sign this assertion?

They have my SP metadata, so I'm not sure if there is anything that I need to configure on my end to enable them to sign the assertion.

Also any documentation to where I can learn more about this specific issue is welcome.

Thanks
idp.response.xml

Peter Schober

unread,
May 28, 2014, 9:43:56 AM5/28/14
to simple...@googlegroups.com
* Akin <akin...@gmail.com> [2014-05-27 21:55]:
> Caused by: SimpleSAML_Error_Exception:
> Neither the assertion nor the response was signed.

That means just that. The IDP did not sign the message.
SSP wants the message to be signed. Only the IDP can fix this.
-peter

Akin

unread,
Jun 4, 2014, 9:29:39 AM6/4/14
to simple...@googlegroups.com, peter....@univie.ac.at
The provider I'm working with said that my SP metadata doesn't state that the signing of assertions is required.

I was looking over the options at https://simplesamlphp.org/docs/stable/saml:sp and 'redirect.sign' and 'redirect.validate' is set to TRUE by default.

What should I be looking for in my SP metadata to see whether it specifies signing of the assertions is a requirement?

Thanks

Peter Schober

unread,
Jun 4, 2014, 9:47:28 AM6/4/14
to simple...@googlegroups.com
* Akin <akin...@gmail.com> [2014-06-04 15:29]:
> The provider I'm working with said that my SP metadata doesn't state
> that the signing of assertions is required.

Not sure how you would create that XML attribute in auto-generated XML
metadata from SimpleSAMLphp (I don't think it's possible), but you
could just add it to the SAML metadata you give to the IDP yourself:
According to the SAML Metadata XSD there's a 'WantAssertionsSigned'
(with "true" or "false" as value) attribute on the SPSSODescriptor
XML element.
That does not seem to be used very often, though, from a quick glance
at some SAML metadata aggregates in the academic world.
-peter

Akin

unread,
Jun 4, 2014, 11:01:01 AM6/4/14
to simple...@googlegroups.com, peter....@univie.ac.at
Thanks for the prompts responses.

I would prefer to distributed auto-generated XML metadata unmodified.  With that being said, is there a way I can turn off the requirement?

Peter Schober

unread,
Jun 4, 2014, 11:51:02 AM6/4/14
to simple...@googlegroups.com
* Akin <akin...@gmail.com> [2014-06-04 17:01]:
> I would prefer to distributed auto-generated XML metadata
> unmodified.

You can always file an RFE and/or hope that someone else implements
that, or better yet, implement the needed change yourself and share it
with the community.

Lacking that, you can workaround that with additional tooling,
e.g. configuring a URL (which you give out as your SAML metadata URL)
on the same (or another) server that fetches metadata from your own
metadata endpoint and XSLT-transforms it and adds the required XML
attribute.

Sounds like more work to me than changing SSP but works without
touching a line of SSP code.

Or copy a (then static) version of your metadata to a webserver, fire
up $EDITOR, add the attribute, and publish that as metadata URL. Rinse
and repeast only if you ever need to change your own metadata.

> With that being said, is there a way I can turn off the requirement?

It's not documented as being configurable (which you can/should check)
I would assume that it's not configurable.

So you could change the code or file an RFE or both. Or hope someone
else does all that for you.
-peter

Jaime Pérez Crespo

unread,
Jun 10, 2014, 5:51:34 AM6/10/14
to simple...@googlegroups.com
Hi,

On 04 Jun 2014, at 17:50 pm, Peter Schober <peter....@univie.ac.at> wrote:
> * Akin <akin...@gmail.com> [2014-06-04 17:01]:
>> With that being said, is there a way I can turn off the requirement?
>
> It's not documented as being configurable (which you can/should check)
> I would assume that it's not configurable.

I’m afraid Peter is right, there’s no support for that in SSP. The only support right now is regarding metadata consumption (parsing metadata that includes the ‘WantsAssertionSigned’ attribute), but not for metadata generation. The main reason is that you can configure SSP in a very flexible way, requiring assertions to be signed on an IdP-basis, for instance, so given that there’s only one URL to retrieve the SP generated metadata, setting the attribute automatically is not possible.

The only way to do so is with an explicit option to add the attribute to the generated metadata. But again, there is only one metadata for an SP, so setting this attribute to true could cause unexpected behaviours from other IdPs automatically consuming it. The changes in the could would probably be trivial, but the side effects are not trivial at all.

> So you could change the code or file an RFE or both. Or hope someone
> else does all that for you.

We are always open to feature requests, and even more to pull requests :-)

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

Reply all
Reply to author
Forward
0 new messages