On Mon, 2009-05-11 at 19:23 +0200, André Warnier wrote: > Ross Boylan wrote: > > On Mon, 2009-05-11 at 11:21 -0400, Nick Owen wrote: > >> On Sat, May 9, 2009 at 12:34 PM, Ross Boylan <ross@xxxxxxxxxxxxxxxx> wrote: > >>> Suppose I have apache running in front of a web application and > >>> subversion. > >>> > >>> I am thinking of a scenario in which the web application provides a > >>> login page. However, the user may also browse to web pages served by > >>> subversion. > >>> > >>> Is there a way that my app can have someone log in and then pass the > >>> identity and authentication "up" to appache? In particular, I'd want > >>> this authentication used if the user browsed over to the subversion > >>> repository. > >>> > >>> I'm assume a common source, e.g., LDAP, will provide user and password > >>> information that is the same for my app and apache. > >>> > >>> A final wrinkle is that the application itself may access subversion via > >>> http:// (https?) using either the identity of the user or, perhaps, a > >>> separate identity the application runs under. > >> Have you investigated single sign-on solutions such as CAS and OpenSSO? > > > > No. That's certainly relevant, since the university is moving toward > > single sign on. I'm not sure of the exact technology, but I believe > > it's from IBM. However, how do I make Apache aware of the single sign > > on? > > That /is/ a very good question, if maybe slightly mis-targeted. > Your problem will not so much be to make Apache aware of the single sign-on. Well, I don't even know how to do that step, though the reference to mod-cas by Nick Owen may be a clue. > Your problem will be to make the various applications running under > Apache aware of the single sign-on. > > For example, take the case of SVN. > Where /can/ SVN obtain a user-id ? This would be svn accessed through Apache, so I think this is almost the same is the Apache problem. However if the flow is Apache -> My Web App -> svn then My Web App has to somehow pass the credentials through. In the presence of single signon, that might not be necessary. > > Then you mentioned another application, self-written apparently. > Where /can/ that application obtain a user-id ? 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). > > (By /can/, I mean : what mechanism is already built-in into this > application) > > The question is : does there exist any /standard/ mechanism, implemented > in all kinds of applications that can run under Apache, to obtain a > user-id ? The answer is basically no, because Apache (and HTTP) do not > define such a standard mechanism. Some of the other answers suggest what I suspect, that it's in an environment variable. Then again, my app would not be cgi-bin. > ... > > > > > We're probably going to need an alternative before the single sign on is > > working. There are also a significant usability issues with the current > > single signon system (for those few areas its active). > > > Probably for the reasons above. More mundane: it's a hassle to get the ids, to remember them, to deal with the requirement for frequent changes to complex passwords, and to figure out which of the many ids people have is the relevant one (that is, the user needs to know which id and password goes with the single signon). When we tested the system, we had a lot of trouble figuring out whether or not we already had a qualifying account. Some, but not all, of this would not have arisen if we'd had a single signon from the start. We don't. Funding cuts also seem likely to delay rollout of the single signon, even if we wanted to use it. --------------------------------------------------------------------- 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
|