Presentation is loading. Please wait.

Presentation is loading. Please wait.

11: COM+ Securing System.EnterpriseServices

Similar presentations


Presentation on theme: "11: COM+ Securing System.EnterpriseServices"— Presentation transcript:

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


Download ppt "11: COM+ Securing System.EnterpriseServices"

Similar presentations


Ads by Google