|
|
When the Web NMS is started, the startup parameters specified in the NmsProcessesBE.conf present in <Web NMS Home>/conf directory are read and the processes are started. Each process consists of two parts:
PROCESS - the fully qualified class name of the process
ARGS - the arguments needed for starting the process.
This document concentrates on explaining the purpose of the authorization processes defined in the conf file along with the description of the command line arguments supplied for starting the process.
BE Processes
FE Processes
com.adventnet.nms.security.authorization.NmsAuthManager
Functionality
Provides Security Management authorization service for the authenticated users of Web NMS by binding the APIs in registry.
Invokes the NMS AuthorizationEngine and AuthorizationAdmin implementation classes in order to provide fine grained access control to the NMS users.
The time for the security scheduler can be set by which the scheduler will check the user status for the specified time interval.
Allows to plugging user defined authorization policy in to NMS by specifying the implementation class names of AuthorizationEngine and AuthorizationAdmin as first and second argument respectively.
Facilitates in persisting security administration related data only in database and not in securitydbData.xml present in <Web NMS Home>/conf directory based on requirement.
Facilitates in updating the securitydbData.xml file with the latest data from the database when the data is saved only in database.
Provides authorization support for all security operations configuration in Security Administration UI.
Declaration
java com.adventnet.nms.security.authorization.NmsAuthManager
[ AuthorizationEngineImpl ]
[ AuthorizationAdminImpl ]
[ time_interval_for_security_scheduler_in_ms ]
[ change_password_for_firsttime_login ]
[ persist_data_in_XML ]
[ update_XML_during_shutdown ]
[ authorization_for_security_administration ]
PROCESS com.adventnet.nms.security.authorization.NmsAuthManager
ARGS AuthorizationEngineImpl NULL AuthorizationAdminImpl NULL time_interval_for_security_scheduler_in_ms 0 change_password_for_firsttime_login false persist_data_in_XML true update_XML_during_shutdown false authorization_for_security_administration false AuthAuditAPIImpl NULL
Arguments and Description
| Arguments |
Description |
|---|---|
|
AuthorizationEngineImpl |
Name of the user defined AuthorizationEngine implementation class name. To define a new AuthorizationEngine implementation class one has to implement the AuthorizationEngine API and CommonModuleAPI and make it pluggable by specifying the implementation class name.
Default Value : NULL
This value invokes the NMS AuthorizationEngineImpl class. |
|
AuthorizationAdminImpl |
Name of the user defined AuthorizationAdmin implementation class name. To define a new AuthorizationAdmin implementation class, one has to implement the AuthorizationAdmin API and CommonModuleAPI and make his Authorization policy pluggable by specifying the implementation class name.
Default Value : NULL
This value invokes the NMS AuthorizationAdmin implementation. |
|
TimeIntervalForSecurityScheduler |
The time interval in milli seconds for the security scheduler to check the user status periodically in order to reflect the exact user status and notify the user during his login.
Default value : 0
Scheduler will not be started and the user expiration check will not be done. |
|
ChangePasswordForFirstTimeLogin |
To set the change password option during the first time login of the user into NMS.
Default value : false
The user will not be posed with the option to change his password when he first logs into Web NMS. |
|
persist_data_in_XML |
While performing security-related operations, say a new user or group is added through security client or using API, this information is added to the database and the same is updated in the securitydbData.xml file present in <Web NMS Home>/conf directory.
This argument is provided to persist the security data only to the database and not to the securitydbData.xml file.
Default value : true
When set to 'true', the security administration related data is persisted in both securitydbData.xml as well as the database. When a cold start or warm start of NMS is done, the security data is read from securitydbData.xml file and then the same is updated to the database.
When set to 'false', the security administration related data is persisted only to the database and not the securitydbData.xml file. With this configuration, during cold start, the security data is read from securitydbData.xml and populated the database as usual. After this, for all security-related operations, data is stored only in database. But during a warm start, the data is read from the database and not from the securitydbData.xml file.
This argument helps you in retaining the securitydbData.xml file in its original form when NMS was started. It also provides better performance of the security module as the number of queries involved in the securitydbData.xml file updation is reduced. |
|
update_XML_during_shutdown |
If the persist_data_in_XML argument is set to 'false', the securitydbData.xml file is no more in sync with the database as the security data is populated only to the database. In order to update the securitydbData.xml file with that of the security information in the database, this argument can be used.
Default value : false
When set to 'true', during shutdown process, the securitydbData.xml file is updated with the latest information as available in the database. You can also use the updateXML() method in AuthorizationAdmin API to update the securitydbData.xml file as when required. |
|
authorization_for_security_administration |
This argument can be used to restrict or enable the privilege of a user to configure security related information using the Security Administration UI in the client.
Default value : false
When set to 'true', only authorized users will be able to perform security-related configurations in the Security Administration UI. For more information, refer Authorization for Security Operations.
When set to 'false' the users, although not authorized to perform certain security-related configurations will be able to perform them. |
Dependencies
Argument Dependencies
If the I & II arguments are NULL, then the user has to specify the III argument to enable the scheduler for user account management and if this is not specified then the scheduler will not be started. If the first two arguments are not NULL, then the user has to specify the argument depending upon his implementation class.
com.adventnet.nms.authentication.UserConfigProcess
Functionality
Binds UserConfigAPI in RMI registry.
Invokes the NMS UserConfAPI implementation by which the administrator can create new user accounts, assign operations to users, change user profile and even delete users through Security Administration wizard.
Declaration
java com.adventnet.nms.authentication.UserConfigProcess
Arguments - Null
Dependencies
Process Dependencies
com.adventnet.nms.security.authorization.NmsAuthManager
Mandatory Process Dependencies
The mandatory processes dependent on com.adventnet.nms.authentication.UserConfigProcess module are given under the Module Services topic, which are to be enabled.
com.adventnet.nms.fe.authorization.AuthorizationManagerFE
Functionality
Binds the AuthorizationEngine and AuthorizationAdmin API in the registry by which the NMS client is authorized to perform his own allotted operations.
Declaration
java com.adventnet.nms.fe.security.authorization.AuthorizationManagerFE
Arguments - Null.
com.adventnet.nms.fe.authentication.UserConfigProcessFE
Functionality
Binds UserConfigAPI in the registry.
Establishes a client session by registering with common socket. Thus, whenever a new request for connection comes, a new session is set and enables the logged in user to access the services of NMS.
Declaration
java com.adventnet.nms.fe.authentication.UserConfigProcessFE
Arguments - Null.
Dependencies
Process Dependencies
com.adventnet.nms.fe.security.authorization.AuthorizationManagerFE
|
|