It depends on your requirement to differentiate between credentials:
- If differentiation is based on different clients(service being invoked from different consumers and for each of them you will have different passwords in outblund) then you can configure service account to be based on user-mapping
- If credential in outbound varies based on endpoint URI of target service then it will be better to use different business service and service account for each of those.
- There is 1 more work around which i can think of but not sure how good that impleemntation will be. If none of the above 2 satisfies your criteria then create a pass through service account. Before invoking business service, replace content of $inbound/security/username and password based on your if-else condition. Value of username and password which will be present inside $inbound/security will be passed as credential for outbound security. This can be done using replace action. (Important thing will be, you will have 7 service account to maintain security standards, just use lookupBasicCredentials function to refer correct service account in your xquery)
- Alas, 1 more way which again i am not sure how good it is, is that instead of policy you just create $header by using xquery. SInce you know outgoing header structure.
Hope this will help. All the best.
Thanks Ankit for your response.
I have only one target URL with different username and passwords. Also I need to pass the password as password digest and also add the create/expire timestamp which I think cant be done in the message flow / xquery. Please confirm.
Because of the above reason we cant use pass through or mapping options.
What is your thought ?
Business Service :As per my understanding, no need to create 7 different business services. Even though if you have 7 different endpoint urls, you can create a business service and while invoking the business service through proxy service you can dynamically pass the endpoint urls using "Routing Options" action. In the "Routing Options" action you need to select URI option and pass your endpoint url. This way you can call different endpoint urls using one business service.
User Name And Password: To pass username and passwords you can use "Transport Headers" action. For Ex: if are using Publish action to call your business service, use "Transport Headers" action, select request, add one header for username. Select "Other" option and enter UserName in the text box and then go to "Set Header to", click on the expression link and provide username or xpath. Similarly you can add header for Password. You need to enter "Password" in text box and provide password or xpath in the expression field.
Please let me know if you have any concern.
Sorry for delayed response, i was away from work in recent times. Option- 3 will work perfectly for your scenario. Below is complete solution:
• Create a custom policy(Use IDE to create new policy resource. Use sample snippet of Identity and MessageAge assertion from the example policy snippet given in below link for your policy. )
• Create pass through service account
• Attach above policy and service account to business service
• Before invoking business service, use xquery to replace username and password of inbound header with appropriate ones based on if-else conditions
Attaching above link for sample policy snippet(Section 52.5.1) I mentioned above. You need to tweak this snippet to remove confidentiality assertion, add MessageAge assertion, modify UsernameToken to use PasswordDigest instead of PasswordText.
It works fine. Hope this helps.
I have similar requirement. For your response "Create a custom policy(Use IDE to create new policy resource. Use sample snippet of Identity and MessageAge assertion from the example policy snippet given in below link for your policy. )" - do we need to give a clear text password when we replace inbound header before calling BS? Will this custom policy automatically creates a password digest from clear text password? As per OASIS standard->
Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )
Will this be taken care by custom policy?
Yes it will be taken care when policy executes. But do remember to replace the word "PasswordText" from "PasswordDigest" in that policy snippet. I tried to attach updated custom policy here but couldn't do so. We need to pass plain text password via service account and when policy executes it will convert it into Digest by adding nonce and created.
For this step suggested by you "Before invoking business service, use xquery to replace username and password of inbound header with appropriate ones based on if-else conditions"-- Can you please let me know the exact Xpath for username and password in $inbound? In inbound structure I could see security->transportClient->username and security->messageLevelclient->username but no presence of password!!
Oh right. My last statement looks confusing. By inbound header, I meant soap header that is $header and not $inbound. Here requirement is to have message level authentication so we don't need to process $inbound at all as it consist of transport level authentication.
We need to replace content of $header variable with ws-security token. There are 2 ways to it:
•Either create a pass-through proxy where client is sending a usernametoken in soap header and then replace content of username and password before invoking BS. Steps present at Configuring Message-Level Security for Web Services section 52.3.2 but I will recommend second option in this case.
•Write an xquery to replace content of $header variable with xml structure of ws-security token(not xml structure of policy statements but xml structure of processed soap header consisting of UsernameToken) and use if-else within that xquery to have correct value of username-password in plain text. For security purpose . instead of hardcoding username-password within xquery, you can create 7 static service account and use lookupBasicCredential function in xquery to retrieve appropriate values. BS will have passthrough service account attached for digest message level policy. So all it will need is correct content of username and password in $header variable to process further.
replace content of $header with below xml(username and password will be within if-else)