Merge pull request #17 from pedroigor/master

Changes to service topics.

SUMMARY.adoc

@@ -34,7 +34,6 @@
  ... link:topics/service/authorization/whatis-obtain-aat.adoc[What is a AAT and How to Obtain It]
  ... link:topics/service/authorization/authorization-api-aapi.adoc[Requesting Authorization Data and Token]
  .. link:topics/service/entitlement/entitlement-api.adoc[Entitlement API]
- ... link:topics/service/entitlement/whatis-obtain-eat.adoc[What is a EAT and How to Obtain It]
  ... link:topics/service/entitlement/entitlement-api-aapi.adoc[Requesting Entitlements]
  .. link:topics/service/protection/token-introspection.adoc[Introspecting a Requesting Party Token]
  .. link:topics/service/client-api.adoc[Authorization Client Java API]

topics/service/authorization/whatis-obtain-aat.adoc

@@ -1,6 +1,12 @@
 == What is a AAT and How to Obtain it ?
 
-An *Authorization API Token* or *AAT* is a special OAuth2 Access Token with the scope *uma_authorization*.
+An *Authorization API Token* or *AAT* is a special OAuth2 Access Token with the scope *uma_authorization*. When you create an user, {{book.project.name}} automatically
+assigns a role _uma_authorization_ to the user. The _uma_authorization_ role is a _default realm role_ as you can see from this page.
+
+.Default Role uma_authorization
+image:../../../images/service/rs-uma-authorization-role.png[alt="Default Role uma_authorization "]
+
+An AAT means that a client application is allowed to query the server for user permissions.
 
 Client applications can obtain an AAT from {{book.project.name}} just like any other OAuth2 Access Token. Usually, client applications obtain AATs after the user is successfully
 authenticated in {{book.project.name}}. By default the _authorizaton_code_ grant type is used to authenticate users and issue an OAuth2 Access Token to the client application acting on their behalf.
@@ -29,8 +35,3 @@ As a result, you will get the following response from the server:
   "session_state": "3cad2afc-855b-47b7-8e4d-a21c66e312fb"
 }
 ```
-
-== About the uma_authorization scope
-
-The *uma_authorization* scope can be created just like any other _realm role_. Or even as a _client role_. Once you created it, just grant this role to
-the users of your realm.

topics/service/entitlement/entitlement-api-aapi.adoc

@@ -14,12 +14,12 @@ The easiest way to obtain entitlements for a specific user is using an HTTP GET
 
 ```bash
 curl -X GET \
-    -H "Authorization: Bearer ${EAT}" \
+    -H "Authorization: Bearer ${access_token}" \
     "http://localhost:8080/auth/realms/hello-world-authz/authz/entitlement/${resource_server_id}"
 ```
 
 [NOTE]
-When asking for entitlements using this endpoint, you need to provide the EAT (as a bearer token) representing user's identity and his consent to access authorization data on his behalf.
+When asking for entitlements using this endpoint, you need to provide the access_token (as a bearer token) representing user's identity and his consent to access authorization data on his behalf.
 
 Where *${resource_server_id}* is the *client_id* registered with the client application acting as a resource server.
 
@@ -39,7 +39,7 @@ authorization policies associated with all resources managed by the resource ser
 The entitlements endpoint also allows you to obtain user's entitlements for a set of one or more resources.
 
 ```bash
-curl -X POST -H "Authorization: Bearer ${EAT}" -d '{
+curl -X POST -H "Authorization: Bearer ${access_token}" -d '{
     "permissions" : [
         {
             "resource_set_name" : "Hello World Resource"
@@ -62,7 +62,7 @@ Unlike the GET version, the server is going to respond with a RPT holding the pe
 When asking for entitlements you can also specify the scopes you want to have access:
 
 ```bash
-curl -X POST -H "Authorization: Bearer ${EAT}" -d '{
+curl -X POST -H "Authorization: Bearer ${access_token}" -d '{
     "permissions" : [
         {
             "resource_set_name" : "Hello World Resource",
@@ -77,7 +77,7 @@ curl -X POST -H "Authorization: Bearer ${EAT}" -d '{
 === Requesting Party Token or RPT
 
 A RPT is basically a https://tools.ietf.org/html/rfc7519[JSON Web Token (JWT)] digitally signed using https://www.rfc-editor.org/rfc/rfc7515.txt[JSON Web Signature (JWS)].
-The token is built based on the EAT sent by the client during the authorization process.
+The token is built based on the access_token sent by the client during the authorization process.
 
 When you decode a RPT you will see something like that:
 

topics/service/entitlement/entitlement-api.adoc

@@ -7,6 +7,3 @@ Unlike the _Authorization API_, the Entitlement API is not UMA-compliant and don
 
 The purpose of this API is provide a more lightweight API for obtaining authorization data, where the client in possession of a valid
 OAuth2 Access Token is able to obtain the necessary authorization data on behalf of their users.
-
-Any client application can access the Entitlement API endpoint, which requires a special OAuth2 access token called *Entitlement API Token* or *EAT*.
-