diff --git a/README.adoc b/README.adoc index 2f3391b7d4..b405f3a8fb 100755 --- a/README.adoc +++ b/README.adoc @@ -1,5 +1,5 @@ -Keycloak Server Adminstration Guide Documentation +Keycloak Server Administration Guide Documentation ====================== image:images/keycloak_logo.png[alt="Keycloak"] diff --git a/book.json b/book.json index 0acc68fe94..01807c04cb 100755 --- a/book.json +++ b/book.json @@ -65,7 +65,7 @@ }, "adminguide": { - "name": "Keycloak Adminstration Guide", + "name": "Keycloak Administration Guide", "link": "https://keycloak.gitbooks.io/server-adminstration-guide/content/" }, "installguide": { @@ -81,4 +81,4 @@ "version": "1.9.3.Final" } } -} \ No newline at end of file +} diff --git a/topics/MigrationFromOlderVersions.adoc b/topics/MigrationFromOlderVersions.adoc index 956b7d8aa9..ff14d5dfe0 100755 --- a/topics/MigrationFromOlderVersions.adoc +++ b/topics/MigrationFromOlderVersions.adoc @@ -112,7 +112,9 @@ Keycloak SAML SP Client Adapter now requires a specific endpoint, `/saml` to be In previous releases we shipped with a default admin user with a default password, this has now been removed. If you are doing a new installation of 1.8 you will have to create an admin user as a first step. -This can be done easily by following the steps in <<_create_admin_user,Admin User>>. +This can be done easily by following the steps in + +// DOCS REMARK: Please add the chapter as the referenced topic does not exist. <<_create_admin_user,Admin User>>. ===== OAuth2 Token Introspection @@ -257,7 +259,9 @@ There are now 3 separate adapter downloads for WildFly, JBoss EAP and JBoss AS7: Make sure you grab the correct one. You also need to update standalone.xml as the extension module and subsystem definition has changed. -See <<_jboss_adapter_installation,Adapter Installation>> for details. +See + +// DOCS REMARK: Topic not found <<_jboss_adapter_installation,Adapter Installation>> for details. ==== Migrating from 1.2.0.Beta1 to 1.2.0.RC1 @@ -339,7 +343,9 @@ Facebook admin console). ==== Migrating from 1.1.0.Beta2 to 1.1.0.Final * WEB-INF/lib -+`standalone/configuration/providers`<<_providers,+providers>> ++`standalone/configuration/providers` + +// DOCS REMARK: Cross Reference not resolved. Please check and update <<_providers,+providers>> ==== Migrating from 1.1.0.Beta1 to 1.1.0.Beta2 diff --git a/topics/clients/client-templates.adoc b/topics/clients/client-templates.adoc index 1dae08a972..75d4f1d972 100644 --- a/topics/clients/client-templates.adoc +++ b/topics/clients/client-templates.adoc @@ -1,18 +1,18 @@ - +[[_client_templates]] === Client Templates If you have a lot of applications you need to secure and register within your organization it can become quite tedious -to configure the <> and <> +to configure the <> and <> for each of these clients. {{book.project.name}} allows you to define shared client configuration in an entity called a _client template_. To create a client template, go to the `Client Templates` left menu item. This initial screen shows you a list of currently defined templates. To create a template click the `Create` button. This brings you to a simple screen in which you name the template and hit save. A _client template_ will have similar tabs to regular clients. You'll be able to define <> -and <> which can be inherited by other clients. +and <> which can be inherited by other clients. Having a client inherit from a template is as simple as choosing the template from the `Client Template` drop down list on either the `Add Client` or client `Settings` tab. You will see the `Mappers` and `Scope` tabs get additional switches which allow you to turn on or off inheriting from the parent template. -Future versions of client templating may get more inheritable configuration options, but for now, that's all there is to talk about. \ No newline at end of file +Future versions of client templating may get more inheritable configuration options, but for now, that's all there is to talk about. diff --git a/topics/clients/oidc/confidential.adoc b/topics/clients/oidc/confidential.adoc index e1b2e982fe..745ae4d196 100644 --- a/topics/clients/oidc/confidential.adoc +++ b/topics/clients/oidc/confidential.adoc @@ -2,7 +2,7 @@ ==== Confidential Client Credentials -If you've set the client's <> to `confidential` in the client's +If you've set the client's <> to `confidential` in the client's `Settings` tab, a new `Credentials` tab will show up. As part of dealing with this type of client you have to configure the client's credentials. diff --git a/topics/clients/oidc/service-accounts.adoc b/topics/clients/oidc/service-accounts.adoc index 18d0b683cf..2cdfb4d13a 100755 --- a/topics/clients/oidc/service-accounts.adoc +++ b/topics/clients/oidc/service-accounts.adoc @@ -1,4 +1,4 @@ -[[_service-accounts]] +[[_service_accounts]] === Service Accounts diff --git a/topics/groups/default-groups.adoc b/topics/groups/default-groups.adoc index f7dd8fec42..d17b063986 100644 --- a/topics/groups/default-groups.adoc +++ b/topics/groups/default-groups.adoc @@ -2,7 +2,7 @@ ==== Default Groups Default groups allow you to automatically assign group membership whenever any new user is created or imported through -<> or <>. +<> or <>. To specify _default groups go to the `Groups` left menu item, and click the `Default Groups` tab. .Default Roles diff --git a/topics/identity-broker.adoc b/topics/identity-broker.adoc index d4152ea146..83ce9afe59 100755 --- a/topics/identity-broker.adoc +++ b/topics/identity-broker.adoc @@ -1,4 +1,4 @@ -[[_identity-brokering]] +[[_identity_broker]] == Identity Brokering diff --git a/topics/identity-broker/mappers.adoc b/topics/identity-broker/mappers.adoc index 45e5b1a1d1..cdc26e0d02 100644 --- a/topics/identity-broker/mappers.adoc +++ b/topics/identity-broker/mappers.adoc @@ -1,4 +1,4 @@ - +[[_mappers]] === Mapping Claims and Assertions You can import the SAML and OpenID Connect metadata provided by the external IDP you are authenticating with into the environment diff --git a/topics/Overview.adoc b/topics/overview.adoc similarity index 100% rename from topics/Overview.adoc rename to topics/overview.adoc diff --git a/topics/realms/create.adoc b/topics/realms/create.adoc index 445bbc0124..b534338f4f 100644 --- a/topics/realms/create.adoc +++ b/topics/realms/create.adoc @@ -12,7 +12,7 @@ image:../../{{book.images}}/add-realm-menu.png[] This menu option will bring you to the `Add Realm` page. Specify the realm name you want to define and click the `Create` button. Alternatively you and import a JSON document that defines your new realm. We'll go over this in more detail in the -<> chapter. +<> chapter. .Create Realm image:../../{{book.images}}/create-realm.png[] diff --git a/topics/realms/ssl.adoc b/topics/realms/ssl.adoc index 2c6cbcd73b..c3fcf97249 100644 --- a/topics/realms/ssl.adoc +++ b/topics/realms/ssl.adoc @@ -1,4 +1,4 @@ -[[_ssl-mode]] +[[_ssl_modes]] === SSL Mode diff --git a/topics/realms/themes.adoc b/topics/realms/themes.adoc index 11a9c49223..70d7a171d5 100644 --- a/topics/realms/themes.adoc +++ b/topics/realms/themes.adoc @@ -1,4 +1,4 @@ - +[[_themes]] === Themes and Internationalization Themes allow you to change the look and feel of any UI in {{book.project.name}}. Themes are configured per realm. To change @@ -29,4 +29,4 @@ Every UI screen is internationalized in {{book.project.name}}. The default lang `Internationalization` switch on the `Theme` tab you can choose which locales you want to support and what the default locale will be. The next time a user logs in, they will be able to choose a language on the login page to use for the login screens, User Account Management UI, and Admin Console. The link:{{book.developerguide.link}}[{{book.developerguide.name}}] explains -how you can offer additional languages. \ No newline at end of file +how you can offer additional languages. diff --git a/topics/roles/client-scope.adoc b/topics/roles/client-scope.adoc index 4df5f938b4..46c589d8d5 100644 --- a/topics/roles/client-scope.adoc +++ b/topics/roles/client-scope.adoc @@ -1,4 +1,4 @@ -[[_client-scope]] +[[_client_scope]] === Client Scope @@ -20,7 +20,7 @@ image:../../{{book.images}}/full-client-scope.png[] As you can see from the picture, you can see that the effect roles of the scope are every declared role in the realm. To change this default behavior, you must explicitly turn off the `Full Scope Allowed` switch and declare the specific roles you want in each individual -client. Alternatively, you can also use <> +client. Alternatively, you can also use <> to define the scope for a whole set of clients. .Partial Scope diff --git a/topics/roles/user-role-mappings/default-roles.adoc b/topics/roles/user-role-mappings/default-roles.adoc index fa082d1361..dc5317c32d 100644 --- a/topics/roles/user-role-mappings/default-roles.adoc +++ b/topics/roles/user-role-mappings/default-roles.adoc @@ -2,7 +2,7 @@ ==== Default Roles Default roles allow you to automatically assign user role mappings when any user is newly created or imported through -<> or <>. +<> or <>. To specify _default roles_ go to the `Roles` left menu item, and click the `Default Roles` tab. .Default Roles diff --git a/topics/sso-protocols/oidc.adoc b/topics/sso-protocols/oidc.adoc index 1d1a3d001f..aface00786 100644 --- a/topics/sso-protocols/oidc.adoc +++ b/topics/sso-protocols/oidc.adoc @@ -55,7 +55,9 @@ to provide a client secret when they exchange the temporary codes for tokens. _ _Public_ clients are perfectly fine so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the client. HTML5/Javascript clients actually always have to be _public_ clients because there is no way to transmit the client secret to them in a secure manner. Again, this is ok so long as you use HTTPS and strictly enforce redirect URI registration. This guide goes more detail -into this in the <> chapter. +into this in the + +// DOCS REMARK: Please update the cross-reference as it does not resolve correctly. <> chapter. ===== Implicit Flow diff --git a/topics/threat/scope.adoc b/topics/threat/scope.adoc index f15df59e71..3e69e6527e 100644 --- a/topics/threat/scope.adoc +++ b/topics/threat/scope.adoc @@ -4,5 +4,5 @@ By default, each new client applications has an unlimited scope. This means that every access token that is created for that client will contain all the permissions the user has. If the client gets compromised and the access token is leaked, then each system that the user has permission to access is now also compromised. It is highly suggested -that you limit the roles an access token is assigned by using the <> for each client. +that you limit the roles an access token is assigned by using the <> for each client.