How to "harden" SimpleSAMLphp for use in a production environment?

[Peter Wolfenden]

Folks,

My employer is looking to support SSO for its SAS platform, and my job
requires me to compare the effort & expense required to use the
SimpleSAMLphp in "SP mode" vs. the effort & expense required to use a
commercial offering (like PingFederate) instead.

I've played a bit with the SimpleSAMLphp 1.8 distribution, and am
convinced that I could make it work with my employer's SAS platform.
But now I'm starting to think about what it would take to use it
responsibly in a production environment, and the following two
questions occur to me:

1) How best to "harden" the SimpleSAMLphp distribution for use in
production?

For example, I notice that the SimpleSAMLphp distribution appears to
expose many pieces of functionality (including the ACS URL, the Admin
UI, and the authentication workflow script) via the module.php script,
e.g.:

/simplesaml/module.php/core/authenticate.php?as=default-sp

The ACS URL *must* be exposed to the Big, Bad, Internet in order for
the SAML 2.0 SSO login process to work. But the Admin UI should *not*
be exposed in production. And the only way I see to protect it is by
hardcoding a cleartext password for it in a configuration file.

I would rather not give any would-be hackers an opportunity to try
to crack the admin password for a SimpleSAMLphp instance which has
been deployed in production.

And yet I don't see any way to "expose" the ACS URL without also
exposing the Admin UI. Is this by design, or another case where I need
to RTFM?

2) What process is used to check the SimpleSAMLphp distribution (and a
given installation/configuration) for security holes?

Note that I'm not talking about farfetched scenarios here (like
someone cracking or stealing the secret key for an IdP). It's simply
that in order to use the SimpleSAMLphp distribution on a Service
Provider I need to expose at least the ACS URL to the Big, Bad,
Internet, which means that "responsible" technology usage requires me
to do some sort of security audit of the code which delivers the new
endpoint.

So naturally I'd like avoid duplication of effort if someone has
already done such an audit. And if an official/format audit process
exists for SimpleSAMLphp then I'd like to be aware of it in case at
some point I decide to propose patches for SimpleSAMLphp.

Thanks in advance for your help,

Peter Wolfenden

[Olav Morken]

It is not really documented anywhere, but such hardening can often
easily be done in the webserver configuration. E.g. in Apache, you
should look at the use of <Location>-directives in combination with
the �Allow from ...� and �Deny from� directives.

> 2) What process is used to check the SimpleSAMLphp distribution (and a
> given installation/configuration) for security holes?
>
> Note that I'm not talking about farfetched scenarios here (like
> someone cracking or stealing the secret key for an IdP). It's simply
> that in order to use the SimpleSAMLphp distribution on a Service
> Provider I need to expose at least the ACS URL to the Big, Bad,
> Internet, which means that "responsible" technology usage requires me
> to do some sort of security audit of the code which delivers the new
> endpoint.
>
> So naturally I'd like avoid duplication of effort if someone has
> already done such an audit. And if an official/format audit process
> exists for SimpleSAMLphp then I'd like to be aware of it in case at
> some point I decide to propose patches for SimpleSAMLphp.

I am not aware of anyone having performed a formal audit of SSP.

Best regards,
Olav Morken
UNINETT / Feide