How to make an external login authentication?

Asked

Viewed 1,550 times

7

I need to develop a system to be used by the user. The user will be registered in another system, where we will have the registration, contracted plans and financial control of the same...

The idea is that when the user tries to log into his system, instead of him authenticating inside the database the user information, he goes to the system "master", authenticate the user and provide the information of his plan...

Then from there the user receives the confirmation of authentication of the "master" system and can use his system...

My question is how do I do it safely? do not want to expose user information and mainly, do not want to expose the "master" system that will have very important data within it...

php security-guard authentication

  • I am right now going through the same problem, and a good answer would help me a lot! But if you want me to share the strategies I’ve been designing for this - and the pros and cons I’ve already identified - I can do that soon. In addition, I would like you to clarify the following: 1) are both systems under the control of the same entity (e.g., your company) or not? In other words, does system A consider system B "reliable" and vice versa? 2) It is important to you that when authenticating on system A the user is automatically authenticated on system B or not?

  • @mgibsonbr the 2 systems will be from my company, the system user A will not have access to anything from system B, however, the authentication must be done using the information that will be contained in the system B. The use of this is to allow me to have the freedom to create N user for the system A, control its packages among other things centrally to automated, without running the risk that an intrusion or anything of the kind on system A will affect system B that we will try to make as "invisible" as possible...

  • @mgibsonbr if you want, you can have the freedom to edit my question to inform the pros and cons among other information you have identified in your analysis (if the comments are too short for this) I believe we have a long way to go

  • Have you ever considered the idea of using the OpenId to carry out this process?? Openid site PHP Openid It’s an interesting idea. Of course it all depends on the architecture of your system, and the need. But here’s the hint. Logging into one system, when accessing another it automatically logs into the user.

  • Thanks, but that won’t be necessary: I intend to post as an answer. His case is simpler than mine, where although one of the systems is "master" he also receives logins directly. And one requirement of my client - which for security reasons is now being reviewed - is that "single login" be done, i.e. when authenticating in one service the user should automatically be authenticated in the other. I mean, it’s a little more complicated... P

  • Openid (and Oauth2) are interesting yes, but in the case where both systems are logged in directly. In the case of AP, the "master" system is not directly accessible to the user, only indirectly through the "slave" system. So, although the suggestion is good, I do not believe it applies here...

  • @mgibsonbr Haaaaaa ta.. If the master system is not visible, the applicability of Openid is not valid.. Now I understand.

  • I believe you can implement this as a webservice on system B (they are safe and the user does not even realize that he is authenticating on another system) http://php.net/manual/en/refs.webservice.php

  • The case of @mgibsonbr ao se autenticar em um serviço o usuário deveria automaticamente estar autenticado no outro reminded me of the Google sites, i.e. when you log in to Youtube, you are automatically already logged in to Google+... Anyway, just sneezing. : P

  • 6

    Take a peek at this: Application separate authentication server

  • @Rodrigoborth, I believe what you need can be seen in this answer I just posted a short while ago: CAS

Show 6 more comments

4 answers

9


An "indirect" login is not much different from a "direct" login. The user presents his credentials to system A, system A presents these same credentials to system B, which in turn responds with a "ok" or not. The differences are as follows::

  • It is important that the system A itself authenticates with the system B (so that B knows it is actually communicating with A). The way to do this will depend on your architecture, but a common and secure means is to use SSL/TLS communication between servers, where the A authenticates itself through a "certificate on the client side" (client Certificate).

    I have no experience with PHP, but that question on Soen suggests the use of curl for server-server communication. That post seems to give an overview of the process.

  • Once the servers are authenticated, A can send the credentials received from the user to B normally. However, since this is only done once (on login), it is necessary that a session token be used to keep the user authenticated. Where to manage this token?

    At first, I would say that this is a server A responsibility - manage all client-server communication, including the decision to keep the user logged in for a long time, expire the session after X minutes, scroll down or not when closing the browser, etc. To the server B does not matter the user’s situation, if the trusted server A asked for information from a user to B, it should simply deliver! It doesn’t make much sense the B server (back end) assume for themselves responsibilities that would be the server A (front end)...

    What may be wrong, however, is some vulnerability on the server that prompts you to make incorrect requests to server B. If Mallory stole Alice’s account and introduced herself to A as Alice, A will hand back Alice’s personal information, And there’s nothing B can do about it. What you can do is try to avoid "catastrophic" results, like an SQL Injection on A causes it to send B a request to get data from multiple users at the same time. To prevent this, B must treat A as if it were an ordinary customer - taking the same steps to sanitize the inputs passed by A that he would take in relation to an unreliable, external customer.

    That is, although B at first trusts A, he does not "trust" - so the additional validation adds to "in-depth defense".

  • is a great way to start, if you think about it, I have to do the same treatment on the 2 servers, since if by chance I have an attack on A that makes it fire requests for B, then I have a problem on A and B, I will try to sanitize the weaknesses of this communication on both sides... hackers even miracle to hack a system :/

  • @In addition to using beyond ssl between servers, I advise information to be encrypted also with blowfilsh or something similar, giving two layers of encryption. You can also use Heartbeat mechanisms to know if the communication between system A and B is "alive". The forms are numerous of protection, to be quite honest, only you do not trust anything that part of the customer and does not make silly mistakes will hardly have any breach in your code

  • @brhvitor6 What benefits would a second layer of encryption bring? Remember that it does no good to have confidentiality without authenticity [and integrity] - if SSL fails, you do not know with whom is communicating, so it’s no use the communication being confidential if "at the other end" is the attacker... I even see some advantage if both servers share a symmetric key for example, but still makes room for various types of attack (such as replays). In my opinion it is Overkill, but I’m not a security expert, there might be something I don’t know about.

  • @mgibsonbr Between client and server A no, but between server A and B it would be interesting to have one more layer applied to client data, so server A may not be "sure" if it is "talking" to server B but the data (eg login and password) will be a block of encryption, making it difficult to access the information. About the symmetrical cellars, I don’t know if they would bring great benefits. but Diffie-Hellman is there for it. rs

  • @brhvitor6 I already think exactly the opposite: DH would be useless by itself since it "allows two parts that have no prior knowledge of each share a secret key...". What’s the point of communicating safely with the attacker? Already a symmetric key previously established (ex. manually installed on both servers) would have exactly the effect you said: 'A may not be "sure" if it is "talking" to server B but the data will be a block of encryption'. Anyway, IMHO is still Overkill: there is little reason to "distrust" SSL.

  • 1

    The way you guys are talking, it’s like the guy’s system is gonna carry credit card numbers. As he did not quote in the requests the needs, SSL is great (even more than necessary), putting another "layer" of security would be unnecessary and would only consume more machine resource.

  • 1

    @wryel Exactly what I think! I only disagree that SSL is "even more than necessary", I believe that this is indispensable when it comes to private data. Only server-server communication that can be unprotected - if it occurs exclusively within the company’s intranet (that yes well protected).

  • 1

    Totally according to @mgibsonbr. In fact I did not know how to express myself in the reply, what I wanted to say is that SSL already has an auto security degree, even more than its application needs rs

Show 3 more comments

2

If you don’t have a request Single Sign On, you can use a Web Service SOAP (whose goal is to integrate) with WS-Security running in https.

  • XML and Webservices (Link to specific information) are documented standards and is supported by W3C

  • Your information is protected by https and you can set policies of who can or cannot try to make a login request

  • Any other platform that supports XML can reuse its service (Android, Python, etc ...).

  • The implementation of "how" and "where" will be validating the logon, is to its implementation, can be in bank, LDAP or delegate to another service.

Complementing the @Bacco method in your question, there is a client of mine who uses the cited model. The (extremely simple) logon system is java, but subsystems exist in PHP, . NET, Ruby and Java. In the first call of these subsystems, the token (?token=ABCDEFGHIJK) is passed and through a common usage component, this token is validated and we can identify the user logged in by it.

Additional

Beware of premature optimization, and don’t try to reinvent the wheel for patterns that are already evident that work.

1

The method of sending is the normal POST as you are already accustomed, but we have to think about security, see the following points:

  1. "System and Master" servers should only communicate between they. Infrared personnel can help you set up the firewall (or they themselves can do) so that this communication between systems is not made from another source.
  2. Use of SSL communication in communication between servers (sending Posts between them must be encrypted);
  3. anti-XSS techniques can be used in process, more information here: Cross-site scripting;

I believe that following these 3 steps, you already leave your system safely to perform the necessary authentication.

Success!

0

This system that the user has to access "B" to have access "A" can be done with Curl/php where you can get the values set by the user and sleeve for the system A, as Curl.

Browser other questions tagged php security-guard authentication

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