We have half-implemented proper key management at our dev shop. We have a SOAP web service (the key management web service) that can be used to retrieve passwords for other systems. So for instance, I might make a request to this service for the password to, say, a production PostgreSQL DB. I hit the web service with my AD credentials, and it determines whether I'm authorized to receive the DB password or not. If I am, then it is sent in the response. I can then use this service across all other software components instead of storing the DB password in a static config file (like Tomcat's context.xml, etc.).The problem, of course, is that with an automated process the AD credentials passed into the web service need to be stored somewhere. So, to obtain the password to a DB (or any other secured resource), one simply needs to gain access to what is used to store the AD credentials, and can then submit them to this web service, which will then authenticate/authorize them, and return the password for the requested resource. Classic key management problem.Hence, I'm trying to figure out a way to protect the AD credentials used to access the service. Someone mentioned Kerberos to me and I've began to dig in a little bit.My understanding is that, with Kerberos, there would be 3 components:A client of the key management web serviceThe key management web serviceA Kerberos (ticket granting ticket, TGT) serverMy understanding is that:The client (somehow) obtains a TGT from KerberosThe client then issues a a request for some resource, say, a DB, to the key management web service, but does not supply any AD credentials, but instead, supplies the TGTThe key management web service is then reconfigured to take this TGT and ping the Kerberos server with an is this TGT valid?-type requestThe Kerberos server responds and says yes (or no) and honors the request for the DB password, sending it back to the client in the responseSo first, if anything about my understanding is incorrect, please begin by correcting me!Assuming I'm more-or-less correct, then I have a few questions about this setup:How would the client first obtain the TGT from Kerberos?Do Kerberos TGT's have expiration dates? How would then client re-request a new TGT?Does the key management web service need to implement any specific TCP protocol to speak with Kerberos, or does HTTP suffice? If Kerberos has its own protocol, are there any Java libs that implement it? (I know its easy to Google java kerberos but not sure what specifically to be looking for because again, I'm not confident I understand the architecture here).
Kerberos for key management?
java;passwords