Fix broken links (#24476)

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]

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>>.

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.

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.

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
 

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:
 

docs/documentation/upgrading/topics/keycloak/changes.adoc

@@ -132,7 +132,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
 

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}].