You can use the authorization provider that the WSRP Producer includes to protect particular portlets according to the J2EE security configuration of the respective web applications. This way, the same authorization constraints are enforced on the provided portlets as for accessing a servlet directly in the web container. This mechanism uses the security context that is established by one of the concepts to secure your Producer as described in the previous sections.
If you deploy the authorization provider, the Producer checks permissions for all WSRP operations that are related to individual portlets. Therefore, for an authenticated user to work with a portlet that is protected by J2EE security on the Producer, the user must have the necessary permissions.
Application Server Full Profile, the authorization provider is provided as a plug-in. On WebSphere
Application Server Liberty Profile, the authorization provider is provided as a Liberty feature.
- If you do not deploy the authorization provider, the WSRP Producer provides a warning that the default provider did not initialize successfully. In this case, the WSRP Producer treats all WSRP requests as unauthorized requests, unless one of the following conditions apply:
- Application security is disabled and the application server is restarted.
- WSRP security is disabled by setting the property wsrp.security.disabled in the environment entries for the WSRP Producer web application to true. This property defaults to false, so that security is enabled by default.
- If application security or WSRP security is disabled, security is not provided for your portlets. Specifically, there is no access control for your portlets.
- If a portlet application does not define any security constraints, the authorization provider gives users access to the portlets in all cases. Therefore, if you enable application security, verify the security constraints of provided portlets carefully.
The following table gives an overview of the security control that is provided by the authorization provider, depending on the combination of the authorization provider deployment and the configuration settings.
Table 1. Configuring the authorization provider
Parent topic: Securing the WSRP Producer
|Configuration option settings that are required for the type of security control||Security control that is provided by the authorization provider|
|Application security||Setting for the property for disabling WSRP security||Authorization provider is deployed.|
|Enabled||false||Yes||Access control checks are based on the J2EE security constraints. |
Note: To benefit from the authorization provider, use this option.
|Enabled||false||No||All requests are blocked with access denied.|
Note: If the authorization provider is not deployed, this value is the default.
|Enabled or disabled||true||Yes or no||The authorization provider does not check access permissions.|
|Disabled||true or false||Yes or no||Access control is not checked.|
Using the authorization provider on WebSphere Application Server Full Profile
To use the default authorization provider, you need to deploy the WebSphere
Application Server plug-in com.ibm.wps.wsrp.securityprovider.defaultimpl_2.0.0.jar
to the directory was_root/plugins
and restart the application server.
- In a clustered environment, copy the JAR file to all nodes.
- The plug-in requires that single sign-on is activated in the application server security settings.
Using the authorization provider on WebSphere Application Server Liberty Profile
The authorization provider is provided as a Liberty feature. To install the authorization provider feature, use the feature manager featureManager install com.ibm.wps.wsrp.securityprovider.defaultimpl.esa
and restart the application server. Then, enable the authorization provider feature in the file server.xml
, for example as follows:
Example: Protecting a portlet with J2EE security by using the authorization provider
The following example shows how you can protect a particular portlet by J2EE security constraints, and what the possibilities for consuming this portlet are. The example defines a web application WSRPAuthzExample
that contains one portlet WSRPAuthzPortlet
. In the web.xml
, you must define a security constraint that includes an auth-constraint
element that references roles. In this example, the security-roles are also defined in the web.xml
Additionally, you must define security-role-ref
elements in the portlet descriptor (portlet.xml
<description>Example for J2EE security constraints</description>
With this configuration, access to the WSRPAuthzPortlet
is restricted to all users that are assigned one of the roles Employee
. You can define those mappings for the respective application on users and groups in the application server. By default, no user or group is mapped to the roles, and access to the portlet is restricted. You can define role mappings for the individual users or implicitly by groups.