Borland VisiBroker® 7.0 - Borland Technical Publications

Server and Client IdentificationCertificate mechanismThe Certificate mechanism is a mechanism that is used for identification usingcertificates. This mechanism is different from GSSUP; certificates are used instead ofusername/password, and these identities are used at the SSL layer and not at thehigher CSIv2 over IIOP layer.You can put certificates into VisiSecure using certificate login or wallet APIs. Whenusing wallet APIs, you need to specify the usage through the constant definitions in thevbsec.h file, class vbsec::WalletFactory. For more information, see “classvbsec::WalletFactory” on page 101.NoteUsing certificate login, you need to specify the target realm using the following format:Certificate#If you do not specify the usage, the default is ALL.The following describes the available targets defined for the certificate loginmechanism.Table 3.1TargetCertificate#CLIENTCertificate#SERVERCertificate#ALLTargets Defined for the Certificate Login MechanismDescriptionIdentifies this process in a client role. When a user establishes anidentity for this target, the certificate identity established will be usedwhen this process acts as a client. In other words, this certificate willidentify this process when it establishes outgoing SSL connections.Identifies this process in a server role. When a user establishes anidentity for this target, this process will use the certificate identityestablished to identify itself when it is accepting SSL connections.Identifies this process in all roles. This identity is used in both of theabove roles.NoteA process can have either a client and server identity that are different or an identitythat is used in all roles, but not both. In other words, you cannot establish an identity inthe Certificate#CLIENT and the Certificate#ALL targets simultaneously.For backward compatibility, wallet properties and SSL APIs are supported; certificateidentities established this way are only treated as Certificate#ALL.Using a VaultWhen running clients, the security subsystem has the opportunity to interact with usersto acquire credentials for authentication. This is done using a callback handler asdefined by JAAS. However, when running servers (your Visibroker server or aPartition), it is not desirable or even possible to have user interaction at start up time. Atypical example of this if the server is started as a service at the startup time of a hostor from a automated script of some sort.The vault was designed to provide the identity information to the security subsystem insuch environments. Note that the vault itself is not directly tied to the securitysubsystem. It is merely a tool to replace the user interaction. In other words, a vaultdoes not contain authenticated credentials. The security service will perform allappropriate authentication, but will receive information from the vault rather than byinteracting with a callback handler. Due to the fact that no user interaction is required,the data in the vault, while sufficiently secure, does contain sensitive information (theusernames and passwords). Hence the vault file that is used for authentication of suchservers must be protected using host security mechanisms (file permissions forexample) or other equivalent approaches.38 VisiBroker Security Guide