No. There are very important reasons why Apache by default puts an ACL restricting .ht* from being viewable. (Basically, the password encryption used in said file is moderately easily cracked via brute force.)
One could use a file distributed using rsync(1) or some such (preferably with RSYNC_RSH=ssh). However, that's still a bit on the unsecure side, unless you really do trust everyone who is running one of these web servers. Ed On Wed, 16 Jan 2002, Medi Montaseri wrote: > I wonder if one could change the HTTP Server's behavior to process a > distributed version of "AuthUserFile" and "AuthGroupFile". > > That instead of > > AuthUserFile "/some/secure/directory/.htpasswd > > One would say > > AuthUserFile "http://xyz.com/some/directory/htpasswd"; > > Then write a GUI (web) inteface to this password and group file and > you have distributed authentication system. > > Ed Grimm wrote: > > > On Wed, 16 Jan 2002, Medi Montaseri wrote: > > > > > I think Netegrity single sing-on system modifies the HTTP server > > > (possible with mod_perl) to overload or override its native > > > authoentication and instead contact a Host, Database or LDAP to get > > > the yes or no along with expiration data.... it then sends its finding > > > to the CGI by sending additonal HTTP Header info. A CGI program can > > > then go from there... > > > > Something like this. Basically, it has modules, plugins, or access > > instructions, as appropriate, for various web servers, to configure them > > to use it. I know it gives an LDAP interface, and I'm assuming it gives > > an LDAPS interface; I'm not sure what others it may present. > > > > > I might not have this 100%, but perhaps we can learn from those > > > commercial products. > > > > > > Someone suggested using LDAP and RDBMS, my question is why both, why > > > not just RDBMS. > > > > Why not just LDAP? As someone working on rolling out a single sign-on > > solution with LDAPS, I really want to know... (We're planning on > > getting Netegrity for its distributed administration stuff; at that > > time, we'll start using its web server configuration stuff for any new > > web servers. Until that time, we're rolling out LDAPS, and we're not > > currently planning on converting systems we roll out in the interm to > > Netegrity.) > > > > Incidentally, we're being a bunch of lazy bums, compared to the rest of > > y'all. We're considering single sign-on to mean they only need to keep > > track of one userid and password (unless they need to access classified > > or otherwise restricted stuff.) If they go to different sites and have > > to log on again, we don't currently care. (Basically, we have too many > > sites created by too many groups. We'll share the same login between > > servers run by the same group, but beyond that, security concerns > > outweigh user convinience.) > > > > Ed > > > > > Aaron Johnson wrote: > > > > > >> We are working on/with a similar system right now. > > >> > > >> We have an application that is written in Perl, but the people > > >> visiting will most likely be signing on at a different point then our > > >> applications sign in page. Our system was built to use its own > > >> internal database for authentication and their app/login uses a > > >> different method. The design requirements were that each side would > > >> have to do as little possible to modify there application to work in > > >> our single sign on solution. > > >> > > >> We have the luxury of not being overly concerned with the security > > >> aspect so please keep that in mind. > > >> > > >> We setup a nightly sync program that verifies the data in the current > > >> database vs. their login user information database. > > >> > > >> Here is a less then detailed summary of how the system operates. > > >> > > >> 1) The user logs into the application through their application and > > >> they are sent a cookie that contains the user name. > > >> > > >> 2) All links to our application are sent to a single page on their > > >> end with the full url of the page they want as part of the query > > >> string. > > >> > > >> 3) They verify that the user is valid using whatever method they > > >> want. > > >> > > >> 4) The user is then redirected to a special page in our application > > >> that expects the query string to contain two items, the user name and > > >> the final URL to go to. > > >> > > >> 5) Our application verifies the HTTP_REFFERER and the query string > > >> contains valid values. > > >> > > >> 6) Our application checks the database for a user matching the name > > >> sent in. Then if the user already has a session if they do then they > > >> are redirected to the correct page, otherwise it does a lookup in our > > >> system to create a session for the user based on the incoming user > > >> name and then redirects to the final URL. > > >> > > >> Now a user can go between the two applications without concern since > > >> they have a cookie for each domain. > > >> > > >> If the user comes to our site the reverse of the above occurs. > > >> > > >> This allowed us to plug into existing applications without a lot of > > >> rework. It is also fairly language/platform independent. > > >> > > >> As stated above I know there are some large security issues with this > > >> approach. > > >> > > >> Aaron Johnson > > >> > > >> Vsevolod Ilyushchenko wrote: > > >> > > >>> Hi, > > >>> > > >>> Have you ever ran into the problem of putting up many separate web > > >>> apps on several machines in your company/university/whatever that > > >>> are written from scratch or downloaded frow the Web and each of > > >>> which has its own user database? What would you think is a good way > > >>> to make the system seem more cohesive for the users? > > >>> > > >>> It occurs to me that 1) for the single login they all should use the > > >>> same user database (obviously :), and 2) for the single sign-on > > >>> there must be a way of storing the session information. That is, > > >>> once I login in the morning to the first app, I get a cookie, a > > >>> ticket or something similar, and then, as I go from app to app, I > > >>> will not have to re-enter my credentials because they are supplied > > >>> by a cookie. Apache::Session sounds like the right tool for the job. > > >>> (Did I hear "Kerberos"? :) > > >>> > > >>> Has anyone had experince with this kind of app integration? The > > >>> downside I see is that once I settle on a particular scheme to do > > >>> it, I will have to build this scheme into every app that was not > > >>> written internally. But that's the life in the before-standards age, > > >>> I guess... > > >>> > > >>> Thanks, > > >>> Simon > > >>> -- > > >>> Simon (Vsevolod ILyushchenko) [EMAIL PROTECTED] > > >>> http://www.simonf.com [EMAIL PROTECTED] > > >>> > > >>> "A man who feels himself a citizen of the world whose > > >>> loyalty is to the human race and to life, rather than > > >>> to any exclusive part of it; a man who loves his country > > >>> because he loves mankind, and whose judgement is not > > >>> warped by tribal loyalties." Erich Fromm > > > > > > -- > > > ------------------------------------------------------------------------- > > > Medi Montaseri [EMAIL PROTECTED] > > > Unix Distributed Systems Engineer HTTP://www.CyberShell.com > > > CyberShell Engineering > > > ------------------------------------------------------------------------- > > > > > > > > > > > -- > ------------------------------------------------------------------------- > Medi Montaseri [EMAIL PROTECTED] > Unix Distributed Systems Engineer HTTP://www.CyberShell.com > CyberShell Engineering > ------------------------------------------------------------------------- > > >
