Merge pull request #288 from k-tamura/fix-typos-in-securing-apps
Fix typos in Securing Apps
This commit is contained in:
commit
781cb95866
4 changed files with 8 additions and 8 deletions
|
@ -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`.
|
||||
|
@ -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]]
|
||||
|
|
|
@ -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+"]
|
||||
----
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue