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 <r...@biostat.ucsf.edu> [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.scho...@univie.ac.at - 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-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
