Fix typos in Authorization Services

authorization_services/topics/auth-services-architecture.adoc

@@ -65,7 +65,7 @@ image:images/policy-mgmt-process.png[alt="Permission and Policy Management Overv
 
 Policies define the conditions that must be satisfied to access or perform operations on something (resource or scope), but they are not tied to what they are protecting. They are generic and can be reused to build permissions or even more complex policies.
 
-For instance,to allow access to a group of resources only for users granted with a role "User Premium,"" you can use RBAC (Role-based Access Control).
+For instance,to allow access to a group of resources only for users granted with a role "User Premium", you can use RBAC (Role-based Access Control).
 
 {project_name} provides a few built-in policy types (and their respective policy providers) covering the most common access control mechanisms. You can even create policies based on rules written using JavaScript or JBoss Drools.
 
@@ -93,7 +93,7 @@ Each of these services provides a specific API covering the different steps invo
 
 === Protection API
 
-The *Protection API* is a https://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol[UMA-compliant] endpoint providing a small set of operations
+The *Protection API* is a https://docs.kantarainitiative.org/uma/rec-uma-core.html[UMA-compliant] endpoint providing a small set of operations
 for resource servers to help them manage their resources and scopes. Only resource servers are allowed to access this API, which also requires a
 *uma_protection* scope.
 
@@ -117,7 +117,7 @@ For more information, see <<_service_protection_api, Protection API>>.
 
 === Authorization API
 
-The Authorization API is also a https://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol[UMA-compliant] endpoint providing a single operation that exchanges an Access Token and <<_overview_terminology_permission_ticket, Permission Ticket>> with a Requesting Party Token (RPT).
+The Authorization API is also a https://docs.kantarainitiative.org/uma/rec-uma-core.html[UMA-compliant] endpoint providing a single operation that exchanges an Access Token and <<_overview_terminology_permission_ticket, Permission Ticket>> with a Requesting Party Token (RPT).
 
 The RPT contains all permissions granted to a client and can be used to call a resource server to get access to its protected resources.
 

authorization_services/topics/auth-services-terminology.adoc

@@ -66,12 +66,12 @@ policy providers, and you can create your own policy types to support your speci
 [[_overview_terminology_permission_ticket]]
 == Permission Ticket
 
-A permission ticket is a special type of token defined by the https://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol[OAuth2's User-Managed Access (UMA) Profile] specification that provides an opaque structure whose form is determined by the authorization server. This
+A permission ticket is a special type of token defined by the https://docs.kantarainitiative.org/uma/rec-uma-core.html[OAuth2's User-Managed Access (UMA) Profile] specification that provides an opaque structure whose form is determined by the authorization server. This
 structure represents the resources and/or scopes being requested by a client as well as the policies that must be applied to a request for authorization data (requesting party token [RPT]).
 
 In UMA, permission tickets are crucial to support person-to-person sharing and also person-to-organization sharing. Using permission tickets for authorization workflows enables a range of scenarios from simple to complex, where resource owners and resource servers have complete control over their resources based on fine-grained policies that govern the access to these resources.
 
 In the UMA workflow, permission tickets are issued by the authorization server to a resource server, which returns the permission ticket to the client trying to access a protected resource. Once the client receives the ticket, it can make a request for an RPT (a final token holding authorization data) by sending the ticket back to the authorization server.
 
-For more information on permission tickets, see <<_service_authorization_api, Authorization API>> and the https://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol[UMA] specification.
+For more information on permission tickets, see <<_service_authorization_api, Authorization API>> and the https://docs.kantarainitiative.org/uma/rec-uma-core.html[UMA] specification.
 

authorization_services/topics/enforcer-keycloak-enforcement-filter.adoc

@@ -114,8 +114,9 @@ Currently a very basic logic for path matching is supported. Examples of valid p
 **** Patterns: /{version}/resource, /api/{version}/resource, /api/{version}/resource/*
 +
 *** *methods*
++
 The HTTP methods (for example, GET, POST, PATCH) to protect and how they are associated with the scopes for a given resource in the server.
-+[/'']
++
 **** *method*
 +
 The name of the HTTP method.

authorization_services/topics/policy-evaluation-api.adoc

@@ -75,7 +75,7 @@ From this interface, policies can obtain:
 * Information about the execution context and runtime environment
 
 The `Identity` is built based on the OAuth2 Access Token that was sent along with the authorization request, and this construct has access to all claims
-extracted from the original token. For example, if you are using a _Protocol Mapper_ to include a custom claim in a OAuth2 Access Token you can also access this claim
+extracted from the original token. For example, if you are using a _Protocol Mapper_ to include a custom claim in an OAuth2 Access Token you can also access this claim
 from a policy and use it to build your conditions.
 
 The `EvaluationContext` also gives you access to attributes related to both the execution and runtime environments. For now, there only a few built-in attributes.

authorization_services/topics/service-client-api.adoc

@@ -46,6 +46,7 @@ The base URL of the {project_name} server. All other {project_name} pages and RE
 The client-id of the application. Each application has a client-id that is used to identify the application.
 
 * *credentials* (required)
++
 Specifies the credentials of the application. This is an object notation where the key is the credential type and the value is the value of the credential type.
 
 The configuration file is usually located in your application's classpath, the default location from where the client is going to try to find a ```keycloak.json``` file.

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

@@ -19,7 +19,7 @@ The Entitlement API comes in two flavors:
 * Using HTTP **GET** in order to obtain all entitlements based on the resources owned by a specific user or/and general resources
 owned and managed by the resource server itself.
 
-* Using HTTP **POST** in order to obtain entitlements based on a a set of one or more resources and scopes sent along with an entitlement request.
+* Using HTTP **POST** in order to obtain entitlements based on a set of one or more resources and scopes sent along with an entitlement request.
 
 [NOTE]
 Using one or another depends on your use case and how much resources you have registered in {project_name}. Although the **GET** variant

authorization_services/topics/service-entitlement-whatis-obtain-eat.adoc

@@ -4,7 +4,7 @@
 An entitlement API token (EAT) is a special OAuth2 access token with the scope *kc_entitlement*.
 
 Client applications can obtain an EAT from {project_name} like any other OAuth2 access token. Usually, client applications obtain EATs after the user is successfully
-authenticated in {project_name}. By default the _authorizaton_code_ grant type is used to authenticate a user and issue an OAuth2 access token to the client application acting on the user's behalf.
+authenticated in {project_name}. By default the _authorization_code_ grant type is used to authenticate a user and issue an OAuth2 access token to the client application acting on the user's behalf.
 
 For demonstration purposes, the example below uses Resource Owner Password Credentials Grant Type to request an EAT: