Where do I configure these attributes AuthnRequestsSigned and WantAssertionsSigned

[Lennart Nordgreen]

Hi,

I need to set these attributes to true and need to be listed in my metadata file.

                'AuthnRequestsSigned' => true,
                'WantAssertionsSigned' => true,

In which file do I add them and how?

I tried adding them to the authsources.php like above but didn't work.

Br,
Lennart

[Peter Schober]

* Lennart Nordgreen <gree...@gmail.com> [2014-07-03 17:28]:

For the first one did you try setting sign.authnrequest, as indicated
in https://simplesamlphp.org/docs/stable/saml:sp ?
Maybe that will also generate the XML attribute in auto-generated XML
metadata, I don't know.
I don't think there's anything to do the latter via auto-generated
XML.

Which leaves adding it to your SP's metadata yourself and serving that
instead.
-peter

[Lennart Nordgreen]

Thanks for reply mate.

I need it like this:

<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true"protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

Doesn't simpleSAMLphp need that metadata of its own (to read or generate on the fly) in its own environment.
Take Shibboleht e.g. there I can specify all these options and attribute directly in a metadata file but where do I do that in
simpleSAMlphp?  Do I add it in this file saml20-sp-remote.php? Which overseeds the authsources.php generated metadata?

The thing is, you'd like the IDp to be able to fetch the metadata from your SP without us having to modify it all the time,
like in Shibboleth.

Br,
Lennart

[Lennart Nordgreen]

I've tried these options in the authsources.

               'redirect.sign' => TRUE,
               'redirect.validate' => TRUE,
               'assertion.encryption' => TRUE,
               'sign.authnrequest' => TRUE,
               'AuthnRequestsSigned' => TRUE,
               'WantAssertionsSigned' => TRUE

On Thursday, July 3, 2014 5:27:53 PM UTC+2, Lennart Nordgreen wrote:

[Peter Schober]

* Lennart Nordgreen <gree...@gmail.com> [2014-07-04 10:22]:

> I need it like this:
> <SPSSODescriptor AuthnRequestsSigned="true"
> WantAssertionsSigned="true"protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

I know. I just said that I don't think this is currently possible, so
you'd just serve up a file with that content yourself.

> Doesn't simpleSAMLphp need that metadata of its own (to read or
> generate on the fly) in its own environment.

Not sure about the use of these elements. saml2int.org for example
mandates the signing of assertions anyway, so many deployments will do
that whether you put WantAssertionsSigned in your SP's metadata or
not.

You didn't follow up on whether configuriung your SSP SP to sign
authnRequests did produce the AuthnRequestsSigned element in metadata,
but I doubt it will.

> Take Shibboleht e.g. there I can specify all these options and
> attribute directly in a metadata file

That's only true for the Shibboleth IDP, which has a handler (by
default in /idp/Metadata/SAML, assumung "idp" is the context you've
deployed your IDP) which serves up a static XML file from the file
system. So it does /exactly/ what I suggested you do yourself with
SimpleSAMLphp.
I.e. if the Shib IDP does what you want you'll need to do the same
with SimpleSAMLphp.

For the Shibboleth SP that simply isn't the case. The Shib SP des not
give you a metadata file you edit and which it will serve it (which,
again, is semi-pointless as you can serve up a metadata file yourself
from the webserver), it will autogenerate SAML metadata at (by
default) /Shibboleth.sso/Metadata, based on its internal
configuration. And that also includes a big warning at the very
beginning of that resource, telling you NOT to use this metadata as
is.

> but where do I do that in simpleSAMlphp?

I told you what I would do (provided I knew I absolutely needed those
elements to be present, of course). Maybe others on this list will
know more.

> The thing is, you'd like the IDp to be able to fetch the metadata
> from your SP without us having to modify it all the time

Do you sign that SAML metadata and was the IDP willing and able to
configura that one signing key specifically to verify signatures on
that one SP's SAML metadata? If not that's all security theater, for
the most part (serving up unsigned plain text files over the internet
to bootsrtap technical trust in cryptographic credentials and protocol
endpoints).
So no, you usually don't point the IDP to your metadata endpoint to
dynamically pull metadata from there, as that would allow others at
any point in the future to sneak in metadata of their own (MITM, etc.)
and the IDP would have no way of noticing.

Also, metadata doesn't change "all the time" in common deployments but
maybe you're requirements are different.

So you still have several options:

0. Find out whether (not) adding those attributes to your metadata
actually causes the IDP to behave differently (doubtful IMHO).

1. Add the missing functionality to SimpleSAMLphp, with new config
options or tied to existing ones (like the one I previously pointed
out, causing the SP to actually sign authnRequests)

2. Point the metadata consumers to a resouces (script) that you
control and in that script fetch and modify your own metadata in
the fly. That way automatically generated metadata will always be
up-to-date and you can still add/modify whatever you want to that.
Doing that in XSLT would be rather simple, for example.
Of course if you're signing the metadata with the SAML
implementation you can't do that as changing the metadata after the
fact would invalidate the signature. You'd need to do the signing
in your script then, after your modifications.


> like in Shibboleth.

Not really. (For the IDP yes, but that's just a static XML file on
disk. For the SP no, it doesn't give you a metadata file you can just
modify and it will serve it up).
-peter

[Lennart Nordgreen]

In Shibboleth you put your specific XML attributes in /etc/shibbolet/metadata.xml (served as a template in next file) and
you put SP settings with certifcate files, entity ID etc. in /etc/shibboleth/shibboleth2.xml.

And when you got to the Shibboleth.sso/Metadata both files are combined in to one Metadata file (containg the public keay) which
you give to the IDp.

I might go for Shibboleth instead in this case.

Thanks for your feedback Peter.

Cheers!

Br,
Lennart

On Thursday, July 3, 2014 5:27:53 PM UTC+2, Lennart Nordgreen wrote:

[Peter Schober]

* Lennart Nordgreen <gree...@gmail.com> [2014-07-04 14:42]:

> In Shibboleth you put your specific XML attributes in
> /etc/shibbolet/metadata.xml (served as a template in next file)

OK, you're referring to the 'template' attribute on the Metadata
handler. I'm not aware of anyone needing to use this, ever.
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPHandler#NativeSPHandler-Attributes

> I might go for Shibboleth instead in this case.

You can certainly do this but I find the reason for that you're
presenting here to be rather rediculous. There are many more and much
more drastic differences between deploying and configuring
SimpleSAMLphp vs. Shibboleth.
But Hooray for choice and Free Software! :)
-peter