Very often, when we want to connect to some external FTP/SFTP or JMS servers or for that matter even for some of the HTTP services we need to authenticate our self before initiating the conservation. The same case applies to OSB proxy and business services as well. To facilitate this OSB has provided a feature of Service Accounts.
Service Account is nothing but an OSB resource that allows us to specify the ‘User Name’ and ‘Password’ for the target server that we want to connect through proxy or business service. The OSB proxy and business service creation wizards provides the option to include this service account resource wherever applicable depending on the transport.
OSB provides 3 types of service accounts and the behavior is like below:
- Static: The specified credentials will be encoded in outbound request.
- Pass-through: The specified credentials in the custom token will be used for outbound WS-Security Username Token authentication.
- Mapping: The credentials mentioned in the inbound request will be mapped to other credentials that are remote.
The Service Account can be used during the design time or at the runtime in the message flow of the proxy service.
Using Service Account in Design Time:
In this section we will have a look at how to use the service account in the design time while creating the business service.
1) Create a simple proxy and route it to the business service.
2) Create a new Service Account resource as shown in the following screenshot.
![clip_image002[4]](https://svgonugu.com/wp-content/uploads/2011/03/clip_image0024.jpg "clip_image002[4]")
3) Enter the Service Account name as TestSA and click on Finish button.
![clip_image002[6]](https://svgonugu.com/wp-content/uploads/2011/03/clip_image0026.jpg "clip_image002[6]")
4) As mentioned earlier, the service account can be of 3 types which are represented by ‘Resource Type’ in the following screenshot. Select the resource type as ‘Static’ and enter the username and password fields that we need to connect to HTTP or FTP or JMS server.
![clip_image002[8]](https://svgonugu.com/wp-content/uploads/2011/03/clip_image0028.jpg "clip_image002[8]")
5) Now go to HTTP Transport configuration page in the business service as shown in the below screenshot. Modify the Authentication to ‘Basic’ and observe that Service Account field became mandatory.
![clip_image002[10]](https://svgonugu.com/wp-content/uploads/2011/03/clip_image00210.jpg "clip_image002[10]")
6) Click on ‘Browse’ button and select the Service Account ‘TestSA.sa’ as shown in the below screenshot. In the same way we can use the service account when the transport is selected as FTP, JMS etc.. and both proxy and business services can make use of the Service Accounts.
![clip_image002[12]](https://svgonugu.com/wp-content/uploads/2011/03/clip_image00212.jpg "clip_image002[12]")
7) Click on OK and save the business service and now you can start testing the business service that accepts these credentials in the request.
![clip_image002[14]](https://svgonugu.com/wp-content/uploads/2011/03/clip_image00214.jpg "clip_image002[14]")
Using Service Account in Run Time:
If we want to use the service account in the message flow of the proxy service, use the following XQuery function
fn-bea:lookupBasicCredentials(‘ServiceAccount/TestSA’);
The above XQuery function results into the following output when used in any of the OSB activities.
<con:UsernamePasswordCredential xmlns:con="http://www.bea.com/wli/sb/services/security/config">
<con:username>Username</con:username>
<con:password>Password</con:password>
</con:UsernamePasswordCredential>
So the following XPath expressions will fetch you the username and password that can be used wherever we want, where varSA represents the variable that store the above XQuery function result.
$varSA/con:username/text()
$varSA/con:password/text()
Siva's Blog 