Security

This section discusses security as it relates to ports and implementation technologies used in an XLANG schedule. As you already know, the schedule instance is created and managed by the XLANG Scheduler Engine. Both, the engine and the schedules are hosted as a COM+ application. Chapter 11 goes further into the details of this; however, the point is that, being COM+ applications, schedules abide by the native security mechanisms provided by Windows and COM+. These mechanisms consist of (among other things) access control based on role-based security and process identity. An application process that, for example, accesses a port on a running XLANG schedule must be appropriately authorized to do so. Chapter 11 describes these kinds of security issues relating to ports bound to COM components.

MSMQ queues have security settings that govern who can read or write messages from the queue. The identity of the COM+ application hosting the schedule must be included in the security settings for the queue; otherwise, the application or the schedule fails to post or receive messages from the queue.

BizTalk Messaging is itself implemented as a COM+ application, called BizTalk Server Interchange Application. Applications, including running schedule instances, that send messages to BizTalk Messaging must comply with the security settings for the COM+ application. This application provides the document submission API for BizTalk Messaging Services. Thus, a COM+ application that hosts an XLANG schedule must have appropriate rights to submit a document to BizTalk Messaging. Conversely, BizTalk Messaging Service must have adequate rights to create schedules or post messages to ports on the schedules. These rights are configured, for example, by assigning the Windows logon identity used by BizTalk Messaging service to the COM+ roles of the application that hosts the XLANG schedule.

Not only schedules, but COM+ components also use the role-based security, hence schedules calling COM+ configured components must comply with the security settings for these components.

In addition to these built-in security features, which are automatically enforced, with XLANG schedules you have access to the message sender's authenticated identity in the XLANG schedule. This identity is provided as a field of a message on the Data page. This identity is of the String type and can be passed in messages. The data type is a BSTR, and it is a sequence of bytes representing a Windows 2000 SID. SID stands for a Security Identifier—a unique byte sequence assigned by Windows 2000 to identify a user or a group. (See the Platform SDK documentation on the structure of SIDs.)

The sender's identity is available when a message is received on ports connected to COM components or MSMQ queues (not from BizTalk Messaging Services). When you bind the port to its implementation, you can specify one of the following three options:

• Sender's identity is not required to receive a message.

• Sender's identity is optional. This identity can be accessed on the Data page, when available.

• Sender's identity is required; the XLANG Scheduler Engine will not accept a message from a sender whose identity cannot be established (authenticated).

The sender's identity is available in the Data page and may be logged or passed as a field in subsequent messages.

If the XLANG Scheduler Engine is unable to establish the identity of a message delivered by MSMQ, then it is posted to a dead letter queue. The queue is created if it is not present and is called .private$<ApplicationName>.DeadLetter, where the token <ApplicationName> is replaced by the name of the COM+ application hosting the schedule instance. The default host application is the XLANG Scheduler.