|
|
This chapter describes security options you can implement for your deployment.
The purpose of this chapter is to help you understand the security requirements so that you can assign responsibility for developing a plan for security in your deployment.
This chapter includes the following topics:
BEA provides the following additional resources to prepare the security leader for this assignment.
Figure 7-1 provides a high-level representation of the recommended network security for deployment of ALI components.
A firewall can be a valuable component in an overall security strategy. However, firewalls alone do not create security. Firewalls typically provide the first line of defense, intelligently routing requests and filtering out those that do not meet requirements configured into the device (or software). Depending on the sophistication of the firewall product, more or less intelligence can be built into the decision tree affecting whether a packet should pass through the firewall. Having a firewall in place can provide a false sense of security, however. Consider the following real world scenario:
Suppose a Web server operating in a DMZ behind a firewall restricts traffic to port 443 (HTTPS) requests. A second firewall insulates the internal network from the computers in the DMZ. A hacker from the Internet sends a buffer overrun attack to the IP address of the Web server. The data looks like a regular HTTPS request, it goes to port 443, and is passed through to the Web server as a TCP stream. The Web server tries to decrypt the stream in the normal fashion. The data inside the request exploits a weakness in the Web server that allows it to overrun the memory stack of one of its threads. The thread executes some code sent by the hacker. The code gains control of the Web server, opens a new socket and sends a similar malicious request to the next server in the HTTP(S) chain. The request goes unnoticed by the second firewall (it still uses HTTPS TCP port 443). The target Web server is controlled in the same fashion. If the second server is a member of your primary domain, the hacker has a good access point to your network. If the buffer overruns were done carefully and security audits for successes (versus failures) are not implemented on the Web servers in the chain, it is unlikely the attack would even be noticed.
This is not to imply that firewalls are useless. On the contrary, firewalls can dramatically limit the nature and even the source of potential attacks. Firewalls must be supplemented by good internal security policies and measures. For example, by restricting the rights and privileges of the user in whose process space the Web server runs, risks can be minimized or eliminated. Furthermore, with careful configuration of network trusts and operating system security audits and alerts, an attack such as that described above could be very difficult to implement.
A DMZ (sometimes referred to as a demilitarized zone or perimeter network) is a computer or small network inserted as a neutral zone between a private network (intranet) and the outside public network (Internet or extranet). A DMZ uses some combination of firewalls and gateways to prevent outside users from having direct access to a server that holds company data.
The remainder of this section focuses on the positioning of ALI components with respect to firewalls and perimeter networks (DMZs). BEA does not advocate the use of any specific configuration. This section presents several possible topologies that incorporate firewalls, since they are a common element of many company infrastructures.
The most important security measure is the "hardening" (establishing maximum possible security) of the computers involved in the portal configuration, especially those that receive direct user requests. These Web server computers are sometimes referred to as bastion hosts, since they are typically the most vulnerable to attack. Establishing the appropriate privileges for the ALUI user is a critical component of this activity (as is installing all of the appropriate security patches for the operating system and application server). However, once steps are taken to secure bastion hosts and other computers, you can provide extra layers of security to protect against unknown vulnerabilities in the operating system or Web server software.
Residing in the DMZ, the Portal component requires the most scrutiny in designing for security. Except for the Database and Search, all requests from the Portal component into the internal network are made through web services protocols using TCP/IP and HTTP 1.1. This web services architecture provides the following security advantages:
ALI provides many out-of-the-box integration web services to connect to Windows Active Directory, LDAP Servers, Documentum, Microsoft Exchange, Lotus Notes, SAP, PeopleSoft, and Siebel, just to name a few. Organizations are encouraged to develop custom web services to integrate with internal systems. From a security standpoint, these are all the same and all would be deployed on the internal network. Organizations can use firewalls to further compartmentalize internal networks as needed.
Following are some simplified examples of perimeter network topologies. In all cases, the target audience for the portal is both internal and external, thus some form of perimeter network is implemented. VPN topology is deliberately omitted, although it is a very common means of accessing internal portal content from outside the firewall. For the purposes of this discussion, VPN is considered equivalent to internal network access.
One of the simplest implementations of a perimeter network involves a reverse proxy. Much as proxy servers route traffic from the internal network to the Internet, reverse proxies route traffic in the opposite direction. A reverse proxy can be hardware (for example, F5 Big IP Application Switch) or a software component (for example, MS Proxy Server), and can incorporate other functionality, such as packet inspection and intelligent routing. The reverse proxy generally acts as the firewall between the outside world and the internal network, but can also be used in concert with multiple firewalls. Reverse proxies are somewhat controversial among network administrators, but are commonly used by organizations who view reverse proxy servers as one component in an overall solution.
A second very common practice is to create multiple networks in a single computer through the use of two or more Network Interface Cards (NICs). With this scenario, you might also incorporate a firewall in addition to multiple NICs, with the firewall and one NIC serving as the perimeter network. The firewall blocks all traffic except HTTP requests, which are received by the Portal component on the first NIC. The Portal component uses the second NIC to communicate with other hosts residing on the internal network. Multiple NICs on the other hosts with yet another firewall can serve to separate them from the true internal network computers. In this case, adding another layer of indirection offers considerable benefit, without any associated performance degradation. The extra network card doubles the network bandwidth of the Portal component, improving scalability, increasing network security, and eliminating the need for server-to-server encryption, since there is no access to the dedicated subnet.
Given the ALUI architecture, it is possible to deploy multiple ALI Web servers that implement different functionality. For example, one Web server might implement administrative functionality (for example, Content Service creation), while another might not. Administrative users are redirected to a separate URL to take advantage of the administrative portal pages. Similarly, external users can be granted more limited use of the portal than internal users. (Users that access the portal through a VPN are considered internal users.) Relegating all externally accessible resources to the perimeter network can eliminate virtually all traffic through the firewall for external users. At some sites, the only resource accessible through the firewall is the database server using vendor-specific database proxy software. For example, you might not want to allow internal documents to be searched or viewed by external users. Likewise, all external users are ALUI users, not LDAP users, since no HTTP or LDAP connection is enabled.
After you install ALI components, you can configure portal communication to use any of the following security modes.
For detailed information on configuring these settings, see the Administrator Guide. For additional information on SSL, see Deploying SSL.
Secure Sockets Layer (SSL) is a protocol developed by Netscape for transmitting private documents on the Internet. SSL works by using a public key to encrypt data that is transferred over the SSL connection. All the major browsers support SSL, and many Web sites use the protocol to obtain confidential user information, such as credit card numbers. By convention, URLs that require an SSL connection start with https rather than http.
SSL prevents potential eavesdroppers from intercepting information (such as passwords) sent to Web sites and information (such as secure documents) the Web site sends back. Encrypting and decrypting communications requires processing and increases the time required for pages to load and display. A Web site can use SSL on some pages and not others, so most sites find a compromise between performance and security by using SSL only in strategic locations. For example, most e-commerce sites allow you to browse selections and add items to your shopping cart over HTTP, then they switch to HTTPS when you check out to protect personal information, such as your name and credit card number. Although there is some overhead in establishing an SSL session, the overhead for encrypting and decrypting during an established session is usually insignificant.
SSL can also be used to encrypt traffic between Web servers and Automation Services and portlet, Content Service, Search, or Authentication components. The Parallel Portal Engine supports SSL encryption of the parallel requests made to these remote servers, allowing safe transmission of portlet preferences and other data delivered from Portal components to other ALI components. To implement SSL between Portal and other hosts, register the remote server (the remote server object is used for all four types of web services) with an HTTPS URL. On Unix and Linux, the PPE implements SSL using OpenSSL libraries. The SSL/TLS strength and algorithm used is determined by the negotiation between the connecting parties. On Windows, the portal engine uses Microsoft SSL libraries.
Generally speaking, encryption is the process of converting plain text into code in order to prevent any but the intended recipient from seeing that data. There are many types of data encryption, and they are a key element of network security. For portals, encryption is important in three primary contexts. These are:
For the first two cases, SSL provides a convenient, standard means of encrypting any data transmitted over HTTP. ALI uses an alternate mechanism for encrypting persistent sensitive data.
ALUI provides a means of encrypting sensitive information that is persisted to any of a variety of repositories (for example, the ALUI database, the Windows registry, configuration files).
Data stored by ALUI components are most commonly encrypted using a 128-Bit AES algorithm. The algorithm is fixed in the software and cannot be altered. This encryption represents the final line of defense; however, additional measures are strongly recommended to secure this data, such as:
PKI systems use two mathematically related keys known as the public key and the private key. The public key can be distributed publicly without compromising the security of a system, as long as the private key remains secret. Anyone can use the public key to encrypt a message such that only someone with access to the private key can read it. Of more importance to this discussion, someone with access to the private key can digitally sign a message. Anyone can read a digitally signed message and can use the public key to verify that it was signed with the private key, proving the identity of the author.
Suppose a bank receives an e-mail message directing the transfer of $10,000 from a particular account to a numbered Swiss bank account. The message is, purportedly, from a bank customer and is digitally signed. The bank officers attempt to verify the digital signature, but, as they have never received e-mail from that particular customer before, they do not have the customer's public key in the system. The e-mail contains a link to a public key server, so the officials follow the link, look up the key, and use it to verify the signature. Everything checks out, so they transfer the money to the account of the impostor who has just robbed the bank customer's account.
How? The impostor set up a key server and entered his own public key under the bank customer's name, then signed the directive using his own private key. The signature is perfectly valid since the public and private keys correspond. The bank was fooled into thinking the impostor's public key was that of the customer, making the directive seem genuine.
The X.509 digital certificate standard was designed for a single purpose: to certify the owner of a public key. A certificate contains a public key and the name and contact information of its owner, all signed by a trusted certificate authority. The certificate authority has taken steps to ensure the bank customer's identity before issuing the certificate, and, verifying the authority's digital signature ensures that the certificate is not a forgery.
Returning to the example above, the impostor will be unable to obtain a certificate for his public key in the name of the bank customer from a reputable authority. If he tries to use his own certificate, the bank officials will note that the owner of the key is not the purported signer of the e-mail and block the transaction.
Suppose the bank receives another e-mail directing a transfer, again purporting to come from one of its customers. This message is not digitally signed, but attached is a copy of the customer's X.509 digital certificate. The certificate contains the customer's name and address and is properly signed by a trusted certificate authority. Should the bank officers approve the transfer?
No, not if they understand PKI. A public key is, by definition, public information. For people to verify a signature, the owner of the signature posts it to public key servers and distributes it to anyone who asks. The message could have come from anyone who has access to a computer.
To be confident of identity in a PKI system, two pieces of information are needed:
SSL employs both of these pieces of information to provide secure client authentication as an optional part of the SSL handshake. If requested by the server, an SSL client provides a copy of its client certificate and digitally signs a digest of the handshake. An impostor can easily supply a copy of a stolen certificate, but cannot forge the signature without knowing the corresponding private key.
Delegation is a technical term for a process in a computer security system that allows a system to act on behalf of a particular user, particularly when accessing other systems. As an example, consider an e-mail portlet in a portal. When the portal system attempts to access the e-mail system, the latter will respond with a challenge for credentials. At this point, the portal can prompt the user for credentials or use credentials stored earlier. What you want to be able to do, however, is delegate to the portal system the authority to access the e-mail system on your behalf. This grant of authority should last only as long as you are connected to the Portal component and should not require storing credentials permanently. Kerberos is an excellent example of a system that permits this sort of delegation.
In any PKI system, the private key is jealously guarded, since access to it grants the privilege of signing messages. Since signing messages is the only way to prove identity within PKI, the only way to delegate authority is to share the private key. This is not controlled, secure delegation, but rather an unlimited, permanent grant of authority.
Returning to the portal example cited previously, consider the case where the portal has been configured to authenticate using the client certificate option of SSL. When a user connects a Web browser, it sends a signed message accompanied by the user's certificate, and these together prove the user's identity to the portal. Can the portal now pass the user's certificate on to the e-mail system to retrieve mail? No, for the same reason the bank officials will reject attack 2. If the e-mail system accepted the certificate as proof of identity, anyone could easily access an e-mail account using the publicly available certificate.
So, to access e-mail on a user's behalf, the portal system needs the private key, which it does not have after the SSL handshake. Browsers do not supply any automatic way to transfer this key (nor should they), so the user needs to go through some configuration process of extracting the private key from the key store on the local machine and uploading it to the portal for storage. The user would either repeat this process on every login or allow the portal to store the certificate permanently. In the latter case, the portal becomes a holding point for every certificate in the system, a sort of master key room, which can potentially grant a hacker access to every system as any user.
Delegation is the major problem, but digital certificates have other drawbacks as a portal single-sign-on solution:
The BEA OEM version of Oblix NetPoint SSO software supports the use of digital certificates to securely and transparently authenticate against the SSO server, which then issues a delegable credential (in the form of an HTTP cookie). Using out-of-the-box configuration options, the portal can accept this credential for user authentication and forward it to selected portlet web services. Further, the Oblix NetPoint product provides tools to simplify the process of issuing and managing certificates and can be configured to accept other forms of authentication (for example, passwords) for users on the road without access to their desktop certificate. To implement this option, consult the Oblix documentation to enable and deploy PKI within that system.
ALUI also supports integration with SSO products from other vendors.
In the absence of a cookie-based SSO solution, there are two approaches to configuring the portal to accept client certificates for authentication. Both require using SSL on the login page (security modes 1, 2, or 3). When using certificates tied to Windows domain accounts, you can configure IIS to accept client certificates and then use the out-of-the-box Windows SSO configuration on your portal. This is the easiest approach to take since it leverages the built-in features of Windows, and is the recommended approach whenever possible. To accept certificates from users unrecognized by IIS, you will need to implement a custom SSO solution, which entails writing a custom SSO vendor class in Java or C#.
You can install server digital certificates on any ALUI component (Administrative Portal, Portal, Remote Servers, and so on) and enable SSL. ALI supports SSL between browser and server as well as between a Portal component and Remote Servers.
You can use a digital certificate and SSL to communicate with your LDAP server.
You can use client digital certificates with SSL to authenticate users to the portal. This can be done with Windows Integrated SSO, with a custom SSO solution, or in conjunction with a supported third-party SSO product (for example, Netegrity, Oblix).
The portal cannot "passthrough" digital certificates to Remote Servers. This is impossible because SSL does not permit delegation.
You can do SSO to portlet Web services and use digital certificates to log in to the portal, but only if you use a third-party SSO product that supports both cookie-based SSO and digital certificates (this includes Oblix WebGate and Netegrity SiteMinder). In this case, users use the digital certificate to log in to the SSO server and obtain the SSO cookie, and ALI accepts the SSO cookie and forwards it to portlet Web services.
There are several steps involved in setting up SSL for your deployment. This section provides a brief overview of the steps you need to complete.
* to http://computer_name:port_number/portal/server.pt.
| Note: | You do not need to include the port_number for .NET deployments. |
https://computer_name:port_number/portal/server.pt.
| Note: | You do not need to include the port_number for .NET deployments. |
| Note: | If you have any portlets or Remote Servers that use JSControls or Adaptive Portlets you must also import the CA certificate into those runtimes. (The JSControls libraries are embedded in server and IDK products and are initialized by HTTP-downloading an XML configuration file from the Image Service.) |
For each machine that makes requests to a secured server running in SSL, you must import into the cacerts keystore the certificate of the CA that signed the certificate used by the secured server:
To obtain the CA certificate, navigate to the CA and save the .der encoded certificate file as a .cer file; you might want to use imgsvr.cer for an Image Service or portal.cer for a Portal, or you might want to use the server hostname.
keytool -v -import -trustcacerts -alias CA_alias -file CA_certificate_path -keystore cacerts_keystore_path
Replace the variables with the following information:
For each machine that makes requests to a secured server running in SSL, you must import into the MMC the certificate of the CA that signed the certificate used by the secured server:
To obtain the CA certificate, navigate to the CA and save the .der encoded certificate file as a .cer file; you might want to use imgsvr.cer for an Image Service or portal.cer for a Portal, or you might want to use the server hostname.
C:\>mmc
CommunityImagePublishBrowserLocation=https://machine_name/imageserver/plumtree/portal/templatesCommunityImagePreviewBrowserLocation=https://machine_name/imageserver/plumtree/portal/templates/previewCommunityStyleSheetListURL=http://machine_name/imageserver/plumtree/common/public/css/community-themes.txtJSComponents.AlternateImageServerUrl=http://machine_name/imageserver
If the Image Service is on Java, be sure to change the port to the correct one (for example, https://machine_name:ssl_port_number/imageserver).
Collaboration does not require any changes to function in security modes 1 or 2, as it uses the portal's Image Service settings. A certificate is not required.
If you are using Security Mode 3, import the certificate of the CA that signed the Image Service and/or Portal certificate into Collaboration. For details, see Importing CA Certificates into the Keystore.
However, if the host/port of the normal Image Service URL used by browsing users is not accessible from Collaboration (for example, the Image Service is on a different machine than Collaboration), you must change the jscontrols component that Collaboration uses. The symptom of this problem is error messages displayed in the Calendar portlets. To avoid the errors:
<jscontrols>
<imageServerConnectionURL>[URL]</imageServerConnectionURL>
Import the certificate of the CA that signed the Image Service and/or Portal certificate into Studio. For details, see Importing CA Certificates into the Keystore.
Single sign-on (SSO) has many different meanings in different contexts. It can mean protecting your Web server with a product from an SSO vendor, such as Oblix. It can mean preventing your users from having to enter credentials more than once, or at all. It can mean identity management or a way to store credentials for many systems to simplify user experience and administrative management. Usually it means some combination of these notions.
The key to understanding your SSO requirements is realizing that the portal is based on a loosely coupled architecture; different tiers of components communicate with each other, primarily over HTTP. The end-user connects to the portal tier over HTTP; the portal connects to numerous other systems over HTTP, including many systems that act on behalf of the end-user. The key is to make this simple for the end-user, simple enough for the administrator, and secure enough for the security team.
When users point their browsers at the portal, the default experience is for users to be presented a login screen. This login screen allows users to authenticate against any authentication source, which might be a remote system such as LDAP, the portal database, or an SSO provider.
When delegating authentication to an LDAP authentication source, the portal can be configured to keep the user credentials in a safe location within memory for later use. The sequence of events for LDAP is as follows:
Delegating authentication to an SSO source can circumvent the ALUI login screen and engage the end-user in the SSO login mechanism (could be a login screen, a key card, or some other mechanism). Common SSO sources include Oblix, Netegrity, and Windows Integrated Authentication (WIA). The sequence of events for Oblix would go something like this:
In both cases the authentication was delegated to an external source. In both cases this was likely ultimately delegated to LDAP. In the first case, however, the portal has the user's password for later use (if configured to do so). In the second case, the SSO vendor might have employed any of several authentication mechanisms that it supports, whether login screen or keycard.
When using Windows Integrated Authentication, the user must be logged in to a machine on a Windows network. The browser on this machine is smart enough to pick up the user's identity, so the browser can negotiate with the portal to establish the users credentials. The sequence of events for WIA is as follows:
Notice that the portal was never able to capture the user's password, and the user needed to be logged in to a Windows network for the authentication to succeed. Additionally, a multi-pass handshake occurred between the browser and the portal. Companies often request that the portal be able to repeat this WIA authentication between the portal and the remote server. The portal cannot do this, because there is no forwardable token; Although WIA supports not only NTLM but also Kerberos5, which theoretically supports delegation, no supported browsers implement delegation. So, not only is the portal unable to broker this multi-pass handshake, WIA will fail across any HTTP proxy.
Other important considerations when using WIA are that the user must be an Active Directory or Windows user, Internet Explorer or Netscape 7.1+ must be used, and proxies between the browser and portal are not allowed.
After the user has logged in to the portal, the portal wants to serve the user exciting applications. These applications might be pulling from custom systems as well as enterprise systems such as SAP. Let us discuss how the portal can connect to SAP.
ALI provides a Integration Services- SAP that allows business users to provide SAP functionality in their applications. This extension is a remote component that calls into various SAP APIs. These APIs require a username and password. By default, the extension gives user credentials to the SAP system.
ALUI can pass user credentials in any of several ways:
The following table summarizes some features of different SSO options.
|