Re-add links to policy-enforcer to the authorization services documen… (#33905)

closes #32644

Signed-off-by: mposolda <mposolda@gmail.com>


Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>
Signed-off-by: Marek Posolda <mposolda@gmail.com>
This commit is contained in:
Marek Posolda 2024-10-15 08:34:56 +02:00 committed by GitHub
parent 936cf68050
commit 94b5f05c64
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
8 changed files with 22 additions and 7 deletions

View file

@ -96,4 +96,6 @@ include::topics/service-rpt-overview.adoc[leveloffset=+2]
include::topics/service-rpt-token-introspection.adoc[leveloffset=+3]
include::topics/enforcer-js-adapter.adoc[leveloffset=+1]
include::topics/enforcer-overview.adoc[leveloffset=+1]
include::topics/enforcer-js-adapter.adoc[leveloffset=+2]

View file

@ -20,7 +20,7 @@ For more information, see <<_service_obtaining_permissions, Obtaining Permission
* **Policy Enforcement Point (PEP)**
+
Provides implementations for different environments to actually enforce authorization decisions at the resource server side.
{project_name} provides some built-in Policy Enforcers.
{project_name} provides some built-in <<_enforcer_overview, Policy Enforcers>>.
+
* **Policy Information Point (PIP)**
@ -78,7 +78,7 @@ what you want to protect (resource or scope) and the policies that must be satis
image:images/pep-pattern-diagram.png[alt="PEP overview"]
{project_name} provides some built-in Policy Enforcers implementations that you can use to protect your applications depending on the platform they are running on.
{project_name} provides some built-in <<_enforcer_overview, Policy Enforcers>> implementations that you can use to protect your applications depending on the platform they are running on.
== Authorization services

View file

@ -0,0 +1,11 @@
[[_enforcer_overview]]
= Policy enforcers
Policy Enforcement Point (PEP) is a design pattern and as such you can implement it in different ways. {project_name} provides all the necessary means to implement PEPs for different
platforms, environments, and programming languages. {project_name} Authorization Services presents a RESTful API and leverages OAuth2 authorization capabilities for fine-grained
authorization using a centralized authorization server.
The Policy enforcers available by {project_name} are:
* {securing_apps_java_policy_enforcer_link}[{securing_apps_java_policy_enforcer_name}] - useful to be used in the Java client applications
* <<_enforcer_js_adapter, Javascript Policy enforcer>> - useful to be used in the applications secured by {project_name} Javascript adapter

View file

@ -16,7 +16,7 @@ image:images/resource-server/default-resource.png[alt="Default resource"]
This resource defines a `Type`, namely `urn:my-resource-server:resources:default` and a `URI` `/*`. Here, the `URI` field defines a
wildcard pattern that indicates to {project_name} that this resource represents all the paths in your application. In other words,
when enabling policy enforcement for your application, all the permissions associated with the resource
when enabling <<_enforcer_overview, policy enforcement>> for your application, all the permissions associated with the resource
will be examined before granting access.
The `Type` mentioned previously defines a value that can be used to create <<_permission_typed_resource, typed resource permissions>> that must be applied

View file

@ -12,7 +12,7 @@ A <<_overview_terminology_permission_ticket, permission ticket>> is a special se
`A correlation handle that is conveyed from an authorization server to a resource server, from a resource server to a client, and ultimately from a client back to an authorization server, to enable the authorization server to assess the correct policies to apply to a request for authorization data.`
In most cases, you won't need to deal with this endpoint directly. {project_name} provides a policy enforcer that enables UMA for your
In most cases, you do not need to deal with this endpoint directly. {project_name} provides a <<_enforcer_overview, policy enforcer>> that enables UMA for your
resource server so it can obtain a permission ticket from the authorization server, return this ticket to client application, and enforce authorization decisions based on a final requesting party token (RPT).
The process of obtaining permission tickets from {project_name} is performed by resource servers and not regular client applications,

View file

@ -5,7 +5,7 @@ The Protection API provides a UMA-compliant set of endpoints providing:
* *Resource Management*
+
With this endpoint, resource servers can manage their resources remotely and enable policy enforcers to query the server for the resources that need protection.
With this endpoint, resource servers can manage their resources remotely and enable <<_enforcer_overview, policy enforcers>> to query the server for the resources that need protection.
* *Permission Management*
+

View file

@ -6,7 +6,7 @@ Sometimes you might want to introspect a requesting party token (RPT) to check i
There are two main use cases where token introspection can help you:
* When client applications need to query the token validity to obtain a new one with the same or additional permissions
* When enforcing authorization decisions at the resource server side, especially when none of the built-in policy enforcers fits your application
* When enforcing authorization decisions at the resource server side, especially when none of the built-in <<_enforcer_overview, policy enforcers>> fits your application
= Obtaining Information about an RPT

View file

@ -125,3 +125,5 @@
:securing_apps_name: Securing applications Guides
:securing_apps_name_short: Securing applications
:securing_apps_link: https://www.keycloak.org/guides#securing-apps
:securing_apps_java_policy_enforcer_link: https://www.keycloak.org/securing-apps/policy-enforcer
:securing_apps_java_policy_enforcer_name: Java Policy enforcer