Management of Network Gatekeeper is performed by administrative users. There are a set of management users, identified by their user type. Each management user is also assigned a user level.
Below is an overview of the operations for managing management users.
Network Gatekeeper classifies its users as either Traffic users or Management users.
Traffic users are users (Application Instances) who use the application-facing interfaces to send traffic.
Management users are users who have access to and can perform management and administration functions.
Traffic users cannot login to the management console or perform any management operations.
During installation, the following default groups are created in WebLogic Server Embedded LDAP server
Table 4-1 User groups
Group Name
Membership
Role
TrafficUser
All Application Instances belong to this group
They should be able to just send traffic and should not have access to management functions.
They should not have access to WebLogic Server or Network Gatekeeper MBeans.
They should not be able to log into the console and perform WebLogic Server administration operations.
TrafficUser
OamUser
Management users who are of OAM type:
They have access to the console based on their level.
They should not be able to send traffic.
OamUser
PrmUser
Management users who are of type PRM:
They should not have access to the console.
They should perform their management operations using the PRM interfaces
PrmUser
When an Application Instance sends a SOAP request to the application-facing interfaces, it is authenticated by the WLNG Application Authenticator; and upon successful authentication it adds WLNGTrafficUsers group to the user principals, in addition to the service provider ID, application ID, service provider group ID, and application group ID.
When management users login successfully, they are added to the oamUser group.
Each group contains a user or set of users and is associated with a Security Role. Groups are generally static; they do not change at runtime.
A basic role condition can include users or user groups in a particular security role. For example: set Admin Role to all users in Administrators group.
Roles are evaluated at runtime by the Role Mapping Provider by checking the authenticated subject.
A policy contains one or more conditions. For example a simple policy can be: Allow access if the user belongs to Admin Role.
User Types
Below are the pre-defined management user types:
Administrative users use the Administration Console or JMX to interact with Network Gatekeeper.
PRM operator users use the PRM Operator Web Services interfaces to interact with Network Gatekeeper.
PRM service provider users use the PRM Service Provider Web Services interfaces to interact with Network Gatekeeper.
When creating a management user, the user is mapped to the Weblogic Server authentication provider WLNG OAM Authenticator.
User Level
User level
Access on Network Gatekeeper
Access on WebLogic Server
1000
Administration access to management functions.
Administration access:
View, modify and administer server configuration
Deploy applications
Start, resume and stop servers
666
Read-write access on management functions.
Deployer access:
View the server configuration, including some encrypted attributes related to deployment activities.
Change startup and shutdown classes, Web applications, JDBC data pool connections, EJB, Java EE Connector, Web Service. If applicable, edit deployment descriptors.
Access deployment operations in the Java EE Deployment Implementation (JSR-88).
333
Read-only access on management functions.
Monitor access:
View the server configuration
Have read-only access to Administration Console, WLST and other MBean APIs
0
No access to management functions.
Assigned to PRM Service Provider users internally.
Anonymous access:
No access to console
Management users are assigned different user levels based on which JMX resources they will be able to access. At a more granular level, an administrator may want to give access to only a subset of management interfaces. This can be achieved by applying XACML policies.
Below is an outline of how to apply these policies, in order to add more granular access control:
ManagementUsers
