Access Control

Now we can address the requirements that our application should be accessed online by members and by guests who need to register themselves with the library system so that they can access it as members (see Requirements).

Naturally, members and guests who will be using our application online will have limited access to the application features. Therefore, we need to define access restrictions in our configuration.

Let us think through the scenarios of a member interaction with the system. A member should be able to do the following:

1. Log into the system using her own credentials
2. View/change her own details, but not details of other members
3. Search for library items, but not change details of these items
4. Reserve an item or cancel reservation
5. Renew her loan
6. Make credit card payment (we will look at this in Payment by credit card)

All other operations should be disallowed for a member.

We will look at each of these operations. Before we do this we need to configure the access level for members working with the application (see also the Access Control section in the Aware IM User Manual). Aware IM automatically creates the “Administrator” access level, which allows all operations by default, and the “Guest” access level, which disallows all operations by default. You can also define your own access levels. We will define the “Member” access level.

To do this right click on the “Access Levels” node in the Elements Tree and select “New” from the pop-up menu. The editor of the access levels appears in the working area of the screen. Enter the name of the access level “Member” in the list of properties and click on the “Save” button. The new access level appears in the Elements Tree. We will edit this access level as we go through the operations of a member.

Instances of the Member object will be created either by the operator or by guests when they register themselves with the system (see Error: Reference source not found). In any event when these instances are created the operator or guest should specify the user name and password of the new member (among other details), which means that the Member object should have these attributes defined. As a matter of fact, we do not need to define these attributes – Aware IM will do it automatically provided that we make the Member object part of the SystemUsers group (this is the special group that Aware IM automatically creates that contains all objects that can access the system). To do this we double click on the SystemUsers node (located under the “Business Object Groups” node) . In the editor of groups we select Member from the list of available objects and click on the right arrow button to make this object member of the group. We click on the “Save” button to save the changes to the group.

If we now look at the Member object we will notice that Aware IM has added a few attributes automatically – for example, LoginName, Password and AccessLevel. The last attribute stores the value of the access level that will be assigned to a member once she logs into the system. We need to assign an initial value Member to this attribute (this is the name of our newly created access level) and not allow anyone to change it. Therefore, we open the Member object for editing and set the initial value of AccessLevel attribute to Member.

We will define access level restrictions that will allow viewing/changing member’s own details but not details of other members in the Member access level. Let us open this access level for editing. In the editor pane click on the “Business object” node to expand it and show the list of all business objects. Click on the cell located at the intersection of Member row and Access column. Select the Creator:modify only from the drop down list. We have thus defined the access level for the Member business object that will make sure that a member will only be able to see/change her own details but not details of other members (she will also not be able to create instances of the Member object).

We can now expand the Member object and define access to its attributes. We need a member to be able to view and change the following attributes – FirstName, LastName, Address, EmailAddress, DateOfBirth, LoginName and Password, so we leave the access level for these attributes as Full access. A member should be able to view but not change the following attributes MemberNumber, Loans, Fees, Payments and Reservation so we change the access level for these attributes to Read-only. Finally a member should not be able even to see the following attributes AccessLevel and Status so we change the access level for these attributes to Not available.

A member must be able to search the library for items and view some details of the items but she should not be able to change any of the details. We can achieve this by setting read-only access to the Item object. We open the Member access level for editing and change access to the Item object to read-only just as we set access to the Member object at the previous step. We also want to make some attributes of the Item object unavailable to member (namely, Loans, Reservations, InternalStatus and CurrentReservation), so we set Not available access to these attributes.

A member should be able to reserve items when she is either looking at the results of the query that found some items or when she is viewing the details of a particular item. The operation that reserves items starts the ReserveItem2 process. This process runs the Member query to identify a member that reserves the item. When the application is used by a particular member, however, we do not need to run this query, as the member is already known (this is the member using the application). So we modify our process to consider this fact. The process rules now look like this:

IF 
 LoggedInSystemUser.AccessLevel='Member'
THEN
 CREATE Reservation WITH 
   Reservation.Item=Item,
   Reservation.Member=LoggedInMember
ELSE
 PICK FROM Member 
 CREATE Reservation WITH 
   Reservation.Item=Item,
   Reservation.Member=Member 

As you can see if currently logged in user has Member access level we create the reservation straight away without running the Member query. LoggedIn prefix in front of the object name can be used to identify the current user of the application (see also “Instance prefixes”).

For all other operations we just need to carefully go through all objects, attributes, processes, queries and documents in the “Member” access level and specify the appropriate access restrictions. For example, as far as processes are concerned we need to allow access to the following processes:

• ReserveItem,
• ReserveItem2,
• CancelReservation and
• RenewLoan. All other processes should be made unavailable.

You can check all access restrictions of the Member access level in the sample configuration of the application located in the samples directory of the Aware IM installation.

We now need to define a menu that will be specific to members only. The menu will have only one level and contain the following operations: My details, Search library, Home page.

The type of the My details operation should be Change login details. The operation of this type will automatically show the form of the current user and allow editing the details. The type of the Search library operation is Run Query that runs the Item query. Home page operation is of the Home page type – it shows the starting page of the application.

Now we need to create a new visual perspective called Member and define the menu as described above for this visual perspective (see "Register new member" operation). To make sure that this visual perspective is used by the system when members log in, we click on the Use in login property of the visual perspective and then tick the Aware IM will use this perspective when user logs in checkbox on the dialog that comes up. We will also click on the Access Levels button and specify the Member access level on this dialog.

To make our application look nicer for members we can create some flashy starting page of the application that will display some information about the library, run some advertisements etc. We can prepare this page in any HTML editor and import the results into the visual perspective for members. To do this expand the Main frame, the Main tab and click on the Main content panel under the Main tab. Then select the Contents property in the list of properties of the content panel and select the Display HTML page radio button. Then click on the Import button and specify the name of the directory where your custom page (and all its images and styles) are.

The operations guests can perform in the library application are these:

1. Search library for items and check item details (but not change these details)
2. Register themselves as library members and specify their details and credentials
3. Log into the library system if they are already registered

The task of configuring our system for guests boils down to specifying access restrictions in the “Guest” access level and preparing a visual perspective for guests.

Most of business objects, attributes, processes, queries and documents should be unavailable for quests. The only exception is the “Item” query that should be available and the “Item” and “Member” business objects. Access restrictions to the Item object should be exactly the same as in the access level for members. Access restrictions to the Member object should allow access to the following attributes: FirstName, LastName, Address, Gender, EmailAddress, LoginName and Password. Access to other attributes should be disallowed. Because guests will be allowed to self-register as members we should assign Creator:full access level to the Member object, which guarantees that guests will be able to view/change their own details, not details of other people.

The menu for guests will include the following operations:

1. Search library (type - “Run Query”, runs the “Item” query)
2. Register (type “Register User” for the object “Member”. The operation of this type will automatically bring up the form of the Member object and allow creating the instance of this object)
3. Login (type “Login”)
4. Home (type “Home page”)

We can add the visual perspective for guests in the same way we have added visual perspective for members. We should specify that the new visual perspective should be used for the “Guest” access level, import some custom home page and select a particular color style.