security capabilities of commercially available middleware platforms: an investigative study group 4...
Post on 20-Jan-2016
225 views
TRANSCRIPT
Security Capabilities of Commercially Available Middleware Platforms:An Investigative Study
Group 4
Qian LuoManu JuyalAmit Rana
Shawn Jacobs
Middleware
What is it: Computer software that connects software components or applications.
What for: Used to support complex distributive computing applications (Wikipedia)
Middleware Platforms
CORBA J2EE .NET WebSphere
Purpose
To explore the concept of middleware security by examining the security capabilities of CORBA .NET J2EE WebSphere
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
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.
Types of Middleware
Remote Procedure Calls Publish/Subscribe Message Oriented Middleware Object Request Broker SQL-Oriented Data Access
CORBA
Introduction to middleware security CORBA security J2EE security WebSphere security .NET security Comparison within these middlewares Conclusion
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 client’s 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.
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.
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
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.
Countermeasures
Three categories in CORBA security countermeasures: Prevention countermeasures Detection countermeasures Reaction countermeasures
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
The CORBA Security Model
Figure: CORBA Security Approach
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).
CORBA Security Execution Model
Figure: Security Binding
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.
CORBA Security Execution Model
Figure: Domain Objects
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.
Problems and Weaknesses of CORBA Security
Architecture Authentication and Authorization Security Audits Non-Repudiation Policy Management Assurance
J2EE
Introduction to middleware security CORBA security J2EE security WebSphere security .NET security Comparison within these middlewares Conclusion
J2EE Platform
The J2EE platform uses a multi-tiered application model
Distributed over three locations:
client machines J2EE server machine database or mainframe
applications.
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.
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.
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
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 code’s characteristics who is running the code, where it is coming from, whether it is digitally signed, and if so by whom.
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
Code Based Access Control
Code-based access control in J2EE is implemented
Bytecode Verifier Class loader the Security Manager and
Access Controller
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
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
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
Code Based Access Control: Bytecode Verifier
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
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.
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
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.
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).
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).
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.
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
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.
WebSphere
Introduction to middleware security CORBA security J2EE security WebSphere security .NET security Comparison within these middlewares Conclusion
WebSphere
IBM Integration Software Platform
Includes – servers, services and tools to write and run web applications
Supports Multiple Platforms – Linux, z/OS etc.
Components of WebSphere
WebSphere has 3 core parts
WebSphere Application Server
WebSphere Process Server
WebSphere Enterprise Service Bus
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
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
WebSphere Enterprise Service Bus
Provides: Web Connectivity JMS Messaging Service oriented Architecture
Improves flexibility through the adoption of service oriented interface.
WebSphere Security
WebSphere Security ComponentsSecurity is a collaborative efforts of Security Server
Security Collaborative
Security Plug-in
Security Server
Controls security policies
Provides application wide services – authentication and authorization
Acts as trusted third party
Security Collaborator
Acts as common runtime environment
Performs authorization check
Logs security-tracing information
Security Plug-in
Resides in the web server
Protect pages served by server
Consults the security server before fulfilling requests.
Security Features
Authentication Authorization
Delegation
Data Protection
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.
Authentication Mechanism
Simple WebSphere Authentication Mechanism (SWAM) – for simple non distributed applications. Relies on session IDs
No forwarding of credentials
Authentication
Light Weight Third Party Authentication For distributed multi-application
servers
Supports forward able credentials and Single Sign On (SSO)
Role Based Authorization
Authorization determines whether a caller has necessary Privileges.
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.
.NET
Introduction to middleware security CORBA security J2EE security WebSphere security .NET security Comparison within these middlewares Conclusion
.NET FrameworkCommon Language Infrastructure
•Common Type System
•Common Intermediate Language
•Common Language Specification
•Just-in-Time Compiler
•Virtual Execution System
Assemblies
Metadata
Base Class Library
.NET Security Implementation
Code Access Security Role Based Security Secure Code Execution and
Verification Secure Code Communication
.NET CAS
Stack Walking
Policy Implementation
Role Based Security
Role-Based Access Control (RBAC) is an approach to restricting system access to authorized users
Administrator User
Secure Code Verification and Execution
Application Domain (“Sandbox”) Managed Code Unmanaged Code (Wrappers)
Secure Sockets Layer (SSL) Transport Layer Security (TSL) Secure Support Provider Interface
(SSPI)
Secure Communications
Security Issues
Only as reliable as the compiler Global assembly cache (GAC) Windows
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.
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.
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.