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

Pls comment/advise
Thanks

Hi Mubarik,

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.

Regards,
Holger

Thanks Holger for your response. I’ll try this solution and revert with my feedback.

Thanks

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?

Hi Mubarik,

you can disable the package “Default”, after which a login via “host:port” is not longer possible.
You have to use “host:port/WmRoot/index.dsp” then.

Regards,
Holger

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.

Hello Jaideep

Thanks for your response on this one.

Actually I tried exactly what you suggested but the newly created user can still connect to IS (besides being able to execute SOAP service).

Please see following screenshots of newly created user, user group & ACL and let me know if I followed your instructions correctly?

Hello @Mubarik
Could you check and confirm that the new User/Group is not added to Administrator’s ACL.?
Regards
RamGopal

Hi RamGopal

Yes I can confirm that new user or group is not part of Admin ACL

Hi,

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.

Regards,
Holger

Thanks @Holger_von_Thomsen for your response.

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:

1. Configured an OAuth client in IS
2. Defined a new scope for OAuth client
3. Added folder that contains WSD (web service descriptor) to newly added scope
4. Generated one time OAuth access_token (never expire token)
5. 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?