|Read more about this book|
(For more resources on BPEL-Websphere, see here.)
Propagating user identity to a BPEL process
To propagate user identity from the UsernameToken to the BPEL process, we will first have to extract that identity from the UsernameToken. Then, we will propagate it to the BPEL process. We will enable identity extraction and propagation through policy set bindings. Policy set bindings will contain token consumer definition for identity extraction and caller definition for identity propagation.
Extracting user identity from UsernameToken
To enable the extraction of user identity from UsernameToken, we have to define a new policy set binding. We have to set this binding to use a UsernameToken consumer that will be performing the extraction. To achieve this, we have to complete the following steps:
- First, we have to create a new policy set binding. We will go to the Integrated Solutions Console and expand Services | Policy Sets | General provider policy set bindings:
- In the General provider policy set bindings list, we can see provided bindings. Apart from BPC Web Service – Provider, which is used for the Business Process Choreographer web service API, all bindings are only samples. Click on the New… button to create a new binding:
(Move the mouse over the image to enlarge.)
- For the new binding, we need to provide a name, description (optional), and policies that the binding refers to (in our example, WS-Security). For the Bindings configuration name, we will enter WSS UsernameToken to Caller Propagation and Propagate WS-Security UsernameToken authentication information to the runtime environment for Description. Now, expand the Add drop-down menu and select WS-Security to add a WS-Security policy:
- Next, we will define the token consumer for identity extraction. After clicking on the WS-Security, we will select the Authentication and protection link to define the UsernameToken consumer:
- Under Authentication tokens we have:
- Protection tokens, which sign messages to provide integrity or encrypt messages to provide confidentiality
- Authentication tokens, which are used to provide or assert (propagate) the identity
Detailed signing and encryption settings can be defined in the Request message signature and encryption protection and Response message signature and encryption protection sections.
To add a UsernameToken consumer, we will expand the New Token drop-down menu in Authentication tokens and select Token Consumer:
- We created a new token consumer. If we want it to be the UsernameToken consumer, we have to specify its name, select UsernameToken for its type, and select the appropriate application login. Application login is basically a Java class that performs the actual authentication of the user based on his/her credentials provided in the token. So, for the token name, we will enter WSS UsernameToken Consumer and for its type, we will select UsernameToken v1.0. We will use version 1.0, as it is sufficient for our example. UsernameToken profile v1.1 contains some additional extensions that are used for deriving keys from the password for protecting message contents in the sense of integrity or confidentiality.
After we have selected the Token type, the Local part field is automatically filled in for us. If we would have chosen some other authentication token (for example LTPA), Namespace URI would be automatically filled in for us.
We leave JAAS login at the default value (wss.consume.unt), because it is a default Java Authentication and Authorization Service system login for UsernameToken consumers. All described details are shown in the following screenshot:
- Now, we should save changes made in the console to the master configuration, as shown in the following screenshot:
We have created a policy set binding with a UsernameToken consumer that can extract user identity from the token.
Propagating an extracted user identity to a BPEL process
With the UsernameToken consumer we have defined a user identity extraction from the UsernameToken.
Now we have to define a Caller that will propagate the extracted identity to the succeeding components:
- We will return to the WS-Security settings using the breadcrumb navigation and select the Caller link:
- We will click on the New button to create a new Caller. We have to specify its name, identity local part (the URL from the token specification that tells from which type of token the identity should be propagated), and application login (the set of Java classes that takes care of token propagation).
- For the Name enter WSS UsernameToken v1.0 Caller and for the Caller identity local part enter the URL http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken. This is the URL defined in the UsernameToken profile v1.0 to uniquely identify UsernameToken. We will leave JAAS login at default (wss.caller), because it is a default Java Authentication and Authorization Service system login for the UsernameToken caller. Click on OK to finish creating the Caller.
We have successfully defined a policy set binding for propagating the identity from the UsernameToken to the succeeding components. We should now save the changes made through editors to the master configuration.
Assigning a policy set binding to propagate an identity to a provider
All that is left to achieve the propagation of the user identity to the BPEL process is to assign the defined policy set binding to the web service that exports our BPEL process. This procedure is necessary after each (re)deploy of the BPEL process to the server:
- Let us assign the policy set binding to the web service provider that represents the web service export of our BPEL process. In the Integrated Solutions Console, expand Services, and click on Service providers:
- In the Service providers list we can see several providers. We will definitely see two: BFMJAXWSService and HTMJAXWSService. These two providers represent the already mentioned Business Process Choreographer web service APIs, for working with BPEL processes and human tasks respectively.
We will also see our TravelApproval provider. We will click on TravelApprovalWS_TravelApprovalPTHttpService:
- In General Properties, we can see a fully qualified XML name of the service. We can look at the service's WSDL document under Additional Properties. There we can also locate the application and the module of the service. In the Policy Set Attachments table, we can see the attached policies to this service provider. There is already the WSS UsernameToken only policy set attached to the provider. We achieved this through the definition in the assembly diagram earlier in this example.
Now, we have to add the policy set binding that contains Caller to propagate a user identity to the BPEL process.
We will click on the checkbox next to TravelApprovalWS_TravelApprovalPTHttpService. We will expand the Assign Binding drop-down menu and select WSS UsernameToken to Caller Propagation:
- With this, we have attached the policy set binding with the proper Caller defined and enabled the user identity propagation. Our configuration should look like the one shown in the following screenshot:
- We will now save changes made to the master configuration.
So far, we have configured everything necessary for the propagation of the user identity to the BPEL process. For the configuration to start working in the previous steps, we assigned the defined policy set binding to the web service export of our BPEL process.
|Read more about this book|
(For more resources on BPEL-Websphere, see here.)
Testing user identity propagation to BPEL process
Let us rerun the test case in soapUI to create another instance of the BPEL process. Now the process contains the user identity from the UsernameToken. Our BPEL process is now running in the name and ownership of the user that was authenticated at the web service export.
We can check if this is really the case. In the Business Process Choreographer, we will check the details of the created process instance. We will notice that the Starter and Administrators properties contain the identity of the user that called the web service:
Restricting access to a BPEL process
Now our BPEL process knows who has called it. All authenticated users can start a new instance of this process. The next thing that we will do is to restrict the group of users that can call our BPEL process. Only a specific group of users should be able to call our process. We can achieve this through the use of qualifiers.
Setting a security permission qualifier
Qualifiers are means to alter behavior of an SCA component. Our BPEL process is an SCA component, so it is possible to define qualifiers to alter its behavior.
We will add a Security permission qualifier to our process. It will define the role name for the authenticated users. We will map this role to specific users in the deployment descriptor. At the runtime (on the server), it will be possible to add or remove users to/from this role. This way, we will be able to change a set of users that will have access to our process. To achieve this, we need to accomplish the following steps:
- First, we have to define the Security permission qualifier on our BPEL process. To add the Security permission qualifier we have to select the BPEL process in the assembly diagram and bring up its properties. Select Properties | Details and then expand the Interfaces | TravelApprovalPT | Qualifiers tab on the right-hand side of the pane:
There is already a Join transaction qualifier set. A join transaction qualifier tells whether the component will join the propagated transaction (value of true) from its client or not (value of false).
- We will add another qualifier by clicking the Add button. A dialog opens and we select the Security permission qualifier. The Security permission qualifier on a component allows us to specify a role of users that have access to this component.
Other qualifiers that we can set are Data validation (turns on or off data validation in business object towards XSD schema), Join activity session (tells whether a component will join the propagated session from its client or not) and Store and forward (stores messages sent from the component in case of failure, for the administrator to be able to resubmit failed messages after the problem on the target component was fixed).
- Next, we have to specify a role name. A role is a logical group of physical groups of users and users without a group assignment. A role defined through the Security permission qualifier restricts the users that can call the SCA component to this role only (direct assignment or indirect assignment through group membership).
Select the newly created Security permission qualifier. The Properties of Qualifier Security permission view pops up. Enter TravelApprovalCaller as Role:. Save the changes made to the assembly diagram:
We have defined the authorized role for calling our BPEL process. But this role does not contain any users yet. At this time, no user will be able to call our process. We will test if this holds true.
Testing the authorization mechanism
Let us test if really no one can access our BPEL process at this time. We will try calling it with our administrative user (admin). Republish the changes made to the integration module to the server. After republishing is finished, we have to reconfigure a WS-Policy set binding for Caller, because it is lost during application redeployment.
Try calling the web service export of our BPEL process from soapUI. The call does not work anymore, because the admin user is not in the TravelApprovalCaller role. We get the following exception:
Console Exception: Permission denied: User admin is not in
role:TravelApprovalCaller and does not have permission to invoke the
Now we will add the admin user to the TravelApprovalCaller role.
Adding users to an authorized role
We have to map the admin username to the TravelApprovalCaller role. This mapping can be done in the deployment descriptor of our module/application. We will right-click on the SecuringBPEL module and select Open Deployment Editor:
- In Module Deployment Editor for SecuringBPEL, expand Module Deployment Configuration | Application Project. Expand Gather Security Roles and click on the Gather security roles link:
- WebSphere Integration Developer gathers all role definitions from all over the module (for example, from all Security permission qualifiers). After it finishes, it displays a message as shown in the following screenshot:
- Click on OK and then expand Application Project to check that Security Role (TravelApprovalCaller) was added. Now, we will map the admin user to this role with the help of an authorization table. An authorization table contains all groups, users, and special subjects such as All authenticated users (everyone that is authenticated on the server) and Everyone (all authenticated users and the ones that are not).
- Right-click on Application Project and select Add | Authorization Table:
- An authorization table can contain multiple authorizations, each defining groups, users, and special subjects that map to one specific role. We will add one authorization that will provide the mapping for the TravelApprovalCaller role. Right-click on Authorization Table, and select Add | Authorization:
- In our example, only one role has been gathered. Therefore, the Security role: in the Authorization section was automatically selected:
If we had more roles, it would be necessary to select the appropriate one from the Security Role drop-down menu.
- Now we will map the admin user to this selected security role. Right-click on the Authorization (role=TravelApprovalCaller) and select Add | User.
- In the User section, enter admin as User name:
We should save changes made in the Deployment Editor. After the solution redeploys, only admin should be able to call our BPEL process.
Testing the authorization mechanism with an authenticated and authorized user
We have to redeploy our application to the server and invoke another request from soapUI to test if admin can start the BPEL process now. In the Business Process Choreographer, we can see that admin successfully started a new process instance.
In this article we have shown how to expose a BPEL process as a web service and protect it to accept requests from authenticated users only. We achieved this through WS-Security UsernameToken, which should hold the username and password of a service consumer. We have shown how to propagate a caller's identity to the BPEL process instance. This way, the client user can be set as the process instance owner. Finally, yet importantly, we used identity propagation to restrict access to the BPEL process to the users that are authorized to access it. We achieved this with authorization rules that limit access to a BPEL process to specific users and groups only. We have shown how to apply authentication on the web service (WS-Security) and component level (SCA qualifier).
- Securing a BPEL process [Article]
- Configuring and Deploying the EJB 3.0 entity in WebLogic Server [Article]
- WebSphere MQ Sample Programs [Article]