Borland VisiBroker® 7.0 - Borland Technical Publications
Borland VisiBroker® 7.0 - Borland Technical Publications Borland VisiBroker® 7.0 - Borland Technical Publications
Steps to secure clients and serversSteps to secure clients and serversNoteImportantListed below are the common steps required for developing a secure client or secureserver. For CORBA users the properties are all stored in files that are located throughconfig files. Where ever appropriate the usage models for clients and servers areseparately discussed. All properties can be set in the VisiBroker Management Consoleby right-clicking the node of interest in the Navigation Pane and selecting “EditProperties.”These steps are similar for both Java and C++ applications.All security information, including RoleDBs, LoginModule configurations, and such canbe set through the Management Console on the appropriate properties tabs.Step One: Providing an identityClientsServersAn identity can be a username/password/realm triad, or certificates can be used.These can be collected through JAAS modules or through APIs.For clients using usernames and passwords, there can be constraints about what theclient knows about the server's realms. Clients may have intimate knowledge of theserver's supported realms or none at all at the time of identity inquiry. Note also thatclients authenticate at the server end.For servers using username and password identities, authentication is performedlocally since the realms are always known.There can be constraints on certificate identities as well, depending on whether theyare stored in a KeyStore or whether they are specified through APIs.Keeping these constraints in mind, the Borland VisiBroker Server supports thefollowing usage models, any of which could be used to provide an identity to the serveror client:■“Username/password authentication, using JAAS modules, for known realms” onpage 66■“Username/password authentication, using APIs” on page 67■“Certificate-based authentication, using KeyStores through property settings” onpage 67■“Certificate-based authentication, using KeyStores through APIs” on page 67■“Certificate-based authentication, using APIs” on page 67■“pkcs12-based authentication, using KeyStores” on page 67■“pkcs12-based authentication, using APIs” on page 67Username/password authentication, using JAAS modules, for knownrealmsIf the realm to which the client wishes to authenticate is known, the client-side JAASconfiguration would take the following form:vbroker.security.login=truevbroker.security.login.realms=66 VisiBroker Security Guide
Steps to secure clients and serversUsername/password authentication, using APIsThe following code sample demonstrates the use of the login APIs. This case uses awallet. For a full description of the four login modes supported, go to the VisiSecure forJava API and SPI sections.public static void main(String[] args) {//initialize the ORBorg.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);com.borland.security.Context ctx = (com.borland.security.Context)orb.resolve_initial_references("VBSecurityContext");if(ctx != null) {com.borland.securty.IdentityWallet wallet =new com.borland.security.IdentityWallet(,.toCharArray(), );ctx.login(wallet);}}Certificate-based authentication, using KeyStores through propertysettingsBy setting the property vbroker.security.login.realms=Certificate#ALL, the client willbe prompted for keystore location and access information. For valid values, see“Certificate mechanism” on page 38.Certificate-based authentication, using KeyStores through APIsYou can use the same APIs discussed in ““Username/password authentication, usingAPIs” on page 67” to login using certificates through KeyStores. The realm name in theIdentityWallet should be CERTIFICATE#ALL, the username corresponds to an alias name inthe default KeyStore that refers to a Key entry, and the password refers to the PrivateKey password (also the KeyStore password) corresponding to the same Key entry.Certificate-based authentication, using APIsIf you do not want to use KeyStores directly, you can specify certificates and privatekeys using the CertificateWalletAPI. This class also supports the pkcs12 file format.X509Certificate[] certChain = ...list-of-X509-certificates...PrivateKey privKey = private-keycom.borland.security.CertificateWallet wallet =new com.borland.security.CertificateWallet(alias,certChain, privKey, "password".toCharArray());The first argument in the new Certificate wallet is an alias to the entry in the KeyStore,if any. If you are not using keystores, set this argument to null.pkcs12-based authentication, using KeyStoresYou can use the same APIs discussed in “Username/password authentication, usingAPIs” on page 67 to login using pkcs12 KeyStores. The realm name in theIdentityWallet should be CERTIFICATE#ALL, the username corresponds to an alias name inthe default KeyStore that refers to a Key entry, and the password refers to the passwordneeded to unlock the pkcs12 file. The property javax.net.ssl.KeyStore specifies thelocation of the pkcs12 file.pkcs12-based authentication, using APIsSee “Certificate-based authentication, using APIs” on page 67.Chapter 6: Making Secure Connections (Java) 67
- Page 21 and 22: Authentication and IdentificationDi
- Page 23 and 24: Secure TransportationSecure Transpo
- 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: Chapter6Making Secure Connections (
- Page 75 and 76: Examining SSL related informationEx
- Page 77 and 78: Chapter7Making Secure Connections (
- Page 79 and 80: Steps to secure clients and servers
- Page 81 and 82: Creating Custom PluginsLoginModules
- Page 83 and 84: ChapterChapter8Security for the Web
- Page 85 and 86: Security for the Apache web serverC
- Page 87 and 88: Enabling certificate passthrough to
- Page 89 and 90: Security for the Borland web contai
- Page 91 and 92: Three-tier authorization schemeNote
- Page 93 and 94: Chapter9Security Properties for Jav
- Page 95 and 96: Security Properties for JavaPropert
- Page 97 and 98: Chapter10Security Properties for C+
- Page 99 and 100: Security Properties for C++Property
- Page 101 and 102: Chapter11VisiSecure for C++ APIsCha
- Page 103 and 104: General APIUse this to login to the
- Page 105 and 106: General APISets the cipher suites t
- Page 107 and 108: General APIReturnsA set of the publ
- Page 109 and 110: SSL APISSL APIThis section explains
- Page 111 and 112: SSL APIclass CipherSuiteNameThis cl
- Page 113 and 114: SSL APIExceptionsCORBA::BAD_OPERATI
- Page 115 and 116: Certificate APICertificate APIThis
- Page 117 and 118: Certificate APIclass CORBAsec::X509
- Page 119 and 120: QoP APIQoP APIThe following section
- Page 121 and 122: Authorization APIAuthorization APIT
Steps to secure clients and serversSteps to secure clients and serversNoteImportantListed below are the common steps required for developing a secure client or secureserver. For CORBA users the properties are all stored in files that are located throughconfig files. Where ever appropriate the usage models for clients and servers areseparately discussed. All properties can be set in the VisiBroker Management Consoleby right-clicking the node of interest in the Navigation Pane and selecting “EditProperties.”These steps are similar for both Java and C++ applications.All security information, including RoleDBs, LoginModule configurations, and such canbe set through the Management Console on the appropriate properties tabs.Step One: Providing an identityClientsServersAn identity can be a username/password/realm triad, or certificates can be used.These can be collected through JAAS modules or through APIs.For clients using usernames and passwords, there can be constraints about what theclient knows about the server's realms. Clients may have intimate knowledge of theserver's supported realms or none at all at the time of identity inquiry. Note also thatclients authenticate at the server end.For servers using username and password identities, authentication is performedlocally since the realms are always known.There can be constraints on certificate identities as well, depending on whether theyare stored in a KeyStore or whether they are specified through APIs.Keeping these constraints in mind, the <strong>Borland</strong> VisiBroker Server supports thefollowing usage models, any of which could be used to provide an identity to the serveror client:■“Username/password authentication, using JAAS modules, for known realms” onpage 66■“Username/password authentication, using APIs” on page 67■“Certificate-based authentication, using KeyStores through property settings” onpage 67■“Certificate-based authentication, using KeyStores through APIs” on page 67■“Certificate-based authentication, using APIs” on page 67■“pkcs12-based authentication, using KeyStores” on page 67■“pkcs12-based authentication, using APIs” on page 67Username/password authentication, using JAAS modules, for knownrealmsIf the realm to which the client wishes to authenticate is known, the client-side JAASconfiguration would take the following form:vbroker.security.login=truevbroker.security.login.realms=66 VisiBroker Security Guide