|
|
WebsydianExpress uses a role-based authorization system.
This means that each user belongs to one or more roles and obtains privileges in WebsydianExpress through these roles.
Accessing site elements is the most important function of the role-based authorization used in WebsydianExpress. Each user is specified as belonging to one or more roles, while each site element is authorized by one or more roles.
The user will be allowed to use the site elements that is authorized by one or more of the roles the user belongs to.
Users who do not belong to any roles will not be able to access the site. Site elements not authorized by any roles will not be accessible.
The roles specified for the user, are not used directly to determine which site element a user can access.
Instead, each session has a number of assigned roles. It is these roles the runtime uses to determine the access.
There are several reasons for using the roles assigned to the session:
When a session is created, it has no user assigned, and in many cases part of the site can be used even though no user has logged in.
To make it possible for these sessions to access any site elements, the sessions must have one or more roles assigned. These roles are assigned to the sessions based on the roles specified for a record in the user table - the so called anonymous user.
When a session is created, the roles are assigned as if the anonymous user had logged in.
The user used as the anonymous user is specified in the site setting "Anonymous user profile".
You should never use an active user profile as the anonymous user. Instead create a specific user for this purpose and set the user to inactive or use the anonymous user delivered as part of the installation.
Creating an anonymous user that does not belong to any roles makes the site inaccessible.
Assigning a role to the user is done using the User management→Users menu item. It is possible to access the page used for assigning roles either form the gridpage or from the update page. In each case, using the "Roles" button launches a pop up window used for assigning roles to users.
When you assign a role to a user, you expand the number of site elements the user will have access to (as described above). You might also change the folder list that will be used when the user accesses the site (see the section Roles and Folder Lists).
The administration interface provides several ways to assign or change the roles assigned to a site element.
The last step of the "Add site element" wizard offers the opportunity to specify the roles that should authorize the site element.
This wizard is launched from the site structure (menu item: Site structure→Site Structure).
In the site structure (menu item: Site structure→Site Structure), you can select the site element you want to update the roles for and press the "Roles" button. This launches a pop up window where you can update the roles used to authorize the site element.
The button also offers the option to add the specified roles to all of the child elements scoped under the selected element ("Recursive add").
The roles authorizing site elements can also be maintained using the site element maintenance pages (menu items: Site Structure→Frameset Elements/URL Elements/Menu Elements/Bus. Proc. Elements). Launch the pop up page by pressing the "Roles" button shown on the grid page.
Authorizing a site element by a role means that the site element will be accessible for users that belongs to the specified role.
A menu item is only shown in a menu if the session belongs to a role that is used to authorize the site element activated by the menu item. In the same way, menu service links are only shown if the session belongs to a role that is used to authorize the site element activated by the link.
Please note, that even though you authorize a site element by a role, this site element might not be available for the user. For example if the site element only exist as a menu item in a menu that the user does not have access to. In this case, the user will not be able to access the menu item, as the menu will never be loaded for the user.
Using the role-based authorization system ensures that only certain users will be allowed to access certain site elements.
WebsydianExpress also provides the opportunity to specify that certain site elements only can be accessed from browsers running on a PC that is placed inside the Intranet.
This is done by specifying the role as being "Available only in Intranet" (advanced setting in the "Update Role" page, menu item User management→Roles).
If the session does not originate inside the intranet, roles that has been specified as being available only in the intranet simply will not be assigned to the session - even though the user belongs to these roles.
In this way, you can ensure that even if login name and password of a user becomes known to a unauthorized individual, he will not be able to access certain site elements unless he can also get access to a PC that is placed inside the intranet belonging to your organization. He will never get the critical roles assigned to his sessions as long as he access the site from outside the intranet.
To determine whether a session originates inside the intranet, the WebsydianExpress runtime compares the IP-address of the PC running the browser with the IP mask specified by the "Intranet mask" site setting.
The Intranet Mask site setting specifies the start of a IP-address - e.g. "192.168.102", "192.168", "192.16" etc.
As long as the start of the IP-address of the PC running the browser is identical to the intranet mask, the session is determined as being inside the intranet.
This means that if the intranet mask is 192.168.102 - an IP-address of 192.168.102.199 will be determined as being inside the intranet, while an IP-address of 192.168.101.199 will be determined as being outside the intranet.
The administration interface is the most common example of functionality, which you will not accept being accessed from outside the Intranet.
When WebsydianExpress is being installed, the roles authorizing the site elements used in the administration interface are defined as being available in Intranet only.
Certain site elements are so sensitive that you need to ensure that all access to the site element happens through the Intranet.
In addition to determining which site elements a user can access, the roles are also used to determine which folder list the session will use.
Each role has an assigned folder list - one folder list can be assigned to many roles.
In addition to assigning folder lists to roles, you can also assign a folder list directly to a user. If a folder list is assigned directly to a user, this will always be the folder list assigned to session belonging to this user - irrespective of the roles assigned to the session.
For an anonymous session or if the user does not have any folder list assigned, the folder list used by the session is determined based on the roles assigned to the session.
One of the limitations of role-based authorization is that it does not provide any functionality for selecting between several authorized privileges.
This section describes a simple mechanism for performing such choices in WebsydianExpress.
You do not have to use this feature, it is only provided as a feature that will make the setup of the site easier and more flexible.
WebsydianExpress provides the option to specify a priority for each role: The higher the priority, the more important role.
If a choice between two privileges (site elements or folder lists) occurs - and the privileges are authorized by two different roles, the runtime will select the privilege authorized by the role having the highest priority.
An example of this could be a site having the roles: User and Administrator. All users belong to the User role, while the administrator belongs to the User and the Administrator roles. For the administrator, the Administrator role is more important than the User role - so in this case, the priority of the Administrator role will be set higher than priority of the User role.
In WebsydianExpress, there are two main situations, where the priority can be relevant.
As each role have one folder list assigned, and as a session can have more than one role assigned, it is evident that in some cases the runtime will have to choose between a number of folder lists to be able to assign a folder list to the session.
This will be done by comparing the priority of the roles that has the folder lists assigned. The folder list belonging to the role having the highest priority will be assigned to the session.
In case where only one role is assigned to the session, where the roles have the same assigned folder list, or where the user has a folder list specifically assigned, there will not be any selection, and the priority will be irrelevant.
When the site is loaded, each frame is populated based on the site structure definitions.
A frame will be populated by a site element, which is a child of the frameset site element - and which has the frame specified as target.
It is possible to specify more than one child element for each frame. An example could be the main frame for a page (shown as the first page when accessing the site) - this could have three different child elements defined:
1. The login page - for anonymous sessions (Role = "Anonymous")
2. A welcome page - for ordinary users (Role = "User")
3. An "Important information" page - for administrators (Role = "Administrator")
This does not necessarily make a selection based on priority necessary. There is no reason that any users should belong to the "Anonymous" role - and if all users either belong to the User role or to the Administrator role no session will be authorized for more than one of these child elements.
But in many cases, the administrators would belong to both the User and Administrator roles - and in this case the session would be authorized for both the welcome page and the "Important information" page. In this case, the runtime will select the site element authorized by the role having the highest priority - which normally would be the Administrator role.
In most cases the assignment of roles and folder list to a session is straightforward.
But as should be obvious from the above descriptions, there are some options that can interact to make these assignments more complex.
The two following diagrams clarifies the assignment of roles to a session (first diagram) - and folder lists to a session (second diagram).
This functionality is performed just after the session is created and when the session has been updated with new information about user and roles (e.g. when a user logs into the session).
The first action is that all roles previously assigned to the session is removed.
If it is an anonymous session, the anonymous user is read from the site settings. Concerning the assignment of roles to the session, this user is handled just like a "normal" user who have logged into the session.
The roles for the user are read one by one.
If the session is an intranet session the role is added to the session.
If the role is not an intranet session, the role is only added if it is not a role for intranet use only.
This functionality is performed after the roles has been assigned to the session.
If a user is assigned to the session - and this user has a folder list assigned - the session is updated with this folder list.
If no folder list can be found for the user, the roles are used to determine the folder list.
The roles assigned to the session are read, and the role with the highest priority is identified.
The folder list specified for this role is updated on the session.
The role-based authorization system is primarily used by the WebsydianExpress runtime and the normal way for you to interact with it is by using the administration interface.
But there are other ways, you can interact with the authorization system. WebsydianExpress provides a number of API functions that can be used to obtain information about the roles assigned to sessions, users and site elements - as well as providing functions that can be used to create or update these relations.
The most obvious use of these APIs is if you want to create your own custom-made user maintenance or login functionality. But the APIs also provides you with the possibility to limit access to part of the functionality in your own business processes to users having certain roles.
Online
documentation - WebsydianExpress v3.5