== Terminology

Before going further, it is important to understand some terms and concepts introduced by {{book.project.name}} {{book.project.module}}.

==== Resource Server

Per OAuth2 terminology, a Resource Server is the server hosting the protected resources and capable of accepting and responding to protected resource requests.

Resource servers usually rely on some kind of information to decide whether access to a protected resource should be granted or not. For RESTful-based resource servers,
that information is usually carried in a security token, typically sent as a bearer token along with every request to the server. Web applications that rely on a session to
authenticate their users usually store that information in the user's session and retrieve it from there on every request.

In Keycloak, any *confidential* client application may act as a resource server. This client's resources and their respective scopes are
protected and ruled by a set of authorization policies.

==== Resource

A resource is part of the assets of an application and the organization. It can be a set of one or more endpoints, a classic web resource such as an HTML page, and so on.
In authorization policy terminology, a resource is the _object_ being protected.

Every single resource has a unique identifier which may represent a single resource or a set of resources. For instance, you may want to manage a _Banking Account Resource_ that represents and defines a set of authorization policies for all banking accounts.
But you may also have a different resource named _Alice's Banking Account_, which represents a single resource owned by a single customer, which may have its own set of authorization policies.

==== Scope

A resource's scope is a bounded extent of access that is possible to perform on a resource. In authorization policy
terminology, a scope is one of the potentially many _verbs_ that can logically apply to a resource.

It usually indicates what can be done with a given resource. Example of scopes are _view_,
_edit_, _delete_, etc. However, it may also be related with some information provided by a resource. In this case, you
may have a _Project_ resource and a _cost_ scope, where _cost_ scope may be used to define specific policies
and permissions for those trying to access project's cost.

==== Permission

Consider this simple and very common permission:

A permission associates the object being protected with the policies that must be evaluated in order to decide whether or not access should be granted.

* *X* CAN DO *Y* ON RESOURCE *Z*
** where ...
*** *X* represents one or more Users, Roles, Groups or a combination of them. You can also use claims and context here ...
*** *Y* represents an action to be performed, e.g., "write", "view", etc
*** *Z* represents a protected resource, e.g., "/accounts".

{{book.project.name}} provides a rich platform for building a range of permission strategies ranging from simple to very complex, rule-based dynamic permissions. It provides great flexibility and helps to:

* Reduce code refactoring and permission management costs
* Support a more flexible security model, helping you to easily adapt to changes in your security requirements
* Make changes at runtime -- applications only care about the resources and scopes being protected and not how they are actually protected

==== Policy

A policy defines the conditions that must be satisfied to grant access to an object. Different than permissions, you don't specify the object being protected
but the conditions that must be satisfied to get access to a given object (e.g., resource, scope, or both).
Policies are strongly related to the different _access control mechanisms_ that you can use to actually protect your resources.
With policies, you can implement strategies for ABAC, RBAC, Context-based Access Control or any combination of these.

Keycloak leverages the concept of policies and how you define them by providing the concept of *Aggregated Policies*, where you can build a "policy of policies" and still control the behavior of the evaluation.
Instead of writing a single and huge policy with all conditions that must be satisfied to get access to a given resource, the policies implementation in {{book.project.name}} {{book.project.module}} follows the *divide-and-conquer* technique.
That is, you can create individual policies, reuse them on different permissions, and build more complex policies by combining individual policies.

==== Policy Provider

Policy providers are implementations of specific policy types. {{book.project.name}} provides some built-in policies, backed by their corresponding
policy providers, and you are free to create your own policy types to support your specific requirements.

{{book.project.name}} provides a *SPI* (Service Provider Interface) that you can use to plug in your own policy provider implementations.

[[_permission_ticket]]
==== Permission Ticket

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 a the policies that must be applied to a request for authorization data (requesting party token or 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.

During the UMA flow, permission tickets are issued by the authorization server to a resource server, which in turn returns it back to the client trying to access a protected resource. Once the client
receives the ticket, it can make a request for a requesting party token (RPT) (a final token holding authorization data) by sending the ticket back to the authorization server.

For more details, see link:../service/authorization/authorization-api.html[Authorization API] and the https://docs.kantarainitiative.org/uma/rec-uma-core.html[UMA] specification.