From 1fbaba133f3e97c9886f7039c5c08492474e85c1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Herbert=20M=C3=BChlburger?= Date: Tue, 3 Oct 2017 15:08:29 +0200 Subject: [PATCH 1/2] Fix spelling for HTTP requests --- .../authorization/authorization-api-aapi.adoc | 2 +- .../service/entitlement/entitlement-api-aapi.adoc | 2 +- securing_apps/topics/client-registration.adoc | 12 ++++++------ server_development/topics/action-token-spi.adoc | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/authorization_services/topics/service/authorization/authorization-api-aapi.adoc b/authorization_services/topics/service/authorization/authorization-api-aapi.adoc index 85cc2cb2fd..21f1455563 100644 --- a/authorization_services/topics/service/authorization/authorization-api-aapi.adoc +++ b/authorization_services/topics/service/authorization/authorization-api-aapi.adoc @@ -15,7 +15,7 @@ When requesting an RPT, you need to provide two things: * A <<_service_protection_permission_api_papi, permission ticket>> representing the resources you want to access * The <<_service_authorization_aat, Authorization API token (AAT)>> (as a bearer token) representing a user's identity and his consent to access authorization data on his behalf. -The permission ticket is added to a HTTP request as a parameter whether the AAT is included in a ```Authorization``` header in order to authenticate de request +The permission ticket is added to an HTTP request as a parameter whether the AAT is included in a ```Authorization``` header in order to authenticate the request using the AAT as a bearer token. ```bash diff --git a/authorization_services/topics/service/entitlement/entitlement-api-aapi.adoc b/authorization_services/topics/service/entitlement/entitlement-api-aapi.adoc index 5b47eaeb80..e1d7a535e2 100644 --- a/authorization_services/topics/service/entitlement/entitlement-api-aapi.adoc +++ b/authorization_services/topics/service/entitlement/entitlement-api-aapi.adoc @@ -27,7 +27,7 @@ provides an easy way to obtain entitlements from the server, it might not be app with an user. In this case, the **POST** method is recommended. Regardless of the HTTP method you decide to use, the Entitlement API endpoint expects an access token in the request representing a user's identity -and his consent to access authorization data on his behalf. The access token must be sent as a bearer token using a HTTP ```Authorization``` header. +and his consent to access authorization data on his behalf. The access token must be sent as a bearer token using an HTTP ```Authorization``` header. After successfully invoking the Entitlement API endpoint, you will get a <<_service_rpt_overview, RPT>> with all permissions granted by the server. diff --git a/securing_apps/topics/client-registration.adoc b/securing_apps/topics/client-registration.adoc index 024a5ae2ae..8413f1af9e 100644 --- a/securing_apps/topics/client-registration.adoc +++ b/securing_apps/topics/client-registration.adoc @@ -72,21 +72,21 @@ The `default` client registration provider can be used to create, retrieve, upda It uses {project_name} Client Representation format which provides support for configuring clients exactly as they can be configured through the admin console, including for example configuring protocol mappers. -To create a client create a Client Representation (JSON) then do a HTTP POST to `/realms//clients-registrations/default`. +To create a client create a Client Representation (JSON) then perform an HTTP POST request to `/realms//clients-registrations/default`. It will return a Client Representation that also includes the registration access token. You should save the registration access token somewhere if you want to retrieve the config, update or delete the client later. -To retrieve the Client Representation then do a HTTP GET to `/realms//clients-registrations/default/`. +To retrieve the Client Representation perform an HTTP GET request to `/realms//clients-registrations/default/`. It will also return a new registration access token. -To update the Client Representation then do a HTTP PUT to with the updated Client Representation to: +To update the Client Representation perform an HTTP PUT request with the updated Client Representation to: `/realms//clients-registrations/default/`. It will also return a new registration access token. -To delete the Client Representation then do a HTTP DELETE to: +To delete the Client Representation perform an HTTP DELETE request to: `/realms//clients-registrations/default/` === {project_name} Adapter Configuration @@ -100,7 +100,7 @@ To do this include the following header in the request: Authorization: basic BASE64(client-id + ':' + client-secret) ---- -To retrieve the Adapter Configuration then do a HTTP GET to `/realms//clients-registrations/install/`. +To retrieve the Adapter Configuration then perfrom an HTTP GET request to `/realms//clients-registrations/install/`. No authentication is required for public clients. This means that for the JavaScript adapter you can load the client configuration directly from {project_name} using the above URL. @@ -120,7 +120,7 @@ It doesn't support retrieving, updating or deleting clients. For those operations the {project_name} representation endpoints should be used. When creating a client a {project_name} Client Representation is returned with details about the created client, including a registration access token. -To create a client do a HTTP POST with the SAML Entity Descriptor to `/realms//clients-registrations/saml2-entity-descriptor`. +To create a client perform an HTTP POST request with the SAML Entity Descriptor to `/realms//clients-registrations/saml2-entity-descriptor`. === Example using CURL diff --git a/server_development/topics/action-token-spi.adoc b/server_development/topics/action-token-spi.adoc index f501990c53..7422b02cd7 100644 --- a/server_development/topics/action-token-spi.adoc +++ b/server_development/topics/action-token-spi.adoc @@ -37,7 +37,7 @@ When an action token is passed to a {project_name} endpoint `_KEYCLOAK_ROOT_/auth/realms/master/login-actions/action-token` via `key` parameter, it is validated and a proper action token handler is executed. The processing always takes place in a context of an authentication session, either a fresh one or the action token service joins an existing authentication session (details are described below). The action token -handler can perform actions prescribed by the token (often it alters the authentication session) and results into a HTTP +handler can perform actions prescribed by the token (often it alters the authentication session) and results into an HTTP response (e.g. it can continue in authentication or display an information/error page). These steps are detailed below. 1. *Basic action token validation.* Signature and time validity is checked, and action token handler is determined based From 3d3412ae33b829f78161b48cc4a8105548c9fa53 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Herbert=20M=C3=BChlburger?= Date: Wed, 4 Oct 2017 15:03:48 +0200 Subject: [PATCH 2/2] Fix spelling in java adapter config --- securing_apps/topics/oidc/java/java-adapter-config.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/securing_apps/topics/oidc/java/java-adapter-config.adoc b/securing_apps/topics/oidc/java/java-adapter-config.adoc index 400583e26c..34c7149179 100644 --- a/securing_apps/topics/oidc/java/java-adapter-config.adoc +++ b/securing_apps/topics/oidc/java/java-adapter-config.adoc @@ -208,7 +208,7 @@ token-store:: See <<_applicationclustering,Application Clustering>> for details principal-attribute:: - OpenID Connection ID Token attribute to populate the UserPrincipal name with. + OpenID Connect ID Token attribute to populate the UserPrincipal name with. If token attribute is null, defaults to `sub`. Possible values are `sub`, `preferred_username`, `email`, `name`, `nickname`, `given_name`, `family_name`.