From 94a501d9eb796b2cbbd32a81a1d5f649dc0bcc5b Mon Sep 17 00:00:00 2001 From: Kohei Tamura Date: Wed, 10 Jan 2018 10:56:35 +0900 Subject: [PATCH] Fix typos in Securing Apps --- .../client-registration/client-registration-cli.adoc | 8 ++++---- securing_apps/topics/oidc/java/spring-boot-adapter.adoc | 2 +- securing_apps/topics/overview/supported-protocols.adoc | 4 ++-- securing_apps/topics/token-exchange/token-exchange.adoc | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/securing_apps/topics/client-registration/client-registration-cli.adoc b/securing_apps/topics/client-registration/client-registration-cli.adoc index 309ae1bccf..7d8a9ed339 100644 --- a/securing_apps/topics/client-registration/client-registration-cli.adoc +++ b/securing_apps/topics/client-registration/client-registration-cli.adoc @@ -24,7 +24,7 @@ To allow a particular user to use `Client Registration CLI` the {project_name} a These permissions grant the user the capability to perform operations without the use of <<_initial_access_token,Initial Access Token>> or <<_registration_access_token,Registration Access Token>>. ==== -It is possible to not assign any [command]`realm-management` roles to a user. In that case, a user can still log in with the Registration Client CLI but cannot use it without an Initial Access Token. Trying to perform any operations without a token results in a *403 Forbidden* error. +It is possible to not assign any [command]`realm-management` roles to a user. In that case, a user can still log in with the Client Registration CLI but cannot use it without an Initial Access Token. Trying to perform any operations without a token results in a *403 Forbidden* error. The Administrator can issue Initial Access Tokens from the Admin Console through the *Realm Settings > Client Registration > Initial Access Token* menu. @@ -36,7 +36,7 @@ By default, the server recognizes the Client Registration CLI as the [filename]` . Strengthen the security by configuring the client [filename]`Access Type` as [filename]`Confidential` and selecting *Credentials > ClientId and Secret*. . Provide a secret when running [command]`kcreg config credentials` by using the [command]`--secret` option. -. Create a new client (for example, [filename]`reg-cli`) if you want to use a separate client configuration for the Registration Client CLI. +. Create a new client (for example, [filename]`reg-cli`) if you want to use a separate client configuration for the Client Registration CLI. . Specify which [filename]`clientId` to use (for example, [command]`--client reg-cli`) when running [command]`kcreg config credentials`. . Enable service accounts if you want to use a service account associated with the client by selecting a client to edit in the *Clients* section of the `Admin Console`. . Under *Settings*, change the *Access Type* to *Confidential*, toggle the *Service Accounts Enabled* setting to *On*, and click [btn]`Save`. @@ -53,7 +53,7 @@ You can configure either [filename]`Client Id and Secret` or [filename]`Signed J The Client Registration CLI is packaged inside the Keycloak Server distribution. You can find execution scripts inside the [filename]`bin` directory. The Linux script is called [filename]`kcreg.sh`, and the Windows script is called [filename]`kcreg.bat`. -Add the Keycloak server directory to your [filename]`PATH` when setting up the client for use from any location on the file system . +Add the Keycloak server directory to your [filename]`PATH` when setting up the client for use from any location on the file system. For example, on: @@ -160,7 +160,7 @@ By default, the Client Registration CLI automatically maintains a configuration Do not make the configuration file visible to other users on the system. The configuration file contains access tokens and secrets that should be kept private. ==== -You might want to avoid storing secrets inside a configuration file by using the [command]`--no-config` option with all of your commands, even thought it is less convenient and requires more token requests to do so. Specify all authentication information with each [command]`kcreg` invocation. +You might want to avoid storing secrets inside a configuration file by using the [command]`--no-config` option with all of your commands, even though it is less convenient and requires more token requests to do so. Specify all authentication information with each [command]`kcreg` invocation. [[_initial_access_and_registration_access_tokens]] diff --git a/securing_apps/topics/oidc/java/spring-boot-adapter.adoc b/securing_apps/topics/oidc/java/spring-boot-adapter.adoc index 0611a85e7e..c02187770e 100644 --- a/securing_apps/topics/oidc/java/spring-boot-adapter.adoc +++ b/securing_apps/topics/oidc/java/spring-boot-adapter.adoc @@ -23,7 +23,7 @@ To add it manually and if you are using Maven, add the following to your depende ---- -Make also sure to add the Adapter POM dependency : +Make also sure to add the Adapter BOM dependency : [source,xml,subs="attributes+"] ---- diff --git a/securing_apps/topics/overview/supported-protocols.adoc b/securing_apps/topics/overview/supported-protocols.adoc index 73d2459f79..91bc5805a6 100644 --- a/securing_apps/topics/overview/supported-protocols.adoc +++ b/securing_apps/topics/overview/supported-protocols.adoc @@ -9,7 +9,7 @@ While OAuth 2.0 is only a framework for building authorization protocols and is protocol. OIDC also makes heavy use of the link:https://jwt.io[Json Web Token] (JWT) set of standards. These standards define an identity token JSON format and ways to digitally sign and encrypt that data in a compact and web-friendly way. -There is really two types of use cases when using OIDC. The first is an application that asks the {project_name} server to authenticate +There are really two types of use cases when using OIDC. The first is an application that asks the {project_name} server to authenticate a user for them. After a successful login, the application will receive an _identity token_ and an _access token_. The _identity token_ contains information about the user such as username, email, and other profile information. The _access token_ is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user @@ -30,7 +30,7 @@ that works by exchanging XML documents between the authentication server and the In {project_name} SAML serves two types of use cases: browser applications and REST invocations. -There is really two types of use cases when using SAML. The first is an application that asks the {project_name} server to authenticate +There are really two types of use cases when using SAML. The first is an application that asks the {project_name} server to authenticate a user for them. After a successful login, the application will receive an XML document that contains something called a SAML assertion that specifies various attributes about the user. This XML document is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user diff --git a/securing_apps/topics/token-exchange/token-exchange.adoc b/securing_apps/topics/token-exchange/token-exchange.adoc index 283073a153..c35ca0f6f4 100644 --- a/securing_apps/topics/token-exchange/token-exchange.adoc +++ b/securing_apps/topics/token-exchange/token-exchange.adoc @@ -84,7 +84,7 @@ a JSON document as described in the link:http://www.ietf.org/id/draft-ietf-oauth Clients requesting a refresh token will get back both an access and refresh token in the response. Clients requesting only access token type will only get an access token in the response. Expiration information may or may not be included for -clients requesting a an external issuer through the `requested_issuer`paramater. +clients requesting a an external issuer through the `requested_issuer` paramater. Error responses generally fall under the 400 HTTP response code category, but other error status codes may be returned depending on the severity of the error. Error responses may include content depending on the `requested_issuer`.