VisiSecure for C++ provides interfaces for you to plug in your own security implementations. In order for the ORB to find your implementation, all plugins must use the REGISTER_CLASS macro provided by VisiSecure to register your classes. The name of the class must be specified in full together with its namespace upon registration. Namespace must be specified in a normalized form supported by VisiSecure, using either a '.' or '::' separated-string starting from the outer namespace. For example:Thus MyLoginModule shall be specified as either MyNameSpace.MyLoginModule or MyNameSpace::MyLoginModule.
• LoginModules: You can implement your own login modules by extending vbsec::LoginModule. To use the login module, you need to set it in the authentication configuration file, just like any other login module.
• Callback handlers: You can implement your own callbacks by extending vbsec::CallbackHandler. To use the callback, you need to set it in the authentication configuration file, just like any other callback handler.
• Identity adapters, Mechanism adapters, and Authentication Mechanisms: These interfaces are provided for users to implement their own authentication mechanisms and identity interpretations. IdentityAdaptor is to interpret identities, MechanismAdaptor is a specialized identity adaptor which also changes target information. AuthenticationMechanism is a pluggable service to authenticate users.To use these plug-ins, you need to set the vbroker.security.identity.xxx properties to define the plug-ins and their properties. For example, an identity adapter or mechanism adapter could specify:The properties specified will be passed to the user plug-in during initialization as a string map. The map contains truncated key/value pairs like property1, value1.
• Attribute codec: This allows you to plug in an attribute codec to encode and decode attributes in their own format. VisiSecure for C++ has one build-in codec, the ATS codec.
• Authorization service provider: You can plugin an authorization service for each authorization domain. VisiSecure has its default implementation, which uses the rolemap. Like the other pluggable services, you will need to define the authorization service with properties which are then passed as string maps. For example:
• Trust provider: This allows you to plug in an assertion trust mechanism. Assertion can happen in multi-hop scenarios, or can be explicitly called through assertion API. The server can have rules to determine whether the peer is trusted to make the assertion or not. The default implementation uses property setting to configure trusted peers on the server side. During runtime, the peer must pass authentication and authorization in order to be trusted to make assertions.Each provider instance is created by the VisiSecure using a Java reflection API. After the instance has been constructed, the initialize method, which must be provided by the implementer, is called passing in a map of options specific for the implementation. The options entries are defined by the implementers of the particular provider. Users specify the options in a property file and the VisiSecure parses the property and passes the options to the corresponding provider. The following table shows the properties for plugging in different provider implementations.
• The final column gives the options prefix for the specific module. The ORB parses the property file and passes the corresponding entries to each of the modules in the initial method as the (Map options) parameter. For example, for the ID_ADA1 IdentityAdapter defined in the previous example, all the entries with the vbroker.security.identity.adapters.ID_ADA1 prefix will be passed to the initial method of ID_ADA1 IdentityAdapter.During initialization, if anything goes wrong the initialize method should throw an instance of InitializationException. For certain categories of providers, there can be multiple instances with different implementations co-existing. Each of them is identified by the name within the VisiSecure system, which is passed as the first parameter in the initialize method. While for some categories of providers there can be only one instance existing for the whole ORB (such as in the case of the TrustProvider) in this case the initialize method has only one single parameter, the options map.LoginModule serves as the parent of all login modules. User plugin login modules must extend this class. Login modules are configured in the authentication configuration file and called during the login process. Login modules are responsible for authenticating the given subject and associating relevant Principals and Credentials with the subject. They are also responsible for removing and disposing of such security information during logout.The vbauthn.h file should be included when you use this class.
• true if the login succeeds, false otherwise.true if the logout succeeds, false otherwise.true if the commit succeeds, false otherwise.true if the abort succeeds, false otherwise.CallbackHandler is the mechanism that produces any necessary user callbacks for authentication credentials and other information. Seven types of callbacks are provided. There is a default handler that handles all callbacks in interactive text mode.The vbauthn.h file should be included when you use this class.void handle (Callback::array& callbacks)the array of callbacks to be processed.
• AnonymousAdapter, with the name "anonymous"
• DNAdapter, with the name "DN"
• X509CertificateAdapter (as an implementation of the sub-interface AuthenticationMechanism)
• GSSUPAuthenticationMechanism (as an implementation of the sub-interface AuthenticationMechanism)
• The IdentityAdapter name.
• A set of InitOptions for the specified IdentityAdapter.virtual ::CSI::IdentityToken* exportIdentity(::vbsec::Subject&, ::CSI::IdentityToken&) =0;virtual void importIdentity (::vbsec::Subject&, ::CSI::IdentityToken&) =0;virtual ::vbsec::Privileges* getPrincipal (::vbsec::Subject&anp;) =0;virtual ::vbsec::setPrivileges (::vbsec::Privileges*) =0;virtual void deleteIdentity (::vbsec::Subject&) =0;This method deletes the principals and the credentials associated with the specified target subject.Extending from IdentityAdapter, a MechanismAdapter has the additional capability of changing the target information. This is very useful in the case where the mechanism used in a remote site is not available locally. Therefore, the local identity must be adapted before sending to the remote site.In the out-of-box installation of VisiSecure, there is no class direct implementation of MechanismAdapter, while a few classes implement the sub-interface AuthenticationMechanism, which in turn gives the support of this interface.Returns a string representation of the mechanism OID. For example, the string representation for a GSSUP mechanism would be oid:2.23.130.1.1.1.virtual ::vbsec::Target* getTarget (const std::string& realm, const std::vector<AppConfigurationEntry*>&) =0;
• A list of AppConfigurationEntry objects.virtual ::vbsec::Target* getTarget (const ::CSI::GSS_NT_ExportedName&) =0;In addition to the methods inherited from its super interfaces, AuthenticationMechanism also has the following categories of methods defined.virtual ::vbsec::Subject* acquireCredentials (const std::string& target, ::vbsec::CallbackHandler*) =0;virtual void destroyPrivateCredentials (::vbsec::Subject&) =0;virtual ::vbsec::Target* processInitContext (::vbsec::Subject&, ::CORBA::OctetSeq&) =0;virtual void processFinalContext (::vbsec::Subject&, ::CORBA::OctetSeq&) =0;virtual ::vbsec::Subject* processErrorContext (::vbsec::Subject&, ::CSI::GSSToken&, ::vbsec::CallbackHandler*) =0;The AuthorizationServicesProvider is initialized during the construction of its corresponding Authorization domain. Use the following property to set the implementing class for the AuthorizationServicesProvider:
A SimpleLogger instance used for login in the current system. virtual ::vbsec::PermissionCollection* getPermissions (const ::vbsec::Resource* resource, const ::vbsec::Privileges* callerPrivileges) =0;The Privileges class implements the javax.security.auth.Destroyable interface.true|falseThis method overrides the default toString implementation of java.lang.Object, and returns “Privileges for <subject name>” information.
A SimpleLogger instance used for the current system for the purpose of logging. This method returns the supported AuthorizationElement type.true|falsevirtual CSI::AuthorizationToken* encode (const CSIIOP::ServiceConfigurationList& privilege_authorities, vbsec::Privileges& caller_privileges, vbsec::Privileges& asserter_privileges) =0;This method encodes privileges as AuthorizationElements. This method encodes the privilege attributes of the given caller and the given asserter, if there is one. It will extract the privilege information from the subject and privilege map of the caller and the asserter.Additionally, an implementation of the AttributeCodec (if supports ClientDelegation) may choose to verify whether the asserter is allowed to assert the caller based on the client delegation information presented by this caller.virtual void decode (const ::CSI::AuthorizationToken& encoded_attributes, vbsec::Privileges& caller_privileges, vbsec::Privileges& asserter_privileges) =0;This method decodes authorization elements and populates the corresponding privilege objects. This is the inversion process of the encode method. When a server receives a set of encoded AuthorizationElements, it passes these elements to the AttributeCodec for interpretation. Based on the encoding method, one particular AttributeCodec consumes the attributes it understands. It may update the caller's or asserter's Privileges, or may add RolePermission directly to the subject's public credentials.Permission represents the authorization information to access resources. Every permission has a name, which can be interpreted only by the actual implementation.The vbsecspishared.h file should be included when you use this class.bool implies (const Permission& p) constthe permission p to be evaluated.true if the permission implies an existing permission, false otherwise.bool operator==(const Permission& p) constthe permission p to be evaluated.true if the permissions are equal, false otherwise.PermissionCollection represents a collection of permissions.The vbsecspishared.h file should be included when you use this class.Evaluate if the PermissionCollection implies the given permission.the permission p to be evaluated.virtual bool implies (const Permission& permission) const;This method checks whether the permission object passed in implies this RolePermission object. The check is based on strict equality, as the method only returns true (implies) when ALL the following conditions exist:True|FalseThe key method is isAssertionTrusted, which is called to determine whether the assertion is trusted given the caller subject and asserter's privileges. This method is called (by the underlying implementation) after the corresponding authorization elements transmitted from a client to the server have been consumed.
2 AttributeCodec implements the necessary logic then passes the attributes and imports them to the caller subject on the server-side. It is also necessary to return true for the method supportsClientDelegation defined in the AttributeCodec interface.This type of evaluation of trust, which is based on rules provided by the caller, is referred to as Forward Trust. Backward Trust is when the evaluation of trust is based on the rules of the target. Backward Trust is the default provided with the VisiSecure installation. For more information, see “Trust assertions and plug-ins”.virtual void initialize (::vbsec::InitOptions&, std::map<std::string, std::string>&) =0;This method initializes the TrustProvider. There can be only one instance of the TrustProvider implementation existing for each process.
A SimpleLogger instance used for the current system for the purpose of logging. true|falseInitOptions is a data structure passed to user plug-ins during initialization calls that facilitates the initialization process.The vbsecspishared.h file should be included when you use this class.SimpleLogger is a mechanism to log information of various levels. Currently it supports four different levels: LEVEL_WARNING, LEVEL_NOTICE, LEVEL_INFO, and LEVEL_DEBUG, with increasingly detailed information. There is only one logger in the whole security service.The logging output stream for LEVEL_WARNING.The logging output stream for LEVEL_NOTICE, or a fake stream if the log level is set below LEVEL_NOTICE.The logging output stream for LEVEL_INFO, or a fake stream if the log level is set below LEVEL_INFO.The logging output stream for LEVEL_DEBUG, or a fake stream if the log level is set below LEVEL_DEBUG.