|
|
|
|
|
|
This topic includes the following sections:
The WLE product requires you have an LDAP-enabled directory service and a certificate authority (either commercial or private) set up for your organization.
Perform the tasks in this topic only if you are using the SSL Protocol or certificate-based authentication.
To use the SSL protocol or certificate-based authentication to protect communication between principals and the WLE domain, you need to install the WLE Security Pack. The WLE Security Pack contains the files necessary to enable the use of the SSL protocol. For complete information about installing the WLE Security Pack, see the BEA WebLogic Enterprise Installation Guide.
The use of a global directory service is the most popular way to store certificates. A directory service simplifies the management of information that needs to be globally available to an ever-growing number of users. The Lightweight Directory Access Protocol (LDAP) provides access to a variety of directory services.
The WLE product retrieves digital certificates for principals and certificate authorities from an LDAP-enabled directory service, such as Netscape Directory Service or Microsoft Active Directory. Before you can use the SSL protocol or certificate-based authentication, you need to install an LDAP-enabled directory service and configure it for your organization. The WLE product requires that the digital certificates be stored in the directory service in Privacy Enhanced Mail (PEM) format.
Directory services define a hierarchy of object classes. While there are a number of different object classes, there is a small set associated with digital certificates. Figure 2-1 illustrates the object classes associated with digital certificates.
By default, the WLE product retrieves digital certificates from the following object classes:
Installing the WLE Security Pack
Using the LDAP Directory Service with Your WLE Application
Figure 2-1 LDAP Directory Structure for Digital Certificates
Refer to the BEA WebLogic Enterprise Installation Guide for information about integrating your LDAP-enabled directory service into the WLE environment.
When configuring a WLE application to use the SSL protocol or certificate-based authentication, you may need to customize the LDAP search filter file to limit the scope of the search of the directory service. Customizing the LDAP search filter file can result in significant performance gains. The WLE Security Pack ships with the following LDAP search filters:
Editing the LDAP Search Filter File
If the directory service scheme for your organization is defined to store digital certificates in object classes other than certificationAuthority
and strongAuthenticationUser
, the LDAP search filter file must be modified to specify those object classes.
If can specify a location of the LDAP search filter file during the installation of the WLE Security pack. For more information, see the BEA WebLogic Enterprise Installation Guide.
The LDAP search filter file is owned by the administrator account. BEA recommends that the file be protected so that only the owner has read and write privileges for the file and all other users have only read privileges for the file.
To limit the search of the directory service for certificates for principals and certificate authorities, you need to modify the following tags in the LDAP search filter file:
These tags identify the stanzas in the LDAP search filter file that contains the filter expression that will be used when looking up information in the directory service. These BEA-specific tags allow the stanzas of an LDAP search filter file to be stored in a common LDAP search filter file with stanzas used by other LDAP-enabled applications that might be found in your organization.
The following is an example of the stanzas of an LDAP search filter file used by the WLE product for the SSL protocol and certificate-based authentication:
"BEA_person_lookup"
".*" " " "(|(objectClass=strongAuthenticationUser) (mail=%v))"
"email address"
"(|(objectClass=strongAuthenticationUser) (mail=%v))"
"start of email address"
"BEA_issuer_lookup"
".*" " " "(&(objectClass=certificationAuthority)
(cn=%v))" "exact match cn"
(sn=%v))" "exact match sn"
See the documentation for your LDAP-enabled directory service for additional information about LDAP Search File filters.
During the authentication process, the identity of a principal depends on the integrity of the public key value in the principal's digital certificate and the private key associated with the digital certificate.A certificate authority is a trusted entity that confirms the integrity of a digital certificate. All digital certificates must be signed by a certificate authority. In order to use the SSL protocol or certificate-based authentication in a WLE application, you need to set up a certificate authority from which to obtain digital certificates.
When setting up security for a WLE application, it is important to choose a suitable certificate authority, make the digital certificate for the certificate authority available, and then use the certificate authority to sign digital certificates for your WLE application. You can use a commercial or private certificate authority of your choice with the WLE product. The certificate authority must be in place before using the SSL protocol or certificate-based authentication.
Once you have chosen a certificate authority, you need a digital certificate for the certificate authority you are using. Refer to the documentation for the certificate authority you are using for instructions on obtaining a digital certificate for the certificate authority. Load the digital certificate for the certificate authority in the certificationAuthority
object class of the LDAP-enabled directory service you are using.
When using the SSL protocol and certificate-based authentication, the IIOP Listener/Handler and any principal that will use your WLE application require a digital certificate and private key to prove their identity to initiators of an SSL connection.
Refer to the documentation for the certificate authority you are using for instructions on obtaining a digital certificate for a principal. Load the digital certificates for the principals in the strongAuthenticationUser
object class of the LDAP-enabled directory service you are using.
When a principal gets a digital certificate from a certificate authority, they also get a file with a private key. Principals need this private key file to verify their identity in the authentication process. Store the private key file in a local directory structure that is accessible to remote applications. Assign the private key file protections so that only the owner of the private key file has write privileges and all other users only have read privileges for the file.
The WLE system uses the email address of the principal to construct a name for the private key file as follows:
Publishing a Certificate for the Certificate Authority
Obtaining Digital Certificates and Private Keys for Principals
Storing the Private Keys in a Common Location
For example, if the name of the principal is milozzi@bigcompany.com the resulting private key file is milozzi_bigcompany.pem . This naming convention allows an enterprise to have multiple principals that share a common username but are in different email domains.
The WLE software looks in the following directories for private key files:
UNIX
$HOME
Window NT
%HOMEDRIVE% %HOMEPATH%
The WLE software also looks in the following directory for private key files:
$TUXDIR/udataobj/security/keys
The /keys directory should be protected so that only the administrator has read and write privileges for the directory and all other users should only have read privileges for the directory.
Listing 2-1 provides an example of a private key file.
Listing 2-1 Example of Private Key File
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIICoDAaBgkqhkiG9w0BBQMwDQQItSFrtYcfKygCAQUEggKAEgrMxo8gYB/MOSXG
SbbCn10vTov6LUndfBNd6Ktg8KX9BFEuR3+26aVq9z9jwJiHsU8ZONxRx+7TV/p4
kDfPy2iwe/jWmNzbyge5ig84igXtkGEHPODWQY/ODmVxq4GwBnt0U5WMjnYt4X8m
y2UsvW9VhZGTzrUGCQ30z9Ixln/pm8PJB8pTBEtJ8rYiNbQGiuwB9GOyZIANYGy+
crfrTIhLp3z4aStcihP1b3R9lFw+t2feYKEQnCfaPmwwJLIk6/bp9Gd6LEEVR45y
+zUxj1uE5K26GyWE/mcdhDtAy+212s5lnfjs5voi1Uv5ER88fTtYjAcMljty0PM/
cIBb8+gEzKQOnjocryWJQHE9rUxnQjdpiCj/FEjz3DPN67AvHcx2UOAqholbNzqn
79c+nnnm9YcnFREwnwTKCticyvXTCsIT/bHD/Tn2RyjVW8Dbq/23I2YZLEMR2+k7
kdeanB8RpHdNHJVTKQM3A/tPo/aSkx6Ce7tXjGCJCyuCGDVRtCxupo2NRYcGi45Z
CzOvJB8tSGLw4WHh/iK8V0dM7H6qV115t4Ha3k+uYU1+0D/eTSfQV77KAfTXLvoO
4LAbV/JvLbAUCD70U/COl8yijllXSZPf6IB1Y5XH8P+FMgCkDOqwYG8zMWjbcgCj
abDVITdwYL5rCaIt8Nnz9xy7c2vKkYoCJLVIvZEVZE22gP77zcE73K4zfv/IlMBV
7npzaWqF4mSnBY5Z5JskM349fiehIKhmTHiBkX0K1r8RNIDle+c9uvbCD+94/q0Z
OYh7K0cycO0sjrIu1jrQQmEy4rFcrSWIOVWNMdN0rPrdR1Rd8T3IRkwo4+aO/icd
gL+rOA==
-----END ENCRYPTED PRIVATE KEY-----
When establishing an SSL connection, the WLE processes (client applications and the IIOP Listener/Handler) check the identity of the certificate authority and certificates from the peer's digital certificate chain against a list of trusted certificate authorities to ensure the certificate authority is trusted by the organization. This check is similar to the check done in Web browsers. If the comparison fails, the initiator of the SSL connection refuses to authenticate the target and drops the SSL connection. It is typically the job of the system administrator to define a list of trusted certificate authorities.
Retrieve from the LDAP-enabled directory service the digital certificates for the certificate authorities that are to be trusted. Cut and paste the PEM formatted digital certificates into a file named trust_ca.cer which is stored in $TUXDIR/udataobj/security/certs . The trust_ca.cer can be edited with any text editor.
The trust_ca.cer file should be owned by the administrator account. BEA recommends that the file be protected so that only the owner has read and write privileges for the file and all other users have only read privileges for the file.
Listing 2-2 provides an example of a Trusted Certificate Authority file.
Listing 2-2 Example of Trusted Certificate Authority File
-----BEGIN CERTIFICATE----
-MIIEuzCCBCSgAwIBAgIQKtZuM5AOzS9dZaIATJxIuDANBgkqhkiG9w0BAQQFADCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDAeFw05OTA2MTQwMDAwMDBaFw0wMDA2MTMyMzU5NTlaMIIB
GjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl
bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxzxdq
IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPUGF1bCBCLiBQYXRy
aWNrMSYwJAYJKoZIhvcNAQkBFhdwYXVsLnBhdHJpY2tAYmVhc3lzLmNvbTBcMA0G
CSqGSIb3DQEBAQUAA0sAMEgCQQDAbJhRRy6eDWiCu4kYLpTPYWtnMmleDb20aqGE
CBdCbyWpkEgl63LFy+LkVdEqfS60zQBFhK4O5f50sT5U7mThAgMBAAGjggGPMIIB
izAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgG
CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUF
BwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglg
hkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJiZDYzZjIwNDcw
MjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAxNzQ3
ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxNmFlNmJmN2Q0MTE0OTlhYTNiMzQ3ZjRm
M2VhNDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBAA0da2gPa4CuEK79rmU62Zwt
+h8f5o3+xerPQd2nVTgE/rinpV1r/9/EgNBvHxnFV6WAnjrfaux1GYKaZfLV/dim
91oyKj/DxVi+t9d1SRbCxE7Ubv0ctGxKJQl7d6ybN0xuIrDNAuuhu2rr6P3ALR79
2Ci6rHHC0HlJGqEFNs95
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE----
-MIIEuzCCBCSgAwIBAgIQKtZuM5AOzS9dZaIATJxIuDANBgkqhkiG9w0BAQQFADCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDAeFw05OTA2MTQwMDAwMDBaFw0wMDA2MTMyMzU5NTlaMIIB
GjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl
cnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx
IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPUGF1bCBCLiBQYXRy
aWNrMSYwJAYJKoZIhvcNAQkBFhdwYXVsLnBhdHJpY2tAYmVhc3lzLmNvbTBcMA0G
CSqGSIb3DQEBAQUAA0sAMEgCQQDAbJhRRy6eDWiCu4kYLpTPYWtnMmleDb20aqGE
CBdCbyWpkEgl63LFy+LkVdEqfS60zQBFhK4O5f50sT5U7mThAgMBAAGjggGPMIIB
izAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgG
CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUF
BwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j
b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglg
hkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJiZDYzZjIwNDcw
MjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAxNzQ
ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxNmFlNmJmN2Q0MTE0OTlhYTNiMzQ3Rm
M2VhNDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBAA0da2gPa4CuEK79rmU62Zwt
+h8f5o3+xerPQd2nVTgE/rinpV1r/9/EgNBvHxnFV6WAnjrfaux1GYKaZfLV/dim
91oyKj/DxVi+t9d1SRbCxE7Ubv0ctGxKJQl7d6ybN0xuIrDNAuuhu2rr6P3ALR79
2Ci6rHHC0HlJGqEFNs95
-----END CERTIFICATE-----
When communicating across network links, it is important to validate the peer to which you are connected is the intended or authorized peer. Without this check, it is possible to make a secure connection, exchange secure messages, and receive a valid chain of digital certificates but still be vulnerable to a man-in-the-middle attach. You perform peer validation by verifying a set of specified information contained in the peer digital certificate against a list of information that specifies the rules for validating peer trust. The system administrator maintains the Peer Rules file.
The peer rules are maintained in an ASCII file named peer_val.rul . Store the peer_val.rul file in the following location in the WLE directory structure:
$TUXDIR/udataobj/security/certs
Listing 2-3 provides an example of a Peer Rules file.
Listing 2-3 Example of Peer Rules File
#
# This file contains the list of rules for validating if
# a peer is authorized as the target of a secure connection
#
O=Ace Industry
O="BEA Systems, Inc."; OU=Enteprise Engineering;L=Nashua;S=NH
O="Netscape Communications, Corp.", C=US
o=Ace Industry, ou=QA, cn=www.ace.com
Each rule in the Peer Rules file is comprised of a set of elements that are identified by a key. The WLE product recognizes the key names listed in Table 2-1.
Key |
Attribute |
|---|---|
Each key is followed by an optional white space, the character =
, an optional white space, and finally the value to be compared. The key is not case sensitive. A rule is not a match unless the subject's distinguished name contains each of the specified elements in the rule and the values of those elements match the values specified in the rule, including case and punctuation.
Each line in the Peer Rules file contains a single rule that is used to determine if a secure connection is to be established. Rules cannot span lines; the entire rule must appear on a single line. Each element in the rule can be separated by either a comma (,
) or semi-colon (;
) character.
Lines beginning with the pound character (#
) are comments. Comments cannot appear on the same line as the name of an organization.
A value must be enclosed in single quotation marks if one of the following cases is true:
, + = "" <CR> < > # ;
By default, the WLE product verifies peer information against the Peer Rules file. If you do not want to perform this check, create an empty Peer Rules file.
|
|
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|