The Authorization model in WSO2 SOA Enablement Server is built upon JAAS and the Java Security API; it uses standard Java security classes such as:
The functionality of standard Java security is extended to provide better control of http://java.sun.com/security/jaas/apidoc//javax/security/auth/Policy.html, including runtime management and roles.
This model is now able to control access between the outside world and the WSO2 SOA Enablement Server Server. The APIs for authorization are able to control access independent of the type of requester authentication.
Note also that authorization is built upon authentication in both JAAS and WSO2 SOA Enablement Server.
org.systinet.security.policy.UpdateablePolicy
Built upon standard JAAS Policy, an implementation of this API provides a means to specify a Subject-based access control policy. Unlike a JAAS Policy, this policy API also provides methods allowing for the management of roles and the modification of permission assignments (both to roles and users) at runtime.
You can invoke the methods of UpdateablePolicy using a reference to its singleton implementation; this reference can be obtained using the getUpdateablePolicy() method. Not all the methods of the updateable policy must be implemented; only the methods inherited from JAAS Policy and metadata methods (canManageRoles() and isUpdatable()) are required. Other methods allow for the management of roles and grant permissions at runtime. These methods do not affect the authorization model. WSO2 SOA Enablement Server also comes with full implementation of the updateable policy and a tool (see the section Service Endpoint Security Requirements) able to manage a policy file.
WaspSecurity checks the permissions of the invoking client. More specifically, its static checkPermission() method checks if the subject contained in received credentials is granted the desired permission.
WSO2 SOA Enablement Server comes with certain implementations of authorization providers. For more information see the section Authorization Providers.
There is also a built-in authorization component that allows for the control of access to particular methods of deployed Web services. You can turn this authorization component on or off for a specific Web service endpoint using the WSO2 SOA Enablement Server management console (see Security Panel in the Administration Console). This component checks if the invoking client is granted the org.systinet.security.perm.WSInvokePermission that contains the name of the Web service endpoint, and the unique identifier for the Web service method constructed from the associated WSDL operation. The policy works with Principal instances. The principal class that is created by WSO2 SOA Enablement Server is always org.idoox.security.WASPPrincipal. You can manage permissions and roles of a principal using the updateable policy instance.
The most important methods for your Web service rely on the org.idoox.wasp.WaspSecurity class. You can check the permissions of the Web service invoker using the checkPermission() method. Specific authorization details can also be found in:
Access Controller in Installation Notes