If you are familiar with OAuth2, a Resource Server is the server hosting the protected resources, and which is 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 obtained from a security token, usually sent as a bearer token on every single request to the server. For web applications that rely on a session to
authenticate their users, that information is usually stored into user's session and retrieved from there on every single request.
In Keycloak, any *confidential* client application may act as a resource server. Whose resources and their respective scopes are
protected and ruled by a set of authorization policies.
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, where a resource may also be used to represent a single
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 _Alice Banking Account_, which represents a single resource owned by a single customer, which may have its own set of authorization policies.
==== Scope
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.
Usually, a scope is defined as a URN that indicates what can be done with a given resource. Example of scopes are _urn:domain:resource:scope:view_,
_urn:domain:scopes:admin:manage_, etc.
Scopes have a small set of information as follows:
* *Name*
+
A human-readable and unique string describing the scope.
A single scope may be associated with zero or more resources.
{{book.project.name}} provides a rich platform for building from the most simple to the more complex permissions. It provides great flexibility and helps to:
* Reduce code refactoring and permission management costs
* Support a more flexible security model where you can easily change
* Make changes at runtime given that applications only care about the resources and scopes being protect and not how they are actually protected
A policy defines the conditions that must be satisfied to grant access to an object. Different than permissions, you don't really specify the object being protected
but the conditions that must be satisfied to get access to a given object (eg.: resource, scope or both).
Policies are strongly related with the different _access control mechanism_ that you can use to actually protect your resources.
Within a policy you can use 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, policies in Keycloak follows the *divide-and-conquer* technique,
so you can create individual policies, reuse them on different permissions and build more complex policies by combining them into a single one.
==== Policy Provider
Policy providers are responsible to support a specific policy type. Although {{book.project.name}} provides some built-in policies, backed by their corresponding
policy providers, nothing stops you to create your own policy types in order to better support your requirements or a specific use case.
{{book.project.name}} provides a *SPI* (Service Provider Interface) that you can use to plug your own policy providers.
