Borland VisiBroker® 7.0 - Borland Technical Publications
Borland VisiBroker® 7.0 - Borland Technical Publications Borland VisiBroker® 7.0 - Borland Technical Publications
AuthorizationThe following table shows the cipher name segments and what these segments mean.Cipher nameRC4 (through RC8)MD5SHAWITHANONNULLEXPORTEXPORT1024DescriptionSymmetric encryption used in the cipherData integrity mechanism.Data is sent clear, but a hash code is used at the receiving end to ensuredata integrity.Data integrity mechanismAuthentication with encryptionUses DLT, an anonymous key exchange algorithmNo encryptionPublic key size is limited.Note: The larger the size of a public/private key, the more secure thatkey is. This option is typically used for international (outside the UnitedStates) users.The maximum key size is limited to 1024 bytes.The list of supported ciphers for VisiSecure for Java, is determined by the JSSEpackage used. As for VisiSecure for C++, the list can be located at csstring.h filebundled with the installation.AuthorizationAuthorization occurs after the user proves who he or she is (Authentication).Authorization is the process of making access control decisions on requestedresources for an authenticated entity based on certain security attributes or privileges.Following Java Security Architecture, VisiBroker adopts the notion of permission inauthorization. In VisiSecure, resource authorization decisions are based onpermissions. Borland uses a proprietary authorization framework based on users androles to accomplish authorization. For example, when a client accesses a CORBA orWeb request enterprise bean method, the application server must verify that the userof the client has the authority to perform such an access. This process is called accesscontrol or authorization.Access Control ListAuthorization is based on the user's identity and an access control list (ACL), which is alist roles. Typically, an access control list specifies a set of roles that can use aparticular resource. It also designates the set of people whose attributes match thoseof particular roles, and thus are allowed to perform those roles.Roles-based access controlVisiSecure uses an access control scheme based on roles. The deployment descriptormaintains a list of roles that are authorized to access each enterprise bean method.VisiSecure uses a role database (a file whose default name is roles.db) to do theassociation between user identities and EJB roles. If a user is associated with at leastone role, the user may access the method. For more information, see Chapter 4,“Authorization.”18 VisiBroker Security Guide
Context PropagationContext PropagationPluggable AuthorizationVisiSecure provides the ability to plug-in an authorization service that can map users toroles. The implementer of the Authorization Service provides the collection ofpermission objects granted access to certain resources. A new class, RolePermission isdefined to represent “role” as permission. The Authorization Services Provider in turnprovides the implementation on the homogeneous collection of RolePermissionscontained for an association between given privileges and a particular resource.The Authorization Service is tightly connected with the concept of Authorizationdomain—each domain has exactly one Authorization Services Providerimplementation. The Authorization domain is the bridge between VisiSecure systemand the authorization service implementation. During the initialization of the ORB itself,the authorization domains defined by the property vbroker.security.authDomains areconstructed, while the Authorization Services Provider implementation is instantiatedduring the construction of the Authorization domain itself.The Authorization Domain defines the set of rules that determine whether a userbelongs to a logical “role” or not.For more information, see Chapter 4, “Authorization.”In addition to ensuring the confidentiality and integrity of transmitted messages, youneed to communicate caller identity and authentication information between clients andservers. This is called delegation. The caller identity also needs to be maintained in thepresence of multiple tiers in an invocation path. This is because a single call to a midtiersystem may result in further calls being invoked on other systems which must beexecuted based on the privileges attributed to the original caller.In a distributed environment, it is common for a mid-tier server to make identityassertions and act on behalf of the caller. The end-tier server must make decision onwhether the assertion is trusted or not. When propagating context, the client transfersthe following information:■■■Authentication token—client's identity and authentication credentials.Identity token—any identity assertion made by this client.Authorization elements—privilege information that a client may push about thecaller and/or itself.Identity assertionsIdentity assertion occurs when several servers with secure components are involved ina client request. At times, it is necessary for a server to act on behalf of its clients—when a client request is passed from one server to another. This is typical in the casewhere a client calls a mid-tier server, and the server further needs to call an end-tierserver to perform a part of the service requested by the client. At such times, the midtierserver typically needs to act on behalf of the client. In other words, it needs to letthe end-tier server know that while it (the mid-tier server) is communicating with theend-tier server, access control decisions must be based on the original caller'sprivileges and not its privileges.Chapter 2: Getting Started with Security 19
- 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 and 22: Authentication and IdentificationDi
- Page 23: Secure TransportationSecure Transpo
- 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 (
- Page 73 and 74: Steps to secure clients and servers
AuthorizationThe following table shows the cipher name segments and what these segments mean.Cipher nameRC4 (through RC8)MD5SHAWITHANONNULLEXPORTEXPORT1024DescriptionSymmetric encryption used in the cipherData integrity mechanism.Data is sent clear, but a hash code is used at the receiving end to ensuredata integrity.Data integrity mechanismAuthentication with encryptionUses DLT, an anonymous key exchange algorithmNo encryptionPublic key size is limited.Note: The larger the size of a public/private key, the more secure thatkey is. This option is typically used for international (outside the UnitedStates) users.The maximum key size is limited to 1024 bytes.The list of supported ciphers for VisiSecure for Java, is determined by the JSSEpackage used. As for VisiSecure for C++, the list can be located at csstring.h filebundled with the installation.AuthorizationAuthorization occurs after the user proves who he or she is (Authentication).Authorization is the process of making access control decisions on requestedresources for an authenticated entity based on certain security attributes or privileges.Following Java Security Architecture, VisiBroker adopts the notion of permission inauthorization. In VisiSecure, resource authorization decisions are based onpermissions. <strong>Borland</strong> uses a proprietary authorization framework based on users androles to accomplish authorization. For example, when a client accesses a CORBA orWeb request enterprise bean method, the application server must verify that the userof the client has the authority to perform such an access. This process is called accesscontrol or authorization.Access Control ListAuthorization is based on the user's identity and an access control list (ACL), which is alist roles. Typically, an access control list specifies a set of roles that can use aparticular resource. It also designates the set of people whose attributes match thoseof particular roles, and thus are allowed to perform those roles.Roles-based access controlVisiSecure uses an access control scheme based on roles. The deployment descriptormaintains a list of roles that are authorized to access each enterprise bean method.VisiSecure uses a role database (a file whose default name is roles.db) to do theassociation between user identities and EJB roles. If a user is associated with at leastone role, the user may access the method. For more information, see Chapter 4,“Authorization.”18 VisiBroker Security Guide
Change language