Thanks for the responses.
I have been trying to get this architecture to work for a little while now. I had originally posted some questions here (and cc to Keith Brown), but got no responses. I am glad of the responses I am getting now. It would be nice to have this figured out.
As for delegation - the impersonation level on a COM+ app determines what rights the app will give to anyone it calls. So, the _caller's_ impersonation level determines what the _callee_ can do with the identity of the caller.
So, in my situation, we have:
ASP(impersonating the user) ----calls----> COM+ Server App (BSL) ----calls----> COM+ Library App (BO)
Restatement of my problem - I need to determine role of the original caller in the BO Library App.
If I set the ASP COM+ App to "Delegate", and then impersonate when I call from BSL to BO, that, I think, would solve my problem. There are two issues with that:
1) Setting ASP package to "Delegate" causes an internal web server error. You need a hotfix to patch that: http://support.microsoft.com/support/kb/articles/Q282/1/89.ASP. To get that patch, I will need to call up Microsoft support - I will try this out shortly and let you know what happens.
2) I will need to impersonate on every call from BSL to BO - haven't figured out how to do that in VB yet. Anyone know?
thanks,
tahsin
  Frederic Gos <fredericgos.dk> wrote:
Ok, I see what you mean. I was just thinking out loud. :-) My number 2 was bullshit, sorry... I have another thinking out loud question: There is this impersonation level called 'Delegate', Would that help? If not why?

Really interesting problems btw, that's why I responded to your question. I'm weeks from a project where I supsect I'll need all this information myself.

I really need to read that Windows Security book I bought some month ago! :-) Maybe Keith Brown could tell us why this COM+ behavior seems so strange...

cheers
Frederic

-----Original Message-----
From: Tahsin Alam
To: DCOMDISCUSS.MICROSOFT.COM
Sent: 03-10-01 22:22
Subject: Re: Using COM+ to control security: architectural issues

 Thanks for your response.
1) Move impersonation from ASP to BSL:
I want to do role checking both at BSL and at BO layers. So, I would
need to impersonate at ASP layer. I can _also_ impersonate when I make
the call from BSL to BO, but I would have to do that before every call
to the BO layer and that's a huge hassle. At ASP, I just impersonate at
the top of every page, so it's easier. [Detail question - how would I
impersonate at the BSL layer using VB?]
2) wouldn't it be a big security hole if you were able to detect the
credentials of a calling process?
How does IsCallerInRole work? What I want is exactly "IsCallerInRole"
but as it applies to the _original_ caller, not the direct caller.
However, "IsUserInRole" takes in a user SID, and doesn't use the
original caller SID already on the call context. As a result, it needs
to look up the credentials, and as a result, COM+ has no choice but to
use the configured identity. I understand the _why_ of COM+ identity
needing to be a domain user; I _don't_ understand why there isn't an
"IsUserInRole" which uses the original caller identity from the context.
I also don't understand why this requirement isn't a natural one for
trying to use COM+ security - how are other people trying to leverage
COM+ security out there?
  Frederic Gos <fredericGOS.DK> wrote: Hi Tahsin,

What if you move the impersonation form the ASP layer to the BSL layer?

It seems to me that the problem is that you are crossing a process
boundary
and that the server application has no chance to know what credentials
to
use but the ones specified under indentity. Correct me if I'm wrong, but
wouldn't it be a big security hole if you were able to detect the
credentials of a calling process?

cheers
Frederic

-----Original Message-----
From: Tahsin Alam
To: DCOMDISCUSS.MICROSOFT.COM
Sent: 10/3/01 2:56 PM
Subject: Using COM+ to control security: architectural issues

Hi all:

I am continuing to struggle with coming up with a good application
architecture based on COM+/IIS/Active Directory security, and I keep on
running into architectural shortcomings in COM+ security. Here is my
latest...

I have the following situation:

ASP(impersonating the caller) -----calls-----> [Roles] COM+ Server
Application ("BSL")
------calls-----> [Roles] COM+ Library Application
("BO")

All three logical tiers (BSL=Business Service Layer, BO=Business
Objects) are on the same physical machine. COM+ security is turned on in
all applications. ASP impersonates the logged in user before making any
COM+ calls. All users have domain accounts in Active Directory.

The users are in Active Directory groups, and I make the COM+ roles
contain the AD groups. This centralizes user administration.

We would like to enforce some business rules in the business objects
based on the role of the original caller. That means, we need to know
the role of the original caller 2 calls away from ASP, i.e. in the BO.

At first I tried IsCallerInRole in the BO. That didn't work as
"IsCallerInRole" checks only the direct caller and at the BO level, the
direct caller is the identity of the BSL Application.

Then I tried "IsUserInRole(user,role)" passing in the original callers
SID as the "user" parameter. That didn't work till I applied Win2k SP2.

-----> PROBLEM: Then I set the identity of the BSL application to a
local user (it was the interactive user before), and voila -
"IsUserInRole" stopped working! Seems like for IsUserInRole to work, you
need the COM+ identity to be a domain user. However, setting the COM+
identity to a domain user makes the machine quite vulnerable - the
userid/pwd is pretty easily available to any hacker who can hack into
the machine and run scripts. Compromising a domain account is not a good
idea.

-----> ARCHITECTURAL ISSUE: So, how do I use COM+ roles and check the
roles across multiple COM+ applications? I can't combine ti all into one
large com+ app for other reasons (easy of sharing the BO's across
multiple apps, deployment ease, etc.).

Has anyone successfully architectected based on COM+ security? What was
the architecture like?

tahsin

---------------------------------
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone with Yahoo! by Phone.

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

---------------------------------
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just
$8.95/month. Yahoo! by Phone.

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

---------------------------------
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. Yahoo! by Phone.

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]