Service to synchronize Ontoportal users with other services (servers)

[rasmi-aw]

Hello i finished working on a Springboot based service (a job that run every hour to fetch the new list of users in your running appliance) the goal was to make all other services use "Industryportal authentication system "to check if this user is already registered and create a new account for him in the new service with the same information.

It stores the users in SQL DB.
please check the code from here SouslesensUserManager

[rasmi-aw]

@syphax-bouazzouni Check that please, open for your suggestions.

[syphax-bouazzouni]

What do you mean by other services ? Can you give us details on how (and why) you use it at Industry portal.

The idea of making an "Industryportal authentication system" may be a good idea, it will be a sort of LDAP system, where a set of systems (services) will a use a centrilize hub for getting users information (for SSO or other).

But here are some of the remarks that I have on your implementation

If I understood well your service is fetching all the users of an Ontoportal instance and save them on the Mysql Database, which others services(applications) will access/connect to get user information (like the figure below).

But the problem here , I think is the duplication of data. Ontoportal doest already contains those information. The best would be that the apps directly connect to ontoportal, though it sure that the problem will became that all those apps will have now duplicate code to connect to ontoportal.

So what I propose is more than creating a DB, is to transform your code to be a reusable java client (a package) to make our java services easily connectable to an ontoportal instance (same as ontologies_api_ruby_client but in java).

In summary it would be something like this

In term of requirements your app needs to implements those functions:

• getUsers() => return all the users
• logInUser() => return a User with its apikey and all its information
• createUser()

You can add others if needed (like removing a User , getting ontologies, getting .... ), here the idea is to have a reusable package over all our java applications (services) to access ontoportal informations

I hope I'm not off topic and that my remarks helps.

[syphax-bouazzouni]

Speaking about an ontoportal_java_client, I found by chance this https://github.com/palexander/ontologies_api_java_client, which is exactly what i spocked about above (but i don't know if it still working)

[jonquet]

Personally, I would enable SSO with GitHub in the main OntoPortal branch which means that on any portal, only a GitHub account will be require to connect to any portal (even if each portal maintains its list of users, the credentials will come from GitHub).
This will enable the connexion for term proposal and other issues to the GitHub repos of the ontologies. CC @jvendetti

[rasmi-aw]

@syphax-bouazzouni The reason why i'm using mysql DB and duplicating db, is that the new services were developed by different parties in different languages, if we want to develop the next services in Java i can transofrt the new code into a JAVA library and push it in Maven central to manage users in your portal through Java, if you need that we can collaborate.

[graybeal]

I also am not clear on the goal to make all other services use "Industryportal authentication system "to check if this user is already registered and create a new account for him in the new service with the same information. Does this mean all other OntoPortal services in the local installation, or all other OntoPortal services anywhere, or all other services of any type anywhere?

In any case, there is a significant security consideration here. The BioPortal user database contains all the API keys. If those keys are compromised, the entire installation is compromised (because people with admin privileges are in the database too). (I'm not sure where passwords are managed, so I'll just talk about API keys.) Making a copy of all that information more than doubles your security exposure, because now there are two sets of software that have to be secure, and the transmissions between them have to be secure.

Even just adding more external services, like logInUser() above, would open up significant possibilities for attacking the system.

So far BioPortal hasn't had many attacks (at Stanford it's behind some heavy-duty firewalls) but it has had people spam it (a LOT at various times) with fake data and users. And if there are dozens of BioPortals out there, it will become a more significant target for bad actors. (And commercial users are very sensitive to security risks.) So if we're talking about something for adoption in all the OntoPortals, I highly recommend sticking with industry-standard distributed authentication approaches, so we don't have to get our hands dirty with properly understanding security. (Would highly recommend KeyCloak in that regard.)