httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Boylan <>
Subject Re: [users@httpd] authentication question
Date Tue, 12 May 2009 16:17:10 GMT
Thanks to everyone for some really good information.

@Marc Paterman, svn's apache module is dav_svn, so it's definitely DAV
related.  I'm not sure if it simply supports DAV or if that is its
native mode; I suspect the former.

On Tue, 2009-05-12 at 10:05 +0200, Peter Schober wrote:
> 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?  
Yes.  As you note below, proxying implies further difficulties getting
authentication info from Apache to the my web app.  It sounds as I can
either place it in carefully cleaned http headers or rely on some other
single sign on technology.

> Where is the SVN access
> happening? From the Smalltalk app? From httpd?
Both, though the smalltalk app is only going to talk to svn via http.
There are potentially several scenarios (though I could probably
dispense with some of them):
1) Someone with a subversion client on another machine accesses the svn
server via http.
2) Someone uses a web browser views the respository through a web
interface like ViewCVS or Trac.
3) Someone browses to our custom app which redirects tham to 2) or else
presents material from 2) as an embedded page.
4) Someone using our custom app triggers some logic which causes the
custom app to access the repository as a svn client (e.g., to get a
changelog).  The custom web app processes the results in some way and
displays the results.  The custom web app would also be accessing svn
via http.
> Is this SVN-webapp something like ViewCV or Trac? 
Yes (2 and 3 above).
> Is it under your
> control (source available, permission to modify)? COST or homegrown?
All the software should be under our control and open source--that is,
all the suff I've discussed above.  If the central IT ever gets its
single signon going it will be effectively out of our control, and
apparently closed source.

> Find a few generally off-topic remarks below ;)
> * Ross Boylan <> [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).
I can pass the suggestion on, but they apparently did an exhaustive
review before settling on their solution.  Their requirements were
undoubtedly complex. For my purposes, their choice is effectively like
the weather: I just have to live with it.

However, if it's the best route, I suppose we could do a single sign on
that at least covers our little ecosystem.  When I started thinking
about this I thought that meant going with LDAP, but I guess that in
itself just assures the different apps have the same id/password.
Ideally, I want the same id/password, and I want it only asked once.

Incidentally, solutions requiring the human clients to have more exotic
technologies (certificates, ssh) are probably out.
> > 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) ;)
I've seen mention of apache using a login page, rather than the usual
popup.  Is there a way to do that?  It might have a nicer feel for

> 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).
They've bought and partly rolled out the software, so I think it's the
cost of people's time, rather than the software, that is the main
difficulty.  Stopping part way through may be a false economy, but the
state of California has been doing a lot of those recently.
> Check out or EDUCASE and
> related Internet2 activities (e.g. "CAMP" workshops).

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message