anchor.diff:  TransportClient client = new TransportClient(ImmutableSettings.builder()
       .put("cluster.name", "myClusterName")
       .put("shield.user", "test_user:changeme")
  -    .put("shield.ssl.truststore.path", "/path/to/truststore.jks")
  +    .put("shield.ssl.truststore.path", "/path/to/truststore.jks") (1)
       .put("shield.ssl.truststore.password", "password")
       .put("shield.transport.ssl", "true"))
       .addTransportAddress(new InetSocketTransportAddress("localhost", 9300))
       .addTransportAddress(new InetSocketTransportAddress("localhost", 9301));
   ------------------------------------------------------------------------------------------------------
  -NOTE: The `truststore.jks` truststore needs to contain the certificate of the CA that has signed the Elasticsearch nodes'
  -certificates. If you are using a public CA that is already trusted by the Java runtime, then you can omit
  -`shield.ssl.truststore.path` and `shield.ssl.truststore.password`.
  -
  -In the above code snippets, we set up a _Transport Client_ and configured the authentication token globally. Meaning,
  -that every request executed with this client will include this token in its headers.
  -
  -The global configuration of the token *must be* set to some user with the privileges in the default `transport_client`
  -role, as described earlier. The global authentication token may also be overridden by adding a `Authorization` header on
  -each request. This is useful when an application uses multiple users to access Elasticsearch via the same client. When
  -operating in this mode, it is best to set the global token to a user that only has the `transport_client` role. The
  -following example directly sets the authentication token on the request when executing a search.
  -
  -[source,java]
  -------------------------------------------------------------------------------------------------------
  -import org.elasticsearch.shield.authc.support.SecuredString;
  -import org.elasticsearch.client.transport.TransportClient;
  -
  -import static org.elasticsearch.shield.authc.support.UsernamePasswordToken.basicAuthHeaderValue;
  -...
  -
  -String token = basicAuthHeaderValue("test_user", new SecuredString("changeme".toCharArray()));
  -TransportClient client = new TransportClient(ImmutableSettings.builder()
  -    .put("shield.user", "transport_client_user:changeme")
  -    ...
  -    .addTransportAddress(new InetSocketTransportAddress("localhost", 9300))
  -    .addTransportAddress(new InetSocketTransportAddress("localhost", 9301));
  -
  -client.prepareSearch().putHeader("Authorization", token).get();
  -------------------------------------------------------------------------------------------------------
  -
  -[float]
  -===== Anonymous Access
  -
  -added[1.1.0]
  -
  -If Shield enables <<anonymous-access,anonymous access>>, the `shield.user` setting may be dropped and all requests will
  -be executed under the anonymous user (with the exception of the requests on which the `Authorization` header is explicitly
  -set, as shown above). For this to work, please make sure the anonymous user is configured with sufficient roles that have
  -the same privileges as described <<java-transport-client-role,above>>.
  -
  +(1) The `truststore.jks` truststore must contain the certificate of the CA that signed the Elasticsearch node certificates. 
  +
  +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`.
  +
  +[float]
  +[[connecting-anonymously]]
  +===== Connecting Anonymously added[1.1.0]
  +
  +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>>.
   
   [float]
   [[shield-client]]
   ==== Shield Client
   
  -Shield exposes its own API to the user which is accessible by the `ShieldClient` class. The purpose of this API
  - is to manage all Shield related aspects. While at the moment it only exposes an operation for clearing up the
  - realm caches, the plan is to extend this API in the future.
  -
  -`ShieldClient` is a wrapper around the existing clients (any client class implementing `org.elasticsearch.client.Client`.
  -
  - The following example shows how one can clear up Shield's realm caches using the `ShieldClient`:
  +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`).
  +
  +The following example shows how you can clear Shield's realm caches using `ShieldClient`:
   
   [source,java]
   ------------------------------------------------------------------------------------------------------
  
positive.code: 
   </project>
  --------------------------------------------------------------
  
  [float]
  ===== Gradle Example
  
  If you are using Gradle, then you will need to add the dependencies to your `build.gradle` file:
  
  [source,groovy]
  --------------------------------------------------------------
  repositories {
  
negative.code: === Using Elasticsearch Java Clients with Shield
  
  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.
  
  NOTE: Using the Java Node Client with Shield is not recommended or supported.
  
  [float]
  [[transport-client]]
  ==== Configuring the Transport Client to work with Shield
  
  To use the transport client with Shield, you need to:
  
  [[java-transport-client-role]]
  . 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/elasticsearch-shield/2.0.0/elasticsearch-shield-2.0.0.jar[Elasticsearch Maven repository].
  +
  If you are using Maven, you need to add the Shield JAR file as a dependency in your project's `pom.xml` file:
  +
  [source,xml]
  --------------------------------------------------------------
  <project ...>
  