From 911336913b959e7d728b5c198b102b2ca239c70c Mon Sep 17 00:00:00 2001 From: Kohei Tamura Date: Tue, 29 May 2018 17:02:18 +0900 Subject: [PATCH] Fix typos and improve readability (#381) --- .../topics/auth-services-overview.adoc | 2 +- .../topics/enforcer-claim-information-point.adoc | 2 +- .../secure-jboss-app/install-client-adapter.adoc | 4 ++-- internal_resources/styleguide.adoc | 2 +- internal_resources/testing.adoc | 2 +- .../content/advanced_concepts/advanced_concepts.adoc | 4 ++-- openshift/content/tutorials/tutorials.adoc | 4 ++-- securing_apps/topics/client-registration.adoc | 4 ++-- securing_apps/topics/oidc/java/adapter-context.adoc | 2 +- securing_apps/topics/oidc/java/fuse/hawtio.adoc | 2 +- .../topics/oidc/java/java-adapter-config.adoc | 4 ++-- securing_apps/topics/oidc/java/jboss-adapter.adoc | 8 ++++---- securing_apps/topics/oidc/javascript-adapter.adoc | 2 +- securing_apps/topics/oidc/nodejs-adapter.adoc | 2 +- securing_apps/topics/oidc/oidc-generic.adoc | 2 +- .../jboss-adapter/jboss_adapter_installation.adoc | 6 +++--- securing_apps/topics/saml/java/logout.adoc | 6 +++--- .../topics/saml/java/saml-jboss-adapter.adoc | 4 ++-- securing_apps/topics/saml/mod-auth-mellon.adoc | 4 ++-- .../topics/token-exchange/token-exchange.adoc | 4 ++-- server_admin/topics/admin-cli.adoc | 8 ++++---- .../topics/admin-console-permissions/fine-grain.adoc | 2 +- server_admin/topics/authentication/kerberos.adoc | 2 +- server_admin/topics/authentication/x509.adoc | 12 ++++++------ server_admin/topics/clients/protocol-mappers.adoc | 2 +- .../topics/identity-broker/social/openshift.adoc | 8 ++++---- server_admin/topics/realms/email.adoc | 4 ++-- server_admin/topics/sso-protocols/saml.adoc | 2 +- server_admin/topics/user-federation.adoc | 4 ++-- server_admin/topics/user-federation/ldap.adoc | 4 ++-- server_development/topics/auth-spi.adoc | 2 +- .../topics/user-storage/simple-example.adoc | 2 +- server_installation/topics/manage.adoc | 2 +- upgrading/topics/keycloak/changes.adoc | 6 +++--- 34 files changed, 65 insertions(+), 65 deletions(-) diff --git a/authorization_services/topics/auth-services-overview.adoc b/authorization_services/topics/auth-services-overview.adoc index f61440fb1c..1cf12a2ff3 100644 --- a/authorization_services/topics/auth-services-overview.adoc +++ b/authorization_services/topics/auth-services-overview.adoc @@ -13,7 +13,7 @@ mechanisms such as: * **User-based access control (UBAC)** * **Context-based access control (CBAC)** * **Rule-based access control** - ** Using Javascript + ** Using JavaScript ** Using JBoss Drools * **Time-based access control** * **Support for custom access control mechanisms (ACMs) through a Policy Provider Service Provider Interface (SPI)** diff --git a/authorization_services/topics/enforcer-claim-information-point.adoc b/authorization_services/topics/enforcer-claim-information-point.adoc index 882ac0e03f..24d8a80818 100644 --- a/authorization_services/topics/enforcer-claim-information-point.adoc +++ b/authorization_services/topics/enforcer-claim-information-point.adoc @@ -10,7 +10,7 @@ to the policy-enforcer in order to resolve claims from different sources, such a * Static values defined in configuration * Any other source by implementing the Claim Information Provider SPI -When pushing claims to the {project_name} server, policies can base decisions not only on who an user is but also by taking +When pushing claims to the {project_name} server, policies can base decisions not only on who a user is but also by taking context and contents into account, based on who, what, why, when, where, and which for a given transaction. It is all about Contextual-based Authorization and how to use runtime information in order to support fine-grained authorization decisions. diff --git a/getting_started/topics/secure-jboss-app/install-client-adapter.adoc b/getting_started/topics/secure-jboss-app/install-client-adapter.adoc index eb02490231..052075fb04 100644 --- a/getting_started/topics/secure-jboss-app/install-client-adapter.adoc +++ b/getting_started/topics/secure-jboss-app/install-client-adapter.adoc @@ -31,14 +31,14 @@ $ ./jboss-cli.sh --file=adapter-install-offline.cli ---- ifeval::[{project_community}==true] -.Wildfly 11 and Linux/Unix +.WildFly 11 and Linux/Unix [source] ---- $ cd bin $ ./jboss-cli.sh --file=adapter-elytron-install-offline.cli ---- -.Wildfly 11 and Windows +.WildFly 11 and Windows [source] ---- > cd bin diff --git a/internal_resources/styleguide.adoc b/internal_resources/styleguide.adoc index a2157adc68..bbca32ef7d 100644 --- a/internal_resources/styleguide.adoc +++ b/internal_resources/styleguide.adoc @@ -36,7 +36,7 @@ Writers will also refer to these: * Do not use Latin abbreviations, such as e.g., etc., and i.e. ** Instead, use "and so on" when you list a clear sequence of elements, such as "1, 2, 3, and so on". Otherwise, rewrite the sentence to replace etc. with something more descriptive, -such as "and other output." +such as "and other output". ** Instead of i.e. use "that is". ** Instead of e.g. use "for example" or "such as". * Do not use "&" in place of "and". diff --git a/internal_resources/testing.adoc b/internal_resources/testing.adoc index 15bdeb4a4f..ce998977c8 100644 --- a/internal_resources/testing.adoc +++ b/internal_resources/testing.adoc @@ -7,7 +7,7 @@ Currently we are testing the following: * Variables - check if there are variables that are not resolved * Includes - check if there are includes where the included file is not found * Images - check if there are images included that are not missing -* Internal links - check that all internal links (HTML anchors) point to an valid id +* Internal links - check that all internal links (HTML anchors) point to a valid id * External links - check that all external links work, including HTML anchors More details about each test below and what to do if the tests are not working. diff --git a/openshift/content/advanced_concepts/advanced_concepts.adoc b/openshift/content/advanced_concepts/advanced_concepts.adoc index 85713af90b..fa0295d4f8 100644 --- a/openshift/content/advanced_concepts/advanced_concepts.adoc +++ b/openshift/content/advanced_concepts/advanced_concepts.adoc @@ -274,7 +274,7 @@ When deploying RH-SSO application template, *_SSO_ADMIN_USERNAME_* and *_SSO_ADM [IMPORTANT] ==== -The lifespan of the RH-SSO server's administrator account depends upon the the storage type used to store the RH-SSO server's database: +The lifespan of the RH-SSO server's administrator account depends upon the storage type used to store the RH-SSO server's database: * For an in-memory database mode (*_sso72-https_* and *_sso72-x509-https_* templates) the account exists throughout the lifecycle of the particular RH-SSO pod (stored account data is lost upon pod destruction), * For an ephemeral database mode (*_sso72-mysql_* and *_sso72-postgresql_* templates) the account exists throughout the lifecycle of the database pod (even if the RH-SSO pod is destructed, the stored account data is preserved under the assumption that the database pod is still running), @@ -351,7 +351,7 @@ sh-4.2$ ./jboss-cli.sh --connect ':reload' ==== When restarting the server it is important to restart just the JBoss EAP process within the running RH-SSO container, and not the whole container. This is because restarting the whole container will recreate it from scratch, without the RH-SSO server administration account for the `master` realm. ==== -. Log in to the `master` realm's administration console of the RH-SSO server using the the credentials created in the steps above. In the browser, navigate to *\http://sso-./auth/admin* for the RH-SSO web server, or to *\https://secure-sso-./auth/admin* for the encrypted RH-SSO web server, and specify the user name and password used to create the administrator user. +. Log in to the `master` realm's administration console of the RH-SSO server using the credentials created in the steps above. In the browser, navigate to *\http://sso-./auth/admin* for the RH-SSO web server, or to *\https://secure-sso-./auth/admin* for the encrypted RH-SSO web server, and specify the user name and password used to create the administrator user. === Deployment Process diff --git a/openshift/content/tutorials/tutorials.adoc b/openshift/content/tutorials/tutorials.adoc index 72beb9c1a6..92e17374f6 100644 --- a/openshift/content/tutorials/tutorials.adoc +++ b/openshift/content/tutorials/tutorials.adoc @@ -1510,7 +1510,7 @@ Export the SAML Keys: Download the Client Adapter: . Click *Installation*. -. Use the *Format Option* drop-down menu to select a format. This example uses *Keycloak SAML Wildfly/JBoss Subsystem*. +. Use the *Format Option* drop-down menu to select a format. This example uses *Keycloak SAML WildFly/JBoss Subsystem*. . Click *Download* and save the file *keycloak-saml-subsystem.xml*. The *keystore-saml.jks* will be used with the other EAP keystores in the next section to create an OpenShift secret for the EAP application project. Copy the *keystore-saml.jks* file to an OpenShift node. + @@ -1583,7 +1583,7 @@ The *keycloak-saml-subsystem.xml*, exported from the RH-SSO client in a previous + The mount path of the *keystore-saml.jks* (in this example *_/etc/eap-secret-volume/keystore-saml.jks_*) can be specified in the application template with the parameter *EAP_HTTPS_KEYSTORE_DIR*. + The aliases and passwords for the *PrivateKey* and the *Certificate* were configured when the SAML Keys were exported from the RH-SSO client. -. Delete the second ** tag and key and replace it with the the realm certificate information: +. Delete the second ** tag and key and replace it with the realm certificate information: + ---- ... diff --git a/securing_apps/topics/client-registration.adoc b/securing_apps/topics/client-registration.adoc index eb6ea8aea9..8cf07ddd8a 100644 --- a/securing_apps/topics/client-registration.adoc +++ b/securing_apps/topics/client-registration.adoc @@ -101,7 +101,7 @@ To do this include the following header in the request: Authorization: basic BASE64(client-id + ':' + client-secret) ---- -To retrieve the Adapter Configuration then perfrom an HTTP GET request to `/realms//clients-registrations/install/`. +To retrieve the Adapter Configuration then perform 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. @@ -187,7 +187,7 @@ Currently we have these policy implementations: * Trusted Hosts Policy - You can configure list of trusted hosts and trusted domains. Request to Client Registration Service can be sent just from those hosts or domains. Request sent from some untrusted IP will be rejected. URLs of newly registered client must also use just those trusted hosts or domains. For example it won't be allowed -to set `Redirect URI` of client pointing to some untrusted host. By default, there is not any whitelisted host, so anonymous client registration is de-facto disabled by default. +to set `Redirect URI` of client pointing to some untrusted host. By default, there is not any whitelisted host, so anonymous client registration is de-facto disabled. * Consent Required Policy - Newly registered clients will have `Consent Allowed` switch enabled. So after successful authentication, user will always see consent screen when he needs to approve personal info and permissions (protocol mappers and roles). It means that client won't have access to any personal diff --git a/securing_apps/topics/oidc/java/adapter-context.adoc b/securing_apps/topics/oidc/java/adapter-context.adoc index a04d36967d..7d74a2fcb7 100644 --- a/securing_apps/topics/oidc/java/adapter-context.adoc +++ b/securing_apps/topics/oidc/java/adapter-context.adoc @@ -10,7 +10,7 @@ httpServletRequest .getAttribute(KeycloakSecurityContext.class.getName()); ---- -Or, it is available in secure and insecure requests in the HttpSession: +Or, it is available in insecured requests in the HttpSession: [source,java] ---- diff --git a/securing_apps/topics/oidc/java/fuse/hawtio.adoc b/securing_apps/topics/oidc/java/fuse/hawtio.adoc index 6a679ce599..30ee9ebb20 100644 --- a/securing_apps/topics/oidc/java/fuse/hawtio.adoc +++ b/securing_apps/topics/oidc/java/fuse/hawtio.adoc @@ -16,7 +16,7 @@ hawtio.rolePrincipalClasses=org.keycloak.adapters.jaas.RolePrincipal,org.apache. . Create a client in the {project_name} administration console in your realm. For example, in the {project_name} `demo` realm, create a client `hawtio-client`, specify `public` as the Access Type, and specify a redirect URI pointing to Hawtio: \http://localhost:8181/hawtio/*. You must also have a corresponding Web Origin configured (in this case, \http://localhost:8181). -. Create the `keycloak-hawtio-client.json` file in the `$FUSE_HOME/etc` directory using content similar to that shown in the example below. Change the `realm`, `resource`, and `auth-server-url` properties according to your {project_name} environment. The `resource` property must point to the client created in the previous step. This file is used by the client (Hawtio Javascript application) side. +. Create the `keycloak-hawtio-client.json` file in the `$FUSE_HOME/etc` directory using content similar to that shown in the example below. Change the `realm`, `resource`, and `auth-server-url` properties according to your {project_name} environment. The `resource` property must point to the client created in the previous step. This file is used by the client (Hawtio JavaScript application) side. + [source,json] ---- diff --git a/securing_apps/topics/oidc/java/java-adapter-config.adoc b/securing_apps/topics/oidc/java/java-adapter-config.adoc index e9e4b53b33..fa30b84027 100644 --- a/securing_apps/topics/oidc/java/java-adapter-config.adoc +++ b/securing_apps/topics/oidc/java/java-adapter-config.adoc @@ -45,7 +45,7 @@ This is what one might look like: You can use `${...}` enclosure for system property replacement. For example `${jboss.server.config.dir}` would be replaced by `/path/to/{project_name}`. Replacement of environment variables is also supported via the `env` prefix, e.g. `${env.MY_ENVIRONMENT_VARIABLE}`. -The initial config file can be obtained from the the admin console. This can be done by opening the admin console, select `Clients` from the menu and clicking +The initial config file can be obtained from the admin console. This can be done by opening the admin console, select `Clients` from the menu and clicking on the corresponding client. Once the page for the client is opened click on the `Installation` tab and select `Keycloak OIDC JSON`. Here is a description of each configuration option: @@ -136,7 +136,7 @@ enable-basic-auth:: The default value is _false_. expose-token:: - If `true`, an authenticated browser client (via a Javascript HTTP invocation) can obtain the signed access token via the URL `root/k_query_bearer_token`. + If `true`, an authenticated browser client (via a JavaScript HTTP invocation) can obtain the signed access token via the URL `root/k_query_bearer_token`. This is _OPTIONAL_. The default value is _false_. diff --git a/securing_apps/topics/oidc/java/jboss-adapter.adoc b/securing_apps/topics/oidc/java/jboss-adapter.adoc index 29b3f1395a..b5a902ee1d 100644 --- a/securing_apps/topics/oidc/java/jboss-adapter.adoc +++ b/securing_apps/topics/oidc/java/jboss-adapter.adoc @@ -1,7 +1,7 @@ [[_jboss_adapter]] ifeval::[{project_community}==true] -==== JBoss EAP/Wildfly Adapter +==== JBoss EAP/WildFly Adapter endif::[] ifeval::[{project_product}==true] ==== JBoss EAP Adapter @@ -29,7 +29,7 @@ Adapters are available as a separate archive depending on what server version yo NOTE: {appserver_name} should be running when you install the adapter. If you have either one running, you must stop it before installing and then restart it after installation is complete. ifeval::[{project_community}==true] -Install on Wildfly 9, 10 or 11: +Install on WildFly 9, 10 or 11: [source, subs="attributes"] ---- @@ -37,7 +37,7 @@ $ cd $WILDFLY_HOME $ unzip keycloak-wildfly-adapter-dist-{project_version}.zip ---- -Install on Wildfly 8: +Install on WildFly 8: [source, subs="attributes"] ---- @@ -138,7 +138,7 @@ NOTE: The offline script is not available for JBoss EAP 6.4 Alternatively, if the server is running execute: ifeval::[{project_community}==true] -.Wildfly 11 +.WildFly 11 [source] ---- $ ./bin/jboss-cli.sh --file=adapter-elytron-install.cli diff --git a/securing_apps/topics/oidc/javascript-adapter.adoc b/securing_apps/topics/oidc/javascript-adapter.adoc index a058314c4e..fb685932e3 100644 --- a/securing_apps/topics/oidc/javascript-adapter.adoc +++ b/securing_apps/topics/oidc/javascript-adapter.adoc @@ -1,5 +1,5 @@ [[_javascript_adapter]] -=== Javascript Adapter +=== JavaScript Adapter {project_name} comes with a client-side JavaScript library that can be used to secure HTML5/JavaScript applications. The JavaScript adapter has built-in support for Cordova applications. diff --git a/securing_apps/topics/oidc/nodejs-adapter.adoc b/securing_apps/topics/oidc/nodejs-adapter.adoc index f5bc8e23b4..16f43318c7 100644 --- a/securing_apps/topics/oidc/nodejs-adapter.adoc +++ b/securing_apps/topics/oidc/nodejs-adapter.adoc @@ -115,7 +115,7 @@ Once instantiated, install the middleware into your connect-capable app: Simple authentication:: -To enforce that an user must be authenticated before accessing a resource, +To enforce that a user must be authenticated before accessing a resource, simply use a no-argument version of `keycloak.protect()`: [source,javascript] diff --git a/securing_apps/topics/oidc/oidc-generic.adoc b/securing_apps/topics/oidc/oidc-generic.adoc index add4a2df5b..793a20cf5e 100644 --- a/securing_apps/topics/oidc/oidc-generic.adoc +++ b/securing_apps/topics/oidc/oidc-generic.adoc @@ -109,7 +109,7 @@ For more details refer to the http://openid.net/specs/openid-connect-core-1_0.ht ===== Implicit -The Implicit flow redirects works similarly to the Authorization Code flow, but instead of returning a Authorization Code the Access Token and ID Token is +The Implicit flow redirects works similarly to the Authorization Code flow, but instead of returning an Authorization Code the Access Token and ID Token is returned. This reduces the need for the extra invocation to exchange the Authorization Code for an Access Token. However, it does not include a Refresh Token. This results in the need to either permit Access Tokens with a long expiration, which is problematic as it's very hard to invalidate these. Or requires a new redirect to obtain new Access Token once the initial Access Token has expired. The Implicit flow is useful if the application only wants to diff --git a/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc b/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc index 786823a96b..2047f61d38 100644 --- a/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc +++ b/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc @@ -5,7 +5,7 @@ Each adapter is a separate download on the {project_name} download site. ifeval::[{project_community}==true] -Install on Wildfly 9 or 10, 11 or JBoss EAP 7: +Install on WildFly 9 or 10, 11 or JBoss EAP 7: [source] ---- @@ -42,7 +42,7 @@ $ unzip rh-sso-saml-eap6-adapter.zip endif::[] -These zip files create new JBoss Modules specific to the Wildfly/JBoss EAP SAML Adapter within your Wildfly or JBoss EAP distro. +These zip files create new JBoss Modules specific to the WildFly/JBoss EAP SAML Adapter within your WildFly or JBoss EAP distro. After adding the modules, you must then enable the {project_name} SAML Subsystem within your app server's server configuration: `domain.xml` or `standalone.xml`. @@ -50,7 +50,7 @@ There is a CLI script that will help you modify your server configuration. Start the server and run the script from the server's bin directory: ifeval::[{project_community}==true] -.Wildfly 11 +.WildFly 11 [source] ---- $ ./bin/jboss-cli.sh --file=adapter-elytron-install-saml.cli diff --git a/securing_apps/topics/saml/java/logout.adoc b/securing_apps/topics/saml/java/logout.adoc index 1a51eae10b..9f12f4a57f 100644 --- a/securing_apps/topics/saml/java/logout.adoc +++ b/securing_apps/topics/saml/java/logout.adoc @@ -9,13 +9,13 @@ This will log you out if you have an SSO session with your browser. ===== Logout in Clustered Environment Internally, the SAML adapter stores a mapping between the SAML session index, principal name (when known), and HTTP session ID. -This mapping can be maintained in JBoss application server family (Wildfly 10/11, EAP 6/7) across cluster for distributable +This mapping can be maintained in JBoss application server family (WildFly 10/11, EAP 6/7) across cluster for distributable applications. As a precondition, the HTTP sessions need to be distributed across cluster (i.e. application is marked with `` tag in application's `web.xml`). To enable the functionality, add the following section to your `/WEB_INF/web.xml` file: -For EAP 7, Wildfly 10/11: +For EAP 7, WildFly 10/11: [source,xml] ---- @@ -51,7 +51,7 @@ to SAML session index to HTTP session mapping which would lead to unsuccessful l [[_saml_logout_in_cross_dc]] ===== Logout in Cross DC Scenario -The cross DC scenario only applies to Wildfly 10 and higher, and EAP 7 and higher. +The cross DC scenario only applies to WildFly 10 and higher, and EAP 7 and higher. Special handling is needed for handling sessions that span multiple data centers. Imagine the following scenario: diff --git a/securing_apps/topics/saml/java/saml-jboss-adapter.adoc b/securing_apps/topics/saml/java/saml-jboss-adapter.adoc index ef7083b061..722139552d 100644 --- a/securing_apps/topics/saml/java/saml-jboss-adapter.adoc +++ b/securing_apps/topics/saml/java/saml-jboss-adapter.adoc @@ -1,14 +1,14 @@ [[_saml_jboss_adapter]] ifeval::[{project_community}==true] -==== JBoss EAP/Wildfly Adapter +==== JBoss EAP/WildFly Adapter endif::[] ifeval::[{project_product}==true] ==== JBoss EAP Adapter endif::[] ifeval::[{project_community}==true] -To be able to secure WAR apps deployed on JBoss EAP or Wildfly, you must install and configure the {project_name} SAML Adapter Subsystem. +To be able to secure WAR apps deployed on JBoss EAP or WildFly, you must install and configure the {project_name} SAML Adapter Subsystem. endif::[] ifeval::[{project_product}==true] To be able to secure WAR apps deployed on JBoss EAP, you must install and configure the {project_name} SAML Adapter Subsystem. diff --git a/securing_apps/topics/saml/mod-auth-mellon.adoc b/securing_apps/topics/saml/mod-auth-mellon.adoc index 32a5c4efd5..6243486b38 100644 --- a/securing_apps/topics/saml/mod-auth-mellon.adoc +++ b/securing_apps/topics/saml/mod-auth-mellon.adoc @@ -189,8 +189,8 @@ To configure the IdP to supply the user's groups as as a SAML attribute, complet . Click the Mappers tab of the client. . In the upper right corner of the Mappers page, click *Create*. . From the Mapper Type drop-down list select *Group list*. -. Set Name to "group list." -. Set the SAML attribute name to "groups." +. Set Name to "group list". +. Set the SAML attribute name to "groups". . Click *Save*. The remaining steps are performed on $sp_host. diff --git a/securing_apps/topics/token-exchange/token-exchange.adoc b/securing_apps/topics/token-exchange/token-exchange.adoc index dc65e6e569..6121cff2b4 100644 --- a/securing_apps/topics/token-exchange/token-exchange.adoc +++ b/securing_apps/topics/token-exchange/token-exchange.adoc @@ -8,7 +8,7 @@ include::../templates/techpreview.adoc[] In {project_name}, token exchange is the process of using a set of credentials or token to obtain an entirely different token. A client may want to invoke on a less trusted application so it may want to downgrade the current token it has. -A client may want to exchange a {project_token} for a token stored for a linked social provider account. +A client may want to exchange a {project_name} token for a token stored for a linked social provider account. You may want to trust external tokens minted by other {project_name} realms or foreign IDPs. A client may have a need to impersonate a user. Here's a short summary of the current capabilities of {project_name} around token exchange. @@ -85,7 +85,7 @@ a JSON document as described in the link:https://www.ietf.org/id/draft-ietf-oaut 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 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`. diff --git a/server_admin/topics/admin-cli.adoc b/server_admin/topics/admin-cli.adoc index 741733fd3b..12042bc8ba 100644 --- a/server_admin/topics/admin-cli.adoc +++ b/server_admin/topics/admin-cli.adoc @@ -91,7 +91,7 @@ c:\> kcadm config truststore --trustpass %PASSWORD% %HOMEPATH%\.keycloak\trustst === Authenticating -When you log in with the Admin CLI, you specify a server endpoint URL and a realm, and then you specify a user name. Another option is to specify only a clientId, which results in using a special "service account." When you log in using a user name, you must use a password for the specified user. When you log in using a clientId, you only need the client secret, not the user password. You could also use [command]`Signed JWT` instead of the client secret. +When you log in with the Admin CLI, you specify a server endpoint URL and a realm, and then you specify a user name. Another option is to specify only a clientId, which results in using a special "service account". When you log in using a user name, you must use a password for the specified user. When you log in using a clientId, you only need the client secret, not the user password. You could also use [command]`Signed JWT` instead of the client secret. Make sure the account used for the session has the proper permissions to invoke Admin REST API operations. For example, the `realm-admin` role of the `realm-management` client allows the user to administer the realm within which the user is defined. @@ -119,7 +119,7 @@ Run the [command]`kcadm.sh config credentials --help` command for more informati [[_working_with_alternative_configurations]] === Working with alternative configurations -By default, the Admin CLI automatically maintains a configuration file called [filename]kcadm.config located under the user's home directory. In Linux-based systems, the full path name is [filename]$HOME/.keycloak/kcadm.config. On Windows, the full path name is [filename]%HOMEPATH%\.keycloak\kcadm.config. You can use the [command]`--config` option to point to a different file or location so you can maintain multiple authenticated sessions in parallel. +By default, the Admin CLI automatically maintains a configuration file called [filename]`kcadm.config` located under the user's home directory. In Linux-based systems, the full path name is [filename]`$HOME/.keycloak/kcadm.config`. On Windows, the full path name is [filename]`%HOMEPATH%\.keycloak\kcadm.config`. You can use the [command]`--config` option to point to a different file or location so you can maintain multiple authenticated sessions in parallel. [NOTE] ==== @@ -858,7 +858,7 @@ $ kcadm.sh get clients/c7b8547f-e748-4333-95d0-410b76b3f4a3/installation/provide ---- [discrete] -==== Getting a Wildfly subsystem adapter configuration for a specific client +==== Getting a WildFly subsystem adapter configuration for a specific client Use a client's ID to construct an endpoint URI that targets a specific client, such as [filename]`clients/ID/installation/providers/keycloak-oidc-jboss-subsystem`. @@ -1635,7 +1635,7 @@ $ kcadm.sh create components -r demorealm -s name=msad-user-account-control-mapp ---- [discrete] -==== Adding an user attribute LDAP mapper +==== Adding a user attribute LDAP mapper . Run the [command]`create` command on the [filename]`components` endpoint. . Set the [command]`providerType` attribute to [filename]`org.keycloak.storage.ldap.mappers.LDAPStorageMapper`. diff --git a/server_admin/topics/admin-console-permissions/fine-grain.adoc b/server_admin/topics/admin-console-permissions/fine-grain.adoc index d8281a0d44..dec7f1bf06 100644 --- a/server_admin/topics/admin-console-permissions/fine-grain.adoc +++ b/server_admin/topics/admin-console-permissions/fine-grain.adoc @@ -71,7 +71,7 @@ the `Authorization` link shown in the above image. Then click on the policies ta There's a pull down menu on this page called `Create policy`. There's a multitude of policies you can define. You can define a policy that is associated with a role or a group or even define -rules in Javascript. For this simple example, we're going to create a `User Policy`. +rules in JavaScript. For this simple example, we're going to create a `User Policy`. .User Policy image:{project_images}/fine-grain-client-user-policy.png[] diff --git a/server_admin/topics/authentication/kerberos.adoc b/server_admin/topics/authentication/kerberos.adoc index 07804c30a2..5d80d06727 100644 --- a/server_admin/topics/authentication/kerberos.adoc +++ b/server_admin/topics/authentication/kerberos.adoc @@ -65,7 +65,7 @@ The Keytab file `/tmp/http.keytab` will need to be accessible on the host where You need to install a kerberos client on your machine. This is also platform dependent. If you are on Fedora, Ubuntu or RHEL, you can install the package `freeipa-client`, which contains a Kerberos client and several other utilities. -Configure the kerberos client (on linux it's in file `/etc/krb5.conf` ). You need to put your Kerberos realm and at least configure the HTTP domains your server will be running on. +Configure the kerberos client (on Linux it's in file `/etc/krb5.conf` ). You need to put your Kerberos realm and at least configure the HTTP domains your server will be running on. For the example realm MYDOMAIN.ORG you may configure the `domain_realm` section like this: [source] diff --git a/server_admin/topics/authentication/x509.adoc b/server_admin/topics/authentication/x509.adoc index 1a07f3c38f..176e5250fb 100644 --- a/server_admin/topics/authentication/x509.adoc +++ b/server_admin/topics/authentication/x509.adoc @@ -54,10 +54,10 @@ Other Features: Extended Certificate Validation:: ==== Enable X.509 Client Certificate User Authentication -The following sections describe how to configure Wildfly/Undertow and the {project_name} Server to enable X.509 client certificate authentication. +The following sections describe how to configure WildFly/Undertow and the {project_name} Server to enable X.509 client certificate authentication. Enable mutual SSL in WildFly:: -See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-EnableSSL[Enable SSL] and link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-%7B%7B%3Cssl%2F%3E%7D%7D[SSL] for the instructions how to enable SSL in Wildfly. +See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-EnableSSL[Enable SSL] and link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-%7B%7B%3Cssl%2F%3E%7D%7D[SSL] for the instructions how to enable SSL in WildFly. * Open {project_dirref}/standalone/configuration/standalone.xml and add a new realm: ```xml @@ -112,7 +112,7 @@ The password to open the truststore Enable https listener:: -See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-HTTPSlistener[HTTPS Listener] for the instructions how to enable HTTPS in Wildfly. +See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-HTTPSlistener[HTTPS Listener] for the instructions how to enable HTTPS in WildFly. * Add the element as shown below: @@ -139,7 +139,7 @@ If set to `REQUESTED`, the server will optionally ask for a client certificate. * Select a realm, click on Authentication link, select the "Browser" flow * Make a copy of the built-in "Browser" flow. You may want to give the new flow a distinctive name, i.e. "X.509 Browser" -* Using the drop down, select the copied flow, and click on "Add Execution" +* Using the drop down, select the copied flow, and click on "Add execution" * Select "X509/Validate User Form" using the drop down and click on "Save" image:images/x509-execution.png[] @@ -196,8 +196,8 @@ If set, X.509 client certificate authentication will not prompt the user to conf * Using {project_name} admin console, click on "Authentication" and select the "Direct Grant" flow, * Make a copy of the build-in "Direct Grant" flow. You may want to give the new flow a distinctive name, i.e. "X509 Direct Grant", -* Delete "Validate Username" and "Password" authenticators, -* Click on "Execution" and add "X509/Validate Username" and click on "Save" to add the execution step to the parent flow. +* Delete "Username Validation" and "Password" authenticators, +* Click on "Add execution" and add "X509/Validate Username" and click on "Save" to add the execution step to the parent flow. image:images/x509-directgrant-execution.png[] diff --git a/server_admin/topics/clients/protocol-mappers.adoc b/server_admin/topics/clients/protocol-mappers.adoc index 841e0a6d76..2c5d8b91c2 100644 --- a/server_admin/topics/clients/protocol-mappers.adoc +++ b/server_admin/topics/clients/protocol-mappers.adoc @@ -32,7 +32,7 @@ are common to all mappers: Consent Required:: If your client requires consent, this mapper will be displayed on the consent screen shown to the user. Consent Text:: - If your client requires consent and the `Consent` switch is on, this is the text that will be displayed by the user. + If your client requires consent and the `Consent Required` switch is on, this is the text that will be displayed by the user. The value for this text is localizable by specifying a substitution variable with `$\{var-name}` strings. The localized value is then configured within property files in your theme. See the link:{developerguide_link}[{developerguide_name}] for more information on localization. diff --git a/server_admin/topics/identity-broker/social/openshift.adoc b/server_admin/topics/identity-broker/social/openshift.adoc index 782cb7b641..2968689b1e 100644 --- a/server_admin/topics/identity-broker/social/openshift.adoc +++ b/server_admin/topics/identity-broker/social/openshift.adoc @@ -1,10 +1,10 @@ -==== Openshift +==== OpenShift -NOTE: Openshift Online is currently in the developer preview mode. This documentation has been based on on-premise installations and local `minishift` development environment. +NOTE: OpenShift Online is currently in the developer preview mode. This documentation has been based on on-premise installations and local `minishift` development environment. There are a just a few steps you have to complete to be able to login to OpenShift. First, go to the `Identity Providers` left menu item -and select `Openshift` from the `Add provider` drop down list. This will bring you to the `Add identity provider` page. +and select `OpenShift` from the `Add provider` drop down list. This will bring you to the `Add identity provider` page. .Add Identity Provider image:images/openshift-add-identity-provider.png[] @@ -36,4 +36,4 @@ grantMethod: prompt <4> Use client ID and secret defined by `oc create` command to enter them back on the {project_name} `Add identity provider` page. Go back to {project_name} and specify those items. -Please refer to https://docs.openshift.org/latest/architecture/additional_concepts/authentication.html#oauth[official Openshift documentation] for more detailed guides. +Please refer to https://docs.openshift.org/latest/architecture/additional_concepts/authentication.html#oauth[official OpenShift documentation] for more detailed guides. diff --git a/server_admin/topics/realms/email.adoc b/server_admin/topics/realms/email.adoc index 76eaa71a90..3e18803a73 100644 --- a/server_admin/topics/realms/email.adoc +++ b/server_admin/topics/realms/email.adoc @@ -21,13 +21,13 @@ From:: `From` denotes the address used for the `From` SMTP-Header for the emails sent. From Display Name:: - `From Display Name` allows to configure an user friendly email address aliases (optional). If not set the plain `From` email address will be displayed in email clients. + `From Display Name` allows to configure a user friendly email address aliases (optional). If not set the plain `From` email address will be displayed in email clients. Reply To:: `Reply To` denotes the address used for the `Reply-To` SMTP-Header for the mails sent (optional). If not set the plain `From` email address will be used. Reply To Display Name:: - `Reply To Display Name` allows to configure an user friendly email address aliases (optional). If not set the plain `Reply To` email address will be displayed. + `Reply To Display Name` allows to configure a user friendly email address aliases (optional). If not set the plain `Reply To` email address will be displayed. Envelope From:: `Envelope From` denotes the https://en.wikipedia.org/wiki/Bounce_address[Bounce Address] used for the `Return-Path` SMTP-Header for the mails sent (optional). diff --git a/server_admin/topics/sso-protocols/saml.adoc b/server_admin/topics/sso-protocols/saml.adoc index a139300b12..81118bed44 100644 --- a/server_admin/topics/sso-protocols/saml.adoc +++ b/server_admin/topics/sso-protocols/saml.adoc @@ -7,7 +7,7 @@ of WS-* specifications so it tends to be a bit more verbose than OIDC. SAML 2.0 that works by exchanging XML documents between the authentication server and the application. XML signatures and encryption is used to verify requests and responses. -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 specify 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/server_admin/topics/user-federation.adoc b/server_admin/topics/user-federation.adoc index 4ea048217c..434d72fb47 100644 --- a/server_admin/topics/user-federation.adoc +++ b/server_admin/topics/user-federation.adoc @@ -16,7 +16,7 @@ runtime. This common user model can then be mapped to OIDC token claims and SAM External user databases rarely have every piece of data need to support all the features that {project_name} has. In this case, the User Storage Provider can opt to store some things locally in the {project_name} user store. Some providers even import the user locally and sync periodically with the external store. All this depends on the capabilities of the provider and how its configured. For example, your -external user store may not support OTP. Depending on the provider, this OTP support can be handled and stored by {project_name} +external user store may not support OTP. Depending on the provider, this OTP can be handled and stored by {project_name}. === Adding a Provider @@ -25,7 +25,7 @@ To add a storage provider go to the `User Federation` left menu item in the Admi .User Federation image:{project_images}/user-federation.png[] -On the right side, there is an `Add Provider` list box. Choose the provider type you want to add and you will be brought to the configuration page of that provider. +On the center, there is an `Add Provider` list box. Choose the provider type you want to add and you will be brought to the configuration page of that provider. === Dealing with Provider Failures diff --git a/server_admin/topics/user-federation/ldap.adoc b/server_admin/topics/user-federation/ldap.adoc index e07b2b7ee7..f2b23ada55 100644 --- a/server_admin/topics/user-federation/ldap.adoc +++ b/server_admin/topics/user-federation/ldap.adoc @@ -30,7 +30,7 @@ a piece of data that a {project_name} feature needs that feature will not work. The benefit to this approach is that you do not have the overhead of importing and synchronizing a copy of the LDAP user into the {project_name} user database. -This storage mode is controled by the `Import Enabled` switch. Set to `On` to import users. +This storage mode is controled by the `Import Users` switch. Set to `On` to import users. ==== Edit Mode @@ -57,7 +57,7 @@ Console Display Name:: Name used when this provider is referenced in the admin console Priority:: - The priority of this provider when looking up users or for adding registrations. + The priority of this provider when looking up users or adding a user. Sync Registrations:: Does your LDAP support adding new users? Click this switch if you want new users created by {project_name} in the admin console or the registration page diff --git a/server_development/topics/auth-spi.adoc b/server_development/topics/auth-spi.adoc index d740cdf3f3..c2bc926c89 100644 --- a/server_development/topics/auth-spi.adoc +++ b/server_development/topics/auth-spi.adoc @@ -723,7 +723,7 @@ You cannot modify built in flows, so, to add the Authenticator we've created you I'm hoping the UI is intuitive enough so that you can figure out for yourself how to create a flow and add the FormAction. Basically you'll have to copy the registration flow. -Then click Actions menu to the right of the Registration Form, and pick "Add Execution" to add a new execution. +Then click Actions menu to the right of the Registration Form, and pick "Add execution" to add a new execution. You'll pick the FormAction from the selection list. Make sure your FormAction comes after "Registration User Creation" by using the down errors to move it if your FormAction isn't already listed after "Registration User Creation". You want your FormAction to come after user creation because the success() method of Regsitration User Creation is responsible for creating the new UserModel. diff --git a/server_development/topics/user-storage/simple-example.adoc b/server_development/topics/user-storage/simple-example.adoc index 9a7cd3328b..dafcf1004e 100644 --- a/server_development/topics/user-storage/simple-example.adoc +++ b/server_development/topics/user-storage/simple-example.adoc @@ -128,7 +128,7 @@ The `isValid()` method is responsible for validating passwords. The `CredentialI ===== CredentialInputUpdater Implementation -As noted before, the only reason we implement the `CredentialInputUpdater` interface in this example is to forbid modifications of user passwords. The reason we have to do this is because otherwise the runtime would allow the password to be overriden in {project_name} local storage. We'll talk more about this later in this chapter. +As noted before, the only reason we implement the `CredentialInputUpdater` interface in this example is to forbid modifications of user passwords. The reason we have to do this is because otherwise the runtime would allow the password to be overridden in {project_name} local storage. We'll talk more about this later in this chapter. [source,java] ---- diff --git a/server_installation/topics/manage.adoc b/server_installation/topics/manage.adoc index 6cc45c8a69..4d76cb6bd9 100644 --- a/server_installation/topics/manage.adoc +++ b/server_installation/topics/manage.adoc @@ -46,4 +46,4 @@ connect You may be thinking to yourself, "I didn't enter in any username or password!". If you run `jboss-cli` on the same machine as your running standalone server or domain controller and your account has appropriate file permissions, you do not have -to setup or enter in a admin username and password. See the link:{appserver_admindoc_link}[_{appserver_admindoc_name}_] for more details on how to make things more secure if you are uncomfortable with that setup. +to setup or enter in an admin username and password. See the link:{appserver_admindoc_link}[_{appserver_admindoc_name}_] for more details on how to make things more secure if you are uncomfortable with that setup. diff --git a/upgrading/topics/keycloak/changes.adoc b/upgrading/topics/keycloak/changes.adoc index c5a84ea697..7f4d31fa8b 100644 --- a/upgrading/topics/keycloak/changes.adoc +++ b/upgrading/topics/keycloak/changes.adoc @@ -200,7 +200,7 @@ You also need to update `keycloak-server.json` as it's changed due to this. ==== Adapter Subsystems only bring in dependencies if Keycloak is on -Previously, if you had installed our SAML or OIDC Keycloak subsystem adapters into Wildfly or JBoss EAP, we would automatically include Keycloak client jars into EVERY application irregardless if you were using Keycloak or not. +Previously, if you had installed our SAML or OIDC Keycloak subsystem adapters into WildFly or JBoss EAP, we would automatically include Keycloak client jars into EVERY application irregardless if you were using Keycloak or not. These libraries are now only added to your deployment if you have Keycloak authentication turned on for that adapter (via the subsystem, or auth-method in web.xml) ==== Client Registration service endpoints moved @@ -229,7 +229,7 @@ Same goes with mongo and Infinispan under modules keycloak-model-mongo and keycl ==== For adapters, session id changed after login -To plug a security attack vector, for platforms that support it (Tomcat 8, Undertow/Wildfly, Jetty 9), the Keycloak OIDC and SAML adapters will change the session id after login. +To plug a security attack vector, for platforms that support it (Tomcat 8, Undertow/WildFly, Jetty 9), the Keycloak OIDC and SAML adapters will change the session id after login. You can turn off this behavior check adapter config switches. ==== SAML SP Client Adapter Changes @@ -540,7 +540,7 @@ Facebook admin console). === Migrating from 1.0 Alpha 1 to Alpha 2 * DB Schema has changed. We don't have any data migration utilities yet as of Alpha 2. -* JBoss and Wildfly adapters are now installed via a {appserver_name} subsystem. Please review the adapter +* JBoss and WildFly adapters are now installed via a {appserver_name} subsystem. Please review the adapter installation documentation. Edits to standalone.xml are now required. * There is a new credential type "secret". Unlike other credential types, it is stored in plain text in the database and can be viewed in the admin console.