fixing remaining header issues so TOC levels are correct
This commit is contained in:
Jen Malloy
parent
e40ebdb6d1
commit
ffdf7957ca
13 changed files with 23 additions and 23 deletions
|
|
@ -80,7 +80,7 @@
|
|||
|
||||
.. link:topics/service/authorization/authorization-api.adoc[Authorization API]
|
||||
|
||||
... link:topics/service/authorization/whatis-obtain-aat.adoc[What is a AAT and How to Obtain It]
|
||||
... link:topics/service/authorization/whatis-obtain-aat.adoc[What is an AAT and How to Obtain It]
|
||||
|
||||
... link:topics/service/authorization/authorization-api-aapi.adoc[Requesting Authorization Data and Token]
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[[_enforcer_authorization_context]]
|
||||
=== Obtaining the Authorization Context
|
||||
==== Obtaining the Authorization Context
|
||||
|
||||
When policy enforcement is enabled, the permissions obtained from the server are available through `org.keycloak.AuthorizationContext`.
|
||||
This class provides several methods you can use to obtain permissions and ascertain whether a permission was granted for a particular resource or scope.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
[[_enforcer_filter_using_https]]
|
||||
=== Setting Up TLS/HTTPS
|
||||
==== Setting Up TLS/HTTPS
|
||||
|
||||
When the server is using HTTPS, make sure your adapter is configured as follows:
|
||||
When the server is using HTTPS, ensure your adapter is configured as follows:
|
||||
|
||||
.keycloak.json
|
||||
```json
|
||||
|
|
@ -15,5 +15,5 @@ The configuration above enables TLS/HTTPS to the Authorization Client, making po
|
|||
{{book.project.name}} Server remotely using the HTTPS scheme.
|
||||
|
||||
[NOTE]
|
||||
Is strongly recommended that you enable TLS/HTTPS when accessing the {{book.project.name}} Server endpoints.
|
||||
It is strongly recommended that you enable TLS/HTTPS when accessing the {{book.project.name}} Server endpoints.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[[_enforcer_js_adapter]]
|
||||
=== JavaScript Integration
|
||||
==== JavaScript Integration
|
||||
|
||||
The {{book.project.name}} Server comes with a JavaScript library you can use to interact with a resource server protected by a policy enforcer.
|
||||
This library is based on the {{book.external_link.keycloakjsadapter.link}}[{{book.project.name}} {{book.external_link.keycloakjsadapter.name}}], which can be integrated to allow your client to obtain permissions from a {{book.project.name}} Server.
|
||||
|
|
@ -26,7 +26,7 @@ The *keycloak-authz.js* library provides two main features:
|
|||
In both cases, the library allows you to easily interact with both resource server and {{book.project.name}} {{book.project.module}} to obtain tokens with
|
||||
permissions your client can use as bearer tokens to access the protected resources on a resource server.
|
||||
|
||||
==== Handling Authorization Responses from a Resource Server
|
||||
===== Handling Authorization Responses from a Resource Server
|
||||
|
||||
If a resource server is protected by a policy enforcer, it responds to client requests based on the permissions carried along with a <<fake/../keycloak-enforcement-bearer.adoc#_enforcer_bearer, bearer token>>.
|
||||
Typically, when you try to access a resource server with a bearer token that is lacking permissions to access a protected resource, the resource server
|
||||
|
|
@ -56,7 +56,7 @@ The `authorize` function is completely asynchronous and supports a few callback
|
|||
|
||||
Most applications should use the `onGrant` callback to retry a request after a 401 response. Subsequent requests should include the RPT as a bearer token for retries.
|
||||
|
||||
==== Obtaining Entitlements
|
||||
===== Obtaining Entitlements
|
||||
|
||||
The keycloak-authz.js library provides an `entitlement` function that you can use to obtain an RPT from the server using the Entitlement API.
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ The `entitlement` function is completely asynchronous and supports a few callbac
|
|||
* `onDeny`: The second argument of the function. Only called if the server has denied the authorization request.
|
||||
* `onError`: The third argument of the function. Only called if the server responds unexpectedly.
|
||||
|
||||
==== Obtaining the RPT
|
||||
===== Obtaining the RPT
|
||||
|
||||
If you have already obtained an RPT using any of the authorization functions provided by the library, you can always obtain the RPT as follows from the authorization object (assuming that it has been initialized by one of the techniques shown earlier):
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[[_enforcer_bearer]]
|
||||
=== Protecting a Stateless Service Using a Bearer Token
|
||||
==== Protecting a Stateless Service Using a Bearer Token
|
||||
|
||||
If the adapter is configured with the `bearer-only` configuration option, the policy enforcer decides whether a request
|
||||
to access a protected resource is allowed or denied based on the permissions of the bearer token.
|
||||
|
|
@ -21,7 +21,7 @@ In this example, a *keycloak.json* file in your application is similar to the fo
|
|||
...
|
||||
```
|
||||
|
||||
==== Authorization Response
|
||||
===== Authorization Response
|
||||
|
||||
When a client tries to access a resource server with a bearer token that is lacking permissions to access a protected resource, the resource server
|
||||
responds with a *401* status code and a `WWW-Authenticate` header. The value of the `WWW-Authenticate` header depends on the authorization protocol
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[[_permission_typed_resource]]
|
||||
=== Typed Resource Permission
|
||||
==== Typed Resource Permission
|
||||
|
||||
Resource permissions can also be used to define policies that are to be applied to all resources with a given <<fake/../../resource/create.adoc#_resource_create_type, type>>. This form of resource-based permission can be useful when you have resources sharing common access requirements and constraints.
|
||||
|
||||
|
|
|
|||
|
|
@ -41,6 +41,6 @@ image:../../images/resource-server/default-permission.png[alt="Default Permissio
|
|||
|
||||
This permission is a <<fake/../../permission/create-resource.adoc#_permission_create_resource, resource-based permission>>, defining a set of one or more policies that are applied to all resources with a given type.
|
||||
|
||||
=== Changing the Default Configuration
|
||||
==== Changing the Default Configuration
|
||||
|
||||
You can change the default configuration by removing the default resource, policy, or permission definitions and creating your own.
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
[[_service_authorization_api_aapi]]
|
||||
=== Requesting Authorization Data and Token
|
||||
==== Requesting Authorization Data and Token
|
||||
|
||||
Client applications using the UMA protocol can use a specific endpoint to obtain a special security token called a requesting party token (RPT).
|
||||
This token consists of all the permissions granted to a user as a result of the evaluation of the permissions and authorization policies associated with the resources being requested.
|
||||
|
|
@ -27,7 +27,7 @@ As a result, the server response is:
|
|||
{"rpt":"${RPT}"}
|
||||
```
|
||||
|
||||
==== Requesting Party Token
|
||||
===== Requesting Party Token
|
||||
|
||||
A Requesting Party Token (RPT) is a https://tools.ietf.org/html/rfc7519[JSON web token (JWT)] digitally signed using https://www.rfc-editor.org/rfc/rfc7515.txt[JSON Web Signature (JWS)].
|
||||
The token is built based on the AAT sent by the client during the authorization process.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[[_service_authorization_aat]]
|
||||
=== What is a AAT and How to Obtain It
|
||||
==== What is an AAT and How to Obtain It
|
||||
|
||||
An authorization API token (AAT) is a special OAuth2 access token with the scope *uma_authorization*. When you create a user, {{book.project.name}} automatically
|
||||
assigns the role _uma_authorization_ to the user. The _uma_authorization_ role is a default realm role.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[[_service_entitlement_api_aapi]]
|
||||
=== Requesting Entitlements
|
||||
==== Requesting Entitlements
|
||||
|
||||
Client applications can use a specific endpoint to obtain a special security token called a requesting party token (RPT).
|
||||
This token consists of all the entitlements (or permissions) for a user as a result of the evaluation of the permissions and authorization policies associated with the resources being requested.
|
||||
|
|
@ -9,7 +9,7 @@ With an RPT, client applications can gain access to protected resources at the r
|
|||
http://${host}:${port}/auth/realms/${realm_name}/authz/entitlement
|
||||
```
|
||||
|
||||
==== Obtaining Entitlements
|
||||
===== Obtaining Entitlements
|
||||
|
||||
The easiest way to obtain entitlements for a specific user is using an HTTP GET request. For example, using curl:
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ As a result, the server response is:
|
|||
Using this method to obtain entitlements, the server responds to the requesting client with *all* entitlements for a user, based on the evaluation of the permissions and
|
||||
authorization policies associated with the resources managed by the resource server.
|
||||
|
||||
==== Obtaining Entitlements for a Specific Set of Resources
|
||||
===== Obtaining Entitlements for a Specific Set of Resources
|
||||
|
||||
You can also use the entitlements endpoint to obtain a user's entitlements for a set of one or more resources. For example, using curl:
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ curl -X POST -H "Authorization: Bearer ${access_token}" -d '{
|
|||
}' "http://localhost:8080/auth/realms/hello-world-authz/authz/entitlement/hello-world-authz-service"
|
||||
```
|
||||
|
||||
==== Requesting Party Token
|
||||
===== Requesting Party Token
|
||||
|
||||
A requesting party token (RPT) is a https://tools.ietf.org/html/rfc7519[JSON web token (JWT)] digitally signed using https://www.rfc-editor.org/rfc/rfc7515.txt[JSON web signature (JWS)]. The token is built based on the access_token sent by the client during the authorization process.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[[_service_protection_permission_api_papi]]
|
||||
=== Managing Permission Requests
|
||||
==== Managing Permission Requests
|
||||
|
||||
Resource servers using the UMA protocol can use a specific endpoint to manage permission requests. This endpoint provides a UMA-compliant flow for registering permission requests and obtaining a permission ticket.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[[_service_protection_resources_api]]
|
||||
=== Managing Resources
|
||||
==== Managing Resources
|
||||
|
||||
Resource servers can manage their resources remotely using a UMA-compliant endpoint.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[[_service_protection_whatis_obtain_pat]]
|
||||
=== What is a PAT and How to Obtain It
|
||||
==== What is a PAT and How to Obtain It
|
||||
|
||||
A *protection API token* (PAT) is a special OAuth2 access token with a scope defined as *uma_protection*. When you create a resource server, {{book.project.name}} automatically
|
||||
creates a role, _uma_protection_, for the corresponding client application and associates it with the client's service account.
|
||||
|
|
|
|||
Loading…
Reference in a new issue