40 lines
No EOL
2.9 KiB
Text
Executable file
40 lines
No EOL
2.9 KiB
Text
Executable file
== 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 |