Multi-tenant user table and authentication

But, you have both chickens and eggs, do you not?

Do you have a philosophical problem with the super-user?   There are very good use cases for one.

no philosophical  problem. Just making sure that creating 2 CP in order to authenticate a user is best practice.

a follow-on question : if you are running webspeed or appserver, do you run the agent as a super user, and then set-effective-tenant for the required tenant user, or do you run as default, authenticate as super-user, then authenticate as the normal tenant user ?

If the latter, how do you handle securing the superuser name and password within your application code ?

I would suggest that you not use the super-tenant except in the case where you are writing utilities that deliberately cross tenant boundaries to maintain data.  

There is no chicken and egg thing.   You are free to use your own user account tables (with an OE domain name column) and create a client-prinicpal for that user's login.   Submitting that client-principal from your application code to change the DB's tenant identity does not require any special privileges, just a client-prinipal the DB can validate against its domain table.  

right - so am I correct in thinking that in order to use my own user account table, that table would have to be shared in order for a pre-authenticated process to find the appropriate user account record to

a) verify that the user exists and

b) that the password is correct) in the first place ?

another option is to use a "shadow table" of user names and passwords that are encrypted - so, encrypt the supplied user name , try to find a match in the shadow table. if so then try to match the encrypted password

if this passes, then set tenant, and then find the associated user record.

As this shadow table only consists of user name and password (both of which are encrypted) then giving access to all records to all tenants doesn't pose much of a security risk

"As this shadow table only consists of user name and password (both of which are encrypted) then giving access to all records to all tenants doesn't pose much of a security risk."

That depends a lot on how you encrypt it.  As a tenant, I wouldn't want any of my tenant specific data in a shared table, much less account credentials.  If users can get at the data, and therefore export it, they can launch offline attacks on another system at their leisure.  So it had better be good crypto. :)

so how would you get round the problem of having to be able to read the user table to find the appropriate entry ? Go for a super user then set-effective-tenant ?

That kinda feels like having to be root and then su to another account. Perhaps its the way, but ...

It doesn't; acknowledged.  My point is that part of the "sale" to the customer of an MT design is that there are protections inherent to the platform that prevent cross-tenant data leakage.  And you can't make that assertion if you roll your own multi-tenancy.  So if you effective say "I guarantee no other tenant can see your orders or customers or invoices, but they can see your (encrypted) password" then that weakens the promise of platform-provided MT functionality.  Because the user's password is the one thing that, if compromised, defeats those platform protections against data leakage.

I share your question about best practice, and I don't have the answer.  I'm just saying that to me user credentials in a shared table just doesn't feel right.  I would love to hear about best practices from Mike Jacobs or someone else at PSC.  I haven't attended most of the recent conference sessions on MT so I don't know if that ground has already been covered.

I haven't been to those sessions either, but Peter Judge has also done some stuff on Client Principal