Good Result but also Access Denied

,
1

Why when invoking a service through SOAPUI or a C# client do I get an access denied message in my logs but still get a successful result to my transaction. The only way I know it happens it to watch the logs. I read on a post somewhere (sorry cannot remember the site) that this happened because of the way .NET communicates with webMethods. Can anyone explain this a little more or have any ideas how to prevent it?

2

when authenticating with a user it still logs an error like it thinks I am trying to access it anonymously.

ACLManager: allow check for user “local/Default” on ACL “BankServiceExecute” is returning false
Access Denied. User “local/Default” does not have permissions to invoke service

Then I immediately see my user authentication

ACLManager: allow check for user “system/username” on ACL “BankServiceExecute” is returning true.

3

It’s the way basic auth works over http, you’ll to send the credentials with the initial request and this error will go away. .Net has a property for it to set and SoapUI also has a checkbox to send the credentials with the initial.

1 Like
4

Thanks Mark, I was able to find the settings. Appreciate the guidance.

5

Hi,

I have something similar. My web service is logged for errors. But with every correct invocation with expected user name, there is a error log for access denied for user Default.

My user belongs to Internal ACL and not Default. Same was the error when it belonged to Default.

Can you pls suggest how to fix it?

Thanks,
Priya

6

I believe this incident will answer all your questions.
https://empower.softwareag.com/sl24sec/SecuredServices/KCFullTextASP/viewing/view.asp?dstype=ISSUE&prdfamily=webMethods_ESB&KEY=139817-12154732&DSN=PIVOTAL&DST=ISSUE

7

Hi Anjni,

Thanks, but this link isnt accessible from our empower id. Can you pls post the content here?

Thanks,
Priya

8

Here it is:

As you have pointed out the Web Service Stack of the IS changed dramatically between 7.x and 8.2. Well, it actually changed dramatically between 8.0 and 8.2 when the IS adopted the SAG WS-Stack component as the Web Services Stack. So you may very well see behavior changes between 8.2 web services and the pre 8.2 web services, which is why IS 8.2 Web Services introduced the “Pre82 Compatibility Mode” setting on WSDs.

But the real problem here is not in the IS code at all. It is in the Web Service Client being used to invoke an IS Web Service or operation (IS Service) that is ACL protected. If the Client sends the credentials on the first request, as the IS client does and as the SOAP UI client does after its preferences are set to do so, the initial call to the IS succeeds. But, when a Web Service Client makes the first call without any credentials, what happens under the covers, is the initial call is rejected by the IS with the HTTP 401 response code and then Client code reissues another request with the credentials which succeeds. The 8.2 IS logs that fact that the first call resulted in an “Access Denied”, and then the second call (automatically re-issued by most Clients that receive an HTTP-401 response without any user intervention) succeeds. So, not only is the IS logging the Access Denied message, you are actually making two distinct HTTP requsts for every web service invocation.

Even if the IS didn’t log the Access Denied message, you would still be making double HTTP calls for every invocation. That has to degrade the performance of all web service calls. If you are going to use ACL protected WSDs and IS Services, as most implementaions do, you really need to ensure that your Web Service Client is configured to provide the credentials on the initial call. You really don’t want to wait for an HTTP-401 response before sending the credentials on a second call.

It was not handled in a single call in 7.1 either. The 7.1 IS may not have been logging the Authorization Access Denied message in this case. But in all reality, that should have been considered a bug which was corrected in the current release.

The fact of the matter is that an inbound request arrives at the IS without any security credentials. While attempting to process that request, The IS determines that the WSD and/or the underlying operation are to be ACL controlled and this call is not authroized to execute the request. The IS rejects the request because the provided Credentails are not authorized to access the Web service or underlying IS Service. The fact that the calling client may or may not already have credentials that they then may or may not use if they decide to resubmit the request a second time, does not change the fact that a request arrived at the IS which was rejected due to not having the proper credentials. I’m sure we could change the IS processing to silently ignore Acccess Denied failures if the “Default” credentials were in use at the time, in the hopes that the request might be resubmited with proper credentials. But we have no way to know whether a subsequent request will be issued.

For example, imagine an inbound request coming from a browser invocation that has not yet prompted for access credentials. The IS will log the access Denied message, reject the request and the Browser would most likely prompt for Credentials and then resubmit the request with the proper credentials. But is the User did not supply those credentials when prompted, there would be no subsequent 2nd successfull call. If we had not logged the original Access Denied failure, there would be no indication that the call had ever occurred.

The IS is correct in logging an Access Denied failure when a request is rejected due to invalid or missing credentials. We have no way of knowing if a subsequent request may be issued with valid credentials.

The fact of the matter is that as far as the IS is concerned an inbound HTTP request arrives without credentials and during processing we discover that the IS Assets being accessed are to be ACL protected. We reject the request, logging the rejection in the IS error log. I’m sure that the IS code could be changed to skip logging the Access Denied messages under certain circumstances. But the point is, we have absolutley no way to know whether the other end will actually resend the request with credentials, as normally expected in a http 401 response situation, or if they will simply go away. If we don’t log the error somewhere when it occurs, there is no record of the attempted access and subsequent rejection.

However, there’s a way to have the old behavior in place, the Pre82 compatibility mode=true property of the WSD can be set to achieve this. If this flag is set, the old behavior still holds in an IS 8.2 system, including the behavior of silently rejecting inbound requests that do not contain credentials. Unfortunately once that flag is set, you’ll be limited to using the older IS Web Services stack and it’s original capabilities, for example the proprietary ws-security configuration language, no WS-Addressing support etc.

9

PFA- Solution for the Access Denid error with SOAP UI way of invoking a webMethods SOAP WS
SOAP-UI Error.docx (70.4 KB)

10

pfa for solution

Good wishes,
Suresh Palanisamy | Software AG - CoE | EAS IPM BPI | Mobile # 9663383142
“Try not to become a man of success rather to become man of Value” - Albert Einstein

SOAP-UI Error.docx (70.5 KB)

11

What is the version of Soap UI you tested on?

12

5.0.0

13

Hi All,

We have business service for which we have been witnessing the ‘Access Denied’ error as below for user - local/Default :

Access Denied. User Default does not have permissions to invoke service -

Now I want to know who exactly is trying to access, is there any way to do so?

Thanks,

Sanket

14

It could be just the initial basic auth challenge or someone calling it anonymously. If you want to find more information about what exactly is happening I can think of 2 options. You could check your session log and match up a time to your Access Denied in the server log. If it is a basic auth initial challenge then you would find a another call right behind it establishing a session for a user and that could answer your question. Or you could turn up the logging for HTTP Headers and HTTP Request and try to trace info about the requests that way. Not sure if either of those will give you what you want but that is the first steps I would take. Hope that atleaset helps a little.

Joe

15

Hi Sanket ,

This is how the basic authentication works.
You can refer this link for more details : http://qnimate.com/understanding-http-authentication-in-depth/
Also you can check the Basic Authentication RFC : RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication

If you do not want the server to reject the first request and then ask for the Basic Authentication credentials from the client. You can use “Preemptive Authentication”

In this mode HttpClient will send the basic authentication response even before the server gives an unauthorized response in certain situations, thus reducing the overhead of making the connection

If you are using SOAP UI , there you will have a check box to set “Authenticate Preemptively”.