Security Capabilities of Commercially Available Middleware Platforms: An Investigative Study

1
Security Capabilities of Commercially Available
Middleware PlatformsAn Investigative Study

• Group 4
• Qian Luo
• Manu Juyal
• Amit Rana
• Shawn Jacobs

2
Middleware

• What is it Computer software that connects
  software components or applications.
• What for Used to support complex distributive
  computing applications (Wikipedia)

3
Middleware Platforms

• CORBA
• J2EE
• .NET
• WebSphere

4
Purpose

• To explore the concept of middleware security by
  examining the security capabilities of
• CORBA
• .NET
• J2EE
• WebSphere

5
Threats in Middleware Systems

• Information compromise Deliberate or accidental
  disclosure of confidential data.
• Integrity violations
• Denial of service
• Repudiation of some action
• Malicious or negligent misuse

6
Vulnerabilities

• An authorized access
• Masquerading
• Security controls could be bypassed.
• Network communications could be subject to
  eavesdropping.
• Network communications between objects could be
  tampered with.
• Lack of accountability for (malicious) actions.

7
Types of Middleware

• Remote Procedure Calls
• Publish/Subscribe
• Message Oriented Middleware
• Object Request Broker
• SQL-Oriented Data Access

8
CORBA

• Introduction to middleware security
• CORBA security
• J2EE security
• WebSphere security
• .NET security
• Comparison within these middlewares
• Conclusion

9
Introduction to CORBA

• CORBA is a specification for the Object Request
  Broker (ORB) that permit software object to
  communicate with each other over a network, but
  the applications developed with CORBA
  specification do not must communicate across a
  network, for the reason that they can use the
  methods which are included in the clients
  address space. In addition, while CORBA
  self-acting using numbers of services to
  communicate, CORBA also can insulate applications
  from the specific of the communications kernel.

10
What Is CORBA Security?

• CORBA security concerns information security
  which describes the mission to prevent
  information assets, both stored and on the wire,
  from being attacked.
• CORBA security specification includes a security
  model, interfaces and facilities for
  applications, implementers, as well as
  administrators.

11
Security Properties within CORBA

• 5 main aspects of CORBA security
• Confidentiality
• Integrity
• Availability
• Accountability
• Dependability

are the fundamental goals of preventing
information assets from unauthorized access
12
Security Properties within CORBA

• The priorities of these five aspects are always
  different under various environments. For
  example, in commercial systems, availability is
  always the most important, while confidentiality
  may be the most critical for military
  environments.

13
Countermeasures

• Three categories in CORBA security
  countermeasures
• Prevention countermeasures
• Detection countermeasures
• Reaction countermeasures

14
Countermeasures

• A countermeasure is a protective measure for
  CORBA security and could be any modality such as
  an action, a device, or a technique.
• Basic functional components for the
  countermeasure of CORBA security services
• Identification and authentication
• Access control
• Security audit
• Communications protection
• Non-repudiation
• Security administration
• Segregation
• Automatic security enforcement

15
The CORBA Security Model
Figure CORBA Security Approach
16
The CORBA Security Model

• A client request services and a target object
  providing services.
• ORB core
• ORB security services
• Access Control Service
• Secure Invocation Service
• Access Control and Secure Invocation Service
  specifications must be available in actual CORBA
  platforms (implementations).

17
CORBA Security Execution Model
Figure Security Binding
18
CORBA Security Execution Model

• Client makes a request to access the target
  object.
• Client must obtain a binding to the target
  object.
• If the binding is established, and a reference to
  the target object is returned, invocation is
  allowed.

19
CORBA Security Execution Model
Figure Domain Objects
20
CORBA Security Execution Model

• policy object
• for groups of target objects to capture common
  security features in a single policy.
• domain manager
• each security policy domain has its own policy
  domain manager.

21
Problems and Weaknesses of CORBA Security

• Architecture
• Authentication and Authorization
• Security Audits
• Non-Repudiation
• Policy Management
• Assurance

22
J2EE

• Introduction to middleware security
• CORBA security
• J2EE security
• WebSphere security
• .NET security
• Comparison within these middlewares
• Conclusion

23
J2EE Platform

• The J2EE platform uses a multi-tiered application
  model
• Distributed over three locations
• client machines
• J2EE server machine
• database or mainframe applications.

24
J2EE

• The architecture includes a large set of
• application programming interfaces (APIs)
• tools and implementations of commonly-used
  security algorithms, mechanisms, and protocols.
• Provides developers a comprehensive security
  framework for writing applications.
• Provides the user or administrator a set of tools
  to securely manage applications.

25
J2EE Component Based Architecture

• J2EE components
• Application clients and applets components run on
  the client.
• Java Servlet and JavaServer Page (JSP) components
  are Web components that run on the server.
• Enterprise JavaBeans (EJB) components (enterprise
  beans) are business components that run on the
  server.

26
J2EE Component Based Architecture

• J2EE components are written in the Java
  programming language and are compiled in the same
  way
• Components are verified to be
• well formed and in compliance with the J2EE
  specification,
• deployed to production, where they are run and
  managed by the J2EE server.
• J2EE components vs. "standard" Java classes
• J2EE components are assembled into a J2EE
  application

27
J2EE Security Model

• Sandbox Approach
• A sandbox is the set of functions or resources
  that a piece of code is allowed to access
• Helps enforce security by restricting the code to
  its sandbox
• Policy based access J2EE platform uses security
  policy to decide which individual access
  permissions are granted to run code.
• Permissions are based on the codes
  characteristics
• who is running the code,
• where it is coming from,
• whether it is digitally signed, and if so by
  whom.

28
J2EE Security Mechanisms

• J2EE that provide mechanism for confidentiality,
  integrity, accountability, and availability
  through
• Access Controls
• Code-based Access
• Role-based Access
• Secure code verification and execution
• Secure communication
• Secure code and data protection.
• Auditing

29
Code Based Access Control

• Code-based access control in J2EE is implemented
• Bytecode Verifier
• Class loader
• the Security Manager and Access Controller

30
Code Based Access Control Class loader

• The hierarchy of the class loader prevents
  unauthorized and un-trusted code from replacing
  any code in the base classes.
• Provide security by managing namespaces.
• A class that is loaded by a particular class
  loader can only reference other classes in the
  same namespace
• Responsible for fetching the applet's code from
  the remote machine, creating and enforcing a
  namespace hierarchy

31
Code Based Access Control Class loader

• Delegation Principle if a particular class is
  not loaded already,
• the classloaders delegate the requests to load
  that class to their parent classloaders
• delegation continues until the top of the
  hierarchy is reached and the primordial
  classloader loads the class

 
32
Code Based Access Control Bytecode Verifier

• Invoked before a class loader may permit
  execution
• Traverse the bytecodes before it goes to the
  Just-in-Time (JIT) compiler or JVM
• Validates all untrusted code before permitting
  execution within a namespace.
• Checks and verifies against the executing code.
• Stack integrity, bytecode structure, buffer
  overflows, method parameter types, semantics, and
  accessibility policies are all checked and

33
Code Based Access Control Bytecode Verifier
34
Code Based Access Control Security Manager

• The Security Manager enforces the boundaries
  around the sandbox by implementing and imposing
  the security policy for applications.
• All classes in Java must ask the security manager
  for permission to perform certain operations.
• Java has two security policy levels
• for the executing machine
• one for the user

35
Role-Based Access Control

• Role-based access control, J2EE uses the Java
  Authentication and Authorization Service (JAAS).
• JAAS is an integrated package that implements a
  Java version of the Pluggable Authentication
  Module (PAM) framework.
• JAAS is a set of APIs that can be used
• For authentication of users, to reliably and
  securely determine who is currently executing
  Java code.
• For authorization of users to ensure they have
  the access control rights (permissions) required
  to do the actions performed.

36
Role-Based Access Control

• JAAS provides flexible access control policy for
  user-based, group-based, and role-based
  authorization
• JAAS currently supports authentication methods
  including Unix, JNDI, and Kerberos
• Java servlets also support authentication through
  all of the HTTP methods
• Basic server prompts for a username and password
  . no Encryption, repeat on failure
• Digest uses encryption to protect passwords
• Form login page is displayed instead of a dialog
  and an error page is s displayed if login fails

37
Role-Based Access Control

• User access checking can be done both
  declaratively and imperatively within different
  components of J2EE
• Java servlets provide user access checking
  declaratively at the servlets level
• EJBs provide user access checking declaratively
  down to the method level
• JAAS provides user access checking imperatively
  within methods.

38
Secure Communication

• J2EE supports APIs and implementations for the
  following standards-based secure communications
  protocols
• Transport Layer Security (TLS)
• Secure Sockets Layer (SSL)
• Kerberos (accessible through GSS-API),
• Simple Authentication and Security Layer (SASL).

39
Secure Communication

• It also has support for HTTPS
• In addition, 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), and can use
  this connection for remote method invocations
  (RMI).

40
Secure Code and Data Protection

• Java provides ways of maintaining code and data
  integrity.
• Java Cryptography Extensions (JCE) provides a
  framework and implementations for
• Encryption
• key generation and key agreement
• Message Authentication Code (MAC) algorithms
• Java Cryptography Architecture (JCA) provide key
  cryptographic functionality
• JCA included APIs for digital signatures and
  message digests.

41
Secure Code and Data Protection

• J2EE provides the ability for signed distribution
  files via certificate management that can be
  utilized to verify code and data sources.
• A supplier bundles Java code (and any related
  files) into a JAR (a Java Archive),
• signs the file with a digital signature.
• 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, in order to
  maintain the security of private data and methods
  of a package

42
Auditing

• The J2EE specification does not specify any
  particular requirements or APIs for auditing in
  J2EE systems
• The J2EE programming model aims to shift the
  burden of auditing away from developers and
  integrators to deployers and managers.
• Auditing functionality will vary from one J2EE
  Product Provider to another.

43
WebSphere

• Introduction to middleware security
• CORBA security
• J2EE security
• WebSphere security
• .NET security
• Comparison within these middlewares
• Conclusion

44
WebSphere

• IBM Integration Software Platform
• Includes servers, services and tools to write
  and run web applications
• Supports Multiple Platforms Linux, z/OS etc.

45
Components of WebSphere

• WebSphere has 3 core parts
• WebSphere Application Server
• WebSphere Process Server
• WebSphere Enterprise Service Bus

46
WebSphere Application Server

• Web services-based application server
• Built on open standards to support wide range of
  applications.
• Acts as a web- middleware
• Web Server handle client request
• Application Server provide linkage between
  HTTP request and business logic
• Business Database

47
WebSphere Process Server

• Service Oriented Architecture integration
  platform
• Ability to develop and modify integration
  applications dynamically
• Used to develop and execute standards-based,
  component-based business integration applications
  in a Service Oriented Architecture

48
WebSphere Enterprise Service Bus

• Provides
• Web Connectivity
• JMS Messaging
• Service oriented Architecture
• Improves flexibility through the adoption of
  service oriented interface.

49
WebSphere Security
50
WebSphere Security Components

• Security is a collaborative efforts of
• Security Server
• Security Collaborative
• Security Plug-in

51
Security Server

• Controls security policies
• Provides application wide services
  authentication and authorization
• Acts as trusted third party

52
Security Collaborator

• Acts as common runtime environment
• Performs authorization check
• Logs security-tracing information

53
Security Plug-in

• Resides in the web server
• Protect pages served by server
• Consults the security server before fulfilling
  requests.

54
Security Features

• Authentication
• Authorization
• Delegation
• Data Protection

55
Authentication

• Process of making sure that a client is valid in
  particular context
• Client user, machine, or an application
• Authentication using WebSphere policies or some
  external application.

56
Authentication Mechanism

• Simple WebSphere Authentication Mechanism (SWAM)
  for simple non distributed applications.
• Relies on session IDs
• No forwarding of credentials

57
Authentication

• Light Weight Third Party Authentication
• For distributed multi-application servers
• Supports forward able credentials and Single Sign
  On (SSO)

58
Role Based Authorization

• Authorization determines whether a caller has
  necessary Privileges.

59
Delegation

• Extension of Enterprise Java Bean Delegation
• Allows intermediary to perform a task initiated
  by a client under an identity determined by the
  associated policies.
• If no delegation policies are declared, the
  intermediary will use the identity of the
  requesting client.

60
.NET

• Introduction to middleware security
• CORBA security
• J2EE security
• WebSphere security
• .NET security
• Comparison within these middlewares
• Conclusion

61
.NET Framework

• Common Language Infrastructure
• Common Type System
• Common Intermediate Language
• Common Language Specification
• Just-in-Time Compiler
• Virtual Execution System
• Assemblies
• Metadata
• Base Class Library

62
.NET Security Implementation

• Code Access Security
• Role Based Security
• Secure Code Execution and Verification
• Secure Code Communication

63
.NET CAS
64
Stack Walking
65
Policy Implementation
66
Role Based Security

• Role-Based Access Control (RBAC) is an approach
  to restricting system access to authorized users
• Administrator
• User

67
Secure Code Verification and Execution

• Application Domain (Sandbox)
• Managed Code
• Unmanaged Code (Wrappers)

68
Secure Communications

• Secure Sockets Layer (SSL)
• Transport Layer Security (TSL)
• Secure Support Provider Interface (SSPI)

69
Security Issues

• Only as reliable as the compiler
• Global assembly cache (GAC)
• Windows

70
J2EE vs. .NET

• Authentication and authorization services in .Net
  are provided through Microsoft windows operating
  systems and identification repositories.
• J2EE, on the other hand, does not specify which
  methods or identification stores should be used
  to perform these functions, leaving these
  decisions up to vendors and developers.
• The permissions capabilities in .NET are more
  robust as compared to J2EE, allowing a more
  fine-grained level of permissions to be
  established for code.

71
J2EE vs. .NET

• J2EE and .NET offer very similar capabilities,
  with their realization slightly differing in
  approach, which is most likely tracked to the
  differences in the underlying paradigm
  philosophies of Java and Microsoft.
• Securing communication capabilities J2EE
  transcends .NET in that it is not limited in its
  usage with an application server, as in .NET's
  IIS.
• As a result the stability and insulation from
  external attacks has been much higher in J2EE
  because .NET continues to build upon the
  Microsoft platform that has numerous security
  holes.

72
CORBA vs. J2EE and .NET

• CORBA security is a meta-model which describes a
  range of security capabilities, while .NET and
  J2EE offer actual security capabilities and APIs
  (Application Programmer Interfaces). In this way,
  .NET and J2EE which can execute a subset of CORBA
  security features and capabilities, could be
  depicted as the realization of the CORBA security
  meta-model.