On Feb 12, 2016 2:35 PM, "Dougherty, Gregory T., M.S." < dougherty.greg...@mayo.edu> wrote: > > You are correct, I¹m trying to authorize the web app, not the user.
I am going to start all the way back here and suggest that you abandon this approach of authenticating a web "app". This is unconventional by all standards and you will end up with a security hole(s). Users authenticate to web apps, nothing further. The web app itself can also authenticate to the database separate from any user....BUT... the web app still has a "user name". Your problem is that someone is giving you impossible to meet security requirements, which results in you wanting to mess with application URLs and the other stuff you mentioned. Secret: even large organizations have some form of clear text passwords, but who has access to these is strictly controlled. > > Goal: I am trying to come up with a way for a Tomcat app to securely store > and retrieve the password it needs to access a DB. > We have given you some options to deal with this. It seems as though the sys admins either can't or don't want to help you establish more of an Enterprise architecture, which would solve a lot of your issues. > My definition of ³secure² includes ³there exist no files with an > unencrypted copy of the password². IIUC, JNDI fails this test. > > My requirements include that all web app components are checked in to a > source control system that malicious users can have read access to. Are you in control of the source control system? You know, you can assign roles to users for certain repositories and restrict access to your code repo. If you have developers working at Mayo who are malicious, get rid of them. > Solution: > 1: Trusted user creates public:private key pair (1), distributes public key > 2: Web app developer creates pubic:private key pair (2), distributes > public key > 3: Web app developer encrypted password with private key 2, then public > key 1, stores with web app > 4: Web app calls decryption jar that¹s in tomcat/lib, passing in the > encrypted password from step 3 > 5: Decryption code determines which app called it, pulls the public key > (3) saved for that app > 6: Decryption code decrypts with private key 1, public key 3, and returns > the unencrypted password. > > So long as 1: Trusted user can store private key where it¹s secure, but > accessible to decryption code, and 2: Can correctly determine the calling > app, I believe this setup is secure. > > We log who uploads the web apps, so if user X uploads a bogus ³User Y > App², we can deal with that. > -- Developers should never get to deploy anything to production servers. In fact, you should have different passwords for different deployment realms. >From my perspective, you (or someone else is telling you to do this) are trying to bypass as much security for the appearance of security simply because of the Tomcat environment you have to work with. I think we all want you to succeed here, but the approach you're leaning towards isn't going to work. > Gregory Dougherty > Sr. Analyst/Programmer | Information Technology > Information Technology > (507) 284-8493 | dougherty.greg...@mayo.edu > > > > > > > > On 2/12/16, 2:00 PM, "Leo Donahue" <donahu...@gmail.com> wrote: > > >On Feb 11, 2016 4:56 PM, "Dougherty, Gregory T., M.S." < > >dougherty.greg...@mayo.edu> wrote: > >> > >> I would like to have a jar file in tomcat/lib that can be called from > >>any > >of the running web apps. I need for the code in the jar to behave > >differently depending on which web app called it. > > > >I would agree with what the others are saying here. It seems you are > >trying to authorize an entire web app instead of authoring the user of the > >web app. > > > >If the jar simply needs to take action based on a role of some kind, then > >could you not tie in a ldap user with appropriate role? > > > >Leo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
