Web-based application Login/Account Management Question...

Question

Question

Chip Gore · May 10, 2016

Hi -

I'm trying to figure out what is the best (or at least pros & cons) on how to manage login accounts in a multi-tenant SaaS web based application context.

Assume that a company is designing a collections of web based applications that they will be selling as "services" to their clients, and that these clients will each have their own "users" and "customers" that will be logging into these services.

In setting up these login accounts for the "users/customers" of the "clients" of the "company", does setting up a unique domain/user-pool context for each "client" make the most sense? And if so, when deploying updates to the applications, would each domain/user-pool context be replicated environments that would each need to be updated?

(I'm trying to figure out what makes any sense in terms of web-login-account management and ease of top-level administration)

Discussion (3)1

Log in or sign up to continue

Eduard Lebedyuk · May 10, 2016

As I understand, you need Caché users + some way to:

Store additional information
Provide methods for web-login-account management
Provide additional security checks

I guess domains could be used, okay. Also, here's somewhat related thread.

>And if so, when deploying updates to the applications, would each domain/user-pool context be replicated environments

> that would each need to be updated?

Why? You have production server with real users and a test one(s) with some test users.

0 0

score 0 · Answer 1 · 2016-05-10T15:42:31-04:00

Hi -

My original thinking/concern is the notion that "Service Provider's Client 'A' - has a set of users" and "Service Provider's Client 'B' - has a different set of users" and neither A nor B users should be restricted in login user names to be unique across the Service Provider's total collection of login accounts. In other word there should be able to be a login for "A-client 's Bob" and "B-client's Bob" and they could both be "bob" at the screen, but "A-bob" and "B-bob" from the SaaS application that is being used by both "Client A" and "Client B". If there are separate installations of the Application for Client-A and Client-B with their own respective web-application user accounts, then the deployment of an upgrade to the application becomes more complicated, where each installation would need to be deploy'ed to instead of a single update being reflected across all instances of the application were it to be deployed in a single "production instance" (i.e. "upgrading multiple installations of the same application" vs. "upgrading a single installation, used by many discrete collections of users")

I'm trying to come up with a "best practice" approach (i.e. Pros/Cons for multiple simple deployments vs single more complex deployment). As more and more companies are looking to provide SaaS solutions there will end up being more and more multi-tenant situations that should be planned for with proper justifications for "lots of simple" or "single complex", and the system level user identification challenge is just one such aspect of the problem space.

score 0 · Answer 2 · 2016-05-12T15:20:00-04:00

> Pros/Cons for multiple simple deployments vs single more complex deployment)

If you have a virtualization platform and clients are heavy users, it would probably make a lot of sense to go with multiple simple deployments, and if you'll have many clients who can't load a single smallest node then "single complex" would be better.

Developing "lots of simple" system (so 1 simple system with multiple deploys) would be cheaper (as you don't have tyo think about domains and security would be simpler, maybe some other simplifications would be possible), but hosting would (maybe) be more expensive as there is a lot of overhead in resources (to run OS/Cache for each deploy).