Authorizing User Access to BPEL Process

0
91
6 min read

 

WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7

WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7

Define, model, implement, and monitor real-world BPEL 2.0 business processes with SOA-powered BPM

  • Develop BPEL and SOA composite solutions with IBM’s WebSphere SOA platform
  • Automate business processes with WS-BPEL 2.0 and develop SOA composite applications efficiently
  • Detailed explanation of advanced topics, such as security, transactions, human workflow, dynamic processes, fault handling, and more—enabling you to work smarter

 

Appendix

        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:

  1. 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:

    Authorizing User Access to BPEL Process

  2. 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.)

  3. 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:

  4. 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:

  5. 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:

  6. 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:

  7. Now, we should save changes made in the console to the master configuration, as shown in the following screenshot:

    Authorizing User Access to BPEL Process

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:

  1. We will return to the WS-Security settings using the breadcrumb navigation and select the Caller link:

  2. 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).
  3. 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:

  1. 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:

    Authorizing User Access to BPEL Process

  2. 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:

  3. 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:

  4. 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:

  5. 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.

LEAVE A REPLY

Please enter your comment!
Please enter your name here