I don't have any hard answers, but here are some ideas:

As for the user friendliness of basic authentication, isn't there a way to
put the uid/pwd in the URL? You could have a form take the uid and password
and build a url that has this info in it and then redirect the browser to
the first secure page. Maybe? I'm not sure is the uid and password being in
the URL is less secure then the default popup dialog (w/ or w/o SSL)?

How feasible is it to use a special domain use that is specifically denied
access to secure stuff?

Why not make the accounts they login with local user accounts instead of
domain users? This wouldn't work with integrated security, but if you're
forcing them to type a userid and password anyway this might be an option? I
guess if you're in a true intranet kind of setting it could be a pain for
users and admins to maintain 2 sets of accounts...?

Could there be some kind of "trust" setup between your domain that contains
the identity of the COM+ app and the users to authenticate? If so would this
work with a local domain?

-----Original Message-----
From: Tahsin Alam [mailto:tahsinalamYAHOO.COM]
Sent: Wednesday, October 03, 2001 4:31 PM
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: Using COM+ to control security: architectural issues

1) Yes - the fact that a vbs script running on the local machine can access
the userid and password in plain text is a security hole.
See:
http://msdn.microsoft.com/msdnmag/issues/0700/websecure2/websecure2.asp,
"it's usually safest to use a local account for a server's identity unless
you absolutely need something different. Anyone with administrative access
to the metabase can read this user name and password, so leaving this as a
local account severely restricts the damage that can be done if the machine
is compromised and the password disclosed."
The article is talking about the IWAM user's identity, but I assume it
applies to COM+ App Identity in general because under high isolation, IWAM
user is the App Identity of the ASP engine's COM+ App.
2) Impersonating in ASP:
This was another _big_ disappointment with IIS/COM+/AD security
architecture. All of COM+ role based security is based on the caller's
identity. However, IIS does not provide a native authentication method that
impersonates the user and is usable on the Internet. You can use Basic, but
that's not very secure, requires SSL, and is not very user friendly (users
are much more used to form fields than ugly popups). You can use Integrated
Windows, but that requires IE and hence is not cross browser.
So, we went with Basic Auth/SSL to start with, but now we have switched to
using making raw SSP calls to simulate a logging in of the user. With .NET
forms based authentication, this problem will go away.
The other option was to use "LogonUser", and "ImpersonateLoggedOnUser" API
calls. But that requires the IWAM user to have "Act as part of operating
system" privilege - try to get _that_ past security audit at your client!
tahsin
  "Weiss, Mike" <Mike.WeissPRICESYSTEMS.COM> wrote: What makes the uid/pwd
for the COM+ identity insure? The fact that the COM+
catalog settings for your application is storing that info somewhere locally
on the PC?

How are you impersonating the clients on the PC? IIS authentication (basic?
integrated?)?
Are the clients NT logins on their PCs the same identities as the identity
IIS impersonates for them?

-----Original Message-----
From: Tahsin Alam [mailto:tahsinalamYAHOO.COM]
Sent: Wednesday, October 03, 2001 8:57 AM
To: DCOMDISCUSS.MICROSOFT.COM
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

----------------------------------------------------------------
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 ]