On 19-Jan-09, at 15:27 , Wendy Smoak wrote:
On the master, we have users and roles, but I really don't want to
drag Redback into the build agent and require a database.
Yeah, this is an authentication and identity, not role based access
control, so you shouldn't need any of that.
Starting out with a simple shared secret sounds good -- even if it's
in plain text in the client config, I'm already planning to use
https:// urls so it wouldn't be going in plain text over the wire.
The simplest working option is often the best, since the "attack
vectors" are clearer.
I'm not familiar enough with client ssl certs. How would this work?
Since the Master is a client from the Agent's perspective, you create
a certificate for the Master. You then provide the public portion to
the Agent, which then uses pretty standard SSL stuff to validate the
identity of the incoming client (Master). In other words, it's
identical to how certificate-based SSH works.
(My experience runs to chasing down missing intermediate and
self-signed certificates and installing them with keytool so a simple
https:// connection will work.)
Actually, you don't care about trust chains. You're not validating a
chain of trust here, because the agent has been provided with a "known
hosts" copy of the public key of the Master. So as long as the Master
can authenticate consistently against that public key (ie, validate
that it has the private key for that public key through cryptographic
means, so as not to actually transmit the private key) then it doesn't
matter who generated the cert. Your chain of trust is the off-line
configuration of the two machines. Chains of trust are necessary if I
want to talk to a machine over which I don't have control - I need to
be able to trust it. If I control both machines, then I can install
something together on both that confirm they're the right machines.
It's a lot like a shared secret, but you don't have to pass the actual
secrets to each other.
Is it something that would be available by configuring the server
and client JVMs, outside of
anything we'd have to do in Continuum itself?
Continuum would probably have to implement it on a filter for the
agent urls, but I think there are standard patterns, and I believe all
the algorithms and APIs necessary are present in the JVM. I can do
some digging, but start with the shared secret. Frankly, since
there's only one master for a given agent (I presume) and you're not
sending clear-text, cert-authentication is probably a bit of
overkill. I'll check with a security consultant that's a friend of
mine and see if he agrees. He wrote the main paper about CSRF
attacks, so he's no slouch in this arena.
cheers,
Christian.
Christian E. Gruber - President / Senior Consultant
email: [email protected]
Isráfíl Consulting Services Corporation
mobile: +1 (289) 221-9839
"Keenness of understanding is due to keenness of vision..."
phone: +1 (905) 640-1119
