keycloak-scim/topics/overview/overview.adoc

== Overview

{{book.project.name}} supports fine-grained authorization policies and is able to mix and match different access control
mechanisms such as:

* **Attribute-based Access Control**
* **Role-based Access Control**
* **User-based Access Control**
* **Context-based Access Control**
* **Rule-based Access Control**
    ** Using Javascript
    ** Using JBoss Drools
* **Time-based Access Control**
* **Support for custom ACMs through a Policy Provider SPI**

{{book.project.name}} is based on a set of administrative UIs and a RESTful API, and provides the necessary means to create permissions
for your protected resources and scopes, associate these permissions with authorization policies, and enforce authorization
decisions in your applications and services.

Resource servers (applications or services serving protected resources) usually rely on some kind of information to decide if access should be granted to a protected resource. For RESTful-based resource servers,
that information is usually obtained from a security token, usually sent as a bearer token on every request to the server. For web applications that rely on a session to
authenticate their users, that information is usually stored in a user's session and retrieved from there on every single request.

Frequently, resource servers only perform authorization decisions based on _Role-based Access Control_ or _RBAC_, where the roles granted to the user trying to access protected resources are
checked against the roles mapped to these same resources. While roles are very useful and used by applications, they also have a few limitations:

* Resources and roles are tightly coupled and changes to roles (such as adding, removing or changing an access context) may impact several resources
* Changes to your security requirements may imply deep changes to application code to reflect these changes
* Depending on your application size, role management may become difficult and error-prone
* It is not the most flexible access control mechanism. Roles do not represent who you are and lack context information. If you have a role, you can do something.

Considering that today we need to consider heterogeneous environments where users are distributed across different regions, with different local policies,
using different devices, and with a high demand for information sharing, {{book.project.name}} Authorization Services can help you improve the authorization capabilities of your applications and services by providing:

* Resource protection using fine-grained authorization policies and different access control mechanisms
* Centralized Resource, Permission and Policy Management
* Centralized Policy Decision Point
* REST security based on a set of REST-based Authorization Services
* Authorization Workflows and User-Managed Access
* The infrastructure to help avoid code replication across projects (and redeploys) and quickly adapt to changes in your security requirements