My approach is correct?
Probably not.
Security is not just about comparing passwords in the database (authentication).
Such an important point involves the level of access of users (authorization), where each system usually has its rules.
I would say that authenticating the user in a new application without taking into account the security rules and business rules of existing applications is a direct breach of security.
The traditional approach to implementing integration, whether using SOA or any other integration model, is to delegate calls to existing systems so that they execute the appropriate business rules and return the correct values.
How to do this in practice is another story.
One way is to use Web Services, where each application makes available the endpoints necessary and the main application triggers them according to the information she needs to get. Web Services can be implemented with SOAP protocol or more lightly with REST.
2.
Another way, if the applications are modular, is to include modules (Jars, for example) of the other applications within your integration application and then directly execute the methods of the Apis. The downside is that your application needs to include all others within it and update the versions as needed, and provide the necessary configuration for other applications to run. It sounds complicated, but I’ve seen it work in practice, although I don’t consider it ideal.
From what I understand of your question, each application has its own authentication method, that is, each one stores the user information in its own way. I believe that the first step, more important and more painful, is to centralize this information so that all applications make use of a common module of user registration.
Each application can still run the authorization independently, but without a unified registry for authentication you will get many headaches when users try to access resources from different applications. The first (and most common) problem is the timing of the registration information.
Do you have access to the encryption used in other software? 'Cause that’s basically it, you’d have to encrypt and compare it to what’s in the database.
– Geferson
Yes, I have access to the other encryption. I think it will be very hardcode.
– Ricardo Farias
Recently I went through something similar, apparently you just do the encryption with what the user informs on the screen and compare with what is in the bank.
– Geferson
Your approach is incorrect, at least from my point of view. Using databases to integrate applications exposes something that should be encapsulated. An application must own the database and any access, especially regarding access control, must be done through an API, otherwise you’ll have to duplicate security rules and my experience says this is 99% likely to go wrong. It may be boring, but ideally each application would have its own web service and then you make your web service integration upon it.
– utluiz
@utluiz, then the SOAP protocol would also be incorrect, taking into account the security?
– Ricardo Farias
@Ricardofarias SOAP is an object transfer protocol. You must be talking about SOA. I have never heard that it is necessary or recommended in SOA that several applications use the same basis. Usually you use a middleware for communication where the various applications talk via messages, for example using JMS.
– utluiz
And if there are many applications, you can use an ESB (Enterprise bus service) for routing messages between different applications.
– utluiz