Merge pull request #43 from jenmalloy/RHSSO-599-2

fixing remaining header issues so TOC levels are correct
This commit is contained in:
Jen Malloy 2016-12-02 12:00:29 -05:00 committed by GitHub
commit 42ea4c088c
13 changed files with 23 additions and 23 deletions

View file

@ -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]

View file

@ -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.

View file

@ -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.

View file

@ -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):

View file

@ -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

View file

@ -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.

View file

@ -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.

View file

@ -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.

View file

@ -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.

View file

@ -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.

View file

@ -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.

View file

@ -1,5 +1,5 @@
[[_service_protection_resources_api]]
=== Managing Resources
==== Managing Resources
Resource servers can manage their resources remotely using a UMA-compliant endpoint.

View file

@ -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.