1

The idea would be to wrap a server-side IMAP client in a wrapper that transforms IMAP authentication into a web API for authentication (maybe OAuth?). When the back-end application receives credentials, it then passes them onto IMAP without storing them, waits to see if authentication was successful and if it was, it then returns the user's session key and identity information.

This could provide a simple form of SSO for authenticating users in an organization that lacks robust, formal identity management like Active Directory.

Does this already exist? Any serious security concerns with this setup given SSL/TLS are used for transporting credentials?

Edit: I want to clarify that I do have one implementation of this method, and it presents itself to the web application as OAuth, so at to avoid being proprietary/not-replaceable. I guess what I'm asking is: "Is wrapping IMAP so that it can present itself as OAuth to an application a valid, novel and secure approach to authentication for people with no other OAuth provider or for whom their email credential is their most important credential?" I'm playing with the idea of turning my wrapper into an open-source project so that small businesses can use this wrapper as an authentication provider for low-traffic web-apps instead of paying for huge identity solutions.

  • 3
    It sounds incredibly hack-ish. Requiring a web app user to have an imap account just seems like poor design, and seems like one of those things someone will highly regret doing in the future. – Steve Sether Jan 27 at 21:52
  • It will work, sure, but later down the road someone inherits the maintenance, and will scratch his sorry head trying to understand why the authentication service needs IMAP... – ThoriumBR Jan 28 at 13:59
  • @ThoriumBR Yes, I understand the downfalls of that, that's why the wrapper I am making will actually provide OAuth, just as an alternative to storing credentials, I am authenticating with IMAP. This way, the web app can use any OAuth service to authenticate down the road. I'm just unfortunately in a situation where these user's most used credential is their email credential and the email provider provides no OAuth or API, just their own private AD on the backend. It's awful. – Robert Talada Jan 28 at 17:12
  • @SteveSether Hackish yes, but could you elaborate on why one would regret this, other than it simply being an unusual solution/hard to support? Do you see any concerns from a security perspective? You're welcome to post an answer. – Robert Talada Jan 28 at 17:17
  • @ThoriumBR I agree with you. Fortunately, the only implementation of this solution I have done is thoroughly documented and since it actually presents itself to the webapp as OAuth, any OAuth service can be plugged in to the webapp in place of this IMAP wrapper. (My wrapper presents IMAP as OAuth) – Robert Talada Jan 28 at 17:19
3

Does this already exist?

Checking login with one service in order to authenticate another one is kind of hackish but actually not that unusual. The Postfix mail server can be configured to check with an IMAP server the same way you describe via SASL instead of having its own authentication - http://www.postfix.org/SASL_README.html. And there is also the infamous POP before SMTP which also relies on successfully authenticating against one service before being able to use another.

And universal web mailers like Roundcube which work with any IMAP server basically use the same method when logging in a user, i.e. they rely on the IMAP server for authentication.

Any serious security concerns with this setup given SSL/TLS are used for transporting credentials?

The main point I see is that a naive implementation could cause a possible denial of service against the mail server via web. IMAP servers are usually designed to handle several long living connections in parallel instead of handling many short lived connections in a short time. So some rate limiting might be appropriate. Such limits and the comparably slow authentication when using IMAP might also result in scalability issues for your web application.

| improve this answer | |
  • I appreciate your answer, I think you best see what I am actually trying to do and understand the use case. I'm up-voting your answer now and I will accept it unless someone else raises a more detailed answer. – Robert Talada Jan 28 at 17:16
  • To alleviate Steffen's concern about DoSing yourself, you'll have to rate-limit the requests per IP interfacing with the web server (since the IMAP server will see all of those requests as originating from there). Make sure your security and logging give you enough clues to detect and mitigate an attack. – Adam Katz Feb 4 at 16:39
3

It is technically possible. IMAP is a well known and well described protocol, so you could easily code the authentication by hand. I used to use telnet mailserver 143 for debugging and if I correctly remember, it was not that hard...

But IMHO it is a very poor way. Web applications and frameworks commonly support some well known SSO protocols like OAuth or CAS. The nice points in using them are:

  • if you use well known identity providers, your users are already used to them
  • the application service never sees the client credentials, so as the app developper you are not responsable for securing them
  • you will find well known libraries to help you in implementing them

When it comes to security, roll your own is to be avoided because flaws generally occurs in corner cases, and well known tools are generally intensively tested. Much more than you will test your own implementation...

| improve this answer | |
  • "Roll your own" is bad. I see why you're saying that, but I'm only rolling a wrapper. Credentials are never stored. I see this as a better alternative to rolling my own authentication that stores credentials, am I wrong for seeing it this way? – Robert Talada Jan 28 at 17:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.