1

Given the following configuration:

  • a web client = a regular, modern browser;
  • a typical ASP.NET web application, somewhere on the Internet;
  • a third-party web service that:
    • sits in another domain (no relation via federation, domain trust relations or so);
    • cannot be touched / configured;
    • is accessible via the Internet;
    • is connection-less;
    • requires each web request to be authenticated;
    • supports a common authentication scheme (Windows) and provides a SDK that allows setting the credentials (username, password) when preparing a request.
    • does not support OAuth or similar techniques, so there's no identity token that can be used instead of credentials.

The ASP.NET web application would implement most of its features by making requests to the third-party web service. Thus the web application requires the Windows credentials of its users.

The ASP.NET web application would act like a UI proxy for the 3rd-party web service. Furthermore, the 3rd-party web service is not a singleton. The web application is supposed to be a UI proxy for many instances of those 3rd-party web services (so many Windows domains). Therefore, the web application would act like a de-multiplexing UI proxy - if there is such a term :) It proxies several instances of the 3rd party web service.

Now I am beating my brains out to find a secure way of passing user's credentials (username, password) from the web client to the third-party service, via the web application :)

Where can the credentials be kept securely after the user provides them, at the beginning of a work session, until the work session ends? I though of various media such as: HTTP cookies, HTTP headers, HTML local storage, server memory, web session, application database.

With respect to the question above, what is a good way of encrypting the credentials so that they can be decrypted when required, that is, when preparing the request for the third-party web service (symmetric encryption)? All communication is HTTPS.

I know this is a weird puzzle :)

Update

Perhaps getting the 3rd-party web service to support a brokered authentication pattern (then use OAuth or something similar) would be best. Right?

Update: similar (or duplicate?) questions - seems to be a popular issue

i *must* store third party credentials in my database. best way?

How to store user password for third party service in Python?

Security model: log in to third-party site with user's credentials

Storing third-party passwords for reuse across pages

What is the best way to store password in database when API call requires sending of password in plain text?

Encrypting 3rd party credentials

What's a smart way of storing user credentials for an external site (that does not use OAuth)?

Need to ephemerally store third-party password

Storing third-party auth info securely

Reversible password storage obfuscation method for third-party login credentials

storing the third party credentials in the database/some secure place

Community
  • 1
  • 1
turdus-merula
  • 8,546
  • 8
  • 38
  • 50
  • 1
    I believe the best way is to keep a session token stored, not the credentials. – Tiago Goddard Jan 17 '15 at 16:52
  • 1
    I mean, if the other side don't implement it, you do on your side. – Tiago Goddard Jan 17 '15 at 16:53
  • @TiagoGoddard thanks :) Though, the third party service is connection-less and does not hold sessions. And each request against it should be authenticated (should contain the credentials, added via its SDK). So user's credentials should live somewhere in this ocean of bits, so that they can be used when preparing the request. – turdus-merula Jan 17 '15 at 16:55
  • You control the user credentials? If so you keep the credentials on your database, and use session on your side, sending it server-side so the connection isn't intercepted – Tiago Goddard Jan 17 '15 at 17:32
  • 1
    Unsure how a _3rd party_ service needs _your Windows users' credentials_ ? – EdSF Jan 17 '15 at 17:37
  • @EdSF As described in the post, the web application offers some features by making requests to a third-party web service. That web-service is a "third-party" for the web application, not for the users themselves. The users are from the same Windows domain as that web service. The web application is somehow just a UI proxy - if there is such a thing :) A UI proxy that lives outside that Windows domain. – turdus-merula Jan 17 '15 at 17:47
  • 1
    If all the users are from the same Windows domain as the 3rd party app, would it be possible to host your web application is the same domain (i.e. intranet)? Then Integrated Windows Authentication would just work. – MvdD Jan 17 '15 at 19:51
  • 1
    @user18044 Thank you :) Unfortunately, that Windows domain hosting the 3rd-party web service is not a _singleton_. The web application is supposed to be a _UI proxy_ for many instances of those 3rd web services (many Windows domains). So, the web application would act like a **de-multiplexing UI proxy** :) – turdus-merula Jan 17 '15 at 20:13

2 Answers2

1

Given that you have many of these 3rd party services (see comment), all living in the customer's domains, your web application (living outside those domains) should NOT communicate with the 3rd party service directly.

Your application would become a target for hacking as it handles user's domain credentials in the clear.

The only solution I see potentially working is to have the user's browser communicate with the 3rd party service to retrieve the data using Integrated Windows Authentication (IWA) and then post this data to your web application.

You will have to configure Cross Origin Resource Sharing (CORS) on the 3rd party application for that to work (or use another way to circumvent the same-origin policy)

Community
  • 1
  • 1
MvdD
  • 22,082
  • 8
  • 65
  • 93
0

There is no best way in this weird scenario but the only way will be store the user name and password in application session. This way at least you can make sure password is not compromised to external world, also removed automatically when user sign out. Someone who has access to production system can profile server and read password. You may need to apply a two way encryption (AES) to make it difficult for a production support person to read it.

You already mentioned third party system cannot be touched, I am not sure if you can propose a minor enhancement to the way credentials passed. Try this one.

  1. Third party accept credentials encrypted by an ssh key (public key).
  2. You can encrypt credentials by public key as soon as user submit to you and keep it in session.

In this scenario, no one at your side can decrypt, but third party can decrypt using private key. You and third party needs to exchange ssh keys as a one time setup though.

kamoor
  • 2,909
  • 2
  • 19
  • 34
  • Thank you for the idea of using the an _asymmetric_ encryption technique. Though, perhaps encryption of credentials should be done using the public key of the 3rd-party? So that decryption would be possible only on its side (using its private key). Data that can be decrypted with a public key is not really a secret. Please correct me if I'm wrong. **Unfortunately, the 3rd party system really cannot be touched.** I have to investigate if a "standard" (non-customized) Windows authentication scheme supports the idea described by you. – turdus-merula Jan 17 '15 at 20:35
  • Somebody, please add a comment for the -1 :) – turdus-merula Jan 17 '15 at 20:39
  • Yes, you are right. But in your scenario you do have plain password, so it may not make any difference either way. Updated post. Thx – kamoor Jan 18 '15 at 00:08