Minor changes : Fixed spell/grammatical errors in docbook.
This commit is contained in:
parent
e796c11b64
commit
7cf1161305
8 changed files with 17 additions and 17 deletions
|
@ -204,7 +204,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
Specify the credentials of the application. This is an object notation where the key
|
||||
is the credential type and the value if the value of the credential type. Currently only
|
||||
is the credential type and the value is the value of the credential type. Currently only
|
||||
<literal>password</literal>
|
||||
is supported.
|
||||
This is <emphasis>REQUIRED</emphasis>.
|
||||
|
@ -374,7 +374,7 @@
|
|||
<term>principal-attribute</term>
|
||||
<listitem>
|
||||
<para>
|
||||
OpenID Connection ID Token attribute to populate the UserPrincipal name with. If token attribute is null, defaults to <literal>sub</literal>
|
||||
OpenID Connection ID Token attribute to populate the UserPrincipal name with. If token attribute is null, defaults to <literal>sub</literal>.
|
||||
Possible values are <literal>sub</literal>, <literal>preferred_username</literal>, <literal>email</literal>, <literal>name</literal>, <literal>nickname</literal>, <literal>given_name</literal>, <literal>family_name</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
|
@ -95,7 +95,7 @@
|
|||
<para>
|
||||
This would mean that browser requests (like redirecting to Keycloak login screen) will be still resolved relatively
|
||||
to current request URI like <emphasis>https://loadbalancer.com/myapp</emphasis>, but backend (out-of-bound) requests between keycloak
|
||||
and your app are send always to same cluster host with application .
|
||||
and your app are sent always to same cluster host with application .
|
||||
</para>
|
||||
<para>
|
||||
Note that additionally to network optimization,
|
||||
|
|
|
@ -155,7 +155,7 @@
|
|||
messages to the cluster. However, as there's no sensitive data sent there's not much that can be achieved.
|
||||
For realms and users all that can be done is to send invalidation messages to make nodes load data from the
|
||||
database more frequently. For user sessions it would be possible to modify existing user sessions, but creating
|
||||
new sessions would have no affect as they would not be linked to any access tokens. There's not to much that
|
||||
new sessions would have no affect as they would not be linked to any access tokens. There's not too much that
|
||||
can be achieved by modifying user sessions. For example it would be possible to prevent sessions from expiring,
|
||||
by changing the creation time. However, it would for example have no effect adding additional permissions to the
|
||||
sessions as these are rechecked against the user and application when the token is created or refreshed.
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
Administering your realm through the <literal>master</literal> realm as discussed in <xref linkend="admin-permissions" /> may not always be
|
||||
ideal or feasible. For example, maybe you have more than one admin application that manages various admin aspects of your organization
|
||||
and you want to unify all these different "admin consoles" under one realm so you can do SSO between them. Keycloak allows you to
|
||||
grant realm admin privleges to users within that realm. These realm admins can participate in SSO for that realm and
|
||||
grant realm admin privileges to users within that realm. These realm admins can participate in SSO for that realm and
|
||||
visit a keycloak admin console instance that is dedicated solely for that realm by going to the url:
|
||||
<literal>/{keycloak-root}/admin/{realm}/console</literal>
|
||||
</para>
|
||||
|
|
|
@ -18,7 +18,7 @@
|
|||
<term>Include AuthnStatement</term>
|
||||
<listitem>
|
||||
<para>
|
||||
SAML login responses may specify the authenticaiton method used (password, etc.) as well as
|
||||
SAML login responses may specify the authentication method used (password, etc.) as well as
|
||||
a timestamp of the login. Setting this to on will include that statement in the response document.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -27,7 +27,7 @@
|
|||
<term>Multi-valued Roles</term>
|
||||
<listitem>
|
||||
<para>
|
||||
If this switch is off, any user role mapings will have a corresponding attribute created for it.
|
||||
If this switch is off, any user role mappings will have a corresponding attribute created for it.
|
||||
If this switch is turn on, only one role attribute will be created, but it will have
|
||||
multiple values within in.
|
||||
</para>
|
||||
|
@ -82,7 +82,7 @@
|
|||
<para>
|
||||
By default, Keycloak will respond using the initial SAML binding of the original request. By turning
|
||||
on this switch, you will force Keycloak to always respond using the SAML POST Binding even if the
|
||||
original request was a the Redirect binding.
|
||||
original request was the Redirect binding.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
|
@ -20,7 +20,7 @@
|
|||
Copy <literal>Client ID</literal> and <literal>Client secret</literal> from the
|
||||
<ulink url="https://github.com/settings/applications">GitHub Settings</ulink> into the settings
|
||||
page in the Keycloak Admin Console as the <literal>Key</literal> and <literal>Secret</literal>. Then click
|
||||
<literal>Save</literal> in the Keycloak Admin Console to enable login with Google.
|
||||
<literal>Save</literal> in the Keycloak Admin Console to enable login with GitHub.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
|
|
@ -25,7 +25,7 @@
|
|||
<title>Configure theme</title>
|
||||
<para>
|
||||
All theme types, except welcome, is configured through <literal>Keycloak Admin Console</literal>. To change
|
||||
the theme used for a realm open the open the <literal>Keycloak Admin Console</literal>, select your realm
|
||||
the theme used for a realm open the <literal>Keycloak Admin Console</literal>, select your realm
|
||||
from the drop-down box in the top left corner. Under <literal>Settings</literal> click on <literal>Theme</literal>.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -166,7 +166,7 @@
|
|||
and <literal>org.keycloak.account.AccountProvider</literal>.
|
||||
</para>
|
||||
<para>
|
||||
Once you have deployed your account provider to Keycloak you need to configure <literal>keycloak-server.json</literal>to specify which provider should be used:
|
||||
Once you have deployed your account provider to Keycloak you need to configure <literal>keycloak-server.json</literal> to specify which provider should be used:
|
||||
<programlisting>
|
||||
"account": {
|
||||
"provider": "custom-provider"
|
||||
|
@ -182,7 +182,7 @@
|
|||
and <literal>org.keycloak.login.LoginFormsProvider</literal> in <literal>forms/login-api</literal>.
|
||||
</para>
|
||||
<para>
|
||||
Once you have deployed your account provider to Keycloak you need to configure <literal>keycloak-server.json</literal>to specify which provider should be used:
|
||||
Once you have deployed your account provider to Keycloak you need to configure <literal>keycloak-server.json</literal> to specify which provider should be used:
|
||||
<programlisting>
|
||||
"login": {
|
||||
"provider": "custom-provider"
|
||||
|
|
|
@ -19,7 +19,7 @@
|
|||
federation plugins may only import the username into Keycloak storage, others might import everything from name,
|
||||
address, and phone number, to user role mappings. Some plugins might want to import credentials directly into
|
||||
Keycloak storage and let Keycloak handle credential validation. Others might want to handle credential validation
|
||||
themselves. Thegoal of the Federation SPI is to support all of these scenarios.
|
||||
themselves. The goal of the Federation SPI is to support all of these scenarios.
|
||||
</para>
|
||||
<section>
|
||||
<title>LDAP and Active Directory Plugin</title>
|
||||
|
@ -76,7 +76,7 @@
|
|||
<term>Display Name</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Name used when this provider is referenced in the admin consle
|
||||
Name used when this provider is referenced in the admin console
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -118,7 +118,7 @@
|
|||
first import this LDAP user into Keycloak database and then authenticate against LDAP password.
|
||||
</para>
|
||||
<para>
|
||||
Thing is that Federation Provider import just requested users by default, so if you click to <literal>View all users</literal>
|
||||
Federation Provider imports just requested users by default, so if you click to <literal>View all users</literal>
|
||||
in Keycloak admin console, you will see just those LDAP users, which were already authenticated/requested by Keycloak.
|
||||
</para>
|
||||
<para>If you want to sync all LDAP users into Keycloak database, you may configure and enable Sync, which is in
|
||||
|
@ -160,7 +160,7 @@
|
|||
<para>
|
||||
Writing a User Federation Provider starts by implementing the <literal>UserFederationProvider</literal>
|
||||
and <literal>UserFederationProviderFactory</literal> interfaces. Please see the Javadoc and example
|
||||
for complete details on on how to do this. Some important methods of note:
|
||||
for complete details on how to do this. Some important methods of note:
|
||||
getUserByUsername() and getUserByEmail() require that you query your federated storage and if the user exists
|
||||
create and import the user into Keycloak storage. How much metadata you import is fully up to you. This
|
||||
import is done by invoking methods on the object returned <literal>KeycloakSession.userStorage()</literal>
|
||||
|
@ -173,7 +173,7 @@
|
|||
contain a file called <literal>org.keycloak.models.UserFederationProviderFactory</literal>
|
||||
within the <literal>META-INF/services</literal> directory of the JAR. This file is a list
|
||||
of fully qualified classnames of all implementations of <literal>UserFederationProviderFactory</literal>.
|
||||
This is how Keycloak discovers which providers have been deployment. Place the JAR in the
|
||||
This is how Keycloak discovers which providers have been deployed. Place the JAR in the
|
||||
keycloak WAR deployment in the <literal>WEB-INF/lib</literal> directory.
|
||||
</para>
|
||||
</section>
|
||||
|
|
Loading…
Reference in a new issue