Designing Security Architecture Solutions phần 6 ppsx

Additional CSI level 0 and level 1 interoperability might exist between vendors. Only pair-wise testing can tell. Vendor Implementations of CORBA Security Vendors are charged with the difficult task of implementing all of the security APIs in a manner that is: ■■ Independent of the underlying security controls ■■ Flexible in supporting multiple security policies ■■ Interoperable with multiple ORBs and with other security components The security service, in line with other OMG goals, must also be portable and fast. The fact that all the vendors claim compliance not only with the standard, but also with the common security interoperability levels means very little. You have to test to see whether this claim holds because of subtle differences in vendor implementations, in the choice of how structures are stored, how messages are formatted, how extensions are parsed, or how errors are handled. Much of the details of how to accomplish these goals are left unspecified. Implementing security under these constraints is made all the more difficult due to the distributed nature of the CORBA software bus. Where do the components of the trusted core supporting all communications reside in a distributed environment? What impact will security have on performance if this core is distributed across the enterprise? Vendors are required to provide security services to applications by implementing all the security facilities and interfaces required to secure an ORB. They must also provide basic administrative support for all choices of policy, but the standard allows for levels of interoperability requirements between security mechanisms. The CORBA Security Specification is very complex and has relatively low usage in applications because almost no compliant COTS products have been developed. Imple- mentations that do exist force the architect to accept the vendor’s interpretation of the open standard, use proprietary APIs, and create complex or brittle solutions that are hard to integrate with other ORB because of security interoperability issues. Vendors faced with the lofty goals within the standard pick a subset of features that would be adequate to claim compliance with the specification, and the final product has constraints of hardware, software, policy, cryptography, and so on. Some vendor security solutions might have some success with interoperability between objects in a heterogeneous environment by using other ORB vendors. Assumptions on policy and security management, however, might make interoperability impossible when extend- ing the CORBA security service across vendors and other enterprise middleware plat- forms. These vendor differences make for a lack of interoperability between security administration components across vendors and across security domains managed by using different products in each domain. It is not possible to manage security policy Middleware Security 211 across ORB vendors because of the impedance mismatch in the implementation of the security administration APIs and in GUI-based management tools. The security standard is also somewhat of a moving target. Many applications are con- tent to go with minimal security solutions, such as running all IIOP traffic over SSL, while waiting for mature specifications and products to emerge. Interfaces with other standards are also an issue. For example, the J2EE specification requires CORBA inter- operability, but the details of how this interconnectivity will happen are still being defined. Security in this context, between a proprietary standard with a reference implementation and an open standard with none, is certainly immature. CORBA Security Levels The Interface Definition Language (IDL) is the heart of CORBA, and the original CORBA security specification was geared more toward protecting interfaces rather than individual objects. CORBA security can be provided in the following three levels. ■■ Secure Interoperability with no reference to or knowledge of the IDL. ■■ Security with knowledge of but no reference to the IDL. In other words, the security solution generally uses statically defined files derived from the IDL definition that must be edited if the IDL changes. There is no code generation phase for the security solution for generating security extensions when mapping IDL definitions to object definitions. Applications are said to be security unaware. Vendor implementations most often use the interceptor security pattern. ■■ Security with reference to the IDL. We can use code generation tools to also generate security extensions to the object definitions generated from the IDL or to add security-related arguments to standard methods. The objects themselves can access the full security API for fine-grained access definition. Vendor implementations most often use the wrapper security pattern in conjunction with interceptors. Secure Interoperability Secure interoperability in CORBA can be achieved in homogenous environments when the following conditions are met: ■■ The ORBs share a common interoperability protocol. ■■ The client object and target object share and implement identical security policies. ■■ All entities share the same security services and mechanisms. General Inter-ORB Operability Protocol (GIOP) traffic is the high-level CORBA mes- saging protocol between the object and the target. GIOP can run over the Secure Inter- MID-LEVEL ARCHITECTURE 212 Data Link Layer SECIOP Server SECIOP Client Client Security Association Context and Message Sequencing Security Association Context and Message Sequencing Target Thread Target Thread Target Thread Target Thread Target Thread ThreadThreadThreadThreadThreadThreadThreadThread Figure 9.1 SECIOP sequence and context maintenance. ORB Protocol (SECIOP) or over IIOP. The Security Specification enables objects and target to communicate securely by either using SECIOP or by using IIOP over SSL. The Secure Inter-ORB Protocol SECIOP enables secure communications with support from the ORB and security infra- structure. Applications can deploy generic security mechanisms underneath SECIOP. The generic mechanisms supported include Kerberos, DCE, SPKM, and CSI ECMA (please refer to the security specification at www.omg.org for details). The standard describes security enhancements to the IOR description that enable the client to extract security information from the target object reference and use it to initiate a security association. This information could include the target’s identity, acceptable security policy, required policy, and cryptographic information. SECIOP implements the concentrator/distributor security pattern by allowing multi- ple threads of execution within each of many client objects to interact with multiple threads within a target object, all over a single underlying security link layer. SECIOP handles the multiplexing and demultiplexing of GIOP traffic in a transparent manner. Each pair of communicating entities can have its own security association. For each object-target pair, SECIOP enforces proper message sequencing at the link layer and maintains context information about the security association and the security mecha- nisms employed between the two entities, as shown in Figure 9.1. It also maintains association integrity by defining how the target should handle messages from the client, depending on the current association state. The standard defines a finite state machine (FSM) with states representing the association context between object and client. The FSM’s transitions are triggered by incoming messages from the client, which provides Middleware Security 213 Figure 9.2 IIOP over SSL. vendors with some guidance on how security associations are to be handled in CORBA, regardless of the underlying security mechanism. Alternatively, objects and targets can communicate securely independent of SECIOP, for example, by running IIOP over SSL. Essentially, the SSL model of security has noth- ing to do with the encapsulated protocol (in this case, IIOP). We will discuss this option in more detail in the following section. Secure Communications through SSL CORBA vendors have adopted SSL as a cost-effective and easily deployed alternative to fully supporting the OMG’s complex and high-level standard for CORBA Security. Run- ning IIOP over SSL provides basic communications security. The SSL protocol per- forms none of the security association, sequencing, and context management available under SECIOP. It implements the transport tunnel paradigm at the application level. To perform this task, developers need several components, including PKI support, certifi- cates, SSL libraries, configuration files, and some code modification. SSL-Enabling IIOP Connections SSL adds a layer of secure communication between the application layer protocol IIOP and TCP/IP. SSL, which we discussed in Chapter 8, “Secure Communications,” and show in Figure 9.2, provides basic security between two endpoints through authentica- tion through a public key cryptographic algorithm such as RSA, confidentiality through data encryption with a private key algorithm such as RC4, and data integrity through a cryptographic hash function such as SHA1. All vendors follow a similar pattern for SSL implementations. The developer must per- form the following actions: MID-LEVEL ARCHITECTURE 214 IIOP Server IIOP Client Certificate Manager - Certificate - Certification path to CA - Encrypted private key - Password to decrypt private key file - SSL protocol version - Cipher suite Current (points to peer) SSL SSL TCP/IP TCP/IP - Certificate - Certification path to CA - Encrypted private key - Password to decrypt private key file - SSL protocol version - Cipher suite Current (points to peer) Certificate Manager ■■ Decide whether authentication will be server-side only or mutual. ■■ Modify the build environment to include SSL and cryptographic libraries. ■■ Create PKI elements and set configuration files to point to the list of certificate authorities, certification path information, the client or server certificate, permitted cipher suites, the private key file associated with the process’s certificate, and an embedded password string to unlock the private key file. ■■ Provision these elements on each host. ■■ Add initialization code in the beginning of the CORBA server code to reference a context holder called the SSL::CertificateManager object to access the server’s certificate, certification path, and private key and a session object, called SSL::Current object, to access the certification chain and certificate of the client entity once the SSL session is established. ■■ Repeat these steps on the client if mutual authentication is desired. At run time, the server initializes the ORB and then uses the ORB::resolve_initial_refer- ences() to obtain the SSL::CertificateManager object for its own identity and the SSL::Current object for the client’s identity. The Current object also holds SSL protocol version and cipher suite information. Why Is SSL Popular? Why is SSL such a popular security solution? Vendors provide SSL because good imple- mentations of the protocol exist, open source or otherwise, that enable any client/server application using TCP/IP to communicate securely. It is easy to SSL-enable applications. There are few code changes. ■■ Some configuration options to the run-time environment must be set describing PKI components. ■■ Some initialization code that points to the correct certificate, private key file, and certificate path must be added. ■■ Some cleanup code to close file connections or write to audit logs must be inserted after the connection closes. The popularity of SSL-enabling CORBA applications comes from the enormous success of SSL-enabled Web traffic. SSL can have performance problems. Poor cryptographic libraries, slow server proces- sors, expensive bulk encryption, or excessive handshakes can cause SSL-enabled con- nections to run at a fraction of nonsecure IIOP connection speeds. SSL-enabled connections can be anywhere from 50 percent to 5 times as slow as nonsecure connec- tions. Some implementations show good performance under SSL-enabled mode, although this function is vendor and application dependent. Hardware accelerators, cre- ated for Web servers that improve SSL connect speeds 20 fold or more, are also avail- able. If CORBA applications can use them on the server side where the performance hit is most noticeable, SSL will become even more attractive. SSL solutions often provide Middleware Security 215 poor support for security management. Vendors provide no explicit guidance on secu- rity policy and the use and management of certificates in a CORBA environment. Raise these application issues (which we reiterate from our earlier discussion of SSL in Chapter 8, but now in the context of middleware) at the architecture review: ■■ Can all daemons be secured? Do some daemons have to accept insecure connections for interacting with legacy applications? ■■ Does the architecture create SSL links for local intra-host traffic? If the client and server are colocated, this process is a waste of resources unless the host itself has other local vulnerabilities that must be protected against. ■■ How does the application manage PKI issues? SSL-enabling an application transfers a significant portion of security management responsibility to the PKI supporting the application. Is certificate policy well defined? How are keys managed? How is revocation handled? How are servers informed of whether their certificates are about to expire? What if the PKI service itself changes? How does the application plan on handling trust during the changing of the guard? ■■ Which connections in the architecture need SSL-enabling? Do SSL connections need proxies to penetrate firewalls? ■■ Is performance an issue? Is the SSL-enabled architecture scalable to projected client volumes? Are there issues of interoperability with other vendor IIOP-over- SSL solutions? Do all applications share the same cipher suite? What does security policy mandate? ■■ What entities get certificates? Is assignment at the level of an object, process, or host? Do we distinguish between user processes and a daemon process on the host and assign separate certificates? Do we lump multiple objects on a host together to share a certificate? ■■ How do we handle the passwords that protect the object’s private key? Are these embedded in binaries? Do we build the passwords into the binaries during development (possibly exposing the private key), or do we maintain separate certificate instances for separate system instances, one for each of the development, integration, system test, and production environments? With good security architecture, running IIOP over SSL provides a low-cost means for applications to get point-to-point security by using a well-understood protocol, interop- erability, and minimal application code modification. Application-Unaware Security CORBA Security Level 1 provides security services to applications that are security unaware or that have limited requirements for access control and auditing. Level 1 secu- rity mechanisms require configuration of the ORB and require no code modification. MID-LEVEL ARCHITECTURE 216 Figure 9.3 CORBA Security Level 1. Level 1 security, shown in Figure 9.3, in almost all vendor products is implemented by using CORBA interceptors. Interceptors are the standard method to add run-time ser- vices to ORBs and allow the core ORB functionality to remain untouched. Several inter- ceptors can be chained together at the client or at the server, and the application must specify the order of interceptors on the chain. Each interceptor on the client is paired with a corresponding interceptor on the server. Interceptors function as communica- tions traps, capturing all requests and messages for service. Interceptors do add a per- formance hit to the communication that must be weighed in the architecture. CORBA Level 1 security is designed to provide security services that can be used by an application without significantly changing the application. The CORBA ORBs require no code changes and require only the run-time loading of security services. This ease of implementation comes with some limitations, however. ■■ Users cannot choose privileges; rather, they are fixed at application startup. Access control lists can be referenced but not modified unless the application is stopped and restarted. ■■ The application normally authenticates the user outside the object model and stores identity credentials at ORB initialization that are accessible to a PrincipalAuthenticator inside a client-side interceptor. This situation could imply that all entities within a single process will potentially share the same privilege level for access control unless the application reauthenticates as another user. ■■ Level 1 does not allow objects to enforce their own security policies. In general, all policy is fixed at compile time and all objects within a process are constrained to the same authorization policy. ■■ The vendor implementation can apply security policy only when communicating with remote objects, unless interprocess invocations on the local host are forced through the interceptor to be secured. Middleware Security 217 Policy Statement - Targets - Users - Groups - Modes - ACLs Authentication Service Authorization Service Directory Service Security Service Level 1 Interceptor Server Level 1 interceptor Client IIOP IIOPORB Figure 9.4 CORBA Security Level 2. PrincipalAuthenticator AuditDecision AccessDecision Current AuditChannel Vault Principal Security logging Session Object Access Control Rule Context Holder To ke n Context Holder Accounting Access Control Credential SecurityContext Figure 9.5 Some security objects visible under Level 2. Application-Aware Security CORBA Security Level 2, shown in Figure 9.4, provides security services to applications that are security aware and that can access a security service by using security API calls. CORBA Level 2 security enhances the security services provided in Level 1 by making some of the objects used to encapsulate features and functions of the security service available to the application programmer. For example, Security Level 2 makes visible to the programmer the same objects, some shown in Figure 9.5, that are visible and used by vendors in their Level 1 interceptor implementations. The application developer can MID-LEVEL ARCHITECTURE 218 ServerClient IIOP IIOP ORB Policy Statement - Targets - Users - Groups - Modes - ACLs Authentication Service Authorization Service Security Service PrincipalAuthenticator AuditDecisionAccessDecision Credentials Current Audit Channel SecurityContext Vault Directory Service use these security objects for authentication, authorization, and delegation purposes from within application objects. The security objects enable application objects to query policy, negotiate cryptographic algorithms, make access decisions, change privileges during execution, enforce their own policy, and provide additional authorization options. They include the following components: PrincipalAuthenticator. This object is used to create credentials for a given principal. If the application authenticates the user outside the object model (perhaps by using a UNIX login ID, authentication to a DCE cell, or a certifi- cate validation check), the application must transfer credentials to the PrincipalAuthenticator, normally at ORB initialization. Alternatively, the appli- cation can invoke PrincipalAuthenticator’s authenticate method to confirm the user’s identity within the object model. Credential. Once a user is authenticated, the PrincipalAuthenticator object can generate credentials upon request. These credentials can be transported with service requests or can be bundled with other credentials to create composite delegation credentials. Credentials are tokens that confirm authentication and provide some additional attributes. Current. The Security namespace has its own Current object. The Current object maintains the execution context at both the client and the server objects and is a container for credentials. SecurityContext. For each security association, there exist SecurityContext objects at the client and server. The SecurityContext object maintains additional security information such as credentials, session keys, policy in effect, cipher suites used within the association, and the peer’s security name. Any entity can have multiple SecurityContext objects, one for each association that is active within the object. Vault. The Vault is an implementation security object that creates SecurityContext objects on a secure invocation. The Vault uses all credentials, attributes, association information, and arguments from a secure invocation. Vaults can be used for simplifying object references in the implementation. AccessDecision. An AccessDecision object is used to implement access control. The access_allowed method on a target AccessDecision object causes the object to look up security policy to check whether the policy explicitly allows the operation or if the client has privileges through group or role membership. Please refer to the access control section in Chapter 3 for details of role-based access management. AuditDecision. The application can use this object to reference a security audit policy to look up the response required on any security event. Some events will be ignored, others will be logged as warnings, and still others will be logged as causing alarms or alerts. The AuditDecision object wraps the accountability functionality of the security services. AuditChannel. Each AuditDecision object owns a local channel to record events. Using Level 2 features, applications can use enhanced security on every object invoca- tion or gain fine-grained access to security options, manage the delegation of credentials, Middleware Security 219 MID-LEVEL ARCHITECTURE 220 specify security policies dynamically, or request applicable policy at the program or ORB level. Security Level 2 has many more features to enable complex security man- agement across multiple security domains, where the clients operating in each domain might not have a trust relationship between each other. Application Implications Although asynchronous messaging and synchronous messaging (using IDL-defined object interfaces) are very different paradigms, we can still draw parallels across the two domains when we discuss security. Many of the security mechanisms documented in the object-oriented CORBA Security Specification also apply to other messaging mid- dleware products, such as products that implement message queues. The requirements for authentication, access control, auditing, confidentiality, and so on are met by using the same underlying security protocols, and solutions encounter many of the same security issues. Other generic security implications include the following: Centrality in the architecture. The complexity of the security solution, and the care and feeding that it demands, might have the effect of pulling the security service toward the center of the architecture. This situation might not be acceptable if a future application feature request is denied because it clashes with the security service. Management of security policy. Managing, configuring, and validating security policy across a heterogeneous, distributed application is very complex. Additional complexities include managing user population changes, IDL evolution, event audit trail merging and analysis, and middleware version management. Scope creep within security. Once the enterprise has invested a considerable amount in deploying a security service for objects, vendors and managers will attempt to extend the solution to other resources by mapping files, appliances, application object methods, databases, URLs, IP addresses and ports, and many more. This assumption of scope limits might not be desirable to the original application as it increases the burden on the security service. IDL-centric security. The name space of objects that are protected is derived from the application’s IDL. This assumption is reasonable, because clients may only invoke operations on this interface. If only interface objects and operations can be defined and protected, however, what about implementation objects? What about possibly complex internal application structure that could potentially represent a vulnerability? What if the application has non-CORBA interfaces that provide access to internal objects? Will the alternate security mechanisms on these non-CORBA interfaces compromise the security architecture? Security through obscurity. Much of the internal details of the specification are left to the vendor. Interface definition is about delegating responsibility to another entity so that the details of service requests can be hidden. In complex architectures with many systems, several ORBs, and conflicting security policy, the team can TEAMFLY Team-Fly ® [...]... Architecture Presentation Data Database Web User Client host: tokens, DCE or logins/ passwords Incoming Web server content Web host security, Kerberos, SSL/SHTTP Servlet engine and EJB Security Web browser configuration policy Web server security policy Servlet and component security policy Database security Technology Policy User access policy Figure 10.2 Web security structural options Database security. .. how to configure and secure their product Web Security 225 All security solutions for Web applications share some common ground for solving our security architecture principles, including authentication, authorization, confidentiality, integrity, and auditing We will discuss client, server, and server-extension security For the last topic, we will describe security extensions to server-side java defined... security extensions to server-side java defined in the Java 2 Enterprise Edition (J2EE) standard J2EE Security has some interesting parallels to the CORBA Security Specification of Chapter 9, “Middleware Security. ” Web Security Issues Security for a Web application must be built with more structure than security for a Web server alone A Web-based application links a user on a client host through a Web... enterprise component services The J2EE standard builds upon the Java security model of virtual machines, security policies, security managers, access controllers, and trust J2EE uses standard extensions for cryptography, authentication, authorization, and programmatic access to security objects Many of the security goals described within the CORBA Security Standard are shared by J2EE, along with strong similarities... introduction to the core Java security model and to Chapter 9, “Middleware Security, ” for common security issues with enterprise middleware Team-Fly® Web Security 241 A key component of J2EE security is the Java Authentication and Authorization Service that is currently seeing some vendor support and availability For a discussion of how the JAAS specification fits into Java Security, please refer to Chapter... data flows from component to component Configuration The component-specific security configuration information that must be either statically loaded at component initialization or that can be dynamically referenced and modified during execution Security administrators manage the configuration components Security architecture solutions often consist of a familiar pattern of a series of chained interceptors... options available under Netscape We expand on Netscape’s security configuration dialog in this section Netscape’s browser security settings are managed through the security console This console presents and manages all underlying security information including passwords, Java controls, JavaScript controls, certificates, and options for mail or news The security console also presents the cryptographic modules... application presentation In this chapter, we will present common security- related issues around three-tiered, Web-based application architectures There are many, many vendor solutions for creating Web applications that conform to the presentation, application, and data layer definition of the standard three-tier architecture model A discussion of how security works in each circumstance would clearly be impossible,... security policy Web Security 229 options, technologies used, and architecture choices change along this path, we can still see elements of each of these four layers at each point Policy The directives of corporate security policy applicable to each of the components along the path from user to data store Technology The technology-specific security options available to secure each component Architecture The... thirdparty security providers, such as token servers or Kerberos Servlets and Declarative Access Control The Java Servlet Standard (at draft version 2.3, as of date) specifies a simple model for securing Java servlets The highlight of this specification is its use of XML for security declarations We will expand on the importance of XML and enterprise security management in Chapter 15, “Enterprise Security Architecture. ” . Access Control Credential SecurityContext Figure 9.5 Some security objects visible under Level 2. Application-Aware Security CORBA Security Level 2, shown in Figure 9.4, provides security services to. security services to applications that are security aware and that can access a security service by using security API calls. CORBA Level 2 security enhances the security services provided in Level. using the same underlying security protocols, and solutions encounter many of the same security issues. Other generic security implications include the following: Centrality in the architecture. The