This documentation is archived and is not being maintained.
Build a Single-Step Provisioning Workflow
At a Glance:
- Using MIISWorkflow
- Implementation and configuration
- Extending MIISWorkflow
If you’ve been looking for a Web-based interface for requesting and approving accounts and your organization employs Microsoft Identity Lifecycle Manager 2007 (ILM 2007, formerly Microsoft Identity Integration Server 2003),
then the MIISWorkflow application may provide a simple and effective solution. MIISWorkflow is part of the MIIS 2003 Resource Tool Kit 2.0 and has been available since December 2004. Although not necessarily a complete solution for every environment, it is a good starting point for building a custom application that fits your organization’s needs.
MIISWorkflow provides approval-based provisioning functionality to ILM 2007 by integrating a Web application. It is a one-step, workflow-driven provisioning system that accepts requests from users and routes them to approvers (typically managers) with sufficient authority to make decisions regarding the specific requests. Based on the approver decision, ILM proceeds with user account provisioning in connected directories using business rules defined in ILM.
This application can facilitate only a single-step workflow; it cannot create complex workflow features, such as a multiple-step approval process with parallel paths or a workflow process with a graphical interface. If your organization does not require these complex workflow features, you can use the MIISWorkflow sample provided by the MIIS Resource Tool Kit to implement a solution.
I’ll focus here on the Human Resource department of a fictitious company. In general, HR systems are the authoritative source for all employee information within an organization. However, while these systems usually have detailed data for permanent employees, they often lack information about temporary workers, such as contractors and student interns. The data contained in an HR system may not track which systems users can access, including the user account information. I’ll show you how to build a simple tracking system for temporary workers within an organization.
Building on MIISWorkflow
An example of how organizations can take advantage of the MIISWorkflow is to create an application that works in conjunction with existing HR systems. When a new employee is hired, user information is added to the HR system. You can design ILM flows that send the information to the MIISWorkflow database and then utilize the workflow application to route user information to approvers before ILM provisions the account in connected directories.
If your organization does not use HR systems to track temporary workers, the MIISWorkflow application can be used as the authoritative data source to manage their accounts in enterprise directories. Since the workflow application reduces the paper-based administrative work needed to obtain approvals, users do not have to wait for days to access accounts in directories and applications. You can also use MIISWorkflow to enable rapid revocation of access, thus enhancing organization security.
MIISWorkflow can also be used as an audit tool to track the number of systems that a user can access, the request and termination dates for each account, and the requestor and approver of each account. The ability to generate reports with detailed account history can facilitate an organization’s compliance with regulatory acts such as Sarbanes-Oxley and HIPAA.
The MIISWorkflow application runs on IIS and uses directory integration and provisioning features of ILM 2007 to provision and deprovision accounts in connected directories. Components of the workflow application include a collection of ASP.NET Web pages, a SQL Server™ database, a management agent, and an authorization policy store (see Figure 1). The application uses SQL Server for data storage, Active Directory® for authentication, and a policy store with Windows® Authorization Manager (commonly known as AzMan) for authorization.
Figure 1 MIISWorkflow application architecture (Click the image for a larger view)
The application can be extended and customized using C# and ASP.NET. MIISWorkflow consists of these five .aspx pages: ContractorApproval, ContractorHistory, ContractorRequest, ContractorStatus, and ContractorUpdate. These pages allow administrators to request, update, approve, and track the status of each user account in the system. Note that, by default, the MIISWorkflow application is set to use IIS Integrated Windows Authentication to take advantage of Kerberos.
The workflow application triggers ILM based on the action of the approver, and ILM provisions or deprovisions user accounts in connected directories using defined rules. Immediately after an action has been taken on the request, the application triggers ILM and requests do not have to wait until the next ILM synchronization cycle for provisioning and deprovisioning to occur in connected directories.
The workflow application requires the MIISWorkflow database to store users’ account information. This is separate from the database where ILM stores metaverse information, but it is configured on the same SQL Server instance. When authorized users request an account through the workflow application, the information is saved by MIISWorkflow. The information is then rendered through an ASP.NET Web page when an approver accesses the page. MIISWorkflow also stores histories of actions and other information about the account in the database. ILM imports the information from the MIISWorkflow database using a SQL Server management agent that comes with the application and provisions or deprovisions the account as necessary.
AzMan, used by MIISWorkflow for authorization, provides role-based access control (RBAC) for managing tasks that users are allowed to perform in the application depending on their assigned roles. (See go.microsoft.com/fwlink/?LinkId=85825 for more information on RBAC.) After a user has been authenticated in Active Directory, thus allowing access, the workflow application checks roles defined in the AzMan authorization store to authorize the operations a user can perform. There are two roles predefined for the application: contractor requestor and contractor approver. Users or groups with the contractor requestor role can only put in a request through the application, but users or groups with the contractor approver role have the ability to create requests and approve or deny requests.
The MIISWorkflow application authorization policy is stored in an XML file. Either Windows users and groups or application groups can be assigned to defined roles. Application groups allow an LDAP query to perform a runtime look up of a user’s Active Directory or Active Directory Application Mode (ADAM) account object based on the attribute value; the user is in the group such that (department=‘marketing’), for example, returns true.
Application administrators control access to the application using AzMan. Depending on how the application is utilized in your organization, you can grant a contractor requestor role to all domain users or only to selected groups. The contractor approver role should only be granted to users and groups who have authority to approve or deny requests. Selected HR administrators, as well as system and group administrators, usually possess this role. By default, the MIISWorkflow application uses IIS Integrated Windows Authentication as its authentication method, so the application will authenticate users through their Windows desktop logon credentials—this means that users will not be prompted again for credentials to authenticate against the application.
A user in the contractor requestor role can point the browser to the contractor request page in the application and supply information about the contractor to request an account for that contractor. Figure 2 shows the contractor request page.
Figure 2 New Contractor Request page (Click the image for a larger view)
The person in the requestor role fills in the pertinent contractor information and submits the request. There is a link to approve requests and a link to check status on the page, but requestors cannot access the approver page unless they are also in contractor approver role. A requestor can click on the Contractor Status link to view his own requests, but will not be able to view the status of requests submitted by others.
Only a contractor approver has access to the contractor approval page in the application, where he can approve or deny the request after reviewing the information. Figure 3 shows the interface of the Contractor Approval Web page.
Figure 3 Contractor Approval page (Click the image for a larger view)
A contractor approver can see requests submitted by all requestors. Any contractor approver can approve the request and only one approval or denial is necessary to route the request to the next stage. The request will disappear from the contractor approval page once action has been taken by the approver. This minimizes redundant approver actions.
To review new requests and to take action on pending requests based on organization requirements, an approver needs to access the contractor approval page regularly as there is no notification mechanism in the application to tell the approver of new requests or a backlog. As soon as the approver approves or denies the request from the page, the application triggers ILM and accounts are provisioned or deprovisioned in connected directories based on the approver’s action.
Figure 4 Contractor Status page (Click the image for a larger view)
The status of pending requests and records of completed requests can be tracked from the contractor status page (see Figure 4). A requestor can undertake several actions from this page. You can view your own requests, including information such as employee ID, first name, last name, department, status, and last modified date. You can also edit the existing information, view history, and terminate a contractor’s account. You can modify first and last name and department information, and resubmit the information for approval. And, finally, you can view a log of actions taken on the request along with the date and time of each action from the contractor history page (see Figure 5).
Figure 5 Contractor History page (Click the image for a larger view)
The MIISWorkflow application makes account termination seamless by allowing a requestor to terminate contractor accounts from the contractor status page. The requestor can click on the terminate link to immediately disable or delete contractor accounts in connected directories. The advantage of this ability to terminate contractor accounts from the workflow application is that system administrators do not have to search for the contractor account in each directory and manually delete accounts. Since the MIISWorkflow application immediately triggers ILM to deprovision those accounts in connected directories, there is no lag time to delete those accounts.
Configuring the Application
The configuration of the MIISWorkflow application involves setting up a service account, setting up the database for the application, configuring ILM to work with the workflow application, configuring IIS, and configuring the policy store. The application contains prebuilt scripts and configuration files to simplify this process.
The MIISWorkflow application comes with a T-SQL query file to make the process of creating a MIISWorkflow database easier. You can load the query file in the Query Analyzer and execute the query to automatically create the database.
Configuration of IIS involves creating a new IIS application pool and a virtual directory, and setting authentication and access control to host ASP.NET pages. The application also comes with an XML file with predefined roles to configure an authorization policy store. You can assign users and groups to existing roles and create new roles using the AzMan MMC.
The final step is to configure the management agent in ILM to import data from MIISWorkflow database to ILM. You do this by importing the management agent configuration in the XML file and copying a prebuilt extension file for the SQL Server management agent. Both the XML file and the management agent extension file are provided with the application. There is a readme file with step-by-step instructions on how to configure each of these steps.
Extending the Application
The MIISWorkflow application provides a starting point for developing simple workflow integration with MIIS and you may need to make a few customizations to extend the application. Besides simple modifications such as changes to the Web pages, there are many other ways to extend this application.
You could add a notification feature so that an approver would receive an e-mail message when there is a pending request. This feature could also send a reminder message to the approver, within a specified number of days, if no action has been taken on the request. If you require more information about users than the default page provides, you can add fields to both the contractor request page and contractor update page. You can add more roles to the application, such as an auditor role that would allow a user to view the history of every request, not only the requests she has submitted.
More complex workflow features, such as a multi-step workflow and the ability to design a workflow using graphical designer, are not within the scope of this application. However, you can use Windows Workflow Foundation to develop a more robust application with complex workflow features.
You’ll find the MIIS Resource Tool Kit at go.microsoft.com/fwlink/?LinkId=85829. Download it today and get started building your own identity workflow solutions.