on 11-15-2017 12:40 AM
We have a SOAP to RFC Interface scenario in which the web service needs to be exposed to the outside of network, and should be invoked externally using dedicated user id and password for each vendor/customer. Basically we want to restrict some vendors who should not be able to access some particular services. Where do we create user id and Password for sender Communication channels? For Example, we have 10 services, where we want to give an access to 8th service for a particular vendor and that vendor should not be able to access other 9 services.
This below URL is working fine as expected, Internally, but has to work externally as well. What should be done to map externalhostname=internalhostname in the DMZ(F5 or any web dispatcher)? followed by path.
http://Internalhostname:port name/XISOAPAdapter/MessageServlet?senderParty=name of the sender party<&senderService>=name of the sender service<∫erface>=name of the interface<&receiverParty>=name of the receiver party<&receiverService>=name of the receiver service<∫erfaceNamespace>=name of the interface namespace
Let me put my question in different way. Let's say I have 3 separate interfaces called a,b,c using 3 different Source wsdl's and 3 Target RFC structures. For all of these 3 Interfaces a sender SOAP and Receiver RFC Communication channel is common across all 3 ICO's. Lets say we have given the url paths of all 3 interfaces details to two(x,y)/all vendors. after some time, business wants to restrict interface b access to vendor x. how it can be achieved? using Logon credentials authentication.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Would you please explain a bit more in detail on how to enable this principal propagation for Sender SOAP Channel to be invoked outside externally?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
Based on what you have described it sounds to me like you could implement principal propagation to handle the user level access per customer/vendor. As far as authorization execution for each interface you could handle that at the back-end but it's hard to say without knowing more about how the content is organized.
Regards,
Ryan Crosby
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
86 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.