anchor.diff:  
   What happens first is that the authentication policy is applied and a login dialog is then displayed:
   
  -![ExampleImage_35](images/35.png)
  +image::images/35.png[ExampleImage_35]
   
   Enter the username and password (user1/password) that we defined when we created the authentication policy to access the API. The fact that you are seeing this dialog confirms that you are accessing the managed API and are not accessing the API directly.
   
  
positive.code: 
  To configure the API, we’ll first create a plan to contain the policies that we want applied by the API Gateway at runtime when requests to the API are made. To create a new plan, select the “Plans” tab. We’ll create a “gold” plan:
  
  ![ExampleImage_11](images/11.png)
  
  Once the plan is created, we will add policies to it:
  
  ![ExampleImage_12](images/12.png)
  
  apiman provides several OOTB policies/plans. Since we want to be able to demonstrate a policy being applied, we’ll select a Rate Limiting Policy, and set its limit to a very low level. If our API receives more than 10 requests in a day/month, the policy should block all subsequent requests. So much for a “gold” level of API!
  
  ![ExampleImage_13](images/13.png)
  
  After we create the policy and add it to the plan, we have to lock the plan:
  
  ![ExampleImage_14](images/14.png)
  
  And, here is the finished, and locked plan:
  
  ![ExampleImage_15](images/15.png)
  
  At this point, additional plans can be defined for the API. We’ll also create a “silver” plan, that will offer a lower level of API (i.e., a request rate limit lower than 10 per day/month) than the gold plan. Since the process to create this silver plan is identical to that of the gold plan, we’ll skip the screenshots.
  
  Now that the two plans are complete and locked, it’s time to define the API.
  
  ![ExampleImage_16](images/15.png)
  
  We’ll give the API an appropriate name, so that providers and consumers alike will be able to run a query in the API Manager to find it.
  
  ![ExampleImage_17](images/17.png)
  
  After the API is defined, we have to define its implementation. In the context of the API Manager, the API Endpoint is the API’s direct URL. Remember that the API Gateway will act as a proxy for the API, so it must know the API’s actual URL. In the case of our example API, the URL is:  +++<u>+++http://localhost:8080/apiman-echo+++</u>+++
  
  ![ExampleImage_18](images/18.png)
  
  The plans tab shows which plans are available to be applied to the API:
  
  ![ExampleImage_19](images/19.png)
  
  Let’s make our API more secure by adding an authentication policy that will require users to login before they can access the API. Select the Policies tab, and then define a simple authentication policy. Remember the user name and password that you define here as we’ll need them later on when send requests to the API.
  
  ![ExampleImage_20](images/20.png)
  
  After the authentication policy is added, we can publish the API to the API Gateway:
  
  ![ExampleImage_21](images/21.png)
  
  And, here it is, the published API:
  
  ![ExampleImage_22](images/22.png)
  
  OK, that finishes the definition of the API provider organization and the publication of the API.
  
  
negative.code: 
  This page will be displayed:
  
  image::images/3.png[ExampleImage_3]
  
  When you select the Administration Console selection, you will be prompted for the username and password:
  
  image::images/4a.png[ExampleImage_4a]
  
  Enter the username and password for the user that you defined (for this example, we used the very unimaginative and insecure username “admin”) and you will brought to the WildFly Server Administration Console:
  
  image::images/4.png[ExampleImage_4]
  
  If you then select the “Deployments” tab at the top of the page, you’ll see the applications deployed to the server. This is where you should see the apiman deployments for the APIs, Gateway, and Management UI:
  
  image::images/5.png[ExampleImage_5]
  
  If you don’t see the apiman deployments, don’t panic, but something went wrong with the installation. The most common reason for the apiman deployments to be missing is that you unzipped the apiman overlay .zip file into a different directory from the WildFly server. Remember, that the reason that the overlay file is named “overlay” is that it must be unzipped over an installed WildFly server. You can confirm that this is what happened by looking in the WildFly server’s deployment directory here:  wildfly-10.0.0.Final/standalone/deployments
  
  