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.
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
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.
... 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
Thanks for your help guys.