Hi All,

Since years we have exposed (SOAP) webservices working without any problems. When we use SoapUI, it generates requests for all the operations, and they contain the username and password (the attached service flow has no input variables) like this:

Calling this operation with the appropriate user, it works fine.

 ---

Now the customer asked to copy this operation to another exposed SOAP service. We did that:

The attached service flow is the same.

But when we import this service in SoapUI, the request for the same operation now do not contain the username and password:

When we call the service, we get Unauthorized user error.

The only difference is that after creating the first, working service and before creating the second, not working service we upgraded from v22.02 to v22.04. 

Using another (new) service flow, the error is the same. Restarting the app server has no effect.

What's wrong? Why do BAW generate a non-working webservice? How to fix this error?

Thx,

This non-standard Web Services authentication (Lombardi heritage) is based on small checkbox "Protected" in  "Behavior" section (top right corner of Process Designer). 

see: https://www.ibm.com/docs/en/baw/22.x?topic=service-creating-web

In BAW 22.x it should be supported on traditional installations  (based on tWAS 8.5.5.X).
So please ensure that this checkbox is enabled.  If enabled - try to disable it (save) and enable it again (save again). 

Please note that this functionality disappears on all containerized versions (including BAW 22.x on WebSphere Liberty profile) - what documentation above clearly says. 

Hi All,

Since years we have exposed (SOAP) webservices working without any problems. When we use SoapUI, it generates requests for all the operations, and they contain the username and password (the attached service flow has no input variables) like this:

Calling this operation with the appropriate user, it works fine.

 ---

Now the customer asked to copy this operation to another exposed SOAP service. We did that:

The attached service flow is the same.

But when we import this service in SoapUI, the request for the same operation now do not contain the username and password:

When we call the service, we get Unauthorized user error.

The only difference is that after creating the first, working service and before creating the second, not working service we upgraded from v22.02 to v22.04. 

Using another (new) service flow, the error is the same. Restarting the app server has no effect.

What's wrong? Why do BAW generate a non-working webservice? How to fix this error?

Thx,

Hi Sebastian,

We must use containerized versions, because the UI toolkit exists only as TC... Really, there is no Protected checkbox there.

Why do work the old service which is in the same TC application? It remembers that it was created years ago when only traditional installation did exist? 

And what to do now? The webservice throws an error because of no user is specified, but we cannot pass the user. How to solve this? Or there is no solution? 

Thx,

This non-standard Web Services authentication (Lombardi heritage) is based on small checkbox "Protected" in  "Behavior" section (top right corner of Process Designer). 

see: https://www.ibm.com/docs/en/baw/22.x?topic=service-creating-web

In BAW 22.x it should be supported on traditional installations  (based on tWAS 8.5.5.X).
So please ensure that this checkbox is enabled.  If enabled - try to disable it (save) and enable it again (save again). 

Please note that this functionality disappears on all containerized versions (including BAW 22.x on WebSphere Liberty profile) - what documentation above clearly says. 

Hi All,

Since years we have exposed (SOAP) webservices working without any problems. When we use SoapUI, it generates requests for all the operations, and they contain the username and password (the attached service flow has no input variables) like this:

Calling this operation with the appropriate user, it works fine.

 ---

Now the customer asked to copy this operation to another exposed SOAP service. We did that:

The attached service flow is the same.

But when we import this service in SoapUI, the request for the same operation now do not contain the username and password:

When we call the service, we get Unauthorized user error.

The only difference is that after creating the first, working service and before creating the second, not working service we upgraded from v22.02 to v22.04. 

Using another (new) service flow, the error is the same. Restarting the app server has no effect.

What's wrong? Why do BAW generate a non-working webservice? How to fix this error?

Thx,

Hi Laszlo, 

WebSphere implementation on containers (Liberty profile)  is different – and does not fully support all features from traditional hosting.  For example WebSphere Policies are not supported – because underlying WebSphere Liberty profile is not supporting it  (yet?). 
And this non-standard protection is also simply not supported (as you see for newly defined services only). I don't see any particular reason of this removal – probably this feature was "strange enough" to be discontinued on modern platforms.

So the only way to continue right now is to switch to authentication on HTTP level (basic authentication) which is supported on containers. It will obviously change WSDLs – but that user and password inside data payload was something that you really should get rid of. 

Another option is to kindly ask IBM to bring this feature back  on containers because very unexpectedly there is one user of this function somewhere :)

Hi Sebastian,

We must use containerized versions, because the UI toolkit exists only as TC... Really, there is no Protected checkbox there.

Why do work the old service which is in the same TC application? It remembers that it was created years ago when only traditional installation did exist? 

And what to do now? The webservice throws an error because of no user is specified, but we cannot pass the user. How to solve this? Or there is no solution? 

Thx,

This non-standard Web Services authentication (Lombardi heritage) is based on small checkbox "Protected" in  "Behavior" section (top right corner of Process Designer). 

see: https://www.ibm.com/docs/en/baw/22.x?topic=service-creating-web

In BAW 22.x it should be supported on traditional installations  (based on tWAS 8.5.5.X).
So please ensure that this checkbox is enabled.  If enabled - try to disable it (save) and enable it again (save again). 

Please note that this functionality disappears on all containerized versions (including BAW 22.x on WebSphere Liberty profile) - what documentation above clearly says. 

Hi All,

Since years we have exposed (SOAP) webservices working without any problems. When we use SoapUI, it generates requests for all the operations, and they contain the username and password (the attached service flow has no input variables) like this:

Calling this operation with the appropriate user, it works fine.

 ---

Now the customer asked to copy this operation to another exposed SOAP service. We did that:

The attached service flow is the same.

But when we import this service in SoapUI, the request for the same operation now do not contain the username and password:

When we call the service, we get Unauthorized user error.

The only difference is that after creating the first, working service and before creating the second, not working service we upgraded from v22.02 to v22.04. 

Using another (new) service flow, the error is the same. Restarting the app server has no effect.

What's wrong? Why do BAW generate a non-working webservice? How to fix this error?

Thx,

Hi Sebastian,

I see.

Finally I switched back the app to T, turned that checkbox on for the webservice and switched the app again to TC. Now it solved the problem. I don't know what will we do when T mode once discontinued and we cannot switch back temporarily to T mode...

You wrote: "So the only way to continue right now is to switch to authentication on HTTP level (basic authentication) which is supported on containers."

Where or how to do this? There is no such setting in the Process Designer as I see.

Thx

Hi Laszlo, 

WebSphere implementation on containers (Liberty profile)  is different – and does not fully support all features from traditional hosting.  For example WebSphere Policies are not supported – because underlying WebSphere Liberty profile is not supporting it  (yet?). 
And this non-standard protection is also simply not supported (as you see for newly defined services only). I don't see any particular reason of this removal – probably this feature was "strange enough" to be discontinued on modern platforms.

So the only way to continue right now is to switch to authentication on HTTP level (basic authentication) which is supported on containers. It will obviously change WSDLs – but that user and password inside data payload was something that you really should get rid of. 

Another option is to kindly ask IBM to bring this feature back  on containers because very unexpectedly there is one user of this function somewhere :)

Hi Sebastian,

We must use containerized versions, because the UI toolkit exists only as TC... Really, there is no Protected checkbox there.

Why do work the old service which is in the same TC application? It remembers that it was created years ago when only traditional installation did exist? 

And what to do now? The webservice throws an error because of no user is specified, but we cannot pass the user. How to solve this? Or there is no solution? 

Thx,

This non-standard Web Services authentication (Lombardi heritage) is based on small checkbox "Protected" in  "Behavior" section (top right corner of Process Designer). 

see: https://www.ibm.com/docs/en/baw/22.x?topic=service-creating-web

In BAW 22.x it should be supported on traditional installations  (based on tWAS 8.5.5.X).
So please ensure that this checkbox is enabled.  If enabled - try to disable it (save) and enable it again (save again). 

Please note that this functionality disappears on all containerized versions (including BAW 22.x on WebSphere Liberty profile) - what documentation above clearly says. 

Hi All,

Since years we have exposed (SOAP) webservices working without any problems. When we use SoapUI, it generates requests for all the operations, and they contain the username and password (the attached service flow has no input variables) like this:

Calling this operation with the appropriate user, it works fine.

 ---

Now the customer asked to copy this operation to another exposed SOAP service. We did that:

The attached service flow is the same.

But when we import this service in SoapUI, the request for the same operation now do not contain the username and password:

When we call the service, we get Unauthorized user error.

The only difference is that after creating the first, working service and before creating the second, not working service we upgraded from v22.02 to v22.04. 

Using another (new) service flow, the error is the same. Restarting the app server has no effect.

What's wrong? Why do BAW generate a non-working webservice? How to fix this error?

Thx,

On containers  protection of exposed services is enabled by default with basic authentication.
You don't have to do anything. 

Just say to clients of exposed services - "please forget about this ugly style  of sending password in soap:body and instead of: 

POST https://bawServers....
<soap:Envelope ...>
   <soap:Body>
      <ns:yourBusinessOperation>
       <ns:username>user</ns:username>
       <ns:password>password</ns:password>
       <ns:bussData>... </ns:bussData>
       … 
please send user/pass encoded in HTTP header like this:

POST https://bawServers....
Authorization: Basic <user:password base64 encoded goes here> 
<soap:Envelope ...>
   <soap:Body>
      <ns:yourBusinessOperation>
        <ns:bussData>... </ns:bussData>
        … 
and BTW new WSDL is like that ... " 

However,  if you are still on traditional hosting - protection is not enabled by default.
And you can achieve that using WebSphere Policies (also available only on traditional WAS now).
What I believe  is a completely new thread :) 

Migration to containers is interesting journey. 

Hi Sebastian,

I see.

Finally I switched back the app to T, turned that checkbox on for the webservice and switched the app again to TC. Now it solved the problem. I don't know what will we do when T mode once discontinued and we cannot switch back temporarily to T mode...

You wrote: "So the only way to continue right now is to switch to authentication on HTTP level (basic authentication) which is supported on containers."

Where or how to do this? There is no such setting in the Process Designer as I see.

Thx

Hi Laszlo, 

WebSphere implementation on containers (Liberty profile)  is different – and does not fully support all features from traditional hosting.  For example WebSphere Policies are not supported – because underlying WebSphere Liberty profile is not supporting it  (yet?). 
And this non-standard protection is also simply not supported (as you see for newly defined services only). I don't see any particular reason of this removal – probably this feature was "strange enough" to be discontinued on modern platforms.

So the only way to continue right now is to switch to authentication on HTTP level (basic authentication) which is supported on containers. It will obviously change WSDLs – but that user and password inside data payload was something that you really should get rid of. 

Another option is to kindly ask IBM to bring this feature back  on containers because very unexpectedly there is one user of this function somewhere :)

Hi Sebastian,

We must use containerized versions, because the UI toolkit exists only as TC... Really, there is no Protected checkbox there.

Why do work the old service which is in the same TC application? It remembers that it was created years ago when only traditional installation did exist? 

And what to do now? The webservice throws an error because of no user is specified, but we cannot pass the user. How to solve this? Or there is no solution? 

Thx,

This non-standard Web Services authentication (Lombardi heritage) is based on small checkbox "Protected" in  "Behavior" section (top right corner of Process Designer). 

see: https://www.ibm.com/docs/en/baw/22.x?topic=service-creating-web

In BAW 22.x it should be supported on traditional installations  (based on tWAS 8.5.5.X).
So please ensure that this checkbox is enabled.  If enabled - try to disable it (save) and enable it again (save again). 

Please note that this functionality disappears on all containerized versions (including BAW 22.x on WebSphere Liberty profile) - what documentation above clearly says. 

Hi All,

Since years we have exposed (SOAP) webservices working without any problems. When we use SoapUI, it generates requests for all the operations, and they contain the username and password (the attached service flow has no input variables) like this:

Calling this operation with the appropriate user, it works fine.

 ---

Now the customer asked to copy this operation to another exposed SOAP service. We did that:

The attached service flow is the same.

But when we import this service in SoapUI, the request for the same operation now do not contain the username and password:

When we call the service, we get Unauthorized user error.

The only difference is that after creating the first, working service and before creating the second, not working service we upgraded from v22.02 to v22.04. 

Using another (new) service flow, the error is the same. Restarting the app server has no effect.

What's wrong? Why do BAW generate a non-working webservice? How to fix this error?

Thx,