Software as a service (SaaS) and CSLA

Software as a service (SaaS) and CSLA

Old forum URL: forums.lhotka.net/forums/t/4479.aspx


Garrison posted on Friday, March 07, 2008

We're evaluating the CSLA framework for use in a hosted web application.  The application will follow a shared database/shared schema architecture, where all objects have an associated owner or owners that are allowed access.

We'd like to be able to use CSLA's built in security to help us jumpstart the project, but I'm seeing some mismatches between the authorization functionality built into CSLA and what is required by the multi-tenant environment.  From my understanding, we can use the existing roles to create roles for each tenant, but what happens when we want multiple roles per tenant, or multiple tenants sharing certain objects?

Have any of you used CSLA to create applications where data is partitioned by user/group?  Can  you shed some light on how you used CSLA's authorization functionality, or how you went about working around the mismatches.

Thanks in advance,
-G

RockfordLhotka replied on Sunday, March 09, 2008

Ultimately all your database operations will end up with a WHERE clause restricting the user's actions to their data right? So they basically have their "own database" simulated through strict application of this clause.

At which point I don't see the disconnect, because they'll only ever see or update their own data and so authorization would work as normal. The business objects and UI would be entirely unaware that anyone else's data is even in the database because the DAL ensures that a user will never see or impact any other data.

So what you have are seperate "virtual databases".

This can get interesting if you allow a user to access multiple virtual databases, which is what I think you are asking.

If you only allow a user to access one virtual database at a time it is still easy. Within the context of any one virtual database all is well, and they'd presumably have to switch from one to another as an explicit thing.

But if you allow a user to simultaneously access different virtual databases then it gets more complex. Not only at the auth level in the objects, but now your DAL is complex too, because it can no longer use a simple WHERE clause to create a virtual database - it must use a more complex algorithm that essentially joins virtual databases into a meta-virtual database.

And to me that sounds like a recipe for disaster in so many levels...

Copyright (c) Marimer LLC