You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Vsevolod Ilyushchenko <si...@cshl.edu> on 2002/01/16 20:14:20 UTC
Single login/sign-on for different web apps?
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) simonf@cshl.edu
http://www.simonf.com simonf@simonf.com
"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
Re: Single login/sign-on for different web apps?
Posted by Ed Grimm <ed...@tgape.org>.
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) simonf@cshl.edu
> > >>> http://www.simonf.com simonf@simonf.com
> > >>>
> > >>> "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 medi@CyberShell.com
> > > Unix Distributed Systems Engineer HTTP://www.CyberShell.com
> > > CyberShell Engineering
> > > -------------------------------------------------------------------------
> > >
> > >
> > >
>
> --
> -------------------------------------------------------------------------
> Medi Montaseri medi@CyberShell.com
> Unix Distributed Systems Engineer HTTP://www.CyberShell.com
> CyberShell Engineering
> -------------------------------------------------------------------------
>
>
>
Re: Single login/sign-on for different web apps?
Posted by Medi Montaseri <me...@cybershell.com>.
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) simonf@cshl.edu
> >>> http://www.simonf.com simonf@simonf.com
> >>>
> >>> "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 medi@CyberShell.com
> > Unix Distributed Systems Engineer HTTP://www.CyberShell.com
> > CyberShell Engineering
> > -------------------------------------------------------------------------
> >
> >
> >
--
-------------------------------------------------------------------------
Medi Montaseri medi@CyberShell.com
Unix Distributed Systems Engineer HTTP://www.CyberShell.com
CyberShell Engineering
-------------------------------------------------------------------------
Re: Single login/sign-on for different web apps?
Posted by Ed Grimm <ed...@tgape.org>.
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) simonf@cshl.edu
>>> http://www.simonf.com simonf@simonf.com
>>>
>>> "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 medi@CyberShell.com
> Unix Distributed Systems Engineer HTTP://www.CyberShell.com
> CyberShell Engineering
> -------------------------------------------------------------------------
>
>
>
Re: Single login/sign-on for different web apps?
Posted by Medi Montaseri <me...@cybershell.com>.
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...
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) simonf@cshl.edu
> > http://www.simonf.com simonf@simonf.com
> >
> > "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 medi@CyberShell.com
Unix Distributed Systems Engineer HTTP://www.CyberShell.com
CyberShell Engineering
-------------------------------------------------------------------------
Re: Single login/sign-on for different web apps?
Posted by Aaron Johnson <so...@gina.net>.
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) simonf@cshl.edu
> http://www.simonf.com simonf@simonf.com
>
> "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
Re: Single login/sign-on for different web apps?
Posted by Dominique Quatravaux <do...@idealx.com>.
> I hadn't really taken a look at personal certificates until this thread
> came up. It looks like thawte is offering personal certificates at no
> charge.
>
> http://www.thawte.com/getinfo/products/personal/contents.html
Yep, and the society I work in develops a GPLed PKI, which is a
Perl+PHP+LDAP app for rolling your own certificates (both user and
server):
http://idx-pki.idealx.com/
Certificates are indeed a straightforward way of getting SSO - but
you have to carry your certificate with you whenever you change
workstations. Here are reasonable solutions (trading security for
convenience):
* most secure: use USB crypto tokens (slow and extra per-user price,
but will safeguard the private key and destroy it upon attack);
* very secure: use dedicated workstations, one per user
(impractical), or laptops (expensive but may be amortized with
other needs);
* not so secure (equivalent of password SSO): carry the key on a
floppy, and keep it password-encrypted at all times.
On the server side, you have to get your Apache to grok certificates
(easy with recent versions of openssl), and the authentication info
then gets passed down to PHP and Perl scripts as environment variables
("OK, this guy is called CN=John Doe, OU=sales, O=yourcompany - trust
me on this"). You have to patch your apps, sure, but all the burden of
binding a bunch of crypto bits to a name is removed from you in a
highly secure fashion.
--
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>
Dominique Quatravaux <do...@kilimandjaro.dyndns.org>
Re: Single login/sign-on for different web apps?
Posted by Aaron Johnson <so...@gina.net>.
I hadn't really taken a look at personal certificates until this thread
came up. It looks like thawte is offering personal certificates at no
charge.
http://www.thawte.com/getinfo/products/personal/contents.html
This would make it a more likely method since lots of site
traffic wouldn't want to pay and people tyring out the service wouldn't
be forced to pay just to login.
When you say plug-in token are you talking about a browser plug-in?
Aaron Johnson
More Resources for PKI, CA, etc.
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.6/OSPKI/impl-mozilla.htm
http://www.openca.org/
http://www.pki-page.org/
Gunther Birznieks wrote:
>
> >
> >Of course, the best authentication system for banking I've seen is
> >from UBS. They send you a scratchlist of around 100 numbers. Every
> >time you login you use one of the numbers and cross it off. Very
> >slick.
>
> Does that really work in practice? That sounds really annoying. Is this for
> business banking or for retail? How do they get the next 100 numbers to the
> user? Do they mail it out when they've used 90?
>
> It sounds like it would be less annoying to use certificates and some
> plug-in token there is going to be that much extra work to deal with a
> password sheet.
Re[2]: Single login/sign-on for different web apps?
Posted by "C.Hauser - IT assistance GmbH" <c....@itassistance.ch>.
>>Of course, the best authentication system for banking I've seen is
>>from UBS. They send you a scratchlist of around 100 numbers. Every
>>time you login you use one of the numbers and cross it off. Very
>>slick.
>
> Does that really work in practice? That sounds really annoying. Is this for
> business banking or for retail? How do they get the next 100 numbers to the
> user? Do they mail it out when they've used 90?
It works, as I'm a customer of UBS. They do it for everybody, business and
private. They send the the scratchlist by post, even, registered.
When you reach the 80th number, a new list will be automatically sent.
BR Christian
Re: Single login/sign-on for different web apps?
Posted by Andrew Ho <an...@tellme.com>.
Hello,
PL>Of course, the best authentication system for banking I've seen is
PL>from UBS. They send you a scratchlist of around 100 numbers. Every
PL>time you login you use one of the numbers and cross it off. Very
PL>slick.
GB>Does that really work in practice? That sounds really annoying. Is this
GB>for business banking or for retail? How do they get the next 100 numbers
GB>to the user? Do they mail it out when they've used 90?
The ACE SecurID system (I think they're owned by RSA now) refines this
process well. You have a hardy little credit-card sized (or key fob sized,
and I'm sure they have other form factors) object. It has a little LCD
screen and every 30 seconds the 4- to 6-digit number on it changes. When
you log into the server, you give it your ID, a password, AND the number
currently on your SecurID card or key fob.
The key fob is nice. It's hardy and lasts a long time. I have one from
Motorola from my stint there many years ago. You could probably toss it on
the sidewalk from my third-story balcony and it'd be okay, plus it's
small and easy to read.
This is inferior to a true zero-knowledge challenge-response system which
would require a little calculator, but it's far more secure than a
password and far easier to use than paper and pencil.
Here's the RSA SecurID URL:
http://www.rsasecurity.com/products/securid/
Here's a picture of some of the hardware tokens:
http://www.rsasecurity.com/products/securid/hardware_token.html
I guess they DO have a challenge-response calculator. Neat.
Humbly,
Andrew
----------------------------------------------------------------------
Andrew Ho http://www.tellme.com/ andrew@tellme.com
Engineer info@tellme.com Voice 650-930-9062
Tellme Networks, Inc. 1-800-555-TELL Fax 650-930-9101
----------------------------------------------------------------------
Re: Single login/sign-on for different web apps?
Posted by Ed Grimm <ed...@tgape.org>.
On Thu, 17 Jan 2002, Gunther Birznieks wrote:
> >Of course, the best authentication system for banking I've seen is
> >from UBS. They send you a scratchlist of around 100 numbers. Every
> >time you login you use one of the numbers and cross it off. Very
> >slick.
>
> Does that really work in practice? That sounds really annoying. Is this for
> business banking or for retail? How do they get the next 100 numbers to the
> user? Do they mail it out when they've used 90?
>
> It sounds like it would be less annoying to use certificates and some
> plug-in token there is going to be that much extra work to deal with a
> password sheet.
Alternately, for a high-tech approach, RSA makes a nice product called a
SecurID token (Well, one of mine says Security Dynamics on the back, but
the new ones definitely say RSA). Actually, they make two, one nice,
one not nice. The nice one has a keypad where you enter in a pin, press
a button, and it generates a temporary id based on its serial number,
your pin, and the current time interval; the time interval changes every
minute or two. The not nice one has no keypad; it works like the other
would if you didn't enter a pin.
I know of several companies that use these; they tend to work fairly
well. (I had one break on me, but I gave it a lot of abuse first; it
lasted almost half of its battery span in spite of not being taken care
of.)
Ed
Re: Single login/sign-on for different web apps?
Posted by Gunther Birznieks <gu...@extropia.com>.
>
>Of course, the best authentication system for banking I've seen is
>from UBS. They send you a scratchlist of around 100 numbers. Every
>time you login you use one of the numbers and cross it off. Very
>slick.
Does that really work in practice? That sounds really annoying. Is this for
business banking or for retail? How do they get the next 100 numbers to the
user? Do they mail it out when they've used 90?
It sounds like it would be less annoying to use certificates and some
plug-in token there is going to be that much extra work to deal with a
password sheet.
Re: Single login/sign-on for different web apps?
Posted by Ed Grimm <ed...@tgape.org>.
On Wed, 16 Jan 2002, Paul Lindner wrote:
> On Wed, Jan 16, 2002 at 06:56:37PM -0500, Vsevolod Ilyushchenko wrote:
>>>
>>> 3) Perl-based applications can just use the module and the common key
>>> to decrypt the contents of the cookie to find the authenticated
>>> username. If the cookie is not present redirect to the central
>>> authentication page, passing in the URL to return to after
>>> authentication.
>>
>> Hmmm... Can I do it securely without using Kerberos? I think so. Looks like
>> if I use https instead of http, people won't be able to steal my (encoded)
>> session information as it is transmitted. And I can also add the IP address
>> to the cookie information.
>>
>> But the cookies file might be readable by other people! If they can steal
>> that file and change the IP address of another machine to yours, they can
>> pretend they are you!
>> I wonder if there is a way out of this...
>
> Yes, you use the timestamp. Just reauthenticate the user when they
> try to do 'sensitive' activities.
No, use session cookies - they're not stored on disk. If you need the
system to retain knowledge through a browser shutdown, you can use a
timestamped cookie to retain the user ID, but don't have it allow them
to do anything other than not have to type their user ID in again
(password screen has user ID filled out for them.)
One can also mark the cookies such that they'll only be transmitted over
https.
$cookie = CGI::Cookie->new(-name => 'login',
-value =>
tgape::setcookiepassword($uid, $pass),
-domain => '.tgape.org',
-path => '/',
-secure => 1,
);
If you feel the need to timestamp your session cookies, make the cookie
include an encrypted timestamp.
> For example you might allow someone to view their bank balance if they
> typed their password within the last 2 hours. Transferring money
> might require a valid password within the last 10 minutes..
Ah, but many systems will refresh a cookie on activity. So they view
their balance, get a new cookie, and then transfer money.
> Of course, the best authentication system for banking I've seen is
> from UBS. They send you a scratchlist of around 100 numbers. Every
> time you login you use one of the numbers and cross it off. Very
> slick.
All I need to do is find where you left the list. Written passwords are
not anywhere near as secure as memorized passwords, unless the person
carrying them around is really conscious about security concerns.
Ed
Re: Single login/sign-on for different web apps?
Posted by Paul Lindner <li...@inuus.com>.
On Wed, Jan 16, 2002 at 06:56:37PM -0500, Vsevolod Ilyushchenko wrote:
> >
> > 3) Perl-based applications can just use the module and the common key
> > to decrypt the contents of the cookie to find the authenticated
> > username. If the cookie is not present redirect to the central
> > authentication page, passing in the URL to return to after
> > authentication.
>
> Hmmm... Can I do it securely without using Kerberos? I think so. Looks like
> if I use https instead of http, people won't be able to steal my (encoded)
> session information as it is transmitted. And I can also add the IP address
> to the cookie information.
>
> But the cookies file might be readable by other people! If they can steal
> that file and change the IP address of another machine to yours, they can
> pretend they are you!
> I wonder if there is a way out of this...
Yes, you use the timestamp. Just reauthenticate the user when they
try to do 'sensitive' activities.
For example you might allow someone to view their bank balance if they
typed their password within the last 2 hours. Transferring money
might require a valid password within the last 10 minutes..
Of course, the best authentication system for banking I've seen is
from UBS. They send you a scratchlist of around 100 numbers. Every
time you login you use one of the numbers and cross it off. Very
slick.
--
Paul Lindner lindner@inuus.com ||||| | | | | | | | | |
mod_perl Developer's Cookbook http://www.modperlcookbook.org
Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: Single login/sign-on for different web apps?
Posted by Vsevolod Ilyushchenko <si...@cshl.edu>.
>
> 3) Perl-based applications can just use the module and the common key
> to decrypt the contents of the cookie to find the authenticated
> username. If the cookie is not present redirect to the central
> authentication page, passing in the URL to return to after
> authentication.
Hmmm... Can I do it securely without using Kerberos? I think so. Looks like
if I use https instead of http, people won't be able to steal my (encoded)
session information as it is transmitted. And I can also add the IP address
to the cookie information.
But the cookies file might be readable by other people! If they can steal
that file and change the IP address of another machine to yours, they can
pretend they are you!
I wonder if there is a way out of this...
Simon
--
Simon (Vsevolod ILyushchenko) simonf@cshl.edu
http://www.simonf.com simonf@simonf.com
"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
Re: Single login/sign-on for different web apps?
Posted by Robert Landrum <rl...@capitoladvantage.com>.
At 9:06 PM +0000 1/16/02, Mark Maunder wrote:
>That's cool, but any ideas on how to do this with different domain names i.e.
>foo.com, bar.com, baz.com and boo.com? You can't create cookies for the .com
>domain, so there's no way to hand out auth cookies from foo.com (when the user
>logs into foo.com) and have the browser send them to bar.com too. Also foo.com
>can't hand out cookies for bar.com, so you can't implement a single sign on
>using cookies for multiple domain names from the same host.
>
>The only way I could come up with, was to have the browser redirected to every
>domain name with an encrypted uri variable to prove it is signed on
>which causes
>each host included in the single sign on to assign an auth cookie to the
>browser.
>So the browser is logged into foo.com, bar.com baz.com and boo.com by logging
>into foo.com which assigns a cookie and redirects to bar.com which assigns a
>cookie and redirects it to baz.com which assigns a cookie and redirects it to
>boo.com which assigns a cookie and redirects it back to foo.com. It has now
>collected all cookies required for signon to all domain names and is
>logged into
>all of them.
That's not terribly efficient for the user. If I were to do this,
I'd probably put some "You are now logged in" page that loads images
from foo.com, bar.com, baz.com, and boo.com (transparent single pixel
gifs would work).
Now the user is logged in to all those servers (provided that the
gifs returned were returned with Set-Cookie headers).
The same thing can be done with authentication. Most browsers allow
you to write urls as
http://user:pass@host.com/images/spacer.gif
It's not pretty, and not super secure, but it does work.
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: Single login/sign-on for different web apps?
Posted by Mark Fowler <ma...@twoshortplanks.com>.
On Wed, 16 Jan 2002, Mark Maunder wrote:
> The only way I could come up with, was to have the browser redirected
> to every domain name with an encrypted uri variable to prove it is
> signed on which causes each host included in the single sign on to
> assign an auth cookie to the browser.
Instead of redirecting the entire page you could just include images
(the typical 1x1 pixel) from each server on the "You've been logged on"
page and have each of them set a cookie for that domain name.
For this to work with modern browsers (i.e. IE6 and properly configured
mozillas) you'll need to include a compact policy in your P3P header[1],
otherwise the browser will consider this an unauthorised attempt to serve
a "third party image" and block the cookie.
Later.
Mark.
[1] See http://www.w3c.org/p3p/,
http://2shortplanks.com/temp/P3P-ToCP-0.02.tar.gz for more information
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ mark@twoshortplanks.com
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
Re: Single login/sign-on for different web apps?
Posted by Mark Maunder <ma...@swiftcamel.com>.
> Here's one idea that worked for me in one application:
>
> 1) assume that all hosts share the same domain suffix:
>
> www.foo.com
> www.eng.foo.com
> www.hr.foo.com
>
> 2) Define a common authentication cookie that is sent to *.foo.com.
> This cookie could might contain the following information:
>
> username, timestamp
That's cool, but any ideas on how to do this with different domain names i.e.
foo.com, bar.com, baz.com and boo.com? You can't create cookies for the .com
domain, so there's no way to hand out auth cookies from foo.com (when the user
logs into foo.com) and have the browser send them to bar.com too. Also foo.com
can't hand out cookies for bar.com, so you can't implement a single sign on
using cookies for multiple domain names from the same host.
The only way I could come up with, was to have the browser redirected to every
domain name with an encrypted uri variable to prove it is signed on which causes
each host included in the single sign on to assign an auth cookie to the
browser.
So the browser is logged into foo.com, bar.com baz.com and boo.com by logging
into foo.com which assigns a cookie and redirects to bar.com which assigns a
cookie and redirects it to baz.com which assigns a cookie and redirects it to
boo.com which assigns a cookie and redirects it back to foo.com. It has now
collected all cookies required for signon to all domain names and is logged into
all of them.
So you end up with something like hotmail.com where you are redirected to like 5
different sites when you login before you get to your inbox. *yuck*. Anyone got
a better idea for this?
Re: Single login/sign-on for different web apps?
Posted by Paul Lindner <li...@inuus.com>.
On Wed, Jan 16, 2002 at 02:14:20PM -0500, 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...
Here's one idea that worked for me in one application:
1) assume that all hosts share the same domain suffix:
www.foo.com
www.eng.foo.com
www.hr.foo.com
2) Define a common authentication cookie that is sent to *.foo.com.
This cookie could might contain the following information:
username, timestamp
Encrypt this info with a server-side key, and send it back to the
user from a login page.
Put all of this in a common perl module.
3) Perl-based applications can just use the module and the common key
to decrypt the contents of the cookie to find the authenticated
username. If the cookie is not present redirect to the central
authentication page, passing in the URL to return to after
authentication.
4) For non-perl applications consider writing a small handler that
takes a cookie and decodes it. Applications present the cookie to
the central auth server, which decodes and verifies it and returns
the encoded data back to the application.
--
Paul Lindner lindner@inuus.com ||||| | | | | | | | | |
mod_perl Developer's Cookbook http://www.modperlcookbook.org
Human Rights Declaration http://www.unhchr.ch/udhr/index.htm