Hi Eoghan,
I'm just going to clear up a few points below.
Glynn, Eoghan wrote:
Just configure a truststore (via the SSLClientPolicy TrustStore element)
that includes only the CAs that the client trusts. Isn't that the basis
of all cert-based auth?
Cert-based Auth means that you merely trust the key-id association
provided by a trusted CA. It doesn't mean you trust the id. George Bush
may have a driver's license signed from the State of Texas (CA), and
I'll accept that that he is George, his picture matches his face, and
that Texas certifies him to drive. However, I don't have trust him with
my car. The guy can't even navigate a coffee table. :)
There may also be cases in which, say, for some authenticated
endpoints, you are willing to disclose a password (it has a key
signed by Zeus), whereas others you don't. So yeah, some details
into the security features of the target could definitely be of use.
Now I'm confused. When would you accept a endpoint's "strong auth" creds
(i.e. the signed cert provided in the TLS handshake) and possibly expose
your own cert (if the endpoint requests it during the TLS handshake),
but not be prepared to expose your own "weak auth" creds (i.e. Basic
auth username/passwd) to that endpoint?
With TLS you are "exposing" a piece of seemingly public information,
which is *not*, in the general case, sensitive information. A
certificate contains a name (DN) of the Certificate Authority (CA), and
the DN of the principal in question, and the *public* key of that
principal. Each end can verify signatures, and authenticate each other
without exposing private keys, which is the sensitive information. So,
exposing your cert is merely like saying, "Hi, I'm Bob" in a crowed room.
If the endpoint isn't worthy of
trust, why would it have a cert signed by a CA we trust.
We don't always have control over what CA's do with their signatures.
For example, a lot of bank server certificates are signed by Verisign,
but you don't have to trust them all. That is why we have certificate
cross-certification with certificate constraints, but because of the
complexity, nobody really uses those. But, still, even so, that only
gets you half-way there.
Or is it a question of degrees of trust? But if so, surely accepting the
endpoint's cert is the bigger leap of faith than handing out your Basic
auth username/passwd?
Before you hand out a sensitive username/password, you authenticate the
server through TLS with the analysis of the certification chain, and
also the quality of the "tunnel" parameters: encryption algorithm, key
length. Then separately you evaluate the trust in the principal
identified by the certificate authentication. In this case you want to
trust the principal on the other end before you hand it sensitive
information.
Well the trust policy in effect is encoded in the truststore, which is
in the client's domain and therefore under their control. So why
replicate this checking in the runtime?
The trust store only authenticates who is "speaking", so that there is
no (less probability of) impersonation. But then you still must make a
trust decision on whether to give that principal what it asks for.
[snip]
That pretty much sums it up. And my (admittedly layperson's, and perhaps
simplistic) notion was the following would give us all or most of what
we need:
1. Extend AuthorizationPolicy to allow multiple per-realm/targetURI
username/password pairs to be configured.
This could be an acceptable approach, but shouldn't be the only approach
as you allude to in the following.
2. Allow (optional) programmatic retrieval of creds via callback into
the app.
This is probably the most viable solution as it may allow for prompting
a user for authentication information, or going off to some other
trusted source for the information, a protected file, trusted password
service, etc, which is solely at the discretion of the deployment.
3. Ensure the http client (either java.net.HttpUrlConnection or commons
HTTPClient) can handle the 401 properly and associate it with the
appropriate creds.
This is a must for HTTP/S protocol, as this is the only way to get the
realm information. That part of the protocol is required, so it must be
supported when it comes about, i.e. 401.
4. Advise users that Basic auth should only be used over HTTPS, unless
they don't care about creds being stolen or have reason to trust HTTP
(e.g. the VPN case).
Agreed.
5. Require that users take responsibility for configuring their trust
policies directly via their truststore.
This is always the case. I don't know how to *require* them to do so,
but we should not preclude them from doing the thing that is right for
them. The purpose is to give them to tools to do a job that is suitable
and is able to support the security scrutiny, especially when it is
mandated by certain US laws, like HIPAA, FERPA, Sarbanes-Oxley and the
privacy laws of many European nations in the users' endeavors, and maybe
even write a value-added Common Criteria Protection Profile, which may
give their services some leverage in the markets requiring security.
So, I believe this effort would take a number of tasks.
1. Building the callback mechanism.
2. Interface Framework to assign the call back mechanism programatically.
3. Configuration to use a particular callback mechanism.
4. Configuration of realm/username/password combinations.
(My initial reaction is that #4 is configuration of specialized
default 3.)
Cheers,
-Polar
Cheers,
Eoghan
