Scenario: Web Expense Application

Applies To: Windows Server 2003 with SP1

In this scenario, a Web-based expense application uses the following procedure.

1. A user goes to the URL of the expense application and chooses to enter a new expense report.

2. The user enters the expense report and submits it for approval.

3. The manager receives e-mail notification that the expense report is awaiting approval.

4. The manager goes to the approval URL, which allows the manager to inspect and approve or reject the expense report.

5. If the manager approves the expense report, it is added to a verification queue, where a verifier can inspect the report, collect receipts, mark the expense report Approval-verified, and request a reimbursement.

Operations

In the above expense application scenario, the operations can be defined as:

• ExecuteExpenseControls. Use the controls that allow user to fill out the expense form.

• ExecuteApprovalControls. Use the controls that allow user to approve the expense.

• RetrieveExpenseForm. Retrieve requested expense form from database

• SaveExpenseForm. Save the expense form to local machine.

• EnqueApproval. Put a copy of the completed form in the approval queue.

• DequeApproval. Remove the expense from approval queue.

• SendRequestNotification. Send e-mail to the manager that requests approval.

• SendApprovalNotification. Send e-mail notification of approval.

• ApproveDenyExpense. Mark the expense as approved or denied.

• VerifyApproval. Mark the expense as Approval-Verified.

• SetExpenseLimit. Set the limit amount that various roles can approve.

• FwdRembursment. Send a message to Accounts Payable.

• ReadApprovals. Read the expense forms in the approval queue.

• ReadArchive. Read the expense forms in approval archive.

Tasks

Each of the above operations may be needed in several expense application tasks that a user may need to do. Applications that use tasks should test each task as a stand-alone requirement that does not require any other task or operations permission.

In the expense application scenario, the tasks could be:

• Create Report. Routines to fill out an expense report. Operations (ExecuteExpenseControls, RetrieveExpenseForm, SaveExpenseForm.)

• Submit Report. Routines that upload the expense report to pending state, Sends e-mail to manager. (EnqueApproval, SendRequestNotification)

• View Report Routines that display a pending report. Operations ([Create Report] + AddApprovalQueue + SendNotification )

• Approve Report Routines that cause report to move from Pending state to Approved state, Sends e-mail to submitter and notifies payment system.

• Verify Approval Operations required to mark expense as Approval-Verified and forward reimbursement request to Accounts Payable. Operations (ExecuteApprovalControls, ApproveExpense SendApprovalNotification, FwdRembursment)

• Audit Report Allows reading of reports in approval queue and approval archive (ReadApprovals)

• Config Limits Allows the setting of approval limits for employees and managers (SetExpenseLimit)

BizRules

In the Web expense application, an Approve Report task would have the following BizRule attached.

Dim Amount 
BizRuleContext.BusinessRuleResult = FALSE 
Amount = BizRuleContext.GetParameter("Amount") 
Limit = BizRuleContext.GetParameter(Limit) 
If Amount < Limit then BizRuleContext.BusinessRuleResult = true

Attaching the above BizRule to the Submit Report task requires that the given expense is less than the limit amount that has been passed. The Amount parameter is retrieved by the application from the expense report, while the Limit amount is configured by the administrator of the Web expense application.

Roles and role definitions

For the Web expense application, the following roles are defined during installation.

Role assignments

Role assignments are configured by the Web expense application administrator after installation. An administrator might use:

• User: A Windows Active Directory group for all employees.

• Manager: An LDAP query group that checks title and number of direct reports.

  (&(Title = Manager)(numReports > 0)) 
  

  The Active Directory schema may be extended to support these properties on the user object. These properties would be maintained by a separate human resources application.

• Verifier: An application basic group that lists each user who verifies each expense.

• Expense Admin: An Active Directory group that contains the users in the expense accounting department.

After using one of the above techniques to create an Authorization Manager client context, the Web expense application can then call the AzClientContext.GetRoles method on the client context interface to determine which roles the user is assigned. This allows you to use the clients role membership to determine what options to display for the user.

If the user is in the Employee role, then the expense controls are displayed, which allows the user to submit an expense. If the user is in the Manager role, the displayed page has an additional area that lists the pending expense forms that have been submitted.

Closely relating role names to application logic makes modifications difficult for administrators, so a convention must be used by the application to customize presentation, based on role memberships. In this example, Employee and Manager roles are not hard-coded into the application. Instead, the role name corresponds to a similarly-named HTML file. Additionally, the ApplicationData property of the AzRole object may be used to provide the application with presentation information.

When the user clicks a form button to create a new expense report, the Web expense application calls AccessCheck, sending in the operation values that correspond to the ExecuteExpenseControls, RetrieveExpenseForm and SaveExpenseForm operations. By doing this, you prevent restricted users from loading these controls and degrading performance. If the user has access to the controls, the controls are displayed, an expense form is retrieved from a SQL store and loaded into the control, and the user is allowed to enter the expense data. When completed, the user clicks Submit and the Web expense application calls AccessCheck, specifying the operations that are needed to submit an expense, for example, the operation number corresponding to EnqueApproval or SendRequestNotification. Additionally, the amount of the expense is sent into AccessCheck as a BizRule parameter called Amount. If access is allowed, the expense report is uploaded to a SQL queue of pending requests and an e-mail is sent that notifies the users manager of the pending request.

To be able to perform these operations, permissions are needed on several back-end resources. These include the NTFS directory from which the expense form is retrieved, the SQL database for submitted expense reports, and a Web expense Microsoft Exchange account which can be used to send e-mail notifications. Instead of impersonating and performing operations as the client, the Web expense service account should be granted enough access on back-end objects to perform the operations that the application needs. Therefore, back-end DACLs only grant access to the Web expense service account. (For more information, see "Trusted subsystem application model" earlier in this paper.)

When a manager sees the pending expense as described above), AccessCheck verifies the ability to use the approval controls. The manager then browses the expense details and clicks Approve or Deny and AccessCheck is called on the operations: DequeApproval, ApproveDenyExpense and SendRequestNotification. Additionally, the Amount, ApprovingMgr, and Submitter parameters are given the values of the amount of the submitted expense, the current user attempting to approve or deny the expense, and the name of the person who submitted the expense, respectively. During AccessCheck, a BizRule validates the calling user as a manager of the submitting user by checking the relationship in Exchange or SQL and verifies that the amount is within a specified limit for the current approving manager.