simplesamlphp on Tomcat

[Atle Johansen]

Hi

Has anybody succeded in getting simplesamlphp to run on Tomcat (6.0.18)
and PHP (5.2.5) ?
Is there any reason why this should not be possible? Any examples exist?

I realize the configuration would be quite different than the one
described in the docs, but still?

best regards

Atle Johansen

[Miguel Cabeça]

Hi,

> Has anybody succeded in getting simplesamlphp to run on Tomcat
> (6.0.18)
> and PHP (5.2.5) ?
> Is there any reason why this should not be possible? Any examples
> exist?

simpleSAMLphp is a PHP application that doesn't require Tomcat. All it
needs to run is PHP support in the web server of your choice (Apache
for most people)

Tomcat is a container for JAVA applications.

Are you trying to protect a JAVA application runing in tomcat with a
simpleSAMLphp Service Provider (SP) component?

Best Regards
Miguel Cabeça

[Atle Johansen]

Hi again, and thank you for a quick answer.

> simpleSAMLphp is a PHP application that doesn't require Tomcat. All it
> needs to run is PHP support in the web server of your choice (Apache
> for most people)
>

Yes, i am aware that it seems a little strange, and in my pure PHP
projects I am using simplesamlphp with no problems both as a IDp and sn SP.

> Tomcat is a container for JAVA applications.
>

yep ;)

> Are you trying to protect a JAVA application runing in tomcat with a
> simpleSAMLphp Service Provider (SP) component?
>

Yes, I am trying to use simplesamlphp to protect a java (gwt) app that
needs to be able to identify against the same IDp as other "normal" apps.
It would be sweet if I could make the SSO work here too, and users who
have already browsed around on the protected website could
use their same login session...

best regards
Atle Johansen

[Miguel Cabeça]

Hi,

> Yes, I am trying to use simplesamlphp to protect a java (gwt) app that
> needs to be able to identify against the same IDp as other "normal"
> apps.
> It would be sweet if I could make the SSO work here too, and users who
> have already browsed around on the protected website could
> use their same login session...

The solution is Auth MemCookie:

http://rnd.feide.no/content/simplesamlphp-advanced-features#id435304

Miguel Cabeça

[Peter Schober]

* Atle Johansen <at...@aplay.no> [2008-10-23 17:58]:

> Yes, I am trying to use simplesamlphp to protect a java (gwt) app that
> needs to be able to identify against the same IDp as other "normal" apps.
> It would be sweet if I could make the SSO work here too, and users who
> have already browsed around on the protected website could
> use their same login session...

You might also run a Shibboleth2 SP on Apache in front of the Java
Servlet Engine and proxy to that via AJP.
https://spaces.internet2.edu/display/SHIB2/NativeSPJavaInstall
This will work just fine with your simpleSAMLphp IdP.

Or try to get simpleSAMLphp running on PHP5 in Java ;)
http://quercus.caucho.com/
Yes, this is sick. No, I'm not making this up.

It seems to be missing the XML processing and OpenSSL bindings,
though. So this would probably involve quite a bit of rewriting (in
Java ;)

Cheers,
-peter

[Steven_...@brown.edu]

>* Atle Johansen <at...@aplay.no> [2008-10-23 17:58]:
>> Yes, I am trying to use simplesamlphp to protect a java (gwt) app that
>> needs to be able to identify against the same IDp as other "normal" apps.
>> It would be sweet if I could make the SSO work here too, and users who
>> have already browsed around on the protected website could
>> use their same login session...
>
>You might also run a Shibboleth2 SP on Apache in front of the Java
>Servlet Engine and proxy to that via AJP.
>https://spaces.internet2.edu/display/SHIB2/NativeSPJavaInstall
>This will work just fine with your simpleSAMLphp IdP.
>

or you could drop the java SP implementation developed by the Danish
government into your tomcat:

http://www.softwareborsen.dk/blog/nyhedsblog/archive/2008/09/06/the-danish-government-releases-free-toolkits-and-reference-implementations-for-egov-federations-based-on-the-open-saml-2-0-standard

This is built on top of the OpenSAML 2 package developed by the
Shibboleth project.

[Luis Meléndez]

Steven_...@brown.edu escribió:

>> * Atle Johansen <at...@aplay.no> [2008-10-23 17:58]:
>>> Yes, I am trying to use simplesamlphp to protect a java (gwt) app that
>>> needs to be able to identify against the same IDp as other "normal" apps.
>>> It would be sweet if I could make the SSO work here too, and users who
>>> have already browsed around on the protected website could
>>> use their same login session...
>> You might also run a Shibboleth2 SP on Apache in front of the Java
>> Servlet Engine and proxy to that via AJP.
>> https://spaces.internet2.edu/display/SHIB2/NativeSPJavaInstall
>> This will work just fine with your simpleSAMLphp IdP.

You can even use an SSO above the simpleSAMLphp IdP and the Java app.
Examples include CAS and the PAPI system, which we use here. It can
protect Tomcat apps and be used as the authentication layer of
a simpleSAMLphp IdP.

Regards.

--
+----------------------------------------------^-----------------------+
| Luis Meléndez Aganzo ^ Email: lu...@uco.es |
| Servicio de Informática ^ Tlf: 34-(9)57-211022 |
| Analista - Área de Sistemas ^ Fax: 34-(9)57-218116 |
| Universidad de Córdoba (SPAIN) ^ http://www.uco.es |
+----------------------------------------------^-----------------------+

[Peter Schober]

* Luis Meléndez <lu...@uco.es> [2008-10-24 02:31]:

> You can even use an SSO above the simpleSAMLphp IdP and the Java app.
> Examples include CAS and the PAPI system, which we use here. It can
> protect Tomcat apps and be used as the authentication layer of
> a simpleSAMLphp IdP.

The poster seemingly has a SAML ecosystem in place, with a SAML IdP
and SAML SPs. Now why would one introduce yet another completely
different SSO system (and proprietary protocol) just to *integrate* a
tomcat app with his SAML system?

cheers,
-peter

--
peter....@univie.ac.at - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140

[Atle Johansen]

Peter Schober skrev:

> The poster seemingly has a SAML ecosystem in place, with a SAML IdP
> and SAML SPs. Now why would one introduce yet another completely
> different SSO system (and proprietary protocol) just to *integrate* a
> tomcat app with his SAML system?
>
>

Just to report back some progress ...
Totally agree, I don't want to introduce yet another SSO system. I am
working with 2 possible solutions here ...
I am taking the MemCache approach mentioned earlier in this thread, and
it seems promising.
I was also trying to do an implementation directly in my serverside
application using javamellon and the lasso library,
but my Java is a bit rusty, so that might be a job for other parts of
the development team here.

I also had some progress with running simplesamlphp in tomcat by PHP
5.2.5 as servlet to Tomcat 6.0.18.
But in the end I was missing the OpenSSL dependency on this setup, and
the Apache Environment variables
that simplesamlphp uses for alot of things are not available to the
application as php is ran in "console" mode,
so therefore i abandoned this approach, though it might be possible to
get further ...

regards
Atle Johansen

[Andreas Åkre Solberg]

We are working on several options in this scenario. The one that is
working right now is auth_memcookie.

You configure simplesamlphp to store a memcookie in memcache, and then
you install the memcookie apache module. In the apache configuration
you can setup auth memcookie to push attributes as http headers.

News item here:
http://rnd.feide.no/content/simplesamlphp-non-php-environments

Full documentation here:
http://rnd.feide.no/content/simplesamlphp-advanced-features#id435304

If you have some questions or comments, please let us know.

--
Andreas Åkre Solberg
=andreas
http://rnd.feide.no

[Luis Meléndez]

Peter Schober wrote:
> * Luis Meléndez <lu...@uco.es> [2008-10-24 02:31]:
>> You can even use an SSO above the simpleSAMLphp IdP and the Java app.
>> Examples include CAS and the PAPI system, which we use here. It can
>> protect Tomcat apps and be used as the authentication layer of
>> a simpleSAMLphp IdP.
>
> The poster seemingly has a SAML ecosystem in place, with a SAML IdP
> and SAML SPs. Now why would one introduce yet another completely
> different SSO system (and proprietary protocol) just to *integrate* a
> tomcat app with his SAML system?

Well, I was just mentioning another approach so he can decide. Many
sites (like mine) already have deployed a local SSO and integrated the IdP as
another app protected by it.

[Miguel Cabeça]

Hello,

> We are working on several options in this scenario. The one that is
> working right now is auth_memcookie.

I would like to resume all knowledge i've acquired on this subject to
help organize my ideas. At our university, we have a local Web SSO
mechanism based on CAS already deployed and in production for some
years now. We are now in the process of turning to SAML for it's added
benefits (mainly attributes for now, but other federation aspects in
the future).

There is a major difference in protecting resources in CAS and in
simpleSAMLphp or shibboleth.

With CAS we have N client libraries written in N different programming
languages. You choose the library correspondent to your application
programming language and make (hopefully) minor changes to the
application to "CASify" it. In practice the CAS client library
implements the client part of the CAS protocol and is incorporated in
the Application being protected. There is also a mod_auth_cas to
protect static directories in apache.

With simpleSAMLphp or shibboleth there seems to be another approach.
We install a SP on the same host as the application you want to
protect, that handles all aspects of the SAML protocol. Then you
"link" both parties with:

- If the application being protected is written in PHP you can add a
library that interacts with simpleSAML
- If the application is written in any other language you use the
auth_memcookie and environment variables to link both parties.
- If you want to protect a static directory of documents you can use
the previous method

Is this view correct?

If so, I have some questions:

- Is it possible to protect more than one application on the same host
with different attribute requirements?
- Is there any way to configure apache to protect a static directory
based on some attribute (in other words, using other method than
"require valid-user" )

Best Regards

Miguel Cabeça

[Miguel Cabeça]

Hello,

>> The poster seemingly has a SAML ecosystem in place, with a SAML IdP
>> and SAML SPs. Now why would one introduce yet another completely
>> different SSO system (and proprietary protocol) just to *integrate* a
>> tomcat app with his SAML system?
>
> Well, I was just mentioning another approach so he can decide. Many
> sites (like mine) already have deployed a local SSO and integrated
> the IdP as
> another app protected by it.

We do just that at our University. simpleSAMLphp IdP is an app
protected by our CAS system. But we are studying the possibility of
substituting CAS with a pure SAML 2.0 system.

Best Regards

Miguel Cabeça

[Andreas Åkre Solberg]

On 27. okt.2008, at 20:46, Miguel Cabeça wrote:

> With simpleSAMLphp or shibboleth there seems to be another approach.
> We install a SP on the same host as the application you want to
> protect, that handles all aspects of the SAML protocol. Then you
> "link" both parties with:
>
> - If the application being protected is written in PHP you can add a
> library that interacts with simpleSAML
> - If the application is written in any other language you use the
> auth_memcookie and environment variables to link both parties.
> - If you want to protect a static directory of documents you can use
> the previous method
>
> Is this view correct?

Yes. But as recently as last week on a simplesamlphp workshop in
denmark we discussed the possibility of adding a CAS server interface
in simpleSAMLphp to interact with applications that is CAS-enabled.
One drawback is the lack of proper logout in CAS, but it will make it
really simple to integrate already CAS-enabled application with a
federation.

Do you think this make sense?

See figure:

[Jon Lustig]

I have an identical challenge to the poster. I'm providing SSO for
three applications, one PHP, one PL/SQL and one Java.

My IdP is simpleSAMLphp, so I did the PHP app SP first - easy.
With some help from the PL/SQL lead, we have a simple solution for that
app as well, also using a simpleSAMLphp SP.

So the Java app (Pentaho BI) is the last one left.

I'm having challenges just hooking into the auth process for Pentaho
(uses acegi), but that's the joy of development.

I'm looking at using the openSaml java library directly and,
essentially, building my own SP with it.

On the edges of what's possible for our organization is using memcache
or using Shibboleth instead. Both are interesting possibilities to me
but present some IT and political challenges - e.g., for Shibboleth, do
I want to recompile Apache with mod_proxy and become responsible for the
build that will eventually be in production?

I have not yet completely ruled out CAS - apparently other Pentaho
installations use it and Andreas diagram intrigued me. Is this
suggesting that the CAS server is written in PHP or that simpleSAMLphp
IS the CAS Server?

I've read this thread with great interest and am curious how Mr.
Johansen resolves these issues.

Thanks,

Jon

[Atle Johansen]

Hi again

> I'm looking at using the openSaml java library directly and,
> essentially, building my own SP with it.

I also pursued this approach, and had a look at the javamellon project,
which uses lasso, but my Java is a bit too rusty to write my own SP,
so I abandon this for now. I will maybe revisit this approach later.

> On the edges of what's possible for our organization is using memcache
> or using Shibboleth instead. Both are interesting possibilities to me
> but present some IT and political challenges - e.g., for Shibboleth, do
> I want to recompile Apache with mod_proxy and become responsible for the
> build that will eventually be in production?

You would only compile the module for apache, wouldn't you?

>
> I've read this thread with great interest and am curious how Mr.
> Johansen resolves these issues.

We are going for the memcached approach, using it as a session store.
we can get a hold of the session simply through a Java library.

We started out here to make the Apache memcookie module:

- http://authmemcookie.sourceforge.net/

Resolve the deps, make and install the memcached server.
There is also some french php sample to test that everything is up ok.
Then configure simplesamlphp to use your memcached server as session store.

In our Java app, we used this to talk to the same memcached server:
- http://whalin.com/memcached/

Hope this helps somebody else too...

best regards
Mr Johansen

[Anders Lund]

On Wed, 2008-10-29 at 23:52 +0100, Atle Johansen wrote:
> Hi again
>
> > I'm looking at using the openSaml java library directly and,
> > essentially, building my own SP with it.
>
> I also pursued this approach, and had a look at the javamellon project,
> which uses lasso, but my Java is a bit too rusty to write my own SP,
> so I abandon this for now. I will maybe revisit this approach later.

This could perhaps also be of interest if you are looking at Java:
http://sourceforge.net/projects/saml2api/

- Anders

--
Anders Lund <ander...@uninett.no> .~.
UNINETT, N-7465 Trondheim, Norway / V \
Phone: +47 73 55 79 08 | Mob: +47 93 03 41 26 /( )\
^ ^

[Peter Schober]

* Jon Lustig <jlu...@ariasystems.com> [2008-10-29 21:49]:

> I'm looking at using the openSaml java library directly and,
> essentially, building my own SP with it.

Don't. See "2.1 Java SP" for existing SP implementations in Java:
https://spaces.internet2.edu/display/SHIB2/Shibboleth+2.2+Roadmap
The toolkit from the Danish government is based on OpenSAML, so this
should be exactly what you're looking for.

> On the edges of what's possible for our organization is using memcache
> or using Shibboleth instead. Both are interesting possibilities to me
> but present some IT and political challenges - e.g., for Shibboleth, do
> I want to recompile Apache with mod_proxy and become responsible for the
> build that will eventually be in production?

May I ask which platform you are on, that ships an Apache httpd without
'--enable-so' (and without '--enable-proxy --enable-proxy-ajp')?
Are you sure you have no loadable modules support in your httpd?
$ httpd -l

If that is indeed the case (and rolling your own is not desirable for
some reason) I'd probably setup the proxy (Apache httpd with mod_shib)
on another (possibly virtual) maschine with a more friendly OS.
You'd only need to make sure Tomcat's AJP connector is not reachable
from anywhere but from the proxy httpd (private network, packet filter,
firewall, whatever), and that there is no Tomcat HTTP connector
listening at all.

I guess auth_memcookie, Shib SP (both depending on your platform and
httpd build) and the danish Java-SP filter would all just work
fine. It just depends on where you'd rather be spending time.

[Miguel Cabeça]

Hi,

> Yes. But as recently as last week on a simplesamlphp workshop in
> denmark we discussed the possibility of adding a CAS server
> interface in simpleSAMLphp to interact with applications that is CAS-
> enabled. One drawback is the lack of proper logout in CAS, but it
> will make it really simple to integrate already CAS-enabled
> application with a federation.
>
> Do you think this make sense?

That's a really, REALLY odd idea. Embedding a CAS server (sort of IdP)
on a simpleSAMLphp SP will blurr the conceptual line separating IdPs
from SPs. It may be a possible technical solution for this problem but
I think it will bring havoc and caos to someone trying to cope with
this subject. With the adicional redirects for the CAS protocol it
will also be harder to debug the SAML instalation.

I think effort should be directed towards the integration of
simpleSAMLphp with other programming languages, as discussed in this
thread, instead of bringing another SSO system to the mix.

Just my €0.02

Miguel Cabeça

[Miguel Cabeça]

Hello,

> My IdP is simpleSAMLphp, so I did the PHP app SP first - easy.
> With some help from the PL/SQL lead, we have a simple solution for
> that
> app as well, also using a simpleSAMLphp SP.

Could you elaborate on how you solved the problem for PL/SQL?

> On the edges of what's possible for our organization is using memcache
> or using Shibboleth instead. Both are interesting possibilities to me
> but present some IT and political challenges - e.g., for Shibboleth,
> do
> I want to recompile Apache with mod_proxy and become responsible for
> the
> build that will eventually be in production?

Most Linux distributions come with mod_proxy already installed. Are
you sure you have to compile apache again?

> I have not yet completely ruled out CAS - apparently other Pentaho
> installations use it and Andreas diagram intrigued me. Is this
> suggesting that the CAS server is written in PHP or that simpleSAMLphp
> IS the CAS Server?

Both, for what I got from the drawing, Andreas is suggesting to write
a CAS server in PHP as a module of simpleSAMLphp SP component.

Miguel Cabeça

[Mads Freek Petersen]

Hi

Seen from the application proper the SimpleSAMLphp sp IS an idp ie. it
makes some attributes available typically in a very simple way
(sessionsharing, environment vars, additional headers, filters).

Providing a CAS interface module (among others) will allow
SimpleSAMLphp to be used in non-php environments out of the box.

Other possibilities which could use existing application
infrastructure are:

LDAP
ShibShim (simple xml based "guard" to a (remote) Shib/SimpleSAMLphp)

-Mads

[Jon Lustig]

Hi -

First of all, thanks for all of the suggestions the saml2api library looks particularly promising. I'll also take another look at the apache install and ask more questions tomorrow.

The PL/SQL solution that works for us is to use a simpleSAMLphp SP on the same server. The PL/SQL app uses a procedure to generate a row in some table for the new session and a cookie with a session identifier. The PL/SQL lead is writing a variant of that procedure that is callable via oci_* and I'm modifying only the lib/SimpleSAML/Session.php's login() method to call that procedure and populate the cookie. The other part is replacing the redirect to login with a redirect to 'initSSO.php' - all of the application code is stored in the DB so this is just a matter of replacing an HTML CLOB with a redirect.

Jon

-----Original Message-----
From: simple...@googlegroups.com [mailto:simple...@googlegroups.com] On Behalf Of Miguel Cabeça
Sent: Thursday, October 30, 2008 9:37 AM
To: simple...@googlegroups.com
Subject: Re: simplesamlphp on Tomcat

[Miguel Cabeça]

Hi,

> Seen from the application proper the SimpleSAMLphp sp IS an idp ie. it
> makes some attributes available typically in a very simple way
> (sessionsharing, environment vars, additional headers, filters).
>
> Providing a CAS interface module (among others) will allow
> SimpleSAMLphp to be used in non-php environments out of the box.
>
> Other possibilities which could use existing application
> infrastructure are:
>
> LDAP
> ShibShim (simple xml based "guard" to a (remote) Shib/SimpleSAMLphp)

Ok. I get it. The way I see it there are several ways of connectig
your application to your SAML AAI.
In the following drawing I try to sketch the possibilities:

[Andreas Åkre Solberg]

On 30. okt.2008, at 14:28, Miguel Cabeça wrote:

>> Yes. But as recently as last week on a simplesamlphp workshop in
>> denmark we discussed the possibility of adding a CAS server
>> interface in simpleSAMLphp to interact with applications that is CAS-
>> enabled. One drawback is the lack of proper logout in CAS, but it
>> will make it really simple to integrate already CAS-enabled
>> application with a federation.
>>
>> Do you think this make sense?
>
> That's a really, REALLY odd idea. Embedding a CAS server (sort of IdP)
> on a simpleSAMLphp SP will blurr the conceptual line separating IdPs
> from SPs. It may be a possible technical solution for this problem but
> I think it will bring havoc and caos to someone trying to cope with
> this subject. With the adicional redirects for the CAS protocol it
> will also be harder to debug the SAML instalation.

Well, if you take a look at 90% of the SAML 2.0 SP implementations,
there is already redirects and a protocol between the application
itself and the applications. Let me take a few examples:
- With shibboleth there is a proprietary protocol where the mod_shib
apache module communicates with shibd. (correct me if I am wrong)
- With Sun OpenSSO there is a proprietary protocol between the SAML2
software, and the application. A library clientSDK allows you to use
this protocol.
- With PingFederate there is a proprietary (they try to standardize
it, but noone else i using the protocol) protocol between the Ping
server and the apachemodule/application.

SimpleSAMLphp currently have not implemented any such proprietary
protocols. Instead we look for existing solutions to solve the same
problem. One way of doing this is communicate by storing a memcookie
in memcache...

Then; CAS is another approach. There are tons of CAS clients for all
kind of programming languages, and there is as well several
applications that are already SSO-enabled with CAS. Still, there are
some issues to be solved: 1) sending attributes through CAS 2) Single
Log-Out.

> I think effort should be directed towards the integration of
> simpleSAMLphp with other programming languages, as discussed in this
> thread, instead of bringing another SSO system to the mix.

--

[Andreas Åkre Solberg]

On 31. okt.2008, at 16:55, Miguel Cabeça wrote:

> Is this correct? If so, can I suggest a simpleSAMLphp SP module that
> would implement a simple API and a set of native language libraries
> to interact with that API.

Thanks for the figure, it was really good.

It probably is a good idea to have several options of how to integrate
simpleSAMLphp with apps. CAS and memcookie is two of them.

If someone feels like writing a new proprietary protocol based on JSON
for this communication, feel free. This kind of integration is fully
possible to implement as a simpleSAMLphp module, that can be easily
installed and maintain side by side by simpleSAMLphp. We'll write much
more documentation and show how this can be done in the future.

Andreas

[Peter Schober]

* Andreas Åkre Solberg <andreas...@uninett.no> [2008-11-04 13:06]:

> Well, if you take a look at 90% of the SAML 2.0 SP implementations,
> there is already redirects and a protocol between the application itself
> and the applications. Let me take a few examples:
> - With shibboleth there is a proprietary protocol where the mod_shib
> apache module communicates with shibd. (correct me if I am wrong)

You might as well consider all this happening just in mod_shib,
conceptually. The only reason shibd is seperate from mod_shib is for
privilege seperation (no read access to the entity's private key is
necessary for the webserver) and for easier handling of sessions
accross several httpd processess (and possibly threads). also this way
your session will survive in case httpd get's restarted.

All the application sees is HTTP environment variables and HTTP
request headers, so this is the "protocol". The splitting of shibd
from mod_shib is not relevant here, IMHO.

> Then; CAS is another approach. There are tons of CAS clients for all
> kind of programming languages, and there is as well several applications
> that are already SSO-enabled with CAS. Still, there are some issues to be
> solved: 1) sending attributes through CAS 2) Single Log-Out.
>
>> I think effort should be directed towards the integration of
>> simpleSAMLphp with other programming languages, as discussed in this
>> thread, instead of bringing another SSO system to the mix.

Personally I consider the CAS-approach (language bindings/APIs) to be
plain wrong since you'd need to SSO-enable every application several
times, once for each SSO-system used, even if they all speak SAML2 on
the outside, cf. Moodle Shibboleth module, Moodle simpleSAMLphp
module, Moodle OpenSSO module, etc.

Just swapping out mod_authnz_ldap for mod_shib or mod_pubcookie or
whatever is trivial and involves no changes to the app, if it either
supports compatibility with http basic auth (REMOTE_USER variable)
upstream or has been extreded for *one* system -- it will just work
with any other system as well. But it won't help with simpleSAMLphp
and not everyone likes the container/webserver-based approach.

Also, while I know nothing about CAS it seems SAML-support has been
added to CAS a while back? Search for SAML in the release notes at
http://www.ja-sig.org/products/cas/announcements/
With CAS having all the clients and bindings for many programming
languages what would simpleSAMLphp gain from re-creating all those
bindings yet again, only for simpleSAMLphp?
Will simpleSAMLphp then become the "lightweight CAS" or the
"CAS with s/Java/PHP/ and without the CAS protocol"?
No offence, just asking some probably stupid questions.

cheers,
-peter

[Miguel Cabeça]

Hi,

All the application sees is HTTP environment variables and HTTP
request headers, so this is the "protocol". The splitting of shibd
from mod_shib is not relevant here, IMHO.

The established way (the only?) of an apache module to comunicate with a hosted application is by HTTP environment variables, so that's probably why this "protocol" was chosen.

Personally I consider the CAS-approach (language bindings/APIs) to be
plain wrong since you'd need to SSO-enable every application several
times, once for each SSO-system used, even if they all speak SAML2 on
the outside, cf. Moodle Shibboleth module, Moodle simpleSAMLphp
module, Moodle OpenSSO module, etc.

That's true also for mod_authnz_ldap, mod_shib or mod_pubcookie or mod_auth_memcookie for that matter. You had to enable every  application to read the environment variables. The only difference to the language bindings/APIs is that there is only one way to do it via HTTP env variables so you can interchange the apache modules with little effort. 

The language bindings/APIs approach is another approach in alternative to the apache module integration, that provides additional functionalities to the application (testing if a user is authenticated without trigering authentication, logout,...)

You are probably right that there should be a common API for all SAML software that should be adopted by all implementations (Shibboleth, simpleSAMLphp, OpenSSO, etc) but that's another story...

Also, while I know nothing about CAS it seems SAML-support has been
added to CAS a while back? Search for SAML in the release notes at
http://www.ja-sig.org/products/cas/announcements/
With CAS having all the clients and bindings for many programming
languages what would simpleSAMLphp gain from re-creating all those
bindings yet again, only for simpleSAMLphp?
Will simpleSAMLphp then become the "lightweight CAS" or the
"CAS with s/Java/PHP/ and without the CAS protocol"?
No offence, just asking some probably stupid questions.

I have to agree with you that simpleSAMLphp would become a lightweight CAS server implemented in PHP instead of Java. I don't like this approach either.

Best Regards

Miguel Cabeça