Greetings Community
I am trying to expose some flow services as SOAP services in webMethods integration server (10.11). E.g. I exposed a flow as a SOAP service using WebServiceDescriptor.
Currently I have to enable “Basic Authentication” in SOAPUI client in order to successfully consume SOAP service otherwise I’ll get access denied type of error message
Currently the username & password that I am using for basic authentication is actually a user created in webMethods which means that using same username & password any consumer of exposed SOAP service can access/login to IS AdminUI as well.
This is something that is a cause of concern for me. Is there a way that we can setup some username & password in webMethods that can be used ONLY for SOAP service basic authentication and at the same time totally disallowing that username any accecss/login to IS AdminUI @ port 5555?
I am not expert in webMethods or SOAP authentications and hence my query might sound naive. Please guide me to right direction or suggest alternative at high level and I’ll then try to work in that direction further
create an ACL and a Group in IS Admin UI.
Add the group to the “Allow” section of the ACL.
Assign this ACL in Designer to the “List ACL” and “Execute ACL” and keep the “Read ACL” and “Write ACL” as default.
Create an user/pw for the invocation of WebServices and this one to the new group created above.
This user can then be used in SOAP UI or by the external invoker for this WS to authenticate them when invoking the WS.
Hello @Holger_von_Thomsen
I created ACL, group & user as you suggested but doing so doesn’t prevent newly created user from a successful login to IS AdminUI.
SOAP Consumer can definitely successfully execute the flow server (via SOAP) using newly created user’s login & password in Basic Authentication, but then at the same time the same newly created user can login to AdminUI (though with limited rights but still login is possible) as well
How can we prevent newly created user from connecting AdminUI?
Does any ACL or user level settings in webMethods can prevent/deny newly created user login to AdminUI?
Thanks Holger but I am afraid it might not solve my problem. Why one has to disable a built-in package just to stop SOAP consumer from login to IS AdminUI. Ideally the SOAP consumer shouldn’t be able to connect AdminUI without any enable/disable of packages etc
If webMethods offers functionality to expose a flow service as SOAP then it should provide some way of authenticating SOAP consumer ‘without’ creating a user in webMethods.
Why one needs to first create some user in webMethods and only then some SOAP consumer (e.g. some externa entity/consumer) can get authenticated and execute SOAP service? There should be some better way of doing user authentication.
May be it is lack of my webMethods knowledge/experience here. I think we should conclude this post here and I’ll try to open a new discussion but from a different angle related to this one.
Hi @Mubarik ,
The approach suggested by @Holger_von_Thomsen is correct. You have to create an ACL (e.g SOAPAcl ) , group (e.g SOAPUsers) and a user (say test ) belonging to that group “SOAPUsers”. And set the SOAPAcl as “Execute ACL” in the SOAP service. Make sure that user “test” belongs to only “Everybody” and “SOAPUsers” group. This way the user “test” will not be able to login to IS Admin UI but will be able to execute the SOAP service.
remember to add the Administrators group to the new ACL otherwise Deployer will not be able to assign the ACL during deployment and you have to assign the ACL manually after deployment.
Just another question:
Why should the SOAP Consumer know how to invoke the IS Admin UI?
Just give them the WS url of the SOAP provider and the credentials dedicated to them.
I was able to come up with an alternative of Basic Authentication for consuming SOAP service. I did a POC to use OAuth token instead of Basic Authentication.
Following is high level details of what I did:
Configured an OAuth client in IS
Defined a new scope for OAuth client
Added folder that contains WSD (web service descriptor) to newly added scope
Generated one time OAuth access_token (never expire token)
Successfully executed SOAP service (which is a flow service exposed as SOAP) using SOAP UI tool by specifying OAuth access_token as Bearer token in SOAP UI tool
By using above sequence of steps, I was able to replace Basic Authentication with one time OAuth token.
It is my understanding that we can now share this one time token with client and the client will then be able to invoke SOAP service by using OAuth access token as bearer token instead of basic authentication
This effort is just a small demo/POC for learning purpose and to find a way to replace basic authentication with some app key/token (e.g. OAuth token in this case).
BTW I am a newbie in webMethods and I am not sure if this approach sounds ok to rest of community members/experts or not?
I would appreciate if @Holger_von_Thomsen or other community members want to share their thoughts on this one. Does this approach look OK?
