Security in CORBA, .NET and J2EE

1
Security in CORBA, .NET and J2EE
Keith Bessette and Prof. Steven A. Demurjian
Computer Science Engineering Department 271
Fairfield Road, Box U-2155 The University of
Connecticut Storrs, Connecticut 06269-2155
http//www.engr.uconn.edu/steve steve_at_engr.uconn.
edu
2
Motivation

• Distributed Computing Applications are
  Constructed From Legacy, COTS, Database, and
  Client/Server Applications
• Solutions Facilitate the Interoperation of
  Applications in a Network Centric Environment
• CORBA, DCOM/OLE, J2EE/EJB, JINI, and .NET have
  Enabled the Parallel and Distributed Processing
  of Large, Computation-intensive Applications
• Security has Historically Often Been an
  Afterthought
• Dramatic Turnaround in Support of Security within
  these Modern Middleware Platforms

3
Overview

• Focus on the Attainment of Security within
• CORBA
• .NET
• J2EE
• Represent Three Dominant Middlware Platforms
• Emphasis on Exploring the RBAC/MAC Capabilities
  of Each
• What Can Each Offer in Support of Security?
• How do the Different Technologies Compare?
• Later - Focus on Using Middlware (e.g., CORBA,
  JINI) to Attain MAC/RBAC for Distributed Setting

4
Security in CORBA, .NET, and J2EE

• The CORBA Security Specification is a Meta-model,
• Similar in Concept to the UML Meta-model with
  Implementations (e.g., Together, Rational, etc.)
• Offers Wide Variety of Security Capabilities at
  the Model Level - RBAC, MAC, Encryption, Etc.
• Language Independent (Not Tied to Java, C,
  .NET, Etc.)
• In Contrast, .NET and J2EE are Commercial
  Products
• Characterizable as Implementations or Instances
  of the CORBA Security Meta-model
• Transition Concepts into Platform Specific
  Implementations

5
CORBA Security Capabilities

• The CORBA Security Service Specification Focuses
  on Four Keys Aspects of Security
• Confidentiality
• Concerned with Access to Information
• Limit Access to Those Individuals (Programs) That
  Have Been Given Explicit Permission
• Integrity
• Only Authorized Users are Allowed to Modify
  Information
• Delegation of this Authorization Between Users is
  Tightly Controlled

6
CORBA Security Capabilities

• Accountability
• Users Must be Responsible for All of their
  Actions
• Security Mechanisms Must be able to Monitor and
  Track the Accountability
• Availability
• If Users have Been Appropriately Authorized, then
  their Authorizations Require the System's
  Availability

7
CORBA Security Capabilities

• Collectively, These Four Features Underlie the
  Security Offered in the Meta Model for
• Identification and Authentication of Users
• Authorization and Access Control of Users to
  Objects
• Security Auditing for Accountability
• Security of Communication Between Users and
  Objects
• Non-repudiation to Provide Proof of Access
  between Client and Target Object
• Administration of All of the Security
  Requirements

8
The CORBA Security Model

• The Structural Model of CORBA is Comprised of
  Different Levels used to Facilitate Secure Object
  Invocation by Clients
• Application Components Client Request Services
  and a Target Object Providing Services
• ORB Security Services
• Access Control Service - If the Operation Being
  Requested is Permitted
• Secure Invocation Service - Protect the Target
  Object in its Interactions With the Client
• Implementation of Security Services
• Available in actual CORBA Implementations
• Platform Specific, must Interact with Security
  supported by OS and Hardware

9
The CORBA Security Model
10
Access Control in CORBA

• Must Verify the Characteristics of a Subject's
  Permissions (via Privilege Attributes) Against
  the Target Objects
• Target Objects Are Managed via Control Attributes
  (Grouped As Domains) and Operations (Grouped as
  Rights)
• Combination of Privilege Attributes, Control
  Attributes, and Domains Provides
• Means to Define Security Requirements
• Basis for Enforcing Those Requirements by Actual
  Clients Against Target Objects

11
Access Control in CORBA

• Privilege Attributes are Associated with the
  Client, Referred to as the Principal
• Privilege Attributes are Used to Capture All of
  the Various Security Permissions for Access
  Control
• Security Permissions
• Identity (e.g., User Id) of the Principal
• Role(s) of the Principal
• Group(s) That the Principal Belongs to in the
  Organization
• Security Clearance (e.g., Secret, Classified,
  Etc.) Of the Principal
• Target Objects and Operations to Which the
  Principal Has Been Granted Access, and Any Other
  Enterprise-wide Privileges.

12
Access Control in CORBA

• Control Attributes are Associated with Each
  Target Object, to Track the Security Privileges
  from an Object's Perspective
• Control Attributes can also Track Security
  Information on the Target Object Itself
• Control Attributes Track All of the Principals on
  a Target-Object-by-Target-Object Basis
• List of all Principles for an Object
• Privilege Attributes Focus on Capabilities of
  Individual Principals

13
Access Control in CORBA

• Rights of a Target Object are the Set of
  Operations That Are Available for Assignment to
  Each Principal
• Examples
• An Access Control List Entry for Each Target
  Object would Track the List of Principals Who
  Have Been Authorized the Role(s) of the Principal
• A Target Object Itself
• Might have a Security Classification (e.g.,
  Secret, Classified, etc.)
• May Be Limited in Access to Certain Time Periods

14
Access Control in CORBA

• To Assist in the Security Definition Process of
  Principles and Objects for an Organization,
  Domains can be Utilized
• Domain Provides a Context to Define Common
  Characteristics and Capabilities Related to
  Security
• Security Policy Domain Represents the Scope Over
  Which Each Security Policy is Enforced
• An Organization May Have Multiple Policies
• Security Policy Domain Permits the Definition of
  Security Requirements for a Group of Target
  Objects
• Group Can Be Managed As a Whole, Thereby Reducing
  the Needed Administrative Effort

15
Access Control in CORBA

• Policy Domain Hierarchies
• Allows a Security Administrator to Design a
  Hierarchy of Policy Domains
• Delegate Subsets of the Hierarchy (Sub-domain) to
  Different Individuals
• Example a Health Care Organization
• Sub-domains for Patient Objects, Test-result
  Objects, Employee Objects, Etc.
• Security for These Sub-domains Delegated to
  Different People in Hospital Administration

16
CORBA Security User Views

• Views to Provide a Hierarchical Structure of the
  Security Requirements for an Organization
• Enterprise Management View
• Organization-wide Perspective on the Treatment of
  Security Requirements
• Risk Assessment, Protection Against Malicious
  Inadvertent Security Breaches, Countermeasures
• End Result Will Be the Definition of Security
  Policies, As Appropriate, for Different Portions
  of an Organization
• End User View
• Involves the Privilege Attributes (E.G., User Id,
  Role, Clearance, Etc.)
• Focus on the Privileges That Are Authorized, and
  Action Authentications of Users

17
CORBA Security Views

• Application Developer View
• Security Definitions Maybe Transparent to the
  Majority of Stakeholders (Programmers,
  Developers, Etc.)
• Security May Be the Strict Responsibility of All
  Stakeholders (Programmers, Developers, Etc.)
• Administrators View
• Security Management Perspective
• Creating and Maintaining the Domains
• Assigning the Privilege Attributes to End Users,
• Administrating the Security Policies, Monitoring
  the Control Attributes of Target Objects, Etc.

18
CORBA Security Execution Model

• Client Makes a Request to Access the Target
  Object.
• Must Obtain a Binding to the Target Object
• Requires a Check to See If the Client Has the
  Permissions (Via the Privilege Attributes) to
  Invoke an Operation on the Target Object (Via the
  Control Attributes)
• The Binding is Established, and a Reference to
  the Target Object is Returned, Allowing the
  Invocation
• The Ability to Obtain an Object Reference May
  Involve Interaction with a Policy Object and the
  Domain Manager

19
Security Binding in CORBA
20
Domain Objects in CORBA
21
Microsofts .NET

• .NET is Microsofts Solution to Enterprise
  Computing and Interoperability
• Aimed to Compete with Java/J2EE
• Interoperability with Old (CORBA, COM) and New
  (RMI)
• Provide Uniform Programming Environment
• Extension of C - C
• Well Briefly Compare/Contrast/Introduce .NET

22
Security in .NET/Java

• Secure Development and Execution Environments via
  a Number of Different Capabilities
• Code-Based Access Control - CBAC Permission for
  Code to Access Resources
• Role-Based Access Control - RBAC Permission for
  Users/roles to Access Resources
• Code Verification and Execution Semantics,
  Bytecode, Safe Execution Environment
• Secure Communication Pass Data/messages Securely
• Code and Data Integrity No Unauthorized Code
  Modification, Cryptography
• Our Objective - Explore their Attainment in .NET
• Apply Similar Framework to J2EE for Comparison

23
.NET Security Capabilities

• Important Initial Definitions
• Assembly Refers to Compiler Generated Code,
  Specifically, Microsoft Intermediate Language
  (MSIL)
• Evidence Refers to the Proof that is Supplied
  Regarding Identity
• Permissions Refers to a Privilege that is Given
  to Perform an Operation on a Resource
• In the Case of an Assembly, the Permission Set
  for All Allowable Privileges on All Required
  Resources
• Well Revisit in Later Slides in more Detail

24
.NET Security Execution Model

• Three Components
• Hosting Environment is Attempting to Execute an
  Application
• Must Provide Both the Code (Via Assembly) and Its
  Identity (Via Evidence) in Its Interactions With
  CLR
• Common Language Runtime (CLR) Provides a Secure
  Execution Environment Through Managed Code and
  Code Access Security
• CLR Contains the Security System That Realizes
  Policy Files Comprised of Rules Defined by a
  Security Administrator (Security Setting)
• The Rules Allow Permission Sets to Different
  Types of Code or Users Based on Evidence

25
.NET Security Execution Model
26
C vs. Java - Differences/Similarities

• Class Hierarchies
• Both have Single Rooted Class Hierarchies
  System.Object and Java.Lang.Object
• Both Classes have Methods Sharing Some
  Similarities and Difference
• Execution Environment
• JAVA Compiled to Bytecodes
• Interpreted or Natively Compiled and Run in
  Managed Execution Environment JVM
• C Code Gets Compiled to MSIL (Microsoft
  Intermediate Language) which Runs in CLR
• C Code is Never Interpreted, it is Always
  Natively Compiled Cs MSIL is More Type Neutral

27
C vs. Java - Differences/Similarities

• Access Modifiers
• Serialization and Documentation
• C supports XML format as well as binary format
  for serialization while Java only supports binary
  format by default.
• JAVA uses Javadoc while C uses XML for
  documentation

(Continued)
28
.NET Security Capabilities

• Code-based Access Control - CBAC
• Giving Permissions at the Code Level to Access
  Resources
• Based on the Application Domain That the Code is
  Assigned to (Information in Evidences)
• Role-based Access Control - RBAC
• Giving Permissions to a User to Access Resources
  Based on the Users Role in the System
• Secure Code Verification Execution
• Similar in Concept to Bytecode Verification in
  Java, MSIL in .NET
• Insures That the Executing Code is Staying Within
  Its Allowed Domain

29
.NET Security Capabilities

• Secure Communication
• Provides the Ability to Pass Data and Messages
  Locally or Remotely in a Secure Manner
• Avoids Both Intentional and Inadvertent
  Data/message Modification
• Secure Code and Data Protection
• Insures That Code Hasnt Been Modified Without
  Authorization
• Utilizes Cryptographic Solutions and Signed
  Distribution Files

30
.NET Code-Based Access Control

• The Determination of What a Piece of Code is
  Allowed to Do is Decided by the Origins and
  Intentions of the Code Itself
• Can Be Decomposed Into Evidence Based Security,
  Permissions, and a Security Policy
• During Execution, the CLR
• Reviews Evidence of an Assembly
• Determines an Identity for the Assembly
• Looks up and Grants Permissions Based on the
  Security Policy for That Assembly Identity

31
.NET CBAC Evidence Based Security

• Used by the CLR to Determine the Origin(s) of an
  Assembly
• At Runtime the CLR
• Examines the Meta-data of an Assembly to
  Determine the Origin of the Code
• Determine the Creator of the Assembly
• Determine the URL and Zone That the Assembly Came
  From
• A Zone Represents the Domain That the Assembly Is
  From, E.G., Internet, LAN, Local Machine, Etc.
• The Association of the Meta-data and Its
  Corresponding Assembly Is Verified by the CLR

32
.NET CBAC Permissions

• An Assembly will Request Permissions to Execute
• Requests are Answered at Runtime by the CLR,
  Assuming that the Assembly Has Provided Evidence
• Partially Denied Requests the CLR Dynamically
  Assigning the Assembly a Lower-level Permission
  Than Requested
• Permissions are Grouped Into Sets Where Each Set
  Has the Same Level of Security and Trust
• Example
• An Assembly that has Originated From the Internet
  Zone May Be Granted an Internet Permission Set
  that Pertains to the Execution of Un-trusted
  Code, Allowing the Behavior of Non-local Code to
  Be Tightly Controlled

33
.NET CBAC Security Policies (SPs)

• The Grouping of Assemblies Establishes Different
  Security Policies for Different Code Groupings
• Security Policy Groups Are Hierarchically
  Categorized Based on the Identity That the CLR
  Determines From the Evidence in the Meta-data
• An Actual Security Policy can be Specified As
  Permissions for All Assemblies in a Group
• This is Accomplished Using Security Policy Files
  to Capture Security Requirements
• A Policy File May Limit the Permissions of
  Another Policy File, but Cant Entirely Restrict
  It

34
.NET CBAC Security Policies

• SP is Set by an Admin to Make Permission
  Decisions for Assemblies and Domains
• Three Policies Total Enterprise, Machine
  Executing Code, Requesting User
• Any Policy File May Partially Restrict
  Permissions of Another Policy File
• SP Groups Code into Hierarchical Categories Based
  on Identity Determined by the CLR
• SP Determines Permissions for Assembly After Code
  is Grouped and Categorized

35
.NET Role-Based Access Control

• A Role Represents a Logical Grouping of Users
  (e.g., in a Health Care Application Physician,
  Nurse)
• .NET Uses Role-based Security to Authenticate an
  Identity and to Pass on That Identity to
  Resources
• Resources Authorize the Users Playing Roles
  Access According to Policies and Permissions
• Principal Defines a Role Membership, and the
  Permissions of Role-based Security are Managed by
  the Principalpermission Object
• Windows Authentication, Passport Authentication,
  IIS Authentication, Impersonation Authentication

36
.NET Secure Code Verification/Execution

• Security Checks Verified During the Code
  Execution
• Stack Integrity, Bytecode Structure,
  Accessibility
• Buffer Overflows, Semantics
• Java Sandbox of .NET is Called the Application
  Domain
• Multiple Assemblies May Be Loaded into the Same
  Application Domain
• No Way for an Object to Directly Reference
  Another Object in a Different Application Domain
• All of the Security Checks to Verify Code are
  Done on Managed Code in a the CLR

37
.NET Secure Communication

• Transmission and Communication of Sensitive Data
  Across Systems Must Be Securely Accomplished
• Secure Communications Occurs at the Application
  Level Via SSL and Transport Layer Security (TLS)
• .NET Applications Can Use the Windows SSPI, but
  Only As Unmanaged Code With Managed Wrappers
• .NET Promotes the Exclusive Use of IIS
• IIS Supports SSL and TLS
• But IIS has an Extensive History of Security
  Flaws

38
.NET Secure Code and Data Protection

• Any Code/data Loaded by the System Must Supply
• Evidence of Its Source, Version Signature
• Proof That There Hasnt Been Any Unauthorized
  Modification
• .NET Uses Strong-named Assemblies That Include
  the Assembly Name and Version Information
• Assemblies Are Signed With an RSA Keypair
  Nullifying the Chance of Unauthorized
  Modification
• Version Information is Included in Order to Avoid
  DLL Conflicts During Execution
• .Nets Encryption Functionality is Tied to the
  Windows Cryptographic API

39
J2EE Security Capabilities

• Platform Independent Java Bytecode That Is Able
  to Execute Either Locally or Remotely
• Bytecode Execution Process Involves a Number of
  Different Components
• The Class Loader (With Bytecode Verifier)
• Java Class Libraries (Apis)
• Java Virtual Machine (JVM) Which Interacts With
  the OS
• All Three Provide a Secure Runtime Environment
• The Security Manager and Access Controller
  Examine and Implement the Security Policy

40
J2EE Security Capabilities
41
J2EE Code-Based Access Control

• CBAC Implemented Through the JVM, Class Loader,
  and the Security Manager and Access Controller.
• The Hierarchy of the Class Loader Prevents
  Unauthorized and Untrusted Code From Replacing
  Any Code in the Base Classes
• Multiple Class Loaders Are Permitted, Each With
  Its Own Namespace, Are Simultaneously Active.
• Namespaces Allow the JVM to Group Classes Based
  on Where They Originated (Local, Remote)
• Namespaces Insure an Application Cant Affect the
  Rest of the Runtime Environment
• Bytecode Verifier All Untrusted Code Is Verified
  Before Permitting Execution Within a Namespace

42
J2EE CBAC The Security Manager

• The Security Manager Enforces the Boundaries
  Around the Sandbox by Implementing and Imposing
  the Security Policy for Applications
• All Classes Must Ask the Security Manager for
  Permission to Perform Certain Operations
• By Default, an Application Has No Security
  Manager, So All Operations Are Allowed
• Java Only Has Two Security Policy Levels, One for
  the Executing Machine, and One for the User
• Each Level Can Expand or Restrict All of the
  Permissions of Another Level
• There Can Be Multiple Policy Files at Each Level

43
J2EE CBAC Permissions

• Permissions Are Determined by the Security Policy
  at Runtime
• Granted by the Security Policy Based on Evidence,
  a Publisher Signature and Location Origin
• Permissions Are Also Grouped Into Protection
  Domains (Similar to Security Policy Domains in
  CORBA and to Security Policy Files in .NET)
• Permissions Are Associated With Groups of Classes
  in Java, and Classes Are Grouped by Their Origins
• CBAC Isnt Automatic in J2EE, but Requires
  Programmatic Effort by the Software Engineer

44
J2EE Role-Based Access Control

• J2EE Uses the Java Authentication and
  Authorization Service (JAAS)
• JAAS an Integrated Package That Implements a
  Java Version of the Pluggable Authentication
  Module (PAM) Framework
• Using JAAS, Software Engineers Are Allowed to
  Modify and Then Plug-in Domain/application
  Specific Authentication Modules
• JAAS Currently Supports Authentication Methods
  Including Unix, JNDI, and Kerberos

45
J2EE Secure Code Verification/Execution

• J2EE Security Checks Are Performed During the
  Code Execution Process, and Have Their Roots in
  the JVM and JRE.
• Java Interprets Compiled Bytecodes
• A Bytecode Verifier Traverse the Bytecodes Before
  It Goes to the Just-in-time (JIT) Compiler or
  JVM.
• Java's Sandbox Protected Domains, Are Similar
  to Application Domains in .NET
• Protected Domains Constitute an Extension of the
  Sandbox, Determining the Domain and Scope in
  Which an Application Can Execute

46
J2EE Secure Code Verification/Execution

• Two Different Protected Domains Can Interact
• Through Trusted Code
• Explicit Consent of Both Parties (Remotely
  Possible in .NET)
• An Object Can Access Another Object in Another
  Protection Domain
• As Long As They Were Both Loaded From the Same
  Class Loader
• This Is Due to the Hierarchical Class Loader
  Structure

47
J2EE Secure Communication

• Like .NET, J2EE Supports Secure Sockets Layer
  (SSL) and Transport Layer Security (TLS)
• Java Provides Java Secure Sockets Extensions
  (JSSE) for Implementing Secure Communications
• JSSE Is a Configurable and Flexible Solution That
  Uses SSL and TLS to Create a Secure Connection
  Using Sockets (Sslsocketfactory)
• The Secure Connection Can Be Used for Remote
  Method Invocations (RMI)

48
J2EE Secure Code and Data Protection

• J2EE Provides Java Cryptography Extensions (JCE)
  and Java Cryptography Architecture (JCA)
• Java Provides the Functionality of a Message
  Digest Algorithm for Use of Digital Signatures
• A Supplier Bundles Java Code Into a JAR (Java
  Archive), Signing the File With a Digital
  Signature
• The JAR is Released As a Version, and the Client
  Can Verify the Authenticity of the Supplier by
  Verifying the Signature
• An Unsigned Class May Be Added to a JAR File, but
  Not to a Package Within a JAR File

49
Java CBAC vs. .NET CBAC

• Permissions Are Grouped Into Protection Domains
  and Associated W/ Groups of Classes
• Permissions Are Grouped Into Sets and Associated
  with Code Groups
• Classes Are Grouped by Their Origin Like Code Is
  Categorized by Assemblys Zone
• No Security Manager by Default in Java
• J2EE Has 2 Security Policy Types
• Executing Machine Requesting User
• .NET Provides a Lot of Standard Permissions
• Stronger Credentials Needed for Permissions in
  .NET (Evidence)
• SP Files Are More Configurable in Java, but
  Doesnt Help W/o All Perm Sets

50
J2EE RBAC vs. .NET RBAC

• .Net Supports Both Imperative and Declarative
  Role Permission Checking
• Java Servlets Provide Declarative Checking at the
  Servlet Level
• EJBs Provide Declarative Checking Down to Method
  Level
• JAAS Provides Imperative Checking Within Method
  Level
• .Net Flexibility is Limited Severely
• IIS is Only Supported Server of .Net Framework
• Passport Requires Users to Be Members of
  Microsoft Passport Service

51
Code Verification/Execution

• Prevent System Weaknesses Exposure by Application
  Errors Malicious or Not
• .NET and Java Perform Security Checks During Code
  Execution
• Stack Integrity, Bytecode Structure, Buffer
  Overflows, Semantics
• Application Domains Have Static Boundaries
• Protection Domains Have Dynamic Boundaries
• All Security Checks to Verify Code Are Done on
  Managed Code
• Both .NET and Java Allow Unmanaged Code to Bypass
  the CLR and JRE

52
Concluding Remarks

• Objective of this Material
• Detail Security Requirements for Middleware
  (CORBAs Meta Model)
• Illustrate the Realization of the Meta-Model
  (Microsofts .NET and Javas J2EE)
• Compare and Contrast .NET and J2EE
• Touching Only Surface of Capabilities and
  Functionalities
• See Paper on Web Site and Various References for
  Additional Detail