1. 11: COM+ Securing System.EnterpriseServices
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

2. Outline Why use COM+? Security settings Role-based access checks
Deployment model
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

3. 11: COM+
Why use COM+?
COM+ (a.k.a. Enterprise Services) provides many features that corporate developers need
Secure hosting and networking via DCOM
Kerberos authentication
Message integrity
Message confidentiality
Role-based security tied to Windows logon
Distributed transactions
Deployment model
May also need to simply support existing COM-based code
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

4. Server applications vs. library applications
11: COM+
Server applications vs. library applications
COM+ allows both inproc and out-of-proc activation
Library applications have very little control over process-wide security settings
Process-wide security settings determined by the single server application in the process
library
app
library
app
server
app
library
app
library
app
DLLHOST.EXE
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

5. Process-wide security settings
11: COM+
Process-wide security settings
Authentication level
Impersonation level
Role-based access checks
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

6. 11: COM+
Authentication level
Controls how much protection is provided for the channel
Client and server both specify this, and COM uses the most secure of the two settings
MAC Protect
Headers
Payload
Encrypt
Authenticate
connection
Level
None
Packet
Packet Integrity
Packet Privacy X
Connect
NOTE: There is also a level named “Call”, but it’s not implemented, and always promoted to Packet.
use Packet Privacy unless you’ve got a really good reason not to
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

7. 11: COM+
Impersonation level
Servers requiring authentication can impersonate clients
Client can restrict what servers can do while impersonating
Choose whether to send network credentials to server
Choose whether server can open local objects with credentials
Note that impersonation level is a client-side setting
Server can
look at token
Level
Anonymous
Impersonate
Delegate
Identify
Server can use
token to open
kernel objects
client’s network
credentials X
local*
remote*
* “local” and “remote” here indicate whether the server has access to a client’s network credentials in the case of local communication (interprocess, same host) or remote communication (cross host)
The Anonymous and Identify levels are really pointless in a distributed scenario because they are enforced by an operating system (the server) that the client does not administer or necessarily even trust. Thus these levels aren’t generally used over the network. On the network, clients should simply use either Impersonate or Delegate to decide whether they want to send a network credential to the server.
For local communication, where the operating system often is administered (or at least trusted) by the client, the Identify level is useful. For local communication, authentication is usually short circuited by simply copying tokens from one process to another. (There is no need to do a full Kerb handshake between process boundaries if the local operating system is trusted.) Practically speaking this means the client is delegating her credentials to the server process at the Impersonate level. With a copied token, the server has direct access to the client’s logon session (along with all of its network credentials). Microsoft defines “delegation” specifically as sending credentials across the network, not just across process boundaries.
The Anonymous level has no practical use and is only academically interesting.
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

8. Role-based access checks
11: COM+
Role-based access checks
COM+ has a very nice infrastructure for role-based access control
It’s all based on the notion of interception
By moving the access checks out of the object and into the interception layer, they can be configured declaratively
object a c e s h k
IFoo
IBar
Client
interceptor a c e s h k
IFoo
IBar
object
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

9. Roles illustrated interface IPetStore PetAnimal BuyAnimal FeedAnimal
11: COM+
Roles illustrated
Bob’s definitions valid
for his pet store
App designer definitions
valid for all pet stores
interface IPetStore
PetAnimal
BuyAnimal
FeedAnimal
interface IEmployer
GetEmployeeInfo
GiveRaise
Interfaces
Supervisors
Employees
Customers
Roles
Everyone
DomA\Staff
DomA\Contractors
DomA\Bob
Accounts
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

10. Role-based access checks
11: COM+
Role-based access checks
COM+ performs three stages of access checks
1) At server process launch, client must be member of a role
2) At server process entry, client must be member of a role
3) At application entry, client must be in a role that grants access to the class, interface, or method being called
Once inside an application, calls between objects are not checked (we assume they trust each other)
Note that for (1) and (2), the client must be in a role defined by the server application (library application roles are not considered here)
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

11. Three stages of COM+ role-based access checks
CoCreateInstance 1 2
server app
library app 3
pObj1->Foo() 2 3
pObj2->Bar() 2 3
Note that the server app controls
the policy for stages 1 and 2 3
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

12. Custom logic for role-based access checks
11: COM+
Custom logic for role-based access checks
Server can query the roles of the caller at runtime
Allows you to make runtime decisions based on your own logic
namespace System.EnterpriseServices {
public sealed class ContextUtil {
public static bool IsCallerInRole(string role);
// ... other non-security related stuff }
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

13. Example public class Bank {
11: COM+
Example
public class Bank {
public void Withdraw(long accountID, long amount) {
if (amount > 5000 && !ContextUtil.IsCallerInRole("Supervisor"))
throw new SecurityException("Must be supervisor");
// ... perform the withdrawal }
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

14. Enabling role-based access checks
11: COM+
Enabling role-based access checks
Checks must be enabled at both the application and component level
Otherwise all three stages of role-based checks are disabled
Also, IsCallerInRole always returns true
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

15. Deploying managed code in COM+
System.EnterpriseServices provides everything you need
Derive component from ServicedComponent
Assembly needs a strong name
Assembly level attributes specify COM+ application settings
ApplicationName
ApplicationActivation
ApplicationAccessControl
Other attributes you need to know about
ComponentAccessControl
PrivateComponent
SecurityRole
SecureMethod
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

16. Example [assembly: AssemblyDelaySign(true)]
11: COM+
Example
[assembly: AssemblyDelaySign(true)]
[assembly:
[assembly: ApplicationName("Pet Store")]
[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: ApplicationAccessControl(true,
Authentication = AuthenticationOption.Privacy,
ImpersonationLevel = ImpersonationLevelOption.Identify,
AccessChecksLevel = AccessChecksLevelOption.ApplicationComponent)]
[ComponentAccessControl(true)]
[SecureMethod]
public class PetStore : ServicedComponent, IPetStore {
[SecurityRole("Customers")] public void PetAnimal() {}
[SecurityRole("Customers")] public void BuyAnimal() {}
[SecurityRole("Staff")] public void FeedAnimal() {}
[SecurityRole("Owners")] public void GiveAwayMoney() {} }
AccessChecksLevel controls whether stage (3) checks are performed. Here we’ve chosen to turn on stage (3) checks. The other option is AccessChecksLevelOption.Application, where only stages (1) and (2), the process-wide checks, are enabled.
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

17. Deploying managed code in COM+
REGSVCS.EXE installs managed applications into the COM+ catalog
Creates a type library
Creates (and configures) the application
Creates roles
Imports (and configures) all public classes into COM+ catalog
REGSVCS.EXE must be run with administrative privileges
regsvcs c:\appDir\petstore.dll
You can also install (and remove) managed COM+ apps into the COM+ catalog programmatically via the RegistrationHelper class.
install
regsvcs /u c:\appDir\petstore.dll
remove
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003

18. Summary COM+ provides a complete security framework
Unlike System.Runtime.Remoting at the moment
Can easily deploy managed code in COM+
COM+ isn’t going away any time soon
Essential .NET Security © 2003 DevelopMentor, Inc.
11/3/2003