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 > ------------------------------------------------------------------------- > > >
