1

This is a general question seeking guidance for the best practice(s) on implementing a Single Sign On (SSO) across many various installations of the same application.

The hypothetical example I would like to pose - imagine you have 200 Wordpress installations / websites that you manage. In order to log into each environment, there's a unique username/password entry for each environment's database. When signing in, the authentication is against an environment-specific database where the query runs against your users table. What would be the appropriate technology(ies) to allow:

  1. Me, as an administrator, the ability to log in one time, and hop from environment to environment. Let's assume each environment runs on different domains, such as client1.com/admin and client2.com/admin

  2. My client, client #1, should be able to sign into their environment, but not automatically gain access to environments 2 and 3...

More context: I am building an application for an agency of several hundred employees. Each installment of the application will be a single-tenant database. I need a solution to allow for each employee to log in once, and jump from environment to environment, while still allowing the application to maintain it's own "local" user database for the specific clients (non-employees of the agency) who will use the application. I am also trying to wrap my head around how an ACL works in such an implementation.

Any leads, suggestions, or feedback are greatly appreciated!

sudoyum
  • 19
  • 1
  • What did you try or thought about ? Are there any constraints that you should mention ? Is a 'superuser' as you mentioned should have access to all of your environments or for a subset (and if so, are there many 'superusers' ?) ? Please try to be more specific and don't expect broad theoretical answers regarding the "best way for SSO". – nadir Jan 23 '19 at 16:43
  • @nadir Reg. superusers, it is foreseeable that there would be many superusers, and each may have access to a subset of environments. Where my head is at is that each environment should maintain a local database of users, and that some would have "NULL" passwords. When authenticating, I would query against a central location (call it "corporate ID") and on success return an access code for this user + start a session. Do I need an oauth server? Not sure what the proper way to implement this is – sudoyum Jan 23 '19 at 22:37
  • It seems like I would need to create an OAuth server of my own, "Corporate OAuth". And then on my app(s) login screen, have a button to sign in with regular credentials OR sign in via "Corporate ID" where we will go through an oauth flow to get a code, access token, and then read their profile. From there, do I check if their email address matches the email on the profile I got from oauth, and if so, establish a session?? – sudoyum Jan 23 '19 at 23:54

0 Answers0