6 Replies Latest reply on Nov 27, 2018 8:25 PM by Joshua Raine

    Base64-encoded login for TSWS?

    Joshua Raine
      Share:|

      I've been using the TSWS and BPPMWS APIs and haven't had any luck getting the Base64-encoded auth to work for TSWS, although the identical encoding works for BPPMWS (URL-encoded auth works fine for both). Docs indicate that TSWS should accept Base64-encoding. Is there a setting somewhere that I'm missing to enable this?

        • 1. Re: Base64-encoded login for TSWS?
          Josh Reynolds

          You use the base64 encoded creds to get your inital auth token, and then after that and for as long as the token is valid (or until you log out), you just reference the token in all further calls.

          1 of 1 people found this helpful
          • 2. Re: Base64-encoded login for TSWS?
            Joshua Raine

            OK. The impression I had was that it was an alternative to using the auth token, but if that's not the case that's OK. I'm still however not having any luck:

             

            The below curl generates the error

             

            ```

            {

                "responseTimeStamp": "2018-10-16T22:29:49",

                "statusCode": "BPPM-RWS40015E",

                "statusMsg": "The value of input parameter {0} is invalid."

            }

            ```

             

            curl sample:

            ```

            curl --no-proxy '*' -X POST \

              https://<server>/tsws/10.0/api/authenticate/login \

              -H 'authorization basic <base64 encoded creds>' \

              -H 'Content-Type: application/json' \

              -H 'cache-control: no-cache' \

              -d '{}'

            ```

             

            The content being something along the lines of

            ```

              -d '{

              "username": "<correct username>",

              "password": "",

              "tenantName": "BMCRealm"

            }'
            ```

            Generates the same error. Replacing the empty password with a wrong password gives a 401.

             

            Basically, it looks like the TSWS Login API is expecting content of a username/password, or it falls over. If I provide an invalid username/password combo but a valid Basic Auth encoded header, it ignores the header. What am I missing here?

            • 3. Re: Base64-encoded login for TSWS?
              Brendan Murray

              Hi Josh,

               

              Thank you for contributing to BMC Communities, but I believe your answer is not correct. The authToken is provided by the login API. That API expects the credentials to be in the body of the request in JSON format. The purpose of basic authentication is to allow stateless interaction with the TSOM APIs, i.e. the client can execute each API call as a standalone action by providing the Base64 encoded credentials with the call. Every interaction with the API is authenticated independently. Basic authentication is an alternative to using the login API to request an authToken that must be 'remembered' by the client application until it expires. If you are using basic authentication, you do not use the login API. You simply call the API endpoint you want and provide the Base64 encoded credentials. The returned data will be whatever is appropriate for the API call you invoked. It will not be an authToken.

               

              The purpose of basic authentication is to allow simple integrations between clients that can call API endpoints but have no ability to store the context of one API call to use as input to subsequent calls. I should add that basic authentication is inherently insecure since Base64 is easily decoded. It should only be used over secure (HTTPS) connections.

               

              Regards,

               

              Brendan

              • 4. Re: Base64-encoded login for TSWS?
                Joshua Raine

                [EDIT: Just noticed that both I and the first responder are named Josh. Whoops]

                Brendan - I haven't submitted an answer, I'm the person who has asked the question in this case, and I was responding to a potential answer. What you're describing (that the base64 option is an alternative to the auth token) was my original assumption, but as stated in the OP this was not working for me in TSWS, only in BPPMWS.

                 

                I'm aware that it's inherently insecure and should only be used over HTTPS (you might note that the examples above all use HTTPS, too), however the alternative is putting plain text username/password into the body of a Login request in order to get an auth token, which is the exact problem you're warning against - at least the base64 encoded token can't be easily read over the shoulder, where the username/password can be, far more easily. If the Auth API is concerned with is security, more options of generating auth tokens (ssh?) should be considered.

                 

                Regardless, to tackle your suggestions, and provide examples where this doesn't seem to be working - here are examples of BPPMWS accepting base64 auth, and TSWS not accepting base64 auth - if you can point out what I'm missing here it would be appreciated:

                 

                ```

                curl --no-proxy '*' -X GET \

                  https://<server>/bppmws/api/CI/search/usage \

                  -H 'Authorization: Basic <base64 encoded string>' \

                  -H 'Content-Type: application/json' \

                  -H 'cache-control: no-cache'
                ```

                - returns 200

                 

                ```

                curl --no-proxy '*' -X POST \

                  'https://<server>/tsws/10.0/api/unifiedadmin/Policy/list?responseType=basic' \

                  -H 'Content-Type: application/json' \

                  -H 'authorization: basic <identical encoded string>' \

                  -H 'cache-control: no-cache' \

                  -d '{

                    "filterCriteria": {

                        "policyEnabledStatus": "ENABLED",

                        "policySharedStatus": "ANY"

                    },

                    "stringToSearch": "mq",

                    "fieldToSearch": "name",

                    "type": "monitoringpolicy"

                }'

                ```

                - returns 401:

                 

                `{"responseTimeStamp":"2018-10-17T03:30:34","statusCode":"401","statusMsg":"401"}`

                 

                NB - using `authorization basic <string>` or `Authorization: Basic <string>` doesn't seem to have any behavioural change.

                • 5. Re: Base64-encoded login for TSWS?
                  Brendan Murray

                  LOL. Yes, I was responding to the other Josh.

                   

                  I have done some (very limited) testing using basic authentication with the TSWS APIs and I can't get it to work either. Like you, I tried the policy list API and got a 401 error. It's possible that the TSWS APIs don't support basic authentication. The documentation stipulates that "You must provide authentication credentials by using the login API before accessing the data." That leads naturally to the conclusion that basic authentication is not supported for this API.

                   

                  Please open a case with BMC Customer Support about this issue. They have a direct line to Engineering and should be able to clear up the confusion. We may need to update our documentation if it turns out that the TSWS APIs don't support basic authentication.

                   

                  Thanks for your patience. I know these kinds of issues can be frustrating.

                   

                  Regards,

                   

                  Brendan

                  1 of 1 people found this helpful
                  • 6. Re: Base64-encoded login for TSWS?
                    Joshua Raine

                    Case has been opened, if the support team doesn't post in here with the answer as part of their response, I'll do so once I hear back.

                     

                    Edit: Support has confirmed this as a defect, and my ticket has been closed with as "defect submitted". If/when I hear anything back about the defect being worked on, I'll update here.
                    Reference - DRTSV-112