S
S
Shedal2011-10-02 21:45:37
Open ID
Shedal, 2011-10-02 21:45:37

Combined authentication methods on a number of sites. Need something like distributed OpenID

Given: several web applications. These are simply multiple copies of the same application running on different subdomains. For example: s1.myapp.com, s2.myapp.com, s3.myapp.com. Applications are not related to each other in any way, i.e. run on different physical servers and each has its own database.
Authorization on all these domains is the same - by login / password.

Task: to create a site like help.myapp.com, which would be available only to users authorized on any of the applications.

The following ideas came to my mind:

1. Create a single authentication host (auth.myapp.com) and use OpenID to authenticate to help.myapp.com.
Minus: additional work on changing the architecture.

2. Entering a password directly on help.myapp.com and querying all available databases, checking if at least one of them has such a login/password combination.
Cons: the solution looks clumsy. In addition, users will have to enter a username/password both on the main site of their application and on the help site.

3. Authorization by referrer. That is, if a person came through the link from at least one of the allowed sites, he automatically gets access, as well as cookies that remember him as authorized.
Cons: referrer can be faked very easily. In addition, direct links to help pages will not work if the user is not authorized. For example, if someone was sent a link to help via Skype, the person will first have to go to help from their main site in order to authenticate, and then open the link.

Are there other ways? Can anything be improved in the above?
Thanks in advance.

Answer the question

In order to leave comments, you need to log in

7 answer(s)
E
edogs, 2011-10-02
@Shedal

Set authorization cookie for *.myapp.com? If the task is correctly understood, then IMHO this is the best way.

P
philpirj, 2011-10-04
@philpirj

A similar question has already been asked here , and they came to a consensus .

A
AigizK, 2011-10-02
@AigizK

Maybe at the time of authorization on any of the sites, in parallel, authorize it on the site auth.myapp.com? And then, when entering help.myapp.com, we transfer it to auth.myapp.com and if it is already authorized there, then we authorize it to help.myapp.com, and if it is not yet authorized, then we show the login and password field. And when the user enters data, we look for a match between the login and the password in the databases of all sites.

S
Stalker_RED, 2011-10-03
@Stalker_RED

as an option:
On one of the sites (or on a separate one), arrange an authentication center. On all pages of sites, if the client is not yet authorized on the site, request a javascript from this "center".
If the client is not authorized in the "center" - the server returns an empty file, and if authorized, then some code that distributes authorization to the "subsidiary" site (sets cookies, redirects, or something else).
Naturally, you should not forget about security, it is worth introducing tokens or something else.
If all sites are subdomains of the same domain, then you can set a common cookie.
If it’s too expensive to change the architecture a lot, then you can collect accounts from all sites into a single database at a time (if only because it’s faster to search this way), and when adding new users, send a copy to the main server (or synchronize databases, as you prefer).

A
Anton_from_Amber, 2011-10-04
@Anton_from_Amber

1. Organize a simple joke database into which you will throw the key-login-application and store the private key (session code for example)
2. Send the public key based on a common algorithm (hashing, salt, another private key) to the client)
As a result, you know authorization level, where you came from for the last time, what the user or application did. Each application can independently work with its own key in the authorization database, as well as edit the shared private key. You can SQL (MyISAM, Memory in MySQL), you can noSQL (memcache, redis, cassandra). The main thing is that no one is tying anyone's hands.

1
1nd1go, 2011-10-07
@1nd1go

I think you should also look aside: Single Sign-on

D
Dmitry Sidorov, 2011-10-03
@Doomsday_nxt

make an openID provider that automatically authorizes your sites ... sooner or later you will want to add another site, and then another site, etc. A single authorization will save you from many problems in the future. And yes - for users, another “OpenID” service will only be a plus :-)

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question