Shield supports the Java http://www.elastic.co/guide/en/elasticsearch/client/java-api/current/transport-client.html[transport client] for Elasticsearch. The transport client uses the same transport protocol that the cluster nodes use for inter-node communication. It is very efficient as it does not have to marshall and unmarshall JSON requests like a typical REST client.
. Configure a user with the privileges required to start the transport client. A default
`transport_client` role is defined in `roles.yml` that grants the `cluster:monitor/nodes/info` cluster permission. The transport client uses the node info API to fetch information about the nodes in the cluster. If the client is configured to use sniffing, you need to add the
`cluster:monitor/state` cluster permission to the `transport_client` role.
. Add the Shield JAR file (`elasticsearch-shield-2.0.0.jar`) to your CLASSPATH. You can download the Shield distribution and extract the JAR file manually or you can get it from the http://maven.elasticsearch.org/releases/org/elasticsearch/plugin/elasticsearch-shield/2.0.0/elasticsearch-shield-2.0.0.jar[Elasticsearch Maven repository].
. Set up the transport client. At a minimum, you must configure `shield.user` to include the name and password of your transport client user in your requests. The following snippet configures the user credentials globally--every request submitted with this client includes the `transport_client_user` credentials in its headers.
WARNING: If you configure a transport client without SSL, passwords are sent in plaintext.
+
You can also add an `Authorization` header to each request. If you've configured global authorization credentials, the `Authorization` header overrides the global authentication credentials. This is useful when an application has multiple users who access Elasticsearch using the same client. You can set the global token to a user that only has the `transport_client` role, and add the `transport_client` role to the individual users.
+
For example, the following snippet adds the `Authorization` header to a search request:
.. Configure the client's keystore path and password. Client authentication requires every
client to have a certification signed by a trusted CA.
+
NOTE: Client authentication is enabled by default. For information about disabling client authentication, see <<disabling-client-auth, Disabling Client Authentication>>.
If you want to disable client authentication, you can use a client-specific transport protocol. For more information, <<separating-node-client-traffic, Separating Node to Node and Client Traffic>>.
If you are not using client authentication and sign the Elasticsearch node certificates with your own CA, you need to set the truststore path and password in the client configuration:
NOTE: If you are using a public CA that is already trusted by the Java runtime, you to not need to set the `shield.ssl.truststore.path` and `shield.ssl.truststore.password`.
To enable the transport client to connect anonymously, you must assign the anonymous user the privileges defined in the <<java-transport-client-role,transport_client>> role. Anonymous access must also be enabled, of course. For more information, see <<anonymous-access,Enabling Anonymous Access>>.
Shield exposes its own API through the `ShieldClient` class. At the moment, this API only exposes one operation, for clearing the realm caches. `ShieldClient` is a wrapper around the existing clients (any client class implementing `org.elasticsearch.client.Client`).
