Ross et al.,
I'm not sure I understand the actual question at hand -- you have (or
want to write) a Smalltalk-based application that runs in it's own
webserver, and proxy to that with httpd? Where is the SVN access
happening? From the Smalltalk app? From httpd?
Is this SVN-webapp something like ViewCV or Trac? Is it under your
control (source available, permission to modify)? COST or homegrown?
Find a few generally off-topic remarks below ;)
* Ross Boylan <ross@xxxxxxxxxxxxxxxx> [2009-05-12 04:35]:
> Well, I don't even know how to do that step, though the reference to
> mod-cas by Nick Owen may be a clue.
Academic organisations should definitively look into running
Shibboleth (mod_shib in httpd, but there's a fastcgi responder as well
as a M$-IIS ISAPI filter, for those less lucky) as campus web SSO
system, since it also does federated websso (via SAML2).
Chances are you'll need this anyway (for access to library ressources
or outsourced student services), sooner or later. Depending on your
university's structure central IT might already offer this service,
and you could even federate internally (if campus IT runs their own
IdM systems).
> > Your problem will be to make the various applications running under
> > Apache aware of the single sign-on.
This is indeed as much an art as a science. Every self-respecting
application has it's own user store, authentication mechanism, login
form, session mechanism, etc. (which is understandable, since it can't
expect everyone to have the necessary parts already in place).
So each and every application needs to be modified to rely on
externally provided authentication (preferrably via replying on
REMOTE_USER already being set by some mod_*), refrain from insisting
to collect username+password itself (and impersonate the user to other
services with them that way), possibly even "outsourcing" it's session
management (also take into account terminiating thise several
different sessions, one for the SSO system, one for the application,
with different timeouts, idle timeouts and consequences for the user
experience.)
Still, there's no way around that. Letting every app in your
environment collect username+password itself just has too many
security implications, as well as teaching users it's OK to enter
their credentials in just about any webpage; instead of just one,
where it's reasonable to check the URL and SSL "lock" icon.
> It's not written! But the natural way it works is to have a login page.
> After login, the id is saved on the server and associated with the
> session (using the Seaside framwork).
First thing that'd need to go is the login page (see above) ;)
Looking at Seaside it seems this comes with it's own VM and webserver,
so you'd need to reverse proxy to this from httpd and do all the authN
and authZ there. Which is fine, but you won't get REMOTE_USER to your
Seaside app via mod_proxy_http (as you would via AJP), also envvar's
won't help, which leaves HTTP request headers (which are easily
spoofed, so would need to be clean by httpd before proxying to
Smalltalk).
> Funding cuts also seem likely to delay rollout of the single signon,
> even if we wanted to use it.
There are several Free Software offerings, some of which are rather
easy to setup and maintain[1] if you have the IdM infrastructure in
place (directory service or database with up to date data/accounts for
your population, a way to authenticate all users).
Check out http://www.nmi-edit.org/started/index.cfm or EDUCASE and
related Internet2 activities (e.g. "CAMP" workshops).
cheers,
-peter
[1] simpleSAMLphp is almost trivial and also does SAML2-based WebSSO,
Shibboleth is a more complete implementation. For intra-campus
there's Pubcookie, Cosign, CAS, etc.
--
peter.schober@xxxxxxxxxxxx - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|