Introduction

In my previous article [1], published atVB2TheMax site, I’ve described briefly how COM+ security and role-based securitywork. I promised you to discuss in the next article about web/IIS security;still I realized, briefly later the article was published, that some more infoabout role-based security and some general security design guide lines wererequired: these are actually the subjects of this article.

Addendum

I think there is a couple of details aboutCOM security settings that should have deserved more attention in the previousarticle. 

Authentication: Both client and serverdeclare (in a programmatic or a declarative way)  their Authorization levelpreferences. The DCOM run-time set up the communication choosing the highestlevel between the two settings.

Identity: Since this setting appearsas an option in the DCOMCNFG.EXE tool, I was mislead for a while about its realmeaning. VB programmers tend to think of security settingsas a server side problem only (I’m afraid to say that I’ve met some VBprogrammers that didn’t even know that something like COM security existed). Thereason for this lies on the fact that COM API functions like CoInitializeSecurityare not really VB friendly and DCOMCNFG.EXE is of no use to set upsecurity settings on a standard exe application (the procedure to do thisrequires to insert some registry keys in the registry manually).
This is why, atthe beginning, I thought that the identity setting went through the samenegotiation process of the authentication setting (hence the identity settingappearing in DCOMCNFG.EXE being the server side preference on this setting). This is notthe case, unlike the authentication setting, this setting is determined entirelyby the client (the identity option on a COM server in DCOMCNFG.EXE appears since aCOM server may act as a client when calling into other COM server). This is areasonable behavior: it’s actually up to the client decide “if andhow” the server can perform “security sensitive” operations usingthe client identity token.

DNA Security: Best Practices

As I said, there is quite a lot of work involved settingup delegation correctly; nevertheless, when all user permissions and COMsettings are set up properly, you still have only half of your work done; youneed to request delegation programmatically in your method implementation: spawna new thread (or pick it up from a thread pool) and ask the thread to impersonatethe caller.
This is not easy feasible (and in any case unsupported) in VB (and there is noway to ask to the MTS/COM+ surrogate process to do this for you), but youshouldn’t actually be worried at all since using delegation is considered a baddesign practice when implementing security in business objects. I know that the use ofimpersonation and delegation sounds tempting, but most times it provides youmore problems than benefits, exposing your application more easily to security holesand making them harder to maintain.
Impersonation and delegation fit only into some specific and low-leveldevelopment scenarios such as file servers or some NT services like IIS.
Think about it: delegation basically means “I don’t care about security, Idelegate security checks to someone else”. You are moving security checksaway from your business objects entry point, down to the next inner level ofyour application (file access and DB access permissions), demandingsecurity set up to system or DB administrators.
The recommended approach is exactly the opposite: 

• Perform all access checks at the point at which client requests enter the middle tier
• Use only role-based security and avoid lower level security API 

As Ted Pattison says in his book “ProgrammingDistributed Applications with COM+ and MS Visual Basic 6.0”, “Mostcompanies who’ve successfully deployed distributed applications on large scalehave found that this is the only sane approach.”

The advantages implied are: 

• You can set permissions using business rule semantic (you cannot withdraw more then 100$ since you are not in the manager role)
• Applications are easy to set up and maintain 
• Applications are more scalable since you can use DB connection pooling only if you do not delegate to the DB security access checks.

Deep into Role-Based Security

There is still a couple of details about role-basedsecurity you have to be aware when designing your multi-tier application properly.
Both of these two details fit naturally into a security architecture where youfollow the DNA recommendations mentioned before.

• Access checks within COM+ applications:
  Once a call into a COM object has passed role-based security using the caller identity, any file or database access (via the NT integrated security) that you require during a method execution is checked against the process identity, not the caller identity. 
• Nested calls from COM+ application to COM+ application:
  Role-based access check is done against the process identity of the direct caller, not against the base client identity (original caller) that initiated the call chain.
  Example: Suppose a base client running under user A calls into a configured COM component named object 1, deployed in a COM+ application X. Application X runs under user B identity. During the method call execution, object 1 calls into object 2 deployed in application Y. Role-based access check in Application Y is done against user B, not against the original caller A.

Although not relevant to role-based security mechanism,MTS/COM+ maintains the identity chain while the logical thread of execution (activity)flows from one COM+ application to another. MTS users were limitedin identity flow discovery, having available only a few methods likeGetDirectCaller and GetOriginalCaller. In COM+ a new interface namedSecurityCallers  has been introduced. Using this interface you can enumerate the whole set ofidentities that have been involved in the activity. Remember that  suchinfo are made available for tracking and logging purposes only, not to set upsome kind of custom security checks.

Conclusions

I hope I have provided valuable information to set up yourdistributed application security effectively as long as you are concerned withstandard win32 clients.
As you know, you can call into a COM object from an ASP page, that is,basically, from an HTTP request. This poses a whole new bunch of security issuesrelated to the fact that, in most cases, the identity calling into a web servervia a browser request is not known inside the domain, hence it cannot beauthenticated. IIS must act then  as the base client when calling into the domainwhere middle-tier COM objects reside, still providing you someway to distinguishamong different internet users identity. What kind of security could you set upif all internet calls were seen as coming from the System account ? (theinetinfo.exe process runs under this account).

You will see in my next article how IIS behaves differentlythan a standard base-client, using impersonation and delegation to provide youdifferent ways to map internet users to domain identities.

Errata

There is a couple of errata in my previous article aboutCOM+ security (it’s likely they have been fixed by the time you read thisarticle): 

• SSP stands for Security Support Provider, not Security Service Provider. 
• Required user rights to set up Delegation: 
  The client account must have the “Account is Sensitive And Cannot Be Delegated” disabled.
  The server process identity must have the “trusted For Delegation” property enabled.

[1] Aguerrilla course on COM(+) security : Enrico Sabbadin