Like many people, you probably have questions about planning a solid K2 deployment. You don't want to underplan for a deployment by not taking into account the different moving parts that make up K2. And it's easy to become overwhelmed by looking at the architecture diagrams and listing out all the different services, databases, and integration points. You may wonder how scalable K2 is, can it run on one box, can it scale, and even how does it scale? The answer is always the same: It depends.
While K2 has much in common with many other three-tier applications, it is also different. It is different in that the workload profile can change dramatically from customer to customer and even from process to process. Some customers may use SharePoint; some may not; some may use ASP.NET forms, and some may use InfoPath. Some may use K2 to integrate with many back-end systems; some may not integrate it at all. There are too many variables to accurately predict, with any degree of certainty, a formula for how to scale.
While the architecture of K2 does correlate to a normal three-tier server application, it also differs in that the tiers can vary.
The front tier can be Web forms, InfoPath forms services, SharePoint, or virtually anything you can imagine. The application tier is the K2 server along with its ancillary services, such as SmartObjects interfaces and the Web services for SharePoint. The data layer is the set of K2 SQL Server databases. However K2 can also use various back-end systems as a data layer where the K2 server acts a broker to the other backed systems and their data.
This chapter will not give you a magic formula for how to calculate the exact deployment model and configuration that will work best in your particular situation. Rather it will attempt to give you guidance on particular aspects of your environment to consider, and particular things to plan and watch for. It will also explain the architecture and attempt to point out the most important aspects according to how you plan to use the platform.
There is a significant advantage to understanding the K2 architecture before you start to examine different deployment models. You need to understand the various K2 blackpearl components that are involved in a deployment of K2 before deploying it or updating an existing deployment.
This chapter covers the following topics:
An overview of the K2 architecture
Considerations for building a K2 plan
Guidance on choosing a K2 deployment architecture
Infrastructure considerations in a K2 environment such as Kerberos, AD, and DNS
The overall K2 architecture is built on and includes different Microsoft components so it is important that we include them in any discussion on the architecture of K2. Depending on the different components being utilized, all or some of these components will be installed. When you are designing your environment, you should be aware of each of these pieces and what functions they perform, so that you have an environment that performs well today and is ready for tomorrow.
At a high level, the K2 blackpearl server uses common Microsoft components, such as the .NET 3.0 Framework, which includes Windows Workflow Foundations (WF) and Windows Communication Foundation (WCF). The K2 blackpearl components are discussed in further detail in following sections.
You can think of the K2 blackpearl components as being divided into two categories:
We next take a look at these different components in some detail.
The client components include K2 Designer for Visual Studio and K2 Designer for Visio and K2 Studio.
The K2 Designer for Visual Studio is a design environment for creating process-driven applications that may be extended with custom code. The K2 Designer is built on top of Visual Studio 2005 and is geared primarily towards the developer audience. Be sure to check out the system requirements in either the Getting Started Guide or other installation documentation, as there are several different requirements you must address before installation.
The K2 Designer for Visio allows Visio diagrams to be extended with workflow design capabilities. The K2 Designer for Visio and K2 Studio are the design tools for the business analysts. Processes designed in K2 Studio and Visio can be opened later in the K2 Designer for Visual Studio for more advanced functionality and allow the developer and the business analyst to collaborate on a design. For more information on collaborative development see Chapter 14. From the installation perspective, the K2 Designer for Visio can be installed by itself on a client machine without other K2 components. Obviously, Visio 2007 (Standard or Professional) is a prerequisite.
Server components are the principle components responsible for running the processes that are deployed from the designers. The primary component is the K2 server itself. The K2 server requires access to the K2 databases to run successfully.
In addition to the K2 server, the server components include:
Workspace and Web Components
K2 for SharePoint
K2 integration with SQL Reporting Services
K2 Workspace and Web Components allow you to design reports, manage servers, and manage security and notifications. All of these can be accomplished in the K2 Workspace. Figure 5-1 shows K2's Workspace architecture.
Some features included in the K2 Workspace are:
Worklist
Management Console (SmartObject Services, Environment Library, Workflow server, SmartBox, Roles)
Report Designer
Notification Event Designer
Carefully think through how you plan to leverage the Workspace. You can use it to surface user worklists or you can do this in other ways, for example in the SharePoint Web part or a custom application. Also consider your use of the Workspace for its reporting function and how much it will be used for this purpose. The Workspace is built in a modular fashion to allow different functionality for the K2 platform. Access to each module can be controlled by a server administrator using the Security module.
The Management Console is a mechanism through which one or more K2 blackpearl servers can be managed. This includes setting security rights on the server and on processes, accessing the global worklist, creating Service Object instances, managing Environment Library templates and fields, creating user roles, creating process instances, configuring working hours, and troubleshooting process errors.
For more information about administrative tasks, see Chapter 15.
The K2 for SharePoint component is split into two separate versions. The installer will install only the component that corresponds to the version of SharePoint you have installed. There are two versions, for Microsoft Office SharePoint Server 2007 or Windows SharePoint Services v3.0. They are installed on the SharePoint servers and enable interaction and communication between K2 server and functions found in SharePoint, including Microsoft InfoPath processes.
The following integration features require Microsoft Office SharePoint Server 2007:
Business Data Catalog
InfoPath Forms Services
Publishing sites and pages
Records management
The remaining integration features that K2 for SharePoint provides are available on any edition of Windows SharePoint Server v3.0:
This component allows K2 blackpearl to interact with Reporting Services of Microsoft SQL Server 2005 SP2 or greater. The .NET Data Provider for K2 SmartObjects allows custom applications to query SmartObject and workflow data from the K2 server. Reports can be hosted in Reporting Services to provide scalable reporting capabilities.
The entire K2 platform architecture is depicted in Figure 5-2. We will now break it down to give you a better idea of what you will be using. To begin let's talk about the hosted servers.
While the hosted servers can be disabled on each K2 blackpearl installation, the core servers and hosted services are required on every installation of K2 blackpearl. In this section, we'll describe each "server" and give you a high-level overview of each component.
This server is responsible for all workflow-related tasks as its name suggests. These can be actions, such as the starting of a process or kicking off a specific activity or user task assignment. This server would also be responsible for evaluating each Line Rule in a process or assigning the tasks of an event to participants.
The logging component is responsible for reading from the K2server database and writing all necessary audit and logging information to the K2serverLog database. See the database breakdown chart for more information on this later in the chapter to understand this relationship better.
The Workflow Management server component is responsible for overall management of the workflows. These tasks can include such things as managing rights and permission to the process, and managing permissions to the global worklist that is surfaced in the K2 Workspace.
The Environment Library is a very critical component in K2 blackpearl and will be discussed in more detail in Chapter 10. Essentially, the Environment Library provides the K2 platform with the ability to deploy to different environments based on the stage of the development process.
The Event Bus allows a person to set notifications or actions based on events, thus increasing visibility into the business. These notifications can be set to occur when there is a change to specific data, when a process starts, finishes, or changes. These events can be raised by third-party servers, from a process, or from a single or recurring schedule. There are three hosted servers that compose the broader Event Bus component. The first is the run-time component, which in the diagram is simply referred to as Event Bus. The other two are Event Bus Scheduler and Event Bus Management.
This uses the SourceCode.EventBus.ClientRecorder to schedule events on specific schedules. For example, you can have events fire on the first of every month.
This is the management component of the Event Bus and is used in conjunction with the Event Bus Scheduler for scheduling new events.
You will learn more about SmartObjects throughout the rest of the book. (Pay special attention to Chapter 7.) SmartObjects are building blocks of data that can encapsulate information from multiple sources and can be used and reused to build process-driven applications. For the purposes of talking about the hosted servers and SmartObjects, there are two main elements:
The run-time component for working with deployed SmartObjects, shown in Figure 5-2 as SmartObjects.
The management aspect of SmartObject services, shown in Figure 5-2 as SmartObject Management. This loads each Service and Service Object instance, while the run-time aspect executes and performs data brokering between the K2 server and the line-of-business (LOB) system.
The core servers are fundamental pieces of the infrastructure that the "hosted services" can all leverage. For example, the User Role Manager (URM) provides the ability to authenticate and authorize users. Thus, all the hosted servers can leverage it any time they need that functionality.
This is the service that all objects use to register their dependencies. For example, when you are deleting an object or incrementing its version, this service will manage the interdependencies of that object with other objects.
This hosted server provides the hierarchical system for deploying processes and SmartObjects as well as for categorizing reports and notifications.
Notice in Figure 5-2 that three services are categorized as hosted services. These serve as communication bridges between servers.
The Discovery service is K2's way of finding other blackpearl services that have been distributed. The Discovery service actively listens on port 49599 (this is the default but can be changed in the DiscoveryService.config file). The Discovery service does not send out a broadcast. There is an API in place that allows for the discovery of hosts. When a component wishes to locate other servers on the network, they send out a broadcast, via the API, to the configured port (49599). Each HostServer that is running the Discovery service on that port will then respond back to the individual IP address that made the search request. The response to the search request includes the HostServer machine name and the port, which the HostServer is listening for connections on.
The Dependency Service is the hosted service for objects, such as processes and SmartObjects, to register their dependencies. It is also used to determine interdependencies of K2 objects, such as processes and SmartObjects.
The TCPIOP layer handles all communication from the standard client APIs typically used by developers, such as SourceCode.Workflow.Client and SourceCode.SmartObjects.Client. Those API calls are then handed off to the run-time component of the particular hosted server using the internal marshaling provided by the Host server. The K2 server pictured above it in Figure 5-2 shows the run-time architecture of the server, including the management portions. Design-time components are provided by the various APIs. Currently all client and management API communications occur over TCP port 5555, except for the workflow communications, which occur over TCP port 5252. This is for backward-compatibility reasons with K2.net 2003. Essentially there are two integrated communication services (one for each port), but only the Workflow hosted server is able to use the backward-compatible 5252 port. All other hosted servers, including the Workflow Log and Workflow Management servers, use port 5555.
Sitting behind it all and at the heart of any K2 deployment are the databases. Keep in mind that in any deployment, each database (see the following table) can be separated to run on different servers, which may be desirable depending on how much each database will be accessed.
The two databases that should be considered the most important are K2server and the K2serverLog (these are default names and can be changed). K2 needs these databases to store its state data. The data must be held both in current instance form and historical (audit) form in order to log all transactional data. These databases contain the transaction and log data, respectively.
These databases can physically reside on the same or different servers.
The purposes of the two databases are very different. The transaction database (K2server) directs internal transactional processing and should not be modified or accessed directly.
The K2serverLog database can be divided into two halves:
The design-time data: The design-time data contains all the process definitions. The reason that this data is duplicated here is that reporting components (such as K2 View Flow) make use of this definition data in order to render a view of the process definition, and then overlay the run-time data on it. Without the design-time data, there would be no definition data (such as the coordinates of process elements), which allows the design view to be rendered.
The run-time (instance) data: The run-time data (also called the instance data) contains all the data for the running instances of processes and their components. This includes details all the way down to audit information for when process and activity data are changed. The level of data logging is set in the K2 Workspace, and can be set per process. By default, all details for each process are logged.
Now that you have a good understanding of the pieces that make up K2, you will be better prepared to start the exploration of what a good deployment model is for your environment.
When determining architecture for your K2 infrastructure, there are many considerations, according to how you plan to use the different components. You need to develop a profile of the processes planned and how they will be leveraging the K2 infrastructure. You need to understand not only the processes themselves but also their users. If this is not possible, you should ensure that you keep the design as flexible as possible, thus allowing for changes as the user population grows or changes. These questions will form the basis on which you make decisions about your architecture. Keep in mind, when creating a plan and picking an architecture, that the most critical component of any K2 deployment is the database, as is the case with many data-intensive applications. K2 relies heavily on the database for everything that it does, and requires information to be read from and written to the various databases constantly. If you have to pick one layer of the architecture to focus on from a resources and hardware perspective, this is the layer to choose.
How many users will there be?
Consider how many total users there will be and how many may be using the system concurrently at any given time.
Take a look at the mix of user interactions with the processes you plan. Effects can be starting processes, reporting on processes, and including out-of-the-box and custom reports.
Having users performing different tasks at the same time will have a different effect on overall system load as opposed to users acting on and interacting with the system in different ways at different times. For example, consider the difference between a user running a report through the Workspace, thus accessing and putting overhead on the system via a Web site, and a user actioning interacting with a process via an InfoPath form through the InfoPath K2 Web service. Each of these components can be on different servers and can be accessing different databases.
Where is the data for the processes coming from?
Having data stored within the process in SmartObjects vs. having to go to back-end systems to retrieve necessary data will affect response time. Having a significant number of these processes may require you to add additional hardware resources.
Where is it being stored?
Data storage requires long-term capacity planning on the database side. Take this into account if you are increasing the storage within the process or within SmartObjects.
If you are doing any type of document workflows, what are you doing with attachments?
Storing these with the process data is not recommended because it will greatly increase the amount of data being moved by the server.
What number of processes do you have today, planned for this quarter, next quarter, and this year, and how many total people will be involved in those in all aspects of system usage?
You need to make sure that you appropriately gauge the level of adoption of K2 in your organization and work to make sure that you size appropriately for growth.
What about in 18 months?
You have to decide, as an organization, how far out you wish to plan before you would feel comfortable taking a look at rearchitecting the system (which may happen when there is a significant change in needs).
Will you need to add layers or resources to the environment to adapt to this?
To help alleviate load, many organizations scale out, add additional Workspace servers, or add servers to their SharePoint farm
What components or architecture layers will be the most important in your environment?
Layers that will get heavy use or are to be considered especially important to the value that the business receives from the K2 solution and should be given heavier priority when allocating hardware resources. For example, if the Workspace will be a heavily used component, you should dedicate a server or multiple servers to that role.
Keep this in mind for the architectural section, as you may want to add redundancy or additional hardware resources to that component.
What will be the most common components used?
This may also affect your architecture, as they may need to have additional hardware resources.
Based on the processes and the users involved, what is the level of business criticality that will be assigned to these systems?
This is a critical decision to be made, and one that requires much thought. This is also a decision that should be made by the business, not IT.
Make sure that you fully understand the people and the systems that will be involved in the processes managed by K2. One of the most important aspects of your deployment will be the level of availability and the criticality with which it is treated. You may be surprised by the level of business criticality that these systems end up having after several processes are running. You may start out by thinking that the criticality level is low; however, down the road, and often very quickly, the processes become critical and need an ever-increasing level of both performance and availability. It is important that you begin with this in mind so that you are not rearchitecting your K2 installation six months after completing it.
Plan above the level of performance and availability that you initially estimate (to allow your system the easiest path to evolve). If you think that the processes and systems could become critical, it is important that you start off with a system that supports it, such as a Network Load Balanced (NLB) farm. This does not mean that you must start out with a full NLB farm. You can configure K2 to be in a single node farm (as shown in Figures 5-3 and 5-4). Simply select the install K2 server farm option and input the farm name. Even if you have one server for now, you can still add servers later that will make the system a true NLB farm. Configuring it in this way makes it much easier to add nodes later without having to reconfigure the K2 installation.
The previous questions all dealt with areas specific to the K2 components. Now it's time to expand on a couple of key integrations that you may have. Each integration will be addressed in the next section.
Will SharePoint be used?
If SharePoint is used, one common decision is whether the same SQL database will be shared between K2 and SharePoint. If you will be using the same SQL database, it is very important that you ensure that this database is very scalable. Adding significant load to SharePoint with K2 and possibly other applications may significantly affect the overall performance of both K2 and SharePoint.
Will K2 share a server with the SharePoint servers themselves?
This can be at the application server level or with the Web front end. Either is technically feasible, but once again, if both K2 and SharePoint are heavily used you will run into bottlenecks. It is best to start off with K2 on a dedicated server for most situations, which allows easier scaling of K2 if and when needs arise. If you don't put K2 on a dedicated server, you may have to perform additional activities, such as establishing Web site Host Headers, dedicated IP addresses, or ports. In some environments this is not desirable, and you may choose to dedicate a server to K2 for this reason alone. Again, this depends on your particular environment, but it is always preferable to dedicate a server to K2 to give you the ability to easily expand its capabilities in the future, rather than having to build a new dedicated server for K2 down the road.
How heavily will you take advantage of SmartObjects?
This question primarily needs to be answered for SmartBox SmartObjects, as they will be stored on the same SQL box as the other K2 databases (refer back to the database table earlier in the chapter).
In this section, we will describe three main architectural approaches. Each approach can be "tuned up," so to speak, to bring more performance and scale to the overall system. Use these templates as a starting point for planning the architecture of your K2 installation. No single template will describe the exact system that you will ultimately build, but they will help you think about the types and configuration of servers that you need for your environment.
The primary focus of planning K2 should be the databases. No component of the entire environment is as critical to the overall success, performance, and scalability as the database. Every decision you make in your processes is directly affected by or has a direct effect on the K2 databases.
Deployment architectures typically fall into one of three general architectural categories:
Small scale
Medium scale
Large scale
Your specific particular configuration may differ slightly, but these should cover the majority of deployments.
These small-, medium-, and large-scale architectures are important when planning a K2 installation in your production environment, but what about your development, test, and staging environments? Most companies already have one for SharePoint or other Web applications. Often these environments can be reused. See Chapter 6 for more information on planning these environments.
The most basic of the small-scale architectures is the standalone install, so that's where we'll start.
A standalone K2 install (see Figure 5-5) is where all the K2 components are on the same server. This would include all K2 components and SharePoint components, if used. This architecture should only be used in nonproduction scenarios because this configuration offers no redundancy of any kind. Furthermore, since all pieces of the architecture are on one server, there is little to no optimization for performance.
This type of architecture could not support a high number of users, even when used in a SharePoint-only capacity. In addition, because there is no redundancy or distribution of services, rerouting traffic from this server to perform maintenance is difficult. If you were to use a standalone server in a production environment, do not deploy processes to this sever that are critical to your business.
In the basic small-scale architecture (see Figure 5-6), we break out the SQL server, often using a database that already exists to support other applications. This helps with the overall workload, given the database-intensive nature of K2. However, for an environment where any of the processes could be deemed critical to the business in any way, this architecture should not be considered. Performance will increase given that the database is separated. However, with SharePoint and K2 on the same server, scale is limited as well as the ease in which maintenance and other operational tasks can be performed. If you need some additional performance, you can move the K2 server to a separate server as depicted in the next version of small-scale architecture.
In this architecture (see Figure 5-7) the major components — Web, K2, and Data — are separated onto their own servers. This should be considered an entry-level departmental small business deployment architecture, as it does offer some degree of separation and a minimal level of operational activity, such as performing maintenance of some layers while allowing other layers to stay running. While this separation may be the most minimal for a production environment, problems in one area may not as readily affect others.
In the medium-scale architecture, we begin to focus on some of the functionality needed for today's important applications. The first entry into the medium-scale architecture focuses on data availability.
This architecture (see Figure 5-8) is very similar to the initial small-scale deployment with the exception that the database layer is redundant. This can often occur because the databases are sharing a cluster with other application databases, including the SharePoint database if present. Having the databases clustered can help in scaling, given the data-intensive nature of both SharePoint and K2. However, with only the data layer being redundant and everything else being on the same server, this architecture has minimal flexibility for operational tasks. If data availability is not a key factor in your architecture, you can focus more on the front-end page-rendering performance.
This architecture (see Figure 5-9) has a load-balanced Web layer, which can be ASP.NET, SharePoint, or Workspace, or a combination of these components. This is great for operational tasks as you can take individual servers out of the NLB cluster for routine maintenance tasks. This makes the Web layer performant and scalable. This layer can be easily expanded by adding additional new nodes. This architectural tradeoff is appropriate if your Web forms, SharePoint sites, and Workspace will be the most heavily utilized components.
We can then take it one step further and combine the two medium-scale options.
This should be considered the entry-level enterprise architecture, as it provides redundancy at both the Web tier and the data tier, thus increasing two very important aspects of the three tiers. This architecture (see Figure 5-10) offers good operational ability and ease of scale. This would be a good choice for an enterprise with a short-term goal of heavy front-end usage involving a heavy dose of SharePoint, and offers good scaling for front-end page rendering and reporting.
This architecture can easily handle a large number of users who interact both with forms, workslists, and reports.
When you surpass the abilities of an entry-level K2 architecture for an enterprise, you must move to a large-scale system. These systems offer additional levels of performance by increasing the components that are set up with NLB in addition to having SQL in a single cluster at a minimum.
This architecture (see Figure 5-11) is similar to the medium scale, full architecture except that K2 is not separated from the other front-end servers. You have a load-balanced front end that also is running K2 on each server. This provides good availability; however, you may still run into issues where problems in one part of the Web application layer take down the others, since there is no separation between them. Maintenance tasks may still be problematic.
This can be thought of as the ideal implementation for the enterprise or for any organization that will deploy business-critical process-driven applications. This architecture (see Figure 5-12) offers:
Load balancing for performance and redundancy
Layer separation and isolation
Clustered database for availability and performance
Obviously, one of the main drawbacks to this architecture would be cost. Not every company has the requirements or budget to accommodate such a deployment. However, you may find that as your company grows its use of process-driven applications, this architecture will become necessary. Keeping this in mind will help you choose the right initial architecture.
If you need to increase performance in this architecture, simply add nodes to the existing NLB clusters. You may also further separate the databases across different clusters.
Now that you understand the architecture and you have chosen a deployment model, you should take steps to understand how your system operates and ensure that you have appropriate capacity as the use of the system expands. For more information about monitoring your servers, see Chapter 19.
Once you have settled on a deployment architecture, there are many additional considerations that you need to take into account when planning administrative tasks and analyzing your existing infrastructure.
Take a look at the following aspects of your existing infrastructure while making decisions about how you will install K2:
Physical network configuration: Where are your servers and users physically located, and what is the link between them?
Kerberos: How many servers do you have and how can they readily impersonate users across all of them? Kerberos is a necessity that requires planning and, most likely, a good dose of troubleshooting.
IIS locations, ports, IP addresses, h ost h eaders, DNS: How is network traffic routed?
Domain configuration: How many domains do you have? Do you have more than a single forest? There are important decisions to make about K2 when you have a nonstandard domain configuration.
Database configurations: As stated before, K2 is a data-intensive platform; the data layer needs special attention to ensure that the K2 databases are appropriately designed.
Service accounts: Will you use a different account for each service? Do you have the accounts configured already?
Methodically working through an infrastructure appraisal phase with the above considerations in mind will ensure that nothing important is overlooked and there are no surprises when you get to actually installing and configuring K2. Ensure that you look through the hardware and software prerequisites that are included in the K2 Getting Started Guide. This is a great resource that includes specific steps to configure and troubleshoot pre- and post-K2-installation.
Often something that is overlooked is the physical network, so it will help to point out a few issues that can become a problem later on.
WAN bandwidth and component location: You need to understand where your users are located relative to the server components. You also need to understand usage patterns across the entire network (time of day, peaks and valleys). You do not want peak usage times for critical processes to coincide with network backups or other types of activities that may take away vital resources needed by your processes.
Network latency: This can affect component location and has the potential to cause a poor user experience if not addressed.
User locations: As stated previously, you need to think about how users will view and interact with items such as worklists and forms that are involved in a process-driven application and optimize the system for the best possible experience.
From a network perspective, you need to understand the network constraints to appropriately place various components for K2. For example, K2 blackpearl and SharePoint network traffic may consist of large documents moving between servers. Furthermore, traffic to and from a SharePoint site or the K2 Workspace involves a considerable amount of communication from the Web servers to the back-end servers running SQL Server. Good connectivity between them is required. Take into account your processes, what forms they use, and how the forms are used. For example how will forms with large attachments being passed form remote office locations over the wide area network (WAN) to the K2 server affect overall WAN performance? Possible solutions to this are regional SharePoint sites, but this is not always the best answer.
Ensure that you plan for appropriate response time for each of these components. You can certainly have each component of K2 across a WAN link to move the layer closer to the user population. However, be sure that the link can support the amount of traffic, particularly when it also involves SharePoint. This choice can often be a double-edged sword because you may move the Web front end closer to your primary user population, thus increasing response time, but the link between the front end and the back end can become saturated and unable to handle the traffic. This will often result in timeouts and user complaints to the Help Desk.
K2 makes extensive use of Active Directory for authentication and authorization, which is why it's an important area to focus some of your attention when planning a K2 installation. For a large percentage of K2 customers, Active Directory plays a crucial role in task assignment. K2 can use Active Directory in task assignment through Active Directory groups or K2 roles and even down to individual static user accounts. It is important that you take this into account before deploying K2 to a production environment. You should make sure that you involve your Active Directory team when architecting the environment so that they know what is going on and can advise you. Here are some aspects that you will need to pay special attention to:
Querying Active Directory for groups and roles used for destination users and for permissions
Multi-domain effects for resolving groups, adding roles, authenticating users
Multi-forest elements for K2 server management of documents in one forest and users in another, for example
DNS to ensure consistency, accuracy, and completeness
Site configuration to ensure that K2 has quick and easy access to Active Directory
Ideally, you should have a domain controller assigned to the same site as your K2 server or servers. This will dramatically increase response and query times between K2 and Active Directory. Queries to domain controllers and the DNS server will be very common in most K2 processes as well as with users and roles. This becomes more complicated when dealing with large Active Directory infrastructures, such as those with many domains or even multiple forests. You should understand how a generic query is handled in Active Directory, especially those that span domains within a forest and have users from multiple forests. Problems in this area can affect how your processes function.
In an extreme case — let's say your process has only three steps, but each step has a destination where users are assigned from different forests. These different users are contained in a role that is assigned as the destination. K2 must regularly query and resolve these users or groups to ensure that the role stays up-to-date. If the name resolution process fails, your process may not be able to function properly.
Also consider where users access K2 processes and where they are in relation to a domain controller (DC) and a Global Catalog (GC). This may make a difference in planning. If you have a DC in the same office as the K2 servers and the WAN link goes down, all the users in that office will still be able to use K2, since they will be able to renew Kerberos tickets at the DC. If there is no DC in that location, they will cease to be able to access K2.
DNS plays a vital role in any network infrastructure and with many distributed applications. In order for K2 to communicate with various servers on which its own or other components are installed, it must be able to resolve their addresses. Additionally, given the reliance on Kerberos in a distributed architecture, your DNS infrastructure must be solid if K2 is going to perform well and without error. This is usually not a problem as many Microsoft servers are set to self-register with their DNS server. However, in cases where you are using host headers or aliases, you will need to make sure you work closely with your DNS administrator in planning your K2 installation to ensure that these entries are added as needed. Having a solid DNS infrastructure will also help with performance, reducing the amount of time that servers have to wait until addresses are returned. If K2 has to go through many hops in order to retrieve DNS information, overall performance will suffer.
Authorization and authentication are important aspects to your Active Directory but also important to K2. Two common aspects that need clarification in this arena are:
Kerberos
SSO
SSO will be covered more in Chapter 17. For more information see that chapter.
A significant aspect of planning a distributed install is Kerberos. You must understand how it affects your environment, and you must prepare for it. Once again, it will be wise to involve your Active Directory and/or Security group in this conversation. There are many good Microsoft resources available to help you, including the following:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/ security/tkerberr.mspx http://www.microsoft.com/windowsserver2003/technologies/security/kerberos/ default.mspx http://technet2.microsoft.com/windowsserver/en/library/ b748fb3f-dbf0-4b01-9b22-be14a8b4ae101033.mspx?mfr=true
There has been a lot of bad press about Kerberos, and most of it is due to a lack of understanding. When it comes to Windows, Kerberos is not something that you install and or enable. Kerberos (see Figure 5-13) is there by default and is typically used when you log in to the domain from a Windows PC. The interesting part comes into play when you need Kerberos to help with some of the advanced authentication scenarios that are becoming more common in the enterprise, such as impersonation and delegation of authentication. Kerberos is Microsoft's way of solving the "double-hop" authentication problem.
As a client, you can browse to a Web page or any other front-tier application and use Kerberos for authentication. This part is easy and will rarely give you problems. However, what if you need to go beyond this front tier? What if you need to, as part of that application, go to the application server as well? How do authentication and authorization work? You don't browse to the application server. Will the front tier of the application prompt you for credentials again? You do not have many options if you want this to work seamlessly. The best, most accepted, and easiest approach is to use impersonation. But because of the double-hop problem, impersonation is not possible. That's where Kerberos comes in.
With Kerberos impersonation becomes easy again, and it can work with Windows authentication and even Basic or Passport authentication, for example.
We highly recommend reading up on Kerberos and some of the technology behind it. Before we get into how K2 uses Kerberos, let's talk about some of the benefits of Kerberos:
Impersonation (delegated authentication): As mentioned, you can use impersonation with Kerberos much more easily now. In Kerberos, different services can impersonate a user when accessing resources on the user's behalf. Previously, this was not possible with Windows, as there is no similar ability with NTLM. Impersonation is leveraged by K2 in all "double-hop" scenarios, such as when a user opens their worklist in a SharePoint site.
Authentication interoperability: The Microsoft implementation of the Kerberos protocol is compliant with the Internet Engineering Task Force (IETF) Standards-track specifications. This compliance allows interoperability with other networks that use Kerberos.
Increased authentication efficiencies: In systems that use NTLM for authentication, the application server must connect to a domain controller in order to authenticate each client. With Kerberos authentication, the application server does not have to contact a domain controller each time. With Kerberos, the application server can authenticate the client by the credentials presented to the server by the client. The clients get credentials for a particular server only once in a given time period, then they are able to reuse those credentials.
Mutual authentication: By using Kerberos, the server can be sure that the client has the appropriate access to the data, services, and applications that the server provides. In addition the client can be sure that the server it is trying to connect to is actually the server it expects it to be.
Taking Kerberos one step further and making it even more valuable, Microsoft added two new Kerberos features in Windows 2003:
Protocol transition: Enables applications to support several different authentication mechanisms at the user authentication tier, Windows will then switch to the Kerberos protocol to move on further into the other subsequent application tiers.
Constrained delegation: gives administrators the ability to specify authentication limits by specifying where application services can impersonate and act on a user's behalf. This is a huge benefit in high-security environments because it allows administrators to limit an application's impersonation boundaries to only other services that the application uses.
Some notes to keep in mind about constrained delegation:
Constrained delegation is possible only if the domain is at the Windows Server 2003 functional level.
Constrained delegation cannot be used between services whose accounts are in different domains. All domain controllers in the domain must be running Windows Server 2003, and the domain must be operating at the Windows Server 2003 functional level. The accounts of users accessing the services do not have to be in the same domain as the services.
The authentication model implementation is dependent on whether user credentials must be passed from one system to another. When they are passed, the system that is attempting to pass the credentials must be trusted for delegation. For this step to take place successfully, Kerberos delegation must be configured. There are some requirements for Kerberos delegation to occur:
A domain user for the application must not have the Account is sensitive and cannot be delegated option checked.
SPNs (Service Principal Names) must be registered for the services on the middle-tier servers. The service's SPN must be registered by a domain administrator if the service account is a domain user account. If the service account uses the computer's account, then the process can register by itself or the local administrator can register it by using the
Setspn.exeutility. SPN's can also not be duplicated anywhere within a forest. Duplicate SPNs will cause Kerberos authentication to fail.Middle-tier service accounts must be trusted for delegation.
An SPN must be registered for the service on the back-end server.
If using constrained delegation, then middle-tier services and back-end services must be in the same domain.
Now that you know why Kerberos is so good, we can go through some of the prerequisites for a good Kerberos experience:
Operating system: Kerberos authentication relies on client functionality that is built into the Windows Server 2003 operating system, the Microsoft Windows XP or Vista operating system, and the Windows 2000 operating system. Earlier versions of the operating system will not work with Kerberos. K2 blackpearl is recommended to run on Windows 2003.
TCP/IP network connectivity: For Kerberos authentication to occur, fully functional network connectivity (over TCP/IP) must exist between the client, the domain controller, and the target server, and they must communicate in a timely manner. TCP/IP is also a requirement for K2 blackpearl.
Domain Name System (DNS): Kerberos clients will use fully qualified domain names (FQDN) to access resources such as the domain controller. In order for Kerberos to work properly DNS must be functioning properly.
Active Directory domain/forest: All accounts that are to be used in a Kerberos authentication session must reside in a valid Active Directory domain. The current version of Microsoft Kerberos does not support the use of local Windows accounts.
Time service: Kerberos is very sensitive to time differences between machines. In order for Kerberos authentication to function correctly, all domains and forests in a network should need to keep time synchronized. Time differences can cause Kerberos authentication to fail. By default, the time differences accepted is < 5 minutes.
Service Principal Names (SPNs): An SPN is a unique identifier for a Windows service. Any service that is going to participate in Kerberos authentication will need to have an SPN. This is so clients can properly identify the service on the network. If you have a service that needs to participate in Kerberos authentication, and it does not have an SPN set for it or it is not set properly, clients who need to connect to it will not have a way of locating that service. Without correctly set SPNs, Kerberos authentication is not possible.
SPNs can be set both with the Microsoft SPN utility and through the ADSIEDIT.MSC, the latter of which is shown in Figures 5-14 and 5-15.
When talking about Kerberos, it is important to understand how K2 uses Kerberos and when. Let's take a look some of the different components of K2 and how they use Kerberos.
K2 makes extensive use of Web services for integration into both InfoPath and SharePoint:
SharePoint Web service (
SharePointService.asmx): The SharePoint Web service is used to initiate process instances from SharePoint Events. This service will require Kerberos authentication in any distributed environment to pass credentials from SharePoint sites to the K2 SharePoint Web service and then to the K2 blackpearl server. This is also used in the SharePoint Integrated workflow to pass credentials from the Web service to the K2 blackpearl server. During the design process, the K2 SharePoint wizards also use this Web service to interact with Microsoft Office SharePoint Server/Windows SharePoint Services (MOSS/WSS).InfoPath Web service (
InfoPathService.asmx): The InfoPath Web service passes credentials to the blackpearl server using Kerberos to interact with processes, including starting new processes.
When using browser-enabled forms the InfoPath Service Web service must be installed on the MOSS/WSS server because of an InfoPath Forms Services limitation.
K2's use of Kerberos, as it pertains to reporting, varies according to how the reports are surfaced.
For Non-SRSS reports: Authentication occurs as the end user via Kerberos. K2 Workspace delegates the user's credentials to the blackpearl server to execute the desired action.
K2 reports (published to SSRS): SSRS delegates the users credentials to blackpearl to obtain and return the report data based on the user's View and Participate permissions. When publishing a report from Workspace Report Designer, both the blackpearl server and the SSRS server are accessed as the Workspace Application Pool account.
SSRS Reports that are imported into Workspace: A user accesses the reports on the Workspace home page. Authentication occurs via Kerberos as the end user opens the report on the Workspace. The Workspace service then delegates the user's credentials to the SQL Reporting Services Web site to run the report. The user must have appropriate permissions (at minimum Browser) in SSRS to run the report. SSRS then delegates the user's credentials to the blackpearl server to run the report and return the data, as long as the user has correct permission to view it.
There are also other components that need to be taken into consideration for the same planning process.
The K2 Web Designer: Deploying a process will use the MOSS or WSS Application Pool account, which must have Export server rights on the K2 blackpearl server. The blackpearl WebWorkflow database is also accessed directly using the identity of the MOSS Application Pool account. This account must have at least the db_datareader and db_datawriter roles in the WebWorkflow database.
SQL Server (for blackpearl): The blackpearl server accesses the blackpearl databases using the blackpearl service account or via SQL Authentication as specified during the install. SPNs for MSSQLSERVER may or may not be required, depending on the environment. In many cases, SQL creates SPNs and in other cases, such as when using a named instance, SPNs must be manually created.
Workspace: A user accesses the Workspace Web site from a remote client and must be authenticated using Kerberos. If the Workspace is on a separate server, it will delegate the user's credentials to the blackpearl server and authenticate them using Kerberos.
SharePoint SmartObject Service Instance: If a security provider, username, and password are not configured for the Service Instance, and Impersonate is not checked, the Service Instance will run under the context of the blackpearl service account and authenticate in MOSS as such. If the Impersonate checkbox is checked, it will try and connect using the user that is logged in to the host Server, that is, the one executing the SmartObject.
The Impersonate checkbox should not be used when configuring the service instance as there typically will not be a user to impersonate.
K2 blackpearl Worklist Web part: A user accesses a page in SharePoint that is configured with the K2 Worklist Web part; if the Web part is running on a different server from K2, it must be authenticated using Kerberos. The Web part will delegate the user's credentials to the blackpearl server and authenticate them using Kerberos to retrieve the worklist, and open the worklist items and action worklist items.
Forms Generation Client Event: When a user opens a Forms Generation Client Event .ASPX Web page, they are authenticated using Integrated Windows Authentication. The RuntimeServices Application Pool account authenticates against the blackpearl server and impersonates the user to retrieve the worklist item. The same thing occurs when the user actions the workflow using the form; actioning the item also calls the ClientEventServer.asmx Web service. This Web service is not used if the process is actioned from the context menu in the Workspace worklist. The identity used for the RuntimeServices Application Pool must have "Impersonate" server rights in the Workflow server. Since the ClientEventService.asmx Web service uses impersonation when communicating with the blackpearl server, it will not work with Kerberos alone in a distributed environment as they work in conjunction for authentication and authorization.
Now that you have a good idea of where K2 uses Kerberos, we can dig into setting SPNs for Kerberos. In order to help you with this, use the following SPN table as a reference.
Kerberos configuration can occur either before or after the installation of K2 blackpearl. The configuration of K2 blackpearl, which occurs directly after installation, allows for the automatic setting of the K2 blackpearl Server SPNs.
SPNs Needed for | From a Command Prompt |
|---|---|
Host Server | K2HostServer/[MachineName]:5555 [DomainName][ServiceAccount] K2HostServer/[MachineName.FQDN]:5555 [DomainName][ServiceAccount] |
Workflow Server | K2Server/[MachineName]:5252 [DomainName][ServiceAccount] K2Server/[MachineName.FQDN]:5252 [DomainName][ServiceAccount] |
Workspace Application Pool Identity Account | HTTP/[MachineName] [DomainName][AppPoolAccount] HTTP/[MachineName.FQDN] [DomainName][AppPoolAccount] If the Web site uses Host Header, create SPNs as follows: HTTP/[HostHeaderName] [DomainName][AppPoolAccount] HTTP/[HostHeaderName.FQDN] [DomainName][AppPoolAccount] |
SQL Server 2005 Service Account | MSSQLSvc/[MachineName]:[Port] [DomainName][ServiceAccount] MSSQLSvc/[MachineName.FQDN]:[Port] [DomainName][ServiceAccount] |
SQL Reporting Service Application Pool Identity Account | HTTP/[MachineName] [DomainName][ServiceAccount] HTTP/[MachineName.FQDN] [DomainName][ServiceAccount] |
When setting up K2 in a farm environment some of the SPNs need to be set up differently. In a farm environment, use the following table as a reference:
From a Command Prompt | |
|---|---|
Server Farm Option for K2 Host Server (SP1 or higher) | In addition to blackpearlserver/K2server SPNs for each farm node, create SPNs for the farm name like this: K2HostServer/ FarmName]:5555 [DomainName][ServiceAccount] K2HostServer/ FarmName.FQDN]:5555 [DomainName][ServiceAccount] |
Workflow Server | K2Server/[FarmName]:5252 [DomainName][ServiceAccount] K2Server/[FarmName.FQDN]:5252 [DomainName][ServiceAccount] |
Server Farm Option for Workspace | HTTP/[WorkspaceFarmName] [DomainName][ServiceAccount] HTTP/[WorkspaceFarmName.FQDN] [DomainName][ServiceAccount] |
SharePoint Server Service Account | HTTP/[MachineName] [DomainName][ServiceAccount] HTTP/[MachineName.FQDN] [DomainName][ServiceAccount] If the Web site uses Host Header, create SPNs as the following: HTTP/[HostHeaderName] [DomainName][ServiceAccount] HTTP/[HostHeaderName.FQDN] [DomainName][ServiceAccount] |
Running K2 Host Server in console mode can be an effective way to verify if the K2 Host Server has started up successfully, or failed to do so. Console mode also reports the reason for the startup failure, thus making troubleshooting simpler.
To help you through a Kerberos delegation setup, use this checklist to ensure that you complete each step.
Recommended domain configuration:
Middle and back-end tiers are in the same domain.
Domain must be Windows 2003 functional mode.
Middle tier and DCs must be Windows Server 2003.
Set service principal names using SETSPN for each account. When setting these SPNs, ensure you use NetBIOS and FQDN names (Host Header, Port Info). This process will not be necessary if these services are running as built-in accounts such as local system; however, this is not a recommended best practice.
This is typically the Web or SharePoint layer. If you are using named user accounts as the AppPool identities at this layer, set service principal names using SETSPN for each account. When setting these SPN's ensure you use NetBIOS and FQDN names.
Ensure that the Kerberos Authentication method is used by IIS virtual server or SharePoint by querying the metabase settings as shown in Microsoft KB articles Q248350 and Q832769.
Ensure that any service account involved with delegation (for example, AppPool identities) is not marked as sensitive (Kerberos delegation will not work if accounts are marked as sensitive).
Using Active Directory Users and Computers, ensure that all service accounts involved with delegation are set to Trust this user for delegation.
If you will be using constrained delegation (in 2003), you must also ensure that the "specified services only" additional checkbox is checked in addition to the back-end system's SPN being listed as the specified service.
The service accounts involved with authentication must be given the Act as Part of the OS or Impersonate a Client after Authentication user rights.
All service accounts at this layer must be added to the local IIS_WPG group.
IIS must be set to use only Integrated Windows Authentication; also make sure that all other authentication methods are cleared, unless you will be using protocol transition.
Load balancing can be done in Win2k3 in some scenarios. See the Microsoft article "Kerberos authentication for load balanced Web sites" at
http://technet.microsoft.com.Set up SPN for Virtual Host Name (cluster name) mapped to service acct.
For ASP.NET applications, Authentication settings must be entered into the appropriate
Web.configfile (see Microsoft KB article Q810572).
Middle-tier Web sites must be in Local Intranet zone. By default, machines will not use Kerberos in the Internet zone.
If proxy servers are in use, you must make sure that you configure IE to bypass proxy server for local addresses.
All clients must be running Internet Explorer version 5.5 or greater.
In Internet Explorer, ensure Integrated Windows Authentication is enabled. This will require a restart of Internet Explorer.
Client must use Kerberos.
To ensure that it's operational, use the resource kit utility
kerbtray.
If you are having trouble with authentication, complete the following Kerberos checklist to ensure that all points are set up correctly.
Ensure that you set up all SPNs correctly and there are no duplicates. Use
LDIFDEto search for and find these. These types of errors can cause the user to be continuously prompted for credentials and fail authentication. (Also check out Microsoft KB article Q871179:http://support.microsoft.com/kb/871179).Confirm the Identity User account and Password.
Review AppPool consistency (compare/contrast AppPools used across all blackpearl resources, MOSS resources, and Web applications).
Check permissions of the AppPool identity account.
Confirm that Web application configurations are set properly
Check the FQDN being used or defined (DNS).
Check the Host Header being used or defined.
Check browser settings (Trusted Sites, Login settings, Security settings, and so on).
Confirm the K2 server Service account permissions and membership.
Check the User permissions for K2 processes, MOSS sites, and MOSS permissions.
Check that HTTP and Machine SPNs are set for proper accounts.
Check for duplicate SPNs.
Confirm that there is a pair of SPNs for each account (HTTP and Machine).
Hopefully, the preceding sections have helped you to identify the various K2 components and to familiarize yourself with installation and architectural requirements of K2 blackpearl products. Along with understanding the various K2 components, you also need to know the organization's existing network and architecture.
The successful development and use of processes with K2 blackpearl not only depends on your ability to know the process and develop it but also on ensuring the infrastructure that it runs in and depends on. This chapter has given you insight into the underlying architecture that is K2 blackpearl, and hopefully has led you down the right path to choosing a K2 blackpearl deployment model. In the next chapter, you will learn what it takes to also be successful in choosing a testing environment to begin testing the processes you build in.