Samples

SamplesXml

Code

Config

API Docs

Download

Neolectric

User Realms

Controlling page access with the realm system

You can restrict access to dxp pages based on user privileges. The simplest format uses basic authentication with a username and password. 

<dxp:AuthUser type="PW" priv="GET" resource="demo" 
 lifespan="120"  store="callerID"/>
This AuthUser tag requires a user to have at least "GET" privilege to a resource called "demo" in order to run the page. A resource is a label that is associated a dxp application. Privileges are stored in the realm database as numbers {0,1,2,3,4,5,6,7} and are referred to by the labels {NONE,GET,POST,PUT,DEL,USR,MGR,ADR}. A valid user has a link to a resource at a particular privilege level. The lifespan defines how many minutes the authentication is cached before the user's browser is asked to authenticate again. The store attribute is used as a key to store information about the user back in the page request.

Resources are organized by "realm" and "realm.resource". Each realm identifies a group of users that have something in common. If your system runs applications for a number of companies each company would have a realm name and a number of different realm.resources. For example:

  • "bigcorp", "bigcorp.seattle.accounts", "bigcorp.portland.accounts"
  • "blug", "blug.msgboard", "blug.lib", "blug.events"
  • "demo", "demo.res1"
Resource labels can be used on specific appication pages and each page can specify what privilege a user must have to run it by setting the priv attribute to a particular value. The dxp AuthService will check the realm system to find out if the user is linked to this resource at the require privilege level or above.

A user's base realm privilege applies to all the realm.resources by default. Because their role in one company application may be different than their role in another one they can be granted a higher privilege to specific realm.resources. For example, pages that run "bigcorp.seattle.accounts" should require higher privilege than GET. 

<dxp:AuthUser type="PW" priv="POST" resource="bigcorp.seattle.accounts"
 lifespan="120"  store="callerID"/>
John Doe can be granted MGR privilege to "bigcorp.seattle.accounts" but another employee like Homer Simpson would not. Homer's default GET privilege to "bigcorp" is not high enough to run pages that require POST to "bigcorp.seattle.accounts". Perhaps Lisa has grown up by now and we grant her POST to this resource.

A critical page in a zone or application could require a higher privilege than others. 

<dxp:AuthUser type="PW" priv="MGR" resource="bigcorp.seattle.accounts"
 lifespan="120"  store="callerID"/>
 -- sorry Lisa, no way Homer --
Since John Doe has MGR privilege to this resource he can run POST and MGR pages. Lisa can run the POST pages but not MGR pages. Homer can't get any access to this resource.

Privileges flow "downhill" to all realm.sub.resources below them. If Mr X has MGR privilege to "bicorp.seattle" it will flow down to all sub resources in seattle like "bigcorp.seattle.account", "bigcorp.seattle.orders". If user "sysadmin" has ADR privilege to "bigcorp" it will flow down to all subrecources and he will have access to everything.

The realm system provide a lot of flexibility especially to an application service provider who runs a multi-company web app. The database sechma and web app can be constructed so that each company views it as their own. Access to their "virtual app" can be granted like this... 

<dxp:AuthUser type="PW" priv="POST" resource="${realm}.${appname}"
 lifespan="120"  store="callerID"/>
If a user authenticates successfully, the store attribute is used as a key to store their session, username, realm and realm.resource in the request. These values can be used to customize the page and database actions to refer to the desired company. If you have 100 different companies using your application you don't want 100 different databases all running the same tables. You want one set of tables with a foreign key column in each table that identifies the company each record belongs to. This allows your application to scale.

Realms, users and resources are stored in the realm database

Login

username: demoadmin
password: demo4adr

For these samples, the demo realm has been identified as the master systemrealm so the demoadmin with ADR privilege is a superuser that is allowed to create new realms and delete them. In realms that are not the systemrealm, a user with ADR privilege may create/delete users and resources but not realms. Only the master systemrealm can manage other realms that are not their own.