diff --git a/docs/documentation/authorization_services/topics/getting-started-overview.adoc b/docs/documentation/authorization_services/topics/getting-started-overview.adoc index a8bb6ed21fe..d844fa2cdf8 100644 --- a/docs/documentation/authorization_services/topics/getting-started-overview.adoc +++ b/docs/documentation/authorization_services/topics/getting-started-overview.adoc @@ -1,7 +1,7 @@ [[_getting_started_overview]] = Getting Started -If you are using Wildfly, Spring Boot, or Quarkus, you can look at the following quickstarts and documentation to quickly +For certain applications, you can look at the following resources to quickly get started with {project_name} Authorization Services: * {quickstartRepo_link}/tree/latest/jakarta/servlet-authz-client[Securing a JakartaEE Application in Wildfly] diff --git a/docs/documentation/authorization_services/topics/policy-js-policy.adoc b/docs/documentation/authorization_services/topics/policy-js-policy.adoc index 248d6533cd2..01884074939 100644 --- a/docs/documentation/authorization_services/topics/policy-js-policy.adoc +++ b/docs/documentation/authorization_services/topics/policy-js-policy.adoc @@ -2,7 +2,7 @@ = JavaScript-based policy WARNING: If your policy implementation is using Attribute based access control (ABAC) as in the examples below, then please make sure that -users are not able to edit the protected attributes and the corresponding attributes are read-only. See the details in the link:{adminguide_link}#_read_only_user_attributes[Threat model mitigation chapter]. +users are not able to edit the protected attributes and the corresponding attributes are read-only. See the details in the link:{adminguide_link}#mitigating_security_threats[Threat model mitigation] chapter. You can use this type of policy to define conditions for your permissions using JavaScript. It is one of the rule-based policy types supported by {project_name}, and provides flexibility to write any policy based on the <<_policy_evaluation_api, Evaluation API>>. diff --git a/docs/documentation/server_admin/topics/threat/read-only-attributes.adoc b/docs/documentation/server_admin/topics/threat/read-only-attributes.adoc index 89a244d6f9c..5403525a318 100644 --- a/docs/documentation/server_admin/topics/threat/read-only-attributes.adoc +++ b/docs/documentation/server_admin/topics/threat/read-only-attributes.adoc @@ -1,4 +1,4 @@ -[[_read_only_user_attributes]] +[[read_only_user_attributes]] === Read-only user attributes Typical users who are stored in {project_name} have various attributes related to their user profiles. Such attributes include email, firstName or lastName. diff --git a/docs/documentation/server_admin/topics/users/proc-configuring-user-attributes.adoc b/docs/documentation/server_admin/topics/users/proc-configuring-user-attributes.adoc index 38601cb9d02..528c090ccd2 100644 --- a/docs/documentation/server_admin/topics/users/proc-configuring-user-attributes.adoc +++ b/docs/documentation/server_admin/topics/users/proc-configuring-user-attributes.adoc @@ -24,4 +24,4 @@ image:images/user-attributes.png[] NOTE: Some read-only attributes are not supposed to be updated by the administrators. This includes attributes that are read-only by design like for example `LDAP_ID`, which is filled automatically by the LDAP provider. Some other attributes should be read-only for -typical user administrators due to security reasons. See the details in the xref:_read_only_user_attributes[Mitigating security threats] chapter. +typical user administrators due to security reasons. See the details in the xref:read_only_user_attributes[Mitigating security threats] chapter. diff --git a/docs/documentation/server_development/topics/auth-spi.adoc b/docs/documentation/server_development/topics/auth-spi.adoc index 068b7e775b5..e2b235df117 100644 --- a/docs/documentation/server_development/topics/auth-spi.adoc +++ b/docs/documentation/server_development/topics/auth-spi.adoc @@ -18,7 +18,7 @@ After the action is performed successfully, the user doesn't have to perform the You can write and plug in your own required actions. WARNING: If your authenticator or required action implementation is using some user attributes as the metadata attributes for linking/establishing the user identity, -then please make sure that users are not able to edit the attributes and the corresponding attributes are read-only. See the details in the link:{adminguide_link}#_read_only_user_attributes[Threat model mitigation chapter]. +then please make sure that users are not able to edit the attributes and the corresponding attributes are read-only. See the details in the link:{adminguide_link}#read_only_user_attributes[Threat model mitigation chapter]. === Terms diff --git a/docs/documentation/server_development/topics/user-storage.adoc b/docs/documentation/server_development/topics/user-storage.adoc index b43444be3fb..131bdcdef42 100644 --- a/docs/documentation/server_development/topics/user-storage.adoc +++ b/docs/documentation/server_development/topics/user-storage.adoc @@ -17,7 +17,7 @@ User Storage SPI provider implementations are packaged and deployed similarly to WARNING: If your user provider implementation is using some user attributes as the metadata attributes for linking/establishing the user identity, then please make sure that users are not able to edit the attributes and the corresponding attributes are read-only. The example is the `LDAP_ID` attribute, which the built-in {project_name} -LDAP provider is using for to store the ID of the user on the LDAP server side. See the details in the link:{adminguide_link}#_read_only_user_attributes[Threat model mitigation chapter]. +LDAP provider is using for to store the ID of the user on the LDAP server side. See the details in the link:{adminguide_link}#read_only_user_attributes[Threat model mitigation chapter]. There are two sample projects in link:{quickstartRepo_link}[{quickstartRepo_name}]. Each quickstart has a `README` file with instructions on how to build, deploy, and test the sample project. The following table provides a brief description of the available User Storage SPI quickstarts: diff --git a/docs/documentation/upgrading/topics/keycloak/changes.adoc b/docs/documentation/upgrading/topics/keycloak/changes.adoc index 4fa5fa1031f..c1a4e8b0127 100644 --- a/docs/documentation/upgrading/topics/keycloak/changes.adoc +++ b/docs/documentation/upgrading/topics/keycloak/changes.adoc @@ -128,7 +128,7 @@ use: * Any other custom functionality, where some of the user attributes are used as the metadata for storing authentication/authorization/identity context rather than simple user profile information. -See the details in the link:{adminguide_link}#_read_only_user_attributes[Threat model mitigation chapter]. +See the details in the link:{adminguide_link}#read_only_user_attributes[Threat model mitigation chapter]. ==== Valid Request URIs diff --git a/docs/documentation/upgrading/topics/rhsso/changes-75.adoc b/docs/documentation/upgrading/topics/rhsso/changes-75.adoc index 286a9786c41..48e0e1d00b5 100644 --- a/docs/documentation/upgrading/topics/rhsso/changes-75.adoc +++ b/docs/documentation/upgrading/topics/rhsso/changes-75.adoc @@ -77,7 +77,7 @@ Read-only user attributes are now available. Some of these user attributes are * X.509 authenticator with a custom attribute for mapping the X.509 certificate to the user identity * Any other custom functionality where some of the user attributes are used as the metadata for storing authentication/authorization/identity context rather than simple user profile information. -For more details, see the link:{adminguide_link}#_read_only_user_attributes[Threat model mitigation chapter]. +For more details, see the link:{adminguide_link}#read_only_user_attributes[Threat model mitigation chapter]. === No user session needed after Docker authentication No user session is created after successful authentication with the Docker protocol. For details, please refer to the link:{adminguide_link}#_docker[{adminguide_name}].