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
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 service
- The key management web service
- A Kerberos (ticket granting ticket, TGT) server
My understanding is that:
- The client (somehow) obtains a TGT from Kerberos
- The 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 TGT
- The key management web service is then reconfigured to take this TGT and ping the Kerberos server with an "is this TGT valid?"-type request
- The Kerberos server responds and says "yes" (or "no") and honors the request for the DB password, sending it back to the client in the response
So 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).