• Enterprise Java Beans (EJB) Container Integration: VisiSecure seamlessly integrates EJB security mechanisms with the underlying CORBA Security Service and CSIv2. CORBA offers enhanced features to the security architecture of your bean. By utilizing VisiSecure, you have options additional to the relatively simple EJB security model.
• Web Container Integration: VisiSecure integrates with the web container by providing mechanisms to the web container that allow its own authentication and authorization engines to propagate security information to other EJB containers, as necessary. For example, a servlet trying to invoke an EJB container's bean will act on behalf of the original browser client that triggered the initial request. Security information supplied from the client will be propagated seamlessly to the EJB container. In addition, the web container authentication and authorization engine can be configured to use authentication LoginModules and authorization rolemaps supplied by Micro Focus.
• Security Services Administrator: The administration and configuration of VisiSecure is performed using simple-to-use properties and supports tools like the Java keytool.
• GateKeeper: You can use GateKeeper to enable authenticated connections across a high-level firewall. This allows clients to connect to the server, even if the server and the application client are on opposite sides of a firewall. Use of the GateKeeper is fully documented in the VisiBroker GateKeeper Guide.
• Secure Transport Layer: VisiSecure for Java utilizes standardized Transport Layer Security (TLS) which has evolved from the older SSL standards. Note that Java only supports the TLS versions provided by its underlying security provider (such as JSSE).VisiSecure for C++ offers similar features to VisiSecure for Java. See “VisiSecure for C++ APIs” and “Security Properties for C++” for detailed information.
• Authentication and Authorization: The Authentication and Authorization model are similar to VisiSecure for Java. This extends the capability of VisiSecure for C++ applications.
• Security Services Administrator: The administration and configuration of VisiSecure is performed using simple-to-use properties.
• Secure Transport Layer: VisiSecure for C++ utilizes standardized Transport Layer Security (TLS) which has evolved from the older SSL standards. This release includes support for TLSv1.3, TLSv1.2, TLSv1.1 and TLSv1.0.
• Authentication realm (User domain): simply a database of users. Each authentication realm describes a set of users and their associated credentials and Privileges attributes.
• Resource Domain: represents a collection of resources of a single application. The application developer defines the access control policies for access to resources in the application.
• Authorization Domain: defines the set of rules that determines whether an access attempt to a particular resource is allowed.For example, if you are using LDAP, then the authentication realm specifies LDAP as the authentication protocol, specifies the name of the server, and specifies other configuration parameters. When you log on to a system, the system is authenticating you. For more information on setting up an authentication realm, see “Authentication”.A resource defines an application component that VisiSecure needs to protect. VisiSecure organizes resources into resource domains containing every resource in an application. This means every remote method or endpoint that is exposed by a server is essentially a resource.The application developer defines access control policies for access to resources in the application. These are defined in terms of roles. Roles provide a logical collection of permissions to access a set of resources. For more information, see “Authorization”.The authorization domain allows users to act in given roles. VisiSecure grants privileges to access resources based on these roles. When VisiBroker applications pass user identities from one application to another, the identity contains user information, and the permissions based on the specified roles. The caller's identity is then matched with the required rules to determine whether the caller satisfies the required rules. If the caller satisfies the rules, access is granted. Otherwise, access is denied. For more information, see “Authorization”.