Application separate authentication server

Asked

Viewed 1,047 times

6

I have a client who will develop two applications of your company, ie two services offered by your company, and plans for other projects, and mobile versions of the same.

Well, for reasons of modularization of the project and ease of development of future applications, we abstract the whole process of authentication of the applications for a single authentication/login service.

How to make all user interaction with your account, login, logout, data update, take place in a single location, on a server and database apart, leaving the server of each application free and busy only with what really interests you?

The architecture we will use is to share a memcached server such as application Session Handler and the authentication server, the servers will be in the same VPC in AWS

software-architecture

  • Hi, Thiago, welcome to [en.so]. I edited your question to take things unrelated to the problem in focus. The question already has 1 vote for closure, it is worth checking the [help/on-topic] and the guide [Ask] to clarify the problem a little more.

  • Is the environment Windows? If it is, use AD and you don’t have to worry about it anymore.

  • You can take a look at Openid. But which technology will you use? Which framework? Maybe I can help more.

  • I think nowadays, this kind of authentication is not even done anymore. Everyone logs with Google Oauth, Facebutts, Openid...

  • Linux environment, PHP and Zend Framework 2. Even with Social Login you need to process at some point. Social Login is just a user facility, but you’ll have to program the same.

  • Simpler than sharing a session memcached?

Show 1 more comment

2 answers

8


One of the ways to simplify is for your application server to use something similar to the following stream:

  • The application generates a hash and directs the user to the login with this parameter and one more token identifying;

  • the server of login requests and checks user credentials;

  • if the user cancels or credentials do not confirm after N times, the login returns the user to the application, without confirming the login, OR

  • by confirming credentials, the login redirects the user back to the application, with the user ID and a hash signed by a common value stored by the parties involved.

You can do this in a relatively simple way, without worrying about Oauth and other poorly documented and complex protocols too much for the specific need.

Advantages of this solution:

  • Portable - each part of the application can be divided into several different machines;

  • little code needed;

  • works for one, two or two hundred applications, as many as necessary;

  • scalable as it does not depend on where each part of the system is running;

  • simple to manage, as the only information shared between the parties is the authenticated user, by the return of a valid ID and signature.

Important considerations

This is a sketch general, which makes sense in an environment not subject to external attacks, or extremely targeted information (not that the solution is not good, but it is only as good as your care to plan the details). You are the one who has to assess the degree of security required for your application and decide whether to simplify or utilize some robust solution. The hard part is separating the robust solutions with reason from the complicated ones.

The explanation was very simplified, just to give an overview. Each step has to be properly taken care of, and you must use a secure connection and have a token separate for each client application. If the connection is not secure, an extra step is required to get a "counter token" server.

  • Right. And whenever I need to confirm the credentials, always the same process right? And the session is in charge of each application?

  • The idea is to completely isolate the processes. Thus, you have the advantage of centralizing login, but avoid side effects. Then of course you can upgrade the system, but the advantage is that everything is isolated. Even more interesting is that if the person saves the credentials in the login application, or if they have already logged in once, who will take care of it is the login system session only. By the time the second application calls, the redirect already goes back and forth transparently to the user.

  • Right. And it gets easier to climb, especially the memcached.

  • How is this redirect made back to the application? In other words, when redirecting the application’s login server to the server, where do you store the hash? In the URL itself? My concern is how to keep this hash safe against replay Attacks or similar (although thinking here, I imagine this can be mitigated using a short-term hash...).

  • @mgibsonbr is not short-lived, it is single-use. The client application redirects the user to authenticator/? hash=11dj1F31a268, for example. Does the authenticator when successfully logging in redirect the user to client/? hash=hhDabG76GD&others_wires=othersData (which is the hash "signed" by a secret that is not transitioned by the web). In this other data, you put what you want (the user ID or other relevant data, which can be "hashed" with the secret of the 2 parts if you want).

  • I took the general idea and found it very interesting, but I’m still racking my brain to understand how to implement it. Like, if it’s a single use then you need a way to invalidate it, right? Likewise, what if for some reason the signed hash isn’t used immediately? Let’s say that the browser stopped at that moment and the user gave up, and another took his place (my scenario is the lab. of a school computer). If the token is still there, in the browser history (possible, since it is in the URL) the next user can open the browser and find themselves authenticated as the first...

  • Anyway, I don’t expect you to answer this, because if we go into all these details the answer will be too extensive... The important thing is that the general idea is good, and with some punctual care can be an excellent solution. I only disagree when you talk about "protocols (...) too complex for the specific need", because security is a complex thing, and if these protocols make "juggling" that to us may seem strange, it is probably because there is a good reason for them to exist! ;)

  • 1

    @mgibsonbr is mostly complex with motive, but other parts are poorly made and poorly documented. Oauth 2.0 for example is complex for use in qq thing. Even I use to make Single Sign On with google accounts where my application is the controller of credentials. I had to juggle, yes, to circumvent gaps in the protocol (and it is not lack of knowledge, are problems known as "excessive academicism", different from something that has technical reason to be). To not stay the chat here, then delete this comment, and detain better when the most opportune occasion arises.

Show 3 more comments

2

Consider using the CAS Central Authentication Service

Basically, CAS is a Java application to which you delegate the authentication service. It integrates, for example, with Active Directory, allowing the user to use the same AD password for WEB applications (something interesting in the case of enterprise applications).

I use CAS successfully in an application developed in Grails (Java web framework, based on Spring, Hibernate, etc).

CAS runs on a server other than applications. Thus, any application that requires authentication, we delegate it to that instance of the CAS.

You can configure for authentication to happen with a database, via JDBC.

The CAS is the name of the protocol whose application has the same name. It is single Sign-on, which means that after you have logged in to an application, others that are opened within the same browser session will share your credentials, not asking again user and password.

See on the CAS page that there are clients in Java, PHP, . NET, etc.

Browser other questions tagged software-architecture

You are not signed in. Login or sign up in order to post.