1 / 72

Security Capabilities of Commercially Available Middleware Platforms: An Investigative Study

Security Capabilities of Commercially Available Middleware Platforms: An Investigative Study. Group 4 Qian Luo Manu Juyal Amit Rana Shawn Jacobs. Middleware. What is it: Computer software that connects software components or applications.

joben
Download Presentation

Security Capabilities of Commercially Available Middleware Platforms: An Investigative Study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Capabilities of Commercially Available Middleware Platforms:An 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 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.

  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 code’s 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

More Related