How to consume a web service with Remedy which requires Basic authentication (HTTP 401)

Version 1
    Share:|

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    Remedy AR System Server


    COMPONENT:

    AR System Mid Tier



    QUESTION:

    Remedy allows you to consume web services published by 3rd party providers. As an extra security measure some providers require authentication in the form of a username and password. If you don't set this up correctly you'll see errors: (401)Unauthorized.

    How can you set this up in Remedy? And what do you need to do when it doesn't work?


    ANSWER:

    Basic authentication means that the resource on the web server requires a username and password. You need to set this up via the Developer Studio interface: use the Login buton (next to Reload) and supply the username/password, then leave the authentication option set to None. The authentication option will add fields to the actual SOAP request (so in the HTTP Body), basic authentication requires a new HTTP header.

    If this doesn't work you need to check what the outgoing request looks like and what sort of error comes back. The error code (HTTP401) is thrown when the resource on the web server expects the client to provide authentication but the HTTP request does not supply this. If this error persists it could mean that the required header is not added or that the request looks different from what the server expects.

    You need some form of logging. Start with the Java plugin logging (for version 9, for previous versions), this won't log the complete HTTP request but it will log the full error returned by the web server. It's in the form of a Java exception and usually gives a better idea what's going wrong.

    If this doesn't help you need to log the actual HTTP communication. This article describes how to do this via Fiddler, but if that is not an option record a network trace. What you need to know is what the HTTP header looks like of the outgoing request. Remedy uses a two-step authentication process. The first request is sent without any authentication. In its most basic form this looks as follows:

    POST http://server:8080/testtest.xml HTTP/1.1
    Content-Type: text/xml; charset=utf-8
    SOAPAction: "http://server:8080/webservice/action1"
    User-Agent: Axis/1.4
    Cache-Control: no-cache
    Host: server:8080
    Proxy-Connection: Keep-Alive
    Content-Length: 377

    <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope...


    Notice it's not sending any authentication information. The server therefore responds with HTTP 401:

    HTTP/1.1 401 Unauthorized
    Date: Wed, 30 Dec 2015 12:54:49 GMT
    Content-Type: text/xml; charset=utf-8
    Server: test
    WWW-Authenticate: Basic realm="test"
    Content-Length: 0


    The client code (that's the plugin server on AR server in this case) receives this and knows it's being challenged. It will repeat the same request, but this time it will include the Authorization header:

    POST http://server:8080/testtest.xml HTTP/1.1
    Content-Type: text/xml; charset=utf-8
    SOAPAction: "http://server:8080/webservice/action1"
    User-Agent: Axis/1.4
    Cache-Control: no-cache
    Host: server:8080
    Proxy-Connection: Keep-Alive
    Content-Length: 377
    Authorization: Basic dGVzdDp0ZXN0

    <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope...


    The server checks if this is this correct and if so will return the data:

    HTTP/1.1 200 OK
    Date: Wed, 30 Dec 2015 12:54:40 GMT
    Content-Type: text/xml; charset=utf-8
    Server: test
    Content-Length: 1000

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"...


    You can also check this on the (publishing) server side by enabling the web server logs (in Tomcat known as Access Logs). Look for the user keyword. For example compare these two requests:

    Client IP=1.200.300.4
    User=
    Request Line=POST /ws/soap/wstest HTTP/1.1
    Status Code=401

    Client IP=1.200.300.4
    User=testuser
    Request Line=POST /ws/soap/wstest HTTP/1.1
    Status Code=200


    The user keyword comes from the Authentication HTTP header. If it's empty it probably means that the header is not included or empty.

    If it's going wrong, compare it to a different test. A client application like SoapUI also allows you to consume the same web service with the same authentication. Does this work okay? And if so, what are the differences in the way the HTTP requests are constructed? If you send the same request generated by Remedy, does this work? SoapUI is a good way to test various ways of dealing with the authentication, once you know what it should be you should be able to understand what's going wrong.

    A common problem is that the web server cannot deal with the two-step authentication process or that the format of the HTTP401 response cannot be understood by the client. Specifically, check the WWW-Authenticate header in the HTTP response. It needs to include a realm, Remedy cannot deal with a response without this.


    Article Number:

    000100367


    Article Type:

    FAQ/Procedural



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles