Security Scenario

One of the first issues that I had to provide a solution for was security in a multi-tenant hosted environment. I knew that I wanted it to be roles based. I also knew that I wanted objects that are generic enough that they can be configured at the UI level to interact with a new clients data store. However, my boss threw a third curve at me earlier this week: Each page, or function, had to not only be reusable client to client, but it also had to be reusable within the same client. Yikes!

So with that added dimension I set out this week to develop the security model. Here's how it works:

A Page with functionality is developed using the four main category pillars: View, Edit, Settings, Personalization. Each one of those can be configured with roles to gain access. So, if you want users to be able to view the object, then you would assign those roles to that security pillar.

Next, I created a scenario where the page is assigned to a portal. But not just the page, but an instance of the page. That way you could have the same page appear n times in the same portal, but with different configuration and security settings.

So this created a four dimensional security model:

Portal, Page, Page Instance, Role

Each user must satisfy all of these parameters before the Framework grants them access to the resource. It also gives each developer the rare chance to make a page Über-configurable. Now you not only have to construct the page to have a single configuration, and not only configurable at the portal level, but now must support multiple configurations in the same portal.

Since the Framework is what takes care of the authorization to the resource the developer can use those same credentials to manage the configuration settings for that given instance. This model leads to an unforgiving demand for flexibility.