Understanding Users, Groups, Security Roles and Policies

This section includes the following topics:

Users

Users are entities that can be authenticated. A user can be a person or a software entity, such as a Web Services client. You must give each user a unique identity (name) within a security realm.

Typically, the users that you create fall into two categories:

Groups

To facilitate administering a large number of users, you can organize users into named groups. Then, instead of giving access privileges or role identities to individual users, you give privileges or identities to groups.

Administrative Security Groups

ALSB provides default security groups to facilitate giving users access to administrative functions such as creating proxy services. Each group is in one of the pre-defined ALSB security roles that have been granted administrative privileges.

For more information, see Configuring Administrative Security in the AquaLogic Service Bus Security Guide.

Roles

A security role is an identity that can be granted to a user or group based on conditions in the runtime environment. When you create access control policies, you can grant access to a role, group, or user.

For example, you can create two of your groups, MyCustomersEast and MyCustomersWest. You create a security role named PrivilegedCustomer and create conditions so that the MyCustomersWest group is in the role from 8am to 8pm EST, while the MyCustomersEast group is in the role from 8pm to 8am EST. Then you create an access control policy for a proxy service that gives the PrivilegedCustomer role access to the service. Different users will have access at different times depending on whether they are in the MyCustomersEast and MyCustomersWest group.

Administrative Security Roles

ALSB provides four, pre-defined security roles (plus four pre-defined roles from WebLogic Server) that give administrative privileges. You cannot change the access privileges for the ALSB administrative security roles, but you can change the conditions under which a user or group is in one of the roles.

For more information about these roles and the privileges available for each role, see Configuring Administrative Security in the AquaLogic Service Bus Security Guide.

Access Control Policies

An access control policy specifies conditions under which users, groups, or roles can access a proxy service. For example, you can create a policy that always allows users in the GoldCustomer role to access a proxy service and that allows users in the SilverCustomer role to access the proxy service only after 12pm on weeknights.

For all proxy services, you can create a transport-level policy, which applies a security check when a client attempts to establish a connection with the proxy service. Only requests from users who are listed in the transport-level policy are allowed to proceed.

A message-level access control policy applies a security check when a client attempts to invoke a proxy service with message-level security. You can create a message-level access control policy in the following cases:

Only users who are listed in the message-level policy are allowed to invoke the operation.

Security Configuration Data and Sessions

Users, groups, and roles are persisted in security providers, which are not governed by ALSB sessions. Therefore, you can create or modify this data when you are in or out of a session. Any additions or modifications to this data take effect immediately and are available to all sessions. If you discard a session in which you added or modified the data, the security data is not discarded.

Access control policies are persisted in authorization providers. However, as of ALSB 3.0 there is now a reference to them in the ALSB repository.

Access control policies are managed within an ALSB design session and not outside the session, as was the case in releases prior to 3.0. Because the changes are made within a session, you can commit or discard the changes as with other resources.

Although ACLs can be managed from the ALSB console, you can change policies outside ALSB. However, changing policies outside of ALSB can make the reference in ALSB out-of-date and invalid.

Therefore, for consistent management, either completely manage ACLs outside of ALSB sessions (using the authorization provider MBeans or third-party authorization provider tools) or completely manage them from within ALSB sessions. Any combination of the two approaches can result in an inconsistent view of policies.