Borland VisiBroker® 7.0 - Borland Technical Publications
Borland VisiBroker® 7.0 - Borland Technical Publications Borland VisiBroker® 7.0 - Borland Technical Publications
Certificate authenticationCertificate authenticationJavaC++Closely associated with authentication is the concept of trust. For practical purposes,trust operates just like authentication. Trust can be applied at the transport level if acertificate identity is presented, or at even higher levels (at the CSIv2 layer) where theidentity takes the form of a username/password.For trusting certificates with Java code, VisiSecure provides mechanisms to supportuser-provided JSSE X509TrustManager that indicates whether a given certificate chain istrusted. You can also specify a Java keystore where certificate entries are trustedusing standard Java properties.For VisiBroker for C++ users, the a set of APIs that allow trustpoints (trustedcertificates) to be configured is provided as well. For more information, see Chapter 11,“VisiSecure for C++ APIs.”Certificate Revocation List (CRL) and revoked certificate serialnumbersC++ OnlyNoteWhen signed public key certificates are created by a Certificate Authority (CA), eachcertificate has an expiration date that indicates when it is no longer valid. However, inorder to address the case where a certificate becomes invalid for some reason beforethe date of expiration, the Certificate Revocation List (CRL) feature is provided forVisiSecure for C++. For more information about Certificate Authorities (CA)s, see the“Certificates and Certificate Authority” on page 14.Using the VisiSecure for C++ Certificate Revocation List (CRL) feature, you can set upCRLs and check peer certificates against this list during SSL handshakecommunication.The CRL files must be in DER format and are stored in a directory. To input a CRL intoVisiSecure for C++, you need to set the vbroker.security.CRLRepository property to thedirectory where the CRL files reside. For more information on VisiSecure for C++properties, see Chapter 10, “Security Properties for C++.”There can be more than one CRL file within the CRL Repository directory structure.Once the CRLs are loaded, VisiSecure examines all certificates sent by a peer duringSSL handshake. If any of the peer certificates appears in the CRLs, an exception willbe thrown and the connection will be refused.Negotiating Quality of Protection (QoP) parametersNoteWhen clients and servers communicate, they both need to agree on some parametersfor the Quality of Protection (QoP) that will be provided. The resource host (the server)will:■■publish all the QoP parameters that it can support, andimpose a set of required QoP parameters on the clients.By definition, a required QoP is also a supported QoP.For example, a server may support and require secure transport (SSL) while it maysupport authentication but not require it. This is useful, for example, in the case wheresome resources are not sensitive and anonymous access is acceptable. For moreinformation about QoP and QoS parameters:C++ See “QoP API” on page 113.JavaSee com.borland.security.csiv2 and Chapter 9, “Security Properties for Java.”16 VisiBroker Security Guide
Secure TransportationSecure TransportationVisiSecure functions in two transport environments:■using IIOP over plain sockets■using secure sockets (SSL)In intranet scenarios, it may be safe to transfer information (including sensitive data,such as user authentication credentials) using IIOP over plain sockets. However, whenthe network environment is not trusted (such as the Internet, or even an intranet), youneed to guarantee integrity (the message was not modified or tampered with duringtransmission) and confidentiality (the message cannot be read by anybody even if theyintercepted it during transmission) of messages being transmitted over the network.This is achieved by using secure sockets (SSL).JSSE and SSL pluggabilityJavaVisiSecure uses Java Secure Sockets Extension (JSSE) to perform SSLcommunication. VisiSecure SPI Secure Socket Provider class provides access to theunderline SSL implementation. Any appropriate implementation following Java SecureSocket Extension (JSSE) framework can be easily plugged in independent of otherprovider mechanisms. The only necessary step is mapping the interfaces (or, inanother word, callback methods) defined to the corresponding JSSE implementation.For more information on the SPI Secure Socket Provider class, see VisiSecure SPI forJava and Chapter 12, “Security SPI for C++.”For the “out-of-box” installation of VisiBroker, the JSSE implementation provided byJava SDK is used.Setting the level of encryptionNoteThe SSL product uses a number of encryption mechanisms. These mechanisms areindustry-standard combinations of authentication, privacy, and message integrityalgorithms. This combination of characteristics is referred to as a cipher suite.The client and server have a static list of supported cipher suites. This list is usedduring the handshake phase of the connection to determine which cipher suite will beused. The client sends a list of all cipher suites it knows to the server. The server thentakes this information and determines which cipher suites both the server and clientunderstand. By default, the server selects the strongest available cipher suite.While this cipher suite order ensures strong security, you may want to adopt a differentcipher suite order based on application-specific security requirements. When you wantto change the order of the cipher suites, use the Quality of Protection (QoP) APIfunction calls; you can retrieve a list of the currently available cipher suites, then set thelist to a new order so weaker cipher suites are used before stronger cipher suites.You cannot add new cipher suites. You can modify only the order of the cipher suitesthat are available and remove cipher suites you do not want to use.Supported cipher suitesA cipher suite is a set of valid encoding algorithms used to encrypt data. Cipher suiteshave different security levels and can serve different purposes. For example, someciphers provide for authentication while others do not; some provide for encryption andothers do not. Segments of the name of the cipher indicate what the cipher suite doesor does not provide.Chapter 2: Getting Started with Security 17
- Page 1 and 2: Security GuideBorlandVisiBroker ®
- Page 3 and 4: ContentsChapter 1Introduction to Bo
- Page 5 and 6: Security for the Borland web contai
- Page 7 and 8: Chapter1Introduction to Borland Vis
- Page 9 and 10: VisiBroker DocumentationImportant
- Page 11 and 12: Contacting Borland support■■■
- Page 13 and 14: Chapter2Getting Started with Securi
- Page 15 and 16: Basic security model■■■■Web
- Page 17 and 18: Distributed environments and VisiSe
- Page 19 and 20: Authentication and IdentificationAu
- Page 21: Authentication and IdentificationDi
- Page 25 and 26: Context PropagationContext Propagat
- Page 27 and 28: Context PropagationTrusting Asserti
- Page 29 and 30: Using IIOP/HTTPSHere are several ex
- Page 31 and 32: ChapterChapter 3AuthenticationJAAS
- Page 33 and 34: Authentication mechanisms and Login
- Page 35 and 36: LoginContext class and LoginModule
- Page 37 and 38: Associating a LoginModule with a re
- Page 39 and 40: Borland LoginModulesThe elements in
- Page 41 and 42: Borland LoginModulesLDAP LoginModul
- Page 43 and 44: Server and Client IdentificationIn
- Page 45 and 46: Server and Client IdentificationCre
- Page 47 and 48: Server and Client IdentificationCli
- Page 49 and 50: ChapterChapter4AuthorizationAuthori
- Page 51 and 52: Defining access control with Role D
- Page 53 and 54: Authorization domainsTo accomplish
- Page 55 and 56: CORBA authorizationwhere is a taut
- Page 57 and 58: Chapter5Configuring Security Profil
- Page 59 and 60: Security ProfilesEnabling SecurityF
- Page 61 and 62: Security ProfilesConfiguring Authen
- Page 63 and 64: Security ProfilesTo access the Auth
- Page 65 and 66: Security ProfilesWorking with Autho
- Page 67 and 68: Security ProfilesAdding and Removin
- Page 69 and 70: Associating a Profile with a Domain
- Page 71 and 72: Chapter6Making Secure Connections (
Certificate authenticationCertificate authenticationJavaC++Closely associated with authentication is the concept of trust. For practical purposes,trust operates just like authentication. Trust can be applied at the transport level if acertificate identity is presented, or at even higher levels (at the CSIv2 layer) where theidentity takes the form of a username/password.For trusting certificates with Java code, VisiSecure provides mechanisms to supportuser-provided JSSE X509TrustManager that indicates whether a given certificate chain istrusted. You can also specify a Java keystore where certificate entries are trustedusing standard Java properties.For VisiBroker for C++ users, the a set of APIs that allow trustpoints (trustedcertificates) to be configured is provided as well. For more information, see Chapter 11,“VisiSecure for C++ APIs.”Certificate Revocation List (CRL) and revoked certificate serialnumbersC++ OnlyNoteWhen signed public key certificates are created by a Certificate Authority (CA), eachcertificate has an expiration date that indicates when it is no longer valid. However, inorder to address the case where a certificate becomes invalid for some reason beforethe date of expiration, the Certificate Revocation List (CRL) feature is provided forVisiSecure for C++. For more information about Certificate Authorities (CA)s, see the“Certificates and Certificate Authority” on page 14.Using the VisiSecure for C++ Certificate Revocation List (CRL) feature, you can set upCRLs and check peer certificates against this list during SSL handshakecommunication.The CRL files must be in DER format and are stored in a directory. To input a CRL intoVisiSecure for C++, you need to set the vbroker.security.CRLRepository property to thedirectory where the CRL files reside. For more information on VisiSecure for C++properties, see Chapter 10, “Security Properties for C++.”There can be more than one CRL file within the CRL Repository directory structure.Once the CRLs are loaded, VisiSecure examines all certificates sent by a peer duringSSL handshake. If any of the peer certificates appears in the CRLs, an exception willbe thrown and the connection will be refused.Negotiating Quality of Protection (QoP) parametersNoteWhen clients and servers communicate, they both need to agree on some parametersfor the Quality of Protection (QoP) that will be provided. The resource host (the server)will:■■publish all the QoP parameters that it can support, andimpose a set of required QoP parameters on the clients.By definition, a required QoP is also a supported QoP.For example, a server may support and require secure transport (SSL) while it maysupport authentication but not require it. This is useful, for example, in the case wheresome resources are not sensitive and anonymous access is acceptable. For moreinformation about QoP and QoS parameters:C++ See “QoP API” on page 113.JavaSee com.borland.security.csiv2 and Chapter 9, “Security Properties for Java.”16 VisiBroker Security Guide