Specchio production deployment connection as JDBC user (AWS EC2/RDS)

[Eric-git-999]

I have a Specchio deployment which is set up differently to the UZh server, I am running the Glassfish app deployment in an (AWS) EC2 and the MySQL server on a RDS. I can connect to the DB and create campaigns etc. via the Specchio client. As I create new users via the client, these authenticate successfully however permissions are not altered i.e. read_only vs full user access. Also, as the new user creates a new data Campaign, this is assigned (seen in Research Group Members metadata) to the same account as the first user. I have investigated and found how this happens:

The Glassfish deploy requires a JDBC connection pool be established, and to connect to the RDS a username and password must be supplied in this connection pool. The user supplied here must exist in the MySQL specchio.specchio_user table.
I have noted that all further actions from the client are being performed by this user supplied in the JDBC connection pool, and not the client authenticated user.
I have tested altering the JDBC connecting user, and see the new user is performing actions on the database (regardless of the account used to connect from the client). This is a problem, as rather than Campaign ownership being assigned to the authenticated user, it is assigned to the user specified in the JDBC connection pool, and therefore anyone connecting via the web address initialised by this JDBC connection pool assumes the role of that user.

I am hoping someone with AWS knowledge can help figure this out, there is an example of a similar deployment that references utilising ElasticBeanstalk for thier Glassfish deployment, and obtaining user/passwords from AWS environment variables. See:
https://stackoverflow.com/questions/27351833/how-to-configure-a-glassfish-instance-running-on-aws-elasticbeanstalk-docker

Ideally, the client-authenticated user will perform actions on the DB rather than the user provided to initialise the JDBC connection pool. The issue seems to arise once the Glassfish app deployment and MySQL DB are initialised on seperate instances.