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