WebSpeed/AppServer and multi-tenancy

Posted by Rob Fitzpatrick on 14-Dec-2011 21:05

I have been reviewing the information on multi-tenancy that was provided  at Revolution.  I think I'm clear on the relationship between  databases, tenants, domains, and users in the context of a 4GL client  app.  We can either use the client-principal or _user authentication,  however the latter puts the onus on the application logic for the  assertion of user tenancy.  So far, so good (I think ).

I'm less clear on how this should work with WebSpeed agents.  One of the  differences here is that unlike a 4GL app, the application user (in  this case logging in from a web browser) is not a database user; the  WebSpeed agent is the DB user.  Obviously, I only want that application  user to be able to query on data belonging to the tenant he is  associated with.  But I don't know which tenant that is until I find his  data to process his authentication. 

So should the WebSpeed agents authenticate against the database as a  super-tenant user, authenticate the user (somehow), determine which  tenant the application user belongs to, assert that tenancy with  SET-EFFECTIVE-TENANT, and then process his query/update/whatever?  Also,  with a stateless broker his next query could hit a different agent, so I  guess it would have to know about his tenant affiliation as well, and  act accordingly.

I'm fairly new to WebSpeed/AppServers so I'm at the limits of my  understanding here.  I'm just trying to get my head around the  multi-tenant world and understand its implications for the various parts  of our application solution.  If anyone has played with the new OE11 MT  features (or thought about them), I'd be interested to hear how they  might be integrating MT into (or SaaSifying ) their application.  Thanks.

All Replies

Posted by Peter Judge on 15-Dec-2011 08:18

I have been reviewing the information on multi-tenancy that was provided  at Revolution.  I think I'm clear on the relationship between  databases, tenants, domains, and users in the context of a 4GL client  app.  We can either use the client-principal or _user authentication,  however the latter puts the onus on the application logic for the  assertion of user tenancy.  So far, so good (I think ).

You can use CLIENT-PRINCIPAL with _User-based authentication or with other authentication realms. In our sample (see below) we use a table in the application DB called "ApplicationUser". The CLIENT-PRINCIPAL is effectively the ABL's security token, and you should use it regardless of the authentication realm you're using.

I'm less clear on how this should work with WebSpeed agents.  One of the  differences here is that unlike a 4GL app, the application user (in  this case logging in from a web browser) is not a database user; the  WebSpeed agent is the DB user.  Obviously, I only want that application  user to be able to query on data belonging to the tenant he is  associated with.  But I don't know which tenant that is until I find his  data to process his authentication. 

So should the WebSpeed agents authenticate against the database as a  super-tenant user, authenticate the user (somehow), determine which  tenant the application user belongs to, assert that tenancy with  SET-EFFECTIVE-TENANT, and then process his query/update/whatever?  Also,  with a stateless broker his next query could hit a different agent, so I  guess it would have to know about his tenant affiliation as well, and  act accordingly.

At it's simplest, the client UI (the HTML in this case, or GUI client with AppServers) keeps a session or context ID, which is passes per request. The very first thing that the ABL server (AppServer or WebSpeed) does on every request, is to use that ID to find a CLIENT-PRINCIPAL (or some other context) and establish the user in the session (via SET-CLIENT, say). Once that's done, the client is asserted as belonging to a particular tenant, and all is good in the world.

If there is no session id, or the session id has expired by some application-defined criteria, then the client needs to reject the request and ask the client to log in. The login routine will create the CLIENT-PRINCIPAL, store it in the context store, and return a session/context ID for use on the next request. The context store can be something as simple as a file on disk (horrible in many ways, performance being one of them), or a table in a (separate) database.

I'm fairly new to WebSpeed/AppServers so I'm at the limits of my  understanding here.  I'm just trying to get my head around the  multi-tenant world and understand its implications for the various parts  of our application solution.  If anyone has played with the new OE11 MT  features (or thought about them), I'd be interested to hear how they  might be integrating MT into (or SaaSifying ) their application.  Thanks.

We have a sample/reference application called AutoEdge that shows some of these concepts*. You can find it at http://communities.progress.com/pcom/community/psdn/openedge/architecture/autoedgethefactory . That page also points to a information about the Dealer module, which has a WebSpeed implementation too.

* The current version implements multi-tenancy in the 10.2B way, and we plan to update it soon with built-in muti-tenancy. I include it here since it shows using the session ID & CLIENT-PRINCIPAL concepts together.

HTH and let us know if you have more questions.

-- peter

Posted by Tim Kuehn on 15-Dec-2011 09:08

pjudge wrote:


You can use CLIENT-PRINCIPAL with _User-based authentication or with other authentication realms. In our sample (see below) we use a table in the application DB called "ApplicationUser". The CLIENT-PRINCIPAL is effectively the ABL's security token, and you should use it regardless of the authentication realm you're using.

Correct me if I'm wrong, but one _must_ use CP in order to get the AVM to assert the appropriate MT identity. One can use _user and other authentication schemes to figure out if the user is who they say they are, and then CP is set based on the user's successful authentication. After that, the AVM uses a sealed CP object to associate the current session with the tenant's defined data areas.

Posted by Peter Judge on 15-Dec-2011 09:14

... one must use CP in order to get the AVM

to assert the appropriate MT identity. One can use _user and other

authentication schemes to figure out if the user is who they say they

are, and then CP is set based on the user's successful authentication.

After that, the AVM uses a sealed CP object to associate the current

session with the tenant's defined data areas.

Exactly.

-- peter

Posted by Rob Fitzpatrick on 15-Dec-2011 22:18

Thanks for your help guys.

This thread is closed