Context Delegation

Context delegation is a form of impersonation first introduced in Windows 2000. It is a very powerful way to run a component in its own COM+ application process, by using the caller's identity. As discussed earlier, it makes use of Kerberos V5 (see the section Certificates and CryptoAPI) to get a positive ID on the client.We discussed previously how you can set context delegation by making use of the Component Services. However, this is only the declarative security, and context delegation only works if you insert context delegation programmatically into the component.You will find it worth the effort, since it adds additional security to your system, and increases the protection of your business processes. When you enforce context delegation, you always know who is initially making a call— hence, starting a business process—all along the chain of calls, even if you built a distributed BizTalk application. However, from the client's point of view, context delegation is also dangerous, since handing over your identity to a rogue component can do that person, your business, and your system a great deal of harm.You must meet the following conditions to be able to use context delegation:

■ All servers, and workstations for that matter, making up your BizTalk application must be running a version ofWindows 2000 and must be part of a Windows 2000 domain.

Kerberos V5 must be running within the Windows 2000 domain.

If the BizTalk application runs over more Windows 2000 domains, the Kerberos instantiations need to have trusted relationships.

The client (the initial component making the call) must have its impersonation level for outgoing calls set to Delegate.You can do this using Component Services, as described earlier.

The client account (the service account of the calling component, or the interactive user making the initial call) cannot be marked for "Account is sensitive and cannot be delegated" in the Active Directory.

The server account (which is the service account of the component being called) must be marked for "Trusted for Delegation."This is needed to limit the risk that the component being called is untrustworthy.

Designing & Planning...

Every COM+ Application Should Have Its Own Identity

When building a BizTalk application, you will probably model it around one or more business processes. It is important to contain a complete business process in one XLANG schedule, and contain the schedule in one COM+ application. By doing so, you can limit the amount of information that needs to be exchanged between COM+ applications. In addition, limit the number of exposed interfaces to as few as possible, and put as many methods in one exposed interface as you can. Remember that the exchange of data and the exposed interface are the most vulnerable parts of your COM+ application.

This is why it is important that you run every COM+ application under its own service account, hence its own identity, and limit its access to the system. If a COM+ application is compromised, or becomes unstable, the damage can be contained and is more easily traced. Additionally, by enforcing Context Delegation you harden both the COM+ application and the business process.

Was this article helpful?

0 0

Post a comment