COmanage Developers List

[Niels van Dijk <>]

Hi all,

Thanks for the lightning fast followup on Fridays call!
As it was the beginning of my weekend, I am lagging a bit...

In regard to the request to talk about SURFnets escience program
(Gigaport), Harold 
()
 will visit the I2
Spring meeting. He's the guy to talk to and I'd be happy to introduce
him to you.

The same goes for Andres 
().
 Within SURFnet
he is among other things responsble for 'online applications' and in
this capacity he has been doing much of the heavy lifting with both
Google as well as Microsoft. Should you want to invite him to you
meeting with Google, please do contact him directly.

Next up the generic webproxy for authenticating and provisioning
(remote) apps.
It is often a lot of work to domesticate an application by actually
changing it, and sometimes even impossible, as in our test case (Adobe
Connect), when it is a closed source app, or the app lives 'in the
cloud'. However, a number of apps do have APIs for authentication and/or
provisioning.
The basis idea was therefor to have a standardized, configurable
domestication 'device', in our case an Apache reverse proxy in front of
the (remote) application. Make sure the app will only talk securly to
the proxy. Next make sure the proxy requires federated authencation
before it redirects to the application. We did this by introducing shib
authentication in Apache. Finally, just before redirecting, call a newly
created module, mod_prov (for provisioning) to handle the provisioning
of the app if need be. mod_prov can run any script in any language as
long as it lives on the server the proxy is living on. As apache in
general can be used to handle multiple virtual domains, one would
require only one proxy to do this trick for multiple applications.
 I've attached the (very rough and poorly tested) code as well as some
pdf's decribing its general and more inner workings. It was tested
against Adove Connect using a php based provisioning script (config also
included)
WARNING! - This is NOT production code, not even nearing something like
production code, we did for example not take in to account the
multi-threathing nature of Apache (which will cause the provisioning
script to be call way to many times....)
We will probably not take this forward any time soon (first rollout a
national infrastructure ;), but if you feel you could give this some
followup, e.g. by getting a decent apache module programmer to take a
look at this, we'de be happy to work with you guys.

regards,
Niels
-- 
Niels van Dijk
Advanced Services

T: +31 302 305 337 / M: +31 651 347 657
SURFnet - PO Box 19035 - NL-3501 DA Utrecht - The Netherlands -

http://www.surfnet.nl
SURFnet - We make innovation work

Attachment: COIN-131108-095308-202.pdf
Description: Adobe PDF document

Attachment: COIN-1081379-095452-204.pdf
Description: Adobe PDF document

Attachment: genericWebProxy.zip
Description: Zip archive