The ActiveGrid Studio allows you to create applications with Role-based Access Control (RBAC). With RBAC, users are assigned roles and are granted or denied access to different elements of the application based on those roles. RBAC is a feature available only in the commercial version of the ActiveGrid Studio.
The ActiveGrid Studio’s Role-Based Access Control (RBAC) feature allows you to configure your application to expose different elements to different users. Here’s how it works:
•
|
The defined roles and their associated rules are defined in an Extensible Access Control Markup Language (XACML) file. Note that you have to create these roles explicitly in .xacml file (the ActiveGrid Studio provides a tool for this). The .xacml file is not automatically populated from the roles in the database.
|
•
|
If a user has multiple roles, the most restrictive rule always wins. For example, suppose you have a restricted role, called delinquent, that you assign to users who are currently delinquent in their payments. You also have an unrestricted role, called normal, for users whose accounts are in good standing. All users with accounts are assigned to the normal role, but when a user’s payment is overdue, you also assign that user to the delinquent role. Because the most restrictive role wins, the user access is restricted, even though they are also assigned to the normal role.
|
While the rules for each role are defined in the ActiveGrid Studio, the roles to which each user is assigned are configured and maintained in a database, along with user IDs and passwords. The first step in adding RBAC to your ActiveGrid Application is to tell the Role Administration where your user/password/role information is stored. For roles, you can use any database supported by the ActiveGrid Studio or you can use Lightweight Directory Access Protocol (LDAP). The steps are slightly different for LDAP than they are for the databases.
If you have user roles defined in an existing database, you just configure the ActiveGrid Studio Role Administration appropriately. The process is slightly different for LDAP than it is for databases.
1.
|
Open the Page Flow ( .bpel) file for your application.
|
3.
|
Click the Configure button at the top left of the screen. The Configuration screen appears.
|
4.
|
Click the LDAP radio button at the top right of the screen. The LDAP configuration fields are now enabled.
|
•
|
LDAP URL: This field specifies the host name and port number of the LDAP server.
|
•
|
Bind DN: This field specifies the DN of the user that will be used to bind to the LDAP Server. The activegrid runtime needs to bind as this DN in order to have access to the LDAP server.
|
•
|
Base DN: This field specifies the DN of the node where the search for a user would start. It can be the suffix or root of the directory such as dc=activegrid, dc=com.
|
•
|
Login Attribute Name: This field specifies the LDAP attribute to use for login. By default, it assumes that user entries are identified by the uid attribute. If your Directory Server uses a different attribute (such as cn), specify the attribute name in this field.
|
6.
|
Click OK. This completes the LDAP configuration.
|
In order to configure roles to work with a database, the data source for your application needs to include a complex type that has elements you can use for user name, password, and role. See
Adding Roles to a Database for instructions. Once you have user roles defined in the data source, you configure the ActiveGrid Studio Role Administration as follows:
1.
|
Open the Page Flow ( .bpel) file for your application.
|
3.
|
Click the Configure button at the top left of the screen. The Configuration screen appears.
|
4.
|
Click the Database radio button at the top right of the screen. The Database configuration fields are now enabled.
|
•
|
Complex Type: In the Data Model for your application ( .xsd) this is the complex type that contains the elements you plan to use for username, password and role.
|
6.
|
Click OK. This completes the database configuration.
|
If you do not have user roles defined in your database, you can set them up in your
Data Model and export them to your database. To do this, follow these steps:
1.
|
Open the Data Model ( .xsd) file for your application.
|
•
|
Table: This should be the table that contains columns for the login name and password.
|
•
|
Column Kind: Select the Database column or expression radio button.
|
4.
|
Click Next. The Column Properties screen appears.
|
•
|
SqlType: Assuming you’re using a string for the role, it’s best to leave the SqlType field as the default, which is varchar. The SqlType is the SQL 2003 data type of the column to which this element is bound. Used when creating DDL statements and when converting values read from/written to the database.
|
•
|
Length: The number of characters which should be used in input or output fields displaying this element.
|
•
|
Binding: Database column to or from which this column stores or retrieves its value. When you export this column to the database, this will be the name of the database column for the role.
|
•
|
Nillable: Boolean indicating whether a value must be supplied for this column or whether it can be left null. The role can be null.
|
•
|
Label: Label used in forms including this column. By default this is populated with the column’s name but you can use whatever label you want.
|
•
|
Short Label: Label used for column headings displaying this column.
|
7.
|
Save the Data Model file. The Data Model now contains an column for user roles, but the database does not yet contain a column for roles. You now need to export the Data Model to the database:
|
8.
|
From the Tools menu select the Export Database... option. The Export Mode screen appears.
|
10.
|
Click Next. The Add New Columns screen appears. This screen should show the elements you added to your Data Model.
|
11.
|
Click Next. The Preview SQL screen appears. This screen shows the SQL command that the tool will execute on the database.
|
12.
|
Click Next. The Export Results screen appears.
|
In order to define access roles for your application, you simply add each role to the role configuration file (
.xacml) using the Role Administration tool and then create rules for each role. When you run the application, the ActiveGrid runtime gets the user login and role information from the database and it gets the rules for each role from the
.xacml file. So each role that is assigned to a particular user in the database needs to be defined in the
.xacml file.
To define a role in the .xacml file, follow these steps:
1.
|
Open the Data Model file ( .xsd) or the Page Flow file ( .bpel) for your application.
|
2.
|
Right click and select Configure Role Administration... from the resulting pop-up menu. The Role Administration screen appears. If the .xacml file already has some defined roles, they are displayed in this screen.
|
3.
|
Click the Add button. The New Role dialog appears.
|
•
|
Deny Read and Update: This rule means that the user cannot see or edit the selected element or complex type. For example, if a Page contains an output field that references the selected element, that output field does not appear to the user.
|
•
|
Deny Update: This rule means that the user can see but cannot edit the selected element or complex type. For example, if a Page contains an input field that references the selected element, that input field is not enabled. However, the existing value is displayed to the user.
|
6.
|
To add a Deny Read and Update rule, click the Add button for that field. The Deny Read and Update screen appears.
|
•
|
Complex Type: Select the complex type that contains the element or elements to which you are denying access.
|
•
|
Element: Select the elements to which you are denying access.
|
9.
|
To add a Deny Update rule, click the Add button for that field. The Deny Update screen appears.
|
•
|
Complex Type: Select the complex type that contains the element or elements to which you are denying edit permissions.
|
•
|
Element: Select the elements to which you are denying edit permissions.
|
13.
|
Then click OK. Save the file. You can always go back and add or delete rules for this user role.
|
To open the Roles Editor, double-click on the .xacml file in the Project panel. The
.xacml file appears in the Roles Editor. The Roles Editor lists all the roles that are defined in the
.xacml file. To see the rules for a role, select it in the list. You can delete existing rules for a particular role or add new ones. You can also add and delete defined roles. Be careful adding and deleting roles because these need to exactly match the role values assigned to users in the database.
Before you deploy your application, you can add and delete rules for any role through the Roles Editor. You can also add and delete roles here. Remember that the roles defined in the Roles Editor need to exactly match the value of the Role in the database.
For example, if the database contains a user ID of Bob with a Role value of
Manager, and you delete the role named Manager from the
.xacml file, then that user does not have a defined role. Since Roles are case sensitive, you would get the same result if the database has a Role value of
Manager, but the
.xacml file has names the role “manager” (all lower case). In either case, unless the user has an additional role, the user is assigned no role.
After the application is deployed, you cannot add, delete or edit roles without redeploying the application. You can, however, change which roles a specific user is assigned to, because this information, like users and user passwords, is stored in the database, rather than the application files.
When a user is not assigned to any role, that user gets read and update access to everything. (This is different from guest users, who are users who have not logged in to the application. The access for guest users is configurable).
Guest users are users that use an application without logging in with a user ID and password. If your application allows users to do this, you should set a role for the guest user.
To set a role for the guest user, open the .xacml file in the Roles Editor. At the bottom left of the editor, select a role from the
Guest Role: pull-down menu. This menu lists all the roles defined in the
.xacml file. You can assign any role to the guest user, although it is safest to define a separate role for guest.
As you’re working on your application in the ActiveGrid Studio, it is sometimes helpful to disable the Role-based Access Control across the entire application. For example, this can help you determine whether a bug is an RBAC problem. To disable/enable RBAC open the
.xacml file in the Roles Editor. At the top left of the editor, under the
Configure button, click to uncheck the
Enable Role-Based Access Control check box. Save the
.xacml file. To enable RBAC again, check the box and save the file.
As with other changes to the .xacml file, if you want to enable or disable RBAC after the application is deployed, you will need to redeploy.
Once you have defined roles in an application, you can preview each Page to see how it would appear to a user with a particular role. To preview a Page by role, double-click on the
.xform file to open it in the Page Editor. Select a role from the
Preview by Role pull-down menu at the bottom of the form.