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.
3) Enter the Service Account name as TestSA and click on Finish button.
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.
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.
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.
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.
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()
Hi,
Is it possible to change the service account id/password based on the payload using xquery at runtime?.
My requirement is if the target system ‘A’ in the payload then I have use one serviceaccount(id/pass)
if the target system ‘B’ then I have use another serviceaccount(id/pass)
Thanks,
Can I customize the service Account url in cutomization file if yes can u give an example customization file
we used single file and used to modify using sbconsole. Need to check again. which release you are using?
In your example, we can see how we can read the credentials but not how to eventually assign the proper Service Account.
Is it feasible to assign a Service Account for a Business Service at runtime?
Or a Business Service can only be bound to a Service Account in a hard-coded manner?
AFAIK, that can only be done at design time
One question that is not related to topic. Please show me the differences between design-time and runtime?
What context you are asking about? you consider usage of service accounts described in this post, first part of this post shows attaching the service account to business service or proxy service during your design time or creation time. second part of it shows using the API, which reads the service account at run time to get the credentials and use it in message flow.
This is some thing like the following loop. If we directly give the value for cnt during our coding itself, its something similar to design time activity. but if we derive the value cnt somehow and use it in the loop, it can be considered as determining the value at runtime.
for(i=0;i<cnt;i++)
hello
I tried this example with pass through service account it did not work, but it is working fine with static one. can you please help
Which context and how are you using it???
Hello
I tried this example with pass through service accont, but it is not working, can you please help
It got resolved. I was using fn-bea:lookupBasicCredentials(‘ServiceAccount/TestSA.sa’) instead of fn-bea:lookupBasicCredentials(‘ServiceAccount/TestSA’).
Thanks for your guidance.
Wonderful article. But my service account is present within some other project, how can I access it in fn-bea:lookupBasicCredentials(‘ServiceAccount/TestSA’)
You can give the path of the service account file considering configuration project as the root.