Securely storing credentials?

[vwegert]

Hi all.

For a POC application, I'm trying to access an external web service. Technically, it works (using a RFC destination to manage the endpoint, cl_http_client=>create_by_destination and cl_rest_http_client) - but I'm not happy with a certain detail. To use the web service, I need to obtain an access token using this API method. It boils down to the following code:

  cl_http_client=>create_by_destination(
    EXPORTING
      destination              = i_destination
    IMPORTING
      client                   = DATA(http_client)
  ).

  data(query_params) = cl_http_utility=>fields_to_string(
    fields      = value #( ( name = 'grant_type' value = 'password' )
                           ( name = 'username'   value = 'username@some.tld')
                           ( name = 'password'   value = 'ssssecret' ) )
  ).

  cl_http_utility=>set_request_uri(
    request = http_client->request
    uri = |/oauth/token?{ query_params }|
  ).

  DATA(rest_client) = NEW cl_rest_http_client( http_client ).
  DATA(request_entity) = rest_client->if_rest_client~create_request_entity( ).
  request_entity->set_content_type( iv_media_type ='application/x-www-form-urlencoded' ).
  rest_client->if_rest_resource~post( io_entity = request_entity ).

(and lo and behold, no prefixes! )

I'm sure you'll see the issue right away. For some reasons I don't fully understand, the service is designed in a way that I need to specify constant values (particle:particle) using HTTP Basic auth (so that's what specified in the RFC destination), and the "real" user name and password need to be supplied using query parameters. I could simply store them in a customizing table, but for obvious reasons, that's less than optimal. I've tried to store the credentials in the RFC destination, but SAP did a good job of protecting the SECSTORE - as far as I can see, I can't read the password stored in the RFC destinations. Which other options for storing the credentials would you suggest?

Thanks

  Volker

[Former Member]

Hello,

Try creating a logical port where you can store the Admin User id and Password. Connect to the Logical Port from your ABAP program and access any Service that you would like to consume.

Cheers

Naavy

[vwegert]

Hello,

I fail to see how that would solve the problem. How does that magically add query parameters containing username and password to my HTTP query?

Best regards

  Volker Wegert

[Former Member]

Hello,

If I understand it correctly, you do not want to hardcode/store the user name and password.

Most of the web services will have operations such as "Authentication", call it first from your code, which will return an encrypted token.

Use the encrypted token obtained from above operation and call desired operation by passing the above authenticated token.

Off course, some of the Authentication Operations do require the user name and password for which you can try what Simone had mentioned.

Hope this helps.

Happy coding!!

Cheers

Naavy

[SimoneMilesi]

Hi Volker

You could use your customizing table as encrypted ones and decripting them at runtime

Check out

and the  suggested links in replies at this thread

You can create as first step a report that read USer and password (like a web registration form), entrcypt what you want and then store to a table.

In your connection, read table, decrypt and use.

[vwegert]

Simone,

thanks for the hint. Unfortunately, that would mean having to modify the generated table maintenance application rather heavily. I think, for my POC application, I'll be taking a different route (interactive authentication), but I'll keep the encryption class in mind. So far, I've only used the STRUST PKI stuff for this...

Best regards

  Volker

[SimoneMilesi]

I would like to know your full scenario and solution Volker, since I'm starting to approach a similar situation (SAP working tightly with Company's intranet+PLM+EWMS) and sharing/stealing a couple of ideas would be great!

[vwegert]

At your request (well, not really, I intended to make it anyway ), here's the description of the full scenario.