You are able to create and manage roles in WSO2 SOA Enablement Server for Java. Management of roles is available through role-oriented methods in the updateable policy. Each role must have a unique name and can contain any Java permission (except the org.systinet.security.perm.WASPRole permission) that is used to assign a role to a principal.

If you ask for principal permissions using the UpdateablePolicy.getPrincipalPermissions(..) method, you can choose if the returned principal collection should also contain all permissions contained in the roles assigned to the principal. A subject-based principal collection query result (UpdateablePolicy.getPermissions(Subject, CodeSource)) always returns a union of its principal permissions. Principal permission is a collection of permissions assigned, together with permissions inherited from assigned roles.

The WaspSecurity and UpdateablePolicy API can accept any Java security permission. Also, WSO2 SOA Enablement Server permission implications conform to Java ones; for example, the java.security AllPermission class applies to all permissions. The org.systinet.security.perm contains all the permissions that are specific to WSO2 SOA Enablement Server.

WSO2 SOA Enablement Server Permissions are also implemented to reflect the real state given by a permission of the same type, as in java.io FilePermission. Thus, you can check a permission that is not directly expressed in an updateable policy, but which the collection of permissions for the given subject implies. For example, if you ask to check if the subject is granted the org.systinet.security.perm.WSInvokePermission, which permits access to the bank service's credit and status methods, the WSInvokePermission class permission, which grants access to all services, will succeed. Moreover, if you ask with a composite subject containing two principals "John Doe" and "Ali Baba" the access control check will be satisfied if "Ali Baba" is granted access to the credit method and "John Doe" access to the status method.