Can I avoid storing MS Exchange credentials while still being able to authenticate (against EWS)?

Question

I'm building an application that syncs data between users' Exchange Server accounts (version 2007-2013 supported) and the application.

The application can't use impersonation (at least not in the typical case) as users could be on any number of domains and exchange servers.

I know I'm going to have to ask for their username/email-address and password initially. However, I really don't want to be responsible for storing these credentials if I don't have to (even if they are encrypted, I'd rather not).

I'm not sure what questions to ask, so I'm going with these:

How does Exchange Server authenticate? Do the user's credentials get sent directly to the server as they are, or are the hashed together before being sent across the wire? If they are hashed, how can I get/generate this hash for re-use on successive authentications?

Does Exchange Server send some sort of authentication token that can be re-used later (and forever, until password change or invalidation)?

If you know of a solution to the problem, that the answers to these questions won't address, please do provide it instead.

Is this going to be a bulk sync you do in the background or something the user would kick off by going into your app? — Limey, Jan 31 '13 at 17:38
could maybe admin access work istead? http://help.outlook.com/en-us/140/gg709759.aspx — Limey, Jan 31 '13 at 21:19
Nope. I don't and won't have access to the user's Exchange Server. — David Murdoch, Jan 31 '13 at 22:51
Have you considered Delegate Access? http://msdn.microsoft.com/en-us/library/exchange/bb655860(v=exchg.80).aspx — Paul Turner, Feb 04 '13 at 17:57
Or using the new OAuth access? http://technet.microsoft.com/en-us/library/jj649094.aspx — Paul Turner, Feb 04 '13 at 17:59
I can't configure *anything* on the Exchange Servers themselves. — David Murdoch, Feb 04 '13 at 18:20
I'm using the EWS Managed API (consuming via C#). var service = `var service = new ExchangeService(version){Credentials = new WebCredentials(user, password)}; /* use service ... */` — David Murdoch, Feb 04 '13 at 18:35

score 5 · Answer 1 · answered Feb 04 '13 at 20:50

5

Active directory federation services is exactly for such tasks. You can read about it there.

answered Feb 04 '13 at 20:50

Kirill Bestemyanov

11,946
2
24
38

score 1 · Answer 2 · answered Feb 11 '13 at 03:06

As mentioned by Kirill, ADFS 2.0 is one of the best solution for your task. You can also look into other SSO implementations as well. Though the main goal of SSO implementation is to maintain single Login state for multiple application (thereby reducing multiple Login prompt for each application), some of your application goals seems relevant. Please do a thorough research on all the tradeoffs before heading to the sso implementation since there is a small degree of complexity involved during implementation. SSO suits best if you are considering integration of multiple application in the future with the exchange server.

To answer some of your questions (in the same order - considering an SSO scenario with ADFS 2.0):

The authentication to exchange server will be done via ADFS 2.0 (Which provides security tokens (STS service) - to your application after authenticating with AD/ main Directory service). All the communication is encrypted and token signing certificates are used for Integrity and confidentiality.
The lifetime of Security tokens sent by ADFS 2.0 can be configured and reused as required. Please see this blog post for more details.

Also you can configure the ADFS 2.0 (Federation Service) to send only the relevant claim values (like username and email address) to the application, thereby improving the data security.

score 0 · Answer 3 · answered Feb 04 '13 at 20:44

The System.Net.CredentialCache should work to suite your needs. The WebCredentials is a wrapper for the System.Net.NetworkCredential. Depending on the connection type/domain ect you should be able to utilize System.Net.CredentialCache.DefaultNetworkCredentials or System.Net.CredentialCache.DefaultCredentials

score 0 · Answer 4 · edited May 23 '17 at 11:58

0

perhaps you should take a look at this Links Connecting to EWS by using the EWS Managed API , Connect to Exchange - Getting Started Tutorial? hopfully it will give you a new idea how to solve your problem :)

because if i understand the information correctly you maybe over think problem but i haven't any experiences so i could also absolute wrong

edited May 23 '17 at 11:58

Community

1
1

answered Feb 11 '13 at 13:40

WiiMaxx

5,322
8
51
89

score 0 · Answer 5 · answered Feb 11 '13 at 15:34

Bottom Line

If you can't configure anything on the server, there's no automatically generated token to use. It's unfortunate, but you're facing the same general problem that web browsers have--saving the password. It's worth noting that any authentication needs to be over SSL (an https connection) to prevent a third party listening in on the authentication.

Password storage thoughts:

My suggestion is then to be somewhat creative when storing the password. You can use a keyed encryption algorithm, and then use a hash to generate the key, letting you arbitrarily choose what goes into the key. You would want at least 3 pieces of information going into this: something unique to the device, something unique to the app, and something unique to the exchange server.

For example:

a unique id given by the device (it doesn't matter whether or not this value is app-specific or not, merely that it is consistent)
a (long) string of information compiled into the app, possibly keyed to installation specific values, say the time when the app was first used
something unique to the destination, like the DNS name and perhaps some more specific server info

If you're willing to provide the option to the user, you could have an authorization PIN of some kind that would also be added to the data.

All this data gets put together in one byte array and hashed. The hash (or part of it, or it twice, depending on the hash size vs. the key length) is then used as the key for the encryption of the password.

You could also include some check information along with the password to be able to check client side whether or not the password was decrypted correctly. (If the wrong data is hashed, the wrong key is generated, and the wrong result comes from the decryption).

It's worth noting that all the information to be used for putting into the hash needs to be stored on the device, which is why I would suggest a Pin to authorize the usage of the account.

Can I avoid storing MS Exchange credentials while still being able to authenticate (against EWS)?

5 Answers5

Bottom Line

Password storage thoughts: