diff --git a/.asciidoctorconfig b/.asciidoctorconfig
deleted file mode 100644
index d35a12c24..000000000
--- a/.asciidoctorconfig
+++ /dev/null
@@ -1,6 +0,0 @@
-:icons: font
-:idprefix:
-:idseparator: -
-:project_buildType: latest
-ifndef::asciidoctorconfigdir[:asciidoctorconfigdir: .]
-include::{asciidoctorconfigdir}/topics/templates/document-attributes.adoc[]
diff --git a/.gitattributes b/.gitattributes
deleted file mode 100644
index 2b70adf8d..000000000
--- a/.gitattributes
+++ /dev/null
@@ -1,20 +0,0 @@
-* text=auto
-
-*.html text eol=lf
-*.java text eol=lf
-*.js text eol=lf
-*.json text eol=lf
-*.jsp text eol=lf
-*.md text eol=lf
-*.properties text eol=lf
-*.svg text auto
-*.xml text eol=lf
-*.xsl text eol=lf
-
-*.png binary
-*.jpg binary
-*.gif binary
-*.ttf binary
-*.eot binary
-*.otf binary
-*.woff binary
diff --git a/.github/ISSUE_TEMPLATE/bug.yml b/.github/ISSUE_TEMPLATE/bug.yml
deleted file mode 100644
index 7fb2a5f59..000000000
--- a/.github/ISSUE_TEMPLATE/bug.yml
+++ /dev/null
@@ -1,40 +0,0 @@
-name: Bug Report
-description: Report a non-security sensitive bug in Keycloak
-labels: ["kind/bug", "status/triage"]
-body:
- - type: textarea
- attributes:
- label: Describe the bug
- description: Provide a clear and concise description of what the problem is.
- validations:
- required: true
- - type: input
- attributes:
- label: Version
- description: What version of Keycloak are you running?
- validations:
- required: true
- - type: textarea
- attributes:
- label: Expected behavior
- description: Describe the expected behavior clearly and concisely.
- validations:
- required: false
- - type: textarea
- attributes:
- label: Actual behavior
- description: Describe the actual behavior clearly and concisely.
- validations:
- required: false
- - type: textarea
- attributes:
- label: How to Reproduce?
- description: Provide clear and concise steps to reproduce the problem.
- validations:
- required: false
- - type: textarea
- attributes:
- label: Anything else?
- description: Links? References? Anything that will give us more context about the issue you are encountering!
- validations:
- required: false
\ No newline at end of file
diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
deleted file mode 100644
index 14eeec14b..000000000
--- a/.github/ISSUE_TEMPLATE/config.yml
+++ /dev/null
@@ -1,11 +0,0 @@
-blank_issues_enabled: false
-contact_links:
- - name: Discussions
- url: https://github.com/keycloak/keycloak/discussions
- about: Propose new ideas, provide feedback, or ask for help here
- - name: User mailing list
- url: https://groups.google.com/forum/#!forum/keycloak-user
- about: Ask and answer questions here
- - name: Developer mailing list
- url: https://groups.google.com/forum/#!forum/keycloak-dev
- about: Propose new features and join in design discussions here
diff --git a/.github/ISSUE_TEMPLATE/enhancement.yml b/.github/ISSUE_TEMPLATE/enhancement.yml
deleted file mode 100644
index 70033aecb..000000000
--- a/.github/ISSUE_TEMPLATE/enhancement.yml
+++ /dev/null
@@ -1,31 +0,0 @@
-name: Enhancement Request
-description: Request an enhancement to an existing feature
-labels: ["kind/enhancement", "status/triage"]
-body:
- - type: textarea
- attributes:
- label: Description
- description: Describe the enhancement at a high-level.
- validations:
- required: true
- - type: input
- attributes:
- label: Discussion
- description: |
- If there has been a discussion around the enhancement, provide a link to the discussion.
-
- Please note that larger enhancements should be discussed through [GitHub Discussion](https://github.com/keycloak/keycloak/discussions/categories/ideas).
- validations:
- required: false
- - type: textarea
- attributes:
- label: Motivation
- description: Describe why the feature should be added.
- validations:
- required: false
- - type: textarea
- attributes:
- label: Details
- description: More details? Implementation ideas? Anything that will give us more context about the enhancement you are proposing!
- validations:
- required: false
\ No newline at end of file
diff --git a/.github/ISSUE_TEMPLATE/epic.yml b/.github/ISSUE_TEMPLATE/epic.yml
deleted file mode 100644
index 7198406c6..000000000
--- a/.github/ISSUE_TEMPLATE/epic.yml
+++ /dev/null
@@ -1,32 +0,0 @@
-name: Epic
-description: A large feature that is broken down into multiple linked issues.
-labels: ["kind/epic", "status/triage"]
-body:
- - type: textarea
- attributes:
- label: Description
- description: Describe the feature at a high-level.
- validations:
- required: true
- - type: input
- attributes:
- label: Discussion
- description: |
- Provide a link to the GitHub Discussion for the feature.
- validations:
- required: true
- - type: textarea
- attributes:
- label: Issues
- description: List the issues related to this epic.
- placeholder: |
- - #1
- - #2
- validations:
- required: false
- - type: textarea
- attributes:
- label: Motivation
- description: Provide a brief explanation of why the feature should be added.
- validations:
- required: false
\ No newline at end of file
diff --git a/.github/ISSUE_TEMPLATE/feature.yml b/.github/ISSUE_TEMPLATE/feature.yml
deleted file mode 100644
index 1be4eb862..000000000
--- a/.github/ISSUE_TEMPLATE/feature.yml
+++ /dev/null
@@ -1,31 +0,0 @@
-name: Feature Request
-description: Request a new feature to be added to Keycloak
-labels: ["kind/feature", "status/triage"]
-body:
- - type: textarea
- attributes:
- label: Description
- description: Describe the feature at a high-level.
- validations:
- required: true
- - type: input
- attributes:
- label: Discussion
- description: |
- If there has been a discussion around the feature, provide a link to the discussion.
-
- Please note that all, except small requests, should be discussed through [GitHub Discussion](https://github.com/keycloak/keycloak/discussions/categories/ideas).
- validations:
- required: false
- - type: textarea
- attributes:
- label: Motivation
- description: Describe why the feature should be added.
- validations:
- required: false
- - type: textarea
- attributes:
- label: Details
- description: Design ideas? Implementation ideas? Anything that will give us more context about the feature you are proposing!
- validations:
- required: false
\ No newline at end of file
diff --git a/.github/ISSUE_TEMPLATE/task.yml b/.github/ISSUE_TEMPLATE/task.yml
deleted file mode 100644
index 9b5649d0d..000000000
--- a/.github/ISSUE_TEMPLATE/task.yml
+++ /dev/null
@@ -1,10 +0,0 @@
-name: Task
-description: Any tasks that are not directly adding a new feature, enhancement or fixing a bug
-labels: ["kind/task"]
-body:
- - type: textarea
- attributes:
- label: Description
- description: Describe the task.
- validations:
- required: true
diff --git a/.github/workflows/test-external-links.yml b/.github/workflows/test-external-links.yml
deleted file mode 100644
index 67aa6cbbb..000000000
--- a/.github/workflows/test-external-links.yml
+++ /dev/null
@@ -1,26 +0,0 @@
-# This workflow will build a Java project with Maven
-# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven
-
-name: External Links
-
-on:
- push:
- branches: [ main ]
- pull_request:
- branches: [ main ]
- schedule:
- - cron: '0 5 * * *'
-jobs:
- test:
- name: Verify links
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v2
- - name: Set up JDK 1.8
- uses: actions/setup-java@v1
- with:
- java-version: 1.8
- - name: Build
- run: mvn install -B -DskipTests
- - name: Test
- run: mvn test -B -pl tests -Dtest=ExternalLinksTest
diff --git a/.github/workflows/test-guides.yml b/.github/workflows/test-guides.yml
deleted file mode 100644
index 7c5db9004..000000000
--- a/.github/workflows/test-guides.yml
+++ /dev/null
@@ -1,25 +0,0 @@
-# This workflow will build a Java project with Maven
-# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven
-
-name: Test
-
-on:
- push:
- branches: [ main ]
- pull_request:
- branches: [ main ]
-
-jobs:
- build:
- name: Verify Keycloak documentation
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v2
- - name: Set up JDK 1.8
- uses: actions/setup-java@v1
- with:
- java-version: 1.8
- - name: Build
- run: mvn install -B -DskipTests
- - name: Test
- run: mvn test -B -pl tests -Dtest=!ExternalLinksTest
diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index e5c4959fe..000000000
--- a/.gitignore
+++ /dev/null
@@ -1,60 +0,0 @@
-.verified-links
-
-_book
-node_modules
-
-# Intellij
-###################
-.idea
-*.iml
-
-# Eclipse #
-###########
-.project
-.settings
-.classpath
-
-# NetBeans #
-############
-nbactions.xml
-nb-configuration.xml
-catalog.xml
-
-# Compiled source #
-###################
-*.com
-*.class
-*.dll
-*.exe
-*.o
-*.so
-
-# Packages #
-############
-# it's better to unpack these files and commit the raw source
-# git has its own built-in compression methods
-*.7z
-*.dmg
-*.gz
-*.iso
-*.jar
-*.rar
-*.tar
-*.zip
-
-# Logs and databases #
-######################
-*.log
-
-# Maven #
-#########
-target
-
-build
-html
-
-# vim
-######
-*.swp
-
-.vale.ini
diff --git a/.vale.ini b/.vale.ini
deleted file mode 100644
index 197401bf4..000000000
--- a/.vale.ini
+++ /dev/null
@@ -1,8 +0,0 @@
-StylesPath = /Users/bdooley/Documents/code/vale-boilerplate/styles
-MinAlertLevel = error
-
-Vocab = blog
-
-
-[*.adoc]
-BasedOnStyles = IBM, Vale, write-good
diff --git a/License.html b/License.html
deleted file mode 100755
index 6ae1dfd82..000000000
--- a/License.html
+++ /dev/null
@@ -1,210 +0,0 @@
-
-
-
-
-
-Apache License
- Version 2.0, January 2004
- http://www.apache.org/licenses/
-
- TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
- 1. Definitions.
-
- "License" shall mean the terms and conditions for use, reproduction,
- and distribution as defined by Sections 1 through 9 of this document.
-
- "Licensor" shall mean the copyright owner or entity authorized by
- the copyright owner that is granting the License.
-
- "Legal Entity" shall mean the union of the acting entity and all
- other entities that control, are controlled by, or are under common
- control with that entity. For the purposes of this definition,
- "control" means (i) the power, direct or indirect, to cause the
- direction or management of such entity, whether by contract or
- otherwise, or (ii) ownership of fifty percent (50%) or more of the
- outstanding shares, or (iii) beneficial ownership of such entity.
-
- "You" (or "Your") shall mean an individual or Legal Entity
- exercising permissions granted by this License.
-
- "Source" form shall mean the preferred form for making modifications,
- including but not limited to software source code, documentation
- source, and configuration files.
-
- "Object" form shall mean any form resulting from mechanical
- transformation or translation of a Source form, including but
- not limited to compiled object code, generated documentation,
- and conversions to other media types.
-
- "Work" shall mean the work of authorship, whether in Source or
- Object form, made available under the License, as indicated by a
- copyright notice that is included in or attached to the work
- (an example is provided in the Appendix below).
-
- "Derivative Works" shall mean any work, whether in Source or Object
- form, that is based on (or derived from) the Work and for which the
- editorial revisions, annotations, elaborations, or other modifications
- represent, as a whole, an original work of authorship. For the purposes
- of this License, Derivative Works shall not include works that remain
- separable from, or merely link (or bind by name) to the interfaces of,
- the Work and Derivative Works thereof.
-
- "Contribution" shall mean any work of authorship, including
- the original version of the Work and any modifications or additions
- to that Work or Derivative Works thereof, that is intentionally
- submitted to Licensor for inclusion in the Work by the copyright owner
- or by an individual or Legal Entity authorized to submit on behalf of
- the copyright owner. For the purposes of this definition, "submitted"
- means any form of electronic, verbal, or written communication sent
- to the Licensor or its representatives, including but not limited to
- communication on electronic mailing lists, source code control systems,
- and issue tracking systems that are managed by, or on behalf of, the
- Licensor for the purpose of discussing and improving the Work, but
- excluding communication that is conspicuously marked or otherwise
- designated in writing by the copyright owner as "Not a Contribution."
-
- "Contributor" shall mean Licensor and any individual or Legal Entity
- on behalf of whom a Contribution has been received by Licensor and
- subsequently incorporated within the Work.
-
- 2. Grant of Copyright License. Subject to the terms and conditions of
- this License, each Contributor hereby grants to You a perpetual,
- worldwide, non-exclusive, no-charge, royalty-free, irrevocable
- copyright license to reproduce, prepare Derivative Works of,
- publicly display, publicly perform, sublicense, and distribute the
- Work and such Derivative Works in Source or Object form.
-
- 3. Grant of Patent License. Subject to the terms and conditions of
- this License, each Contributor hereby grants to You a perpetual,
- worldwide, non-exclusive, no-charge, royalty-free, irrevocable
- (except as stated in this section) patent license to make, have made,
- use, offer to sell, sell, import, and otherwise transfer the Work,
- where such license applies only to those patent claims licensable
- by such Contributor that are necessarily infringed by their
- Contribution(s) alone or by combination of their Contribution(s)
- with the Work to which such Contribution(s) was submitted. If You
- institute patent litigation against any entity (including a
- cross-claim or counterclaim in a lawsuit) alleging that the Work
- or a Contribution incorporated within the Work constitutes direct
- or contributory patent infringement, then any patent licenses
- granted to You under this License for that Work shall terminate
- as of the date such litigation is filed.
-
- 4. Redistribution. You may reproduce and distribute copies of the
- Work or Derivative Works thereof in any medium, with or without
- modifications, and in Source or Object form, provided that You
- meet the following conditions:
-
- (a) You must give any other recipients of the Work or
- Derivative Works a copy of this License; and
-
- (b) You must cause any modified files to carry prominent notices
- stating that You changed the files; and
-
- (c) You must retain, in the Source form of any Derivative Works
- that You distribute, all copyright, patent, trademark, and
- attribution notices from the Source form of the Work,
- excluding those notices that do not pertain to any part of
- the Derivative Works; and
-
- (d) If the Work includes a "NOTICE" text file as part of its
- distribution, then any Derivative Works that You distribute must
- include a readable copy of the attribution notices contained
- within such NOTICE file, excluding those notices that do not
- pertain to any part of the Derivative Works, in at least one
- of the following places: within a NOTICE text file distributed
- as part of the Derivative Works; within the Source form or
- documentation, if provided along with the Derivative Works; or,
- within a display generated by the Derivative Works, if and
- wherever such third-party notices normally appear. The contents
- of the NOTICE file are for informational purposes only and
- do not modify the License. You may add Your own attribution
- notices within Derivative Works that You distribute, alongside
- or as an addendum to the NOTICE text from the Work, provided
- that such additional attribution notices cannot be construed
- as modifying the License.
-
- You may add Your own copyright statement to Your modifications and
- may provide additional or different license terms and conditions
- for use, reproduction, or distribution of Your modifications, or
- for any such Derivative Works as a whole, provided Your use,
- reproduction, and distribution of the Work otherwise complies with
- the conditions stated in this License.
-
- 5. Submission of Contributions. Unless You explicitly state otherwise,
- any Contribution intentionally submitted for inclusion in the Work
- by You to the Licensor shall be under the terms and conditions of
- this License, without any additional terms or conditions.
- Notwithstanding the above, nothing herein shall supersede or modify
- the terms of any separate license agreement you may have executed
- with Licensor regarding such Contributions.
-
- 6. Trademarks. This License does not grant permission to use the trade
- names, trademarks, service marks, or product names of the Licensor,
- except as required for reasonable and customary use in describing the
- origin of the Work and reproducing the content of the NOTICE file.
-
- 7. Disclaimer of Warranty. Unless required by applicable law or
- agreed to in writing, Licensor provides the Work (and each
- Contributor provides its Contributions) on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
- implied, including, without limitation, any warranties or conditions
- of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
- PARTICULAR PURPOSE. You are solely responsible for determining the
- appropriateness of using or redistributing the Work and assume any
- risks associated with Your exercise of permissions under this License.
-
- 8. Limitation of Liability. In no event and under no legal theory,
- whether in tort (including negligence), contract, or otherwise,
- unless required by applicable law (such as deliberate and grossly
- negligent acts) or agreed to in writing, shall any Contributor be
- liable to You for damages, including any direct, indirect, special,
- incidental, or consequential damages of any character arising as a
- result of this License or out of the use or inability to use the
- Work (including but not limited to damages for loss of goodwill,
- work stoppage, computer failure or malfunction, or any and all
- other commercial damages or losses), even if such Contributor
- has been advised of the possibility of such damages.
-
- 9. Accepting Warranty or Additional Liability. While redistributing
- the Work or Derivative Works thereof, You may choose to offer,
- and charge a fee for, acceptance of support, warranty, indemnity,
- or other liability obligations and/or rights consistent with this
- License. However, in accepting such obligations, You may act only
- on Your own behalf and on Your sole responsibility, not on behalf
- of any other Contributor, and only if You agree to indemnify,
- defend, and hold each Contributor harmless for any liability
- incurred by, or claims asserted against, such Contributor by reason
- of your accepting any such warranty or additional liability.
-
- END OF TERMS AND CONDITIONS
-
- APPENDIX: How to apply the Apache License to your work.
-
- To apply the Apache License to your work, attach the following
- boilerplate notice, with the fields enclosed by brackets "[]"
- replaced with your own identifying information. (Don't include
- the brackets!) The text should be enclosed in the appropriate
- comment syntax for the file format. We also recommend that a
- file or class name and description of purpose be included on the
- same "printed page" as the copyright notice for easier
- identification within third-party archives.
-
- Copyright [yyyy] [name of copyright owner]
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
-
-
diff --git a/aggregation/src/keycloak_logo.png b/aggregation/src/keycloak_logo.png
deleted file mode 100644
index 4883f5230..000000000
Binary files a/aggregation/src/keycloak_logo.png and /dev/null differ
diff --git a/api_documentation/index.adoc b/api_documentation/index.adoc
deleted file mode 100644
index d84f1d4ae..000000000
--- a/api_documentation/index.adoc
+++ /dev/null
@@ -1,8 +0,0 @@
-include::topics/templates/document-attributes.adoc[]
-
-:api_documentation:
-:linkattrs:
-
-= {apidocs_name}
-
-include::topics.adoc[]
diff --git a/api_documentation/pom.xml b/api_documentation/pom.xml
deleted file mode 100644
index 1644ce5e2..000000000
--- a/api_documentation/pom.xml
+++ /dev/null
@@ -1,46 +0,0 @@
-
-
- 4.0.0
-
-
- org.keycloak.documentation
- documentation-parent
- 999.0.0-SNAPSHOT
- ../
-
-
- API Documentation
- api-documentation
- pom
-
-
-
-
- org.keycloak.documentation
- header-maven-plugin
-
-
- add-file-headers
-
-
-
-
- org.asciidoctor
- asciidoctor-maven-plugin
-
-
- asciidoc-to-html
-
-
-
-
- maven-antrun-plugin
-
-
- echo-output
-
-
-
-
-
-
diff --git a/api_documentation/topics.adoc b/api_documentation/topics.adoc
deleted file mode 100644
index 6d4f5942d..000000000
--- a/api_documentation/topics.adoc
+++ /dev/null
@@ -1 +0,0 @@
-include::topics/overview.adoc[]
diff --git a/api_documentation/topics/overview.adoc b/api_documentation/topics/overview.adoc
deleted file mode 100644
index a06996fbf..000000000
--- a/api_documentation/topics/overview.adoc
+++ /dev/null
@@ -1,12 +0,0 @@
-
-include::templates/making-open-source-more-inclusive.adoc[]
-
-== {project_name} API Documentation
-
-=== JavaDocs Documentation
-
-{apidocs_javadocs_link}[{apidocs_javadocs_name}]
-
-=== Admin REST API Documentation
-
-{apidocs_adminrest_link}[{apidocs_adminrest_name}]
diff --git a/api_documentation/topics/templates b/api_documentation/topics/templates
deleted file mode 120000
index d19126411..000000000
--- a/api_documentation/topics/templates
+++ /dev/null
@@ -1 +0,0 @@
-../../topics/templates
\ No newline at end of file
diff --git a/authorization_services/docinfo-footer.html b/authorization_services/docinfo-footer.html
deleted file mode 120000
index a39d3bd0f..000000000
--- a/authorization_services/docinfo-footer.html
+++ /dev/null
@@ -1 +0,0 @@
-../aggregation/navbar.html
\ No newline at end of file
diff --git a/authorization_services/docinfo.html b/authorization_services/docinfo.html
deleted file mode 120000
index 14514f94d..000000000
--- a/authorization_services/docinfo.html
+++ /dev/null
@@ -1 +0,0 @@
-../aggregation/navbar-head.html
\ No newline at end of file
diff --git a/authorization_services/images/authz-arch-overview.png b/authorization_services/images/authz-arch-overview.png
deleted file mode 100644
index 47c80b923..000000000
Binary files a/authorization_services/images/authz-arch-overview.png and /dev/null differ
diff --git a/authorization_services/images/authz-calls.png b/authorization_services/images/authz-calls.png
deleted file mode 100644
index a7bf4d97c..000000000
Binary files a/authorization_services/images/authz-calls.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/access-denied-page.png b/authorization_services/images/getting-started/hello-world/access-denied-page.png
deleted file mode 100644
index 365bd215d..000000000
Binary files a/authorization_services/images/getting-started/hello-world/access-denied-page.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/adapter-config.png b/authorization_services/images/getting-started/hello-world/adapter-config.png
deleted file mode 100644
index e1b2add74..000000000
Binary files a/authorization_services/images/getting-started/hello-world/adapter-config.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/authz-settings.png b/authorization_services/images/getting-started/hello-world/authz-settings.png
deleted file mode 100644
index 5214a2fba..000000000
Binary files a/authorization_services/images/getting-started/hello-world/authz-settings.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/create-client.png b/authorization_services/images/getting-started/hello-world/create-client.png
deleted file mode 100644
index e59680027..000000000
Binary files a/authorization_services/images/getting-started/hello-world/create-client.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/create-realm.png b/authorization_services/images/getting-started/hello-world/create-realm.png
deleted file mode 100644
index cadf50202..000000000
Binary files a/authorization_services/images/getting-started/hello-world/create-realm.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/create-scope.png b/authorization_services/images/getting-started/hello-world/create-scope.png
deleted file mode 100644
index 55147e663..000000000
Binary files a/authorization_services/images/getting-started/hello-world/create-scope.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/create-user.png b/authorization_services/images/getting-started/hello-world/create-user.png
deleted file mode 100644
index 097e65703..000000000
Binary files a/authorization_services/images/getting-started/hello-world/create-user.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/enable-authz.png b/authorization_services/images/getting-started/hello-world/enable-authz.png
deleted file mode 100644
index d7a6e4d39..000000000
Binary files a/authorization_services/images/getting-started/hello-world/enable-authz.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/login-page.png b/authorization_services/images/getting-started/hello-world/login-page.png
deleted file mode 100644
index c6bfb2466..000000000
Binary files a/authorization_services/images/getting-started/hello-world/login-page.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/main-page.png b/authorization_services/images/getting-started/hello-world/main-page.png
deleted file mode 100644
index 89da72077..000000000
Binary files a/authorization_services/images/getting-started/hello-world/main-page.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/hello-world/reset-user-pwd.png b/authorization_services/images/getting-started/hello-world/reset-user-pwd.png
deleted file mode 100644
index c3528814e..000000000
Binary files a/authorization_services/images/getting-started/hello-world/reset-user-pwd.png and /dev/null differ
diff --git a/authorization_services/images/getting-started/kc-start-page.png b/authorization_services/images/getting-started/kc-start-page.png
deleted file mode 100644
index e20eb9bdb..000000000
Binary files a/authorization_services/images/getting-started/kc-start-page.png and /dev/null differ
diff --git a/authorization_services/images/keycloak_logo.png b/authorization_services/images/keycloak_logo.png
deleted file mode 100755
index 4883f5230..000000000
Binary files a/authorization_services/images/keycloak_logo.png and /dev/null differ
diff --git a/authorization_services/images/pep-pattern-diagram.png b/authorization_services/images/pep-pattern-diagram.png
deleted file mode 100644
index 3e019cce8..000000000
Binary files a/authorization_services/images/pep-pattern-diagram.png and /dev/null differ
diff --git a/authorization_services/images/permission/create-resource.png b/authorization_services/images/permission/create-resource.png
deleted file mode 100644
index e4b1c1d36..000000000
Binary files a/authorization_services/images/permission/create-resource.png and /dev/null differ
diff --git a/authorization_services/images/permission/create-scope.png b/authorization_services/images/permission/create-scope.png
deleted file mode 100644
index 6ba0c886a..000000000
Binary files a/authorization_services/images/permission/create-scope.png and /dev/null differ
diff --git a/authorization_services/images/permission/typed-resource-perm-example.png b/authorization_services/images/permission/typed-resource-perm-example.png
deleted file mode 100644
index 678bc4474..000000000
Binary files a/authorization_services/images/permission/typed-resource-perm-example.png and /dev/null differ
diff --git a/authorization_services/images/permission/view.png b/authorization_services/images/permission/view.png
deleted file mode 100644
index fa4a185c7..000000000
Binary files a/authorization_services/images/permission/view.png and /dev/null differ
diff --git a/authorization_services/images/policy-evaluation-tool/policy-evaluation-tool.png b/authorization_services/images/policy-evaluation-tool/policy-evaluation-tool.png
deleted file mode 100644
index 079b0cb6b..000000000
Binary files a/authorization_services/images/policy-evaluation-tool/policy-evaluation-tool.png and /dev/null differ
diff --git a/authorization_services/images/policy-mgmt-process.png b/authorization_services/images/policy-mgmt-process.png
deleted file mode 100644
index 876e1511b..000000000
Binary files a/authorization_services/images/policy-mgmt-process.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-aggregated.png b/authorization_services/images/policy/create-aggregated.png
deleted file mode 100644
index b7fe7d050..000000000
Binary files a/authorization_services/images/policy/create-aggregated.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-client-scope.png b/authorization_services/images/policy/create-client-scope.png
deleted file mode 100644
index 2412a3e84..000000000
Binary files a/authorization_services/images/policy/create-client-scope.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-client.png b/authorization_services/images/policy/create-client.png
deleted file mode 100644
index f16e8c2ca..000000000
Binary files a/authorization_services/images/policy/create-client.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-drools.png b/authorization_services/images/policy/create-drools.png
deleted file mode 100644
index 1e1198e3d..000000000
Binary files a/authorization_services/images/policy/create-drools.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-group-extend-children.png b/authorization_services/images/policy/create-group-extend-children.png
deleted file mode 100644
index 36c1cee11..000000000
Binary files a/authorization_services/images/policy/create-group-extend-children.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-group.png b/authorization_services/images/policy/create-group.png
deleted file mode 100644
index 09691f383..000000000
Binary files a/authorization_services/images/policy/create-group.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-js.png b/authorization_services/images/policy/create-js.png
deleted file mode 100644
index bbee097b4..000000000
Binary files a/authorization_services/images/policy/create-js.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-regex.png b/authorization_services/images/policy/create-regex.png
deleted file mode 100644
index e9bb82677..000000000
Binary files a/authorization_services/images/policy/create-regex.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-role.png b/authorization_services/images/policy/create-role.png
deleted file mode 100644
index 0aece01ca..000000000
Binary files a/authorization_services/images/policy/create-role.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-time.png b/authorization_services/images/policy/create-time.png
deleted file mode 100644
index 3cc3a6279..000000000
Binary files a/authorization_services/images/policy/create-time.png and /dev/null differ
diff --git a/authorization_services/images/policy/create-user.png b/authorization_services/images/policy/create-user.png
deleted file mode 100644
index 5ece77b8e..000000000
Binary files a/authorization_services/images/policy/create-user.png and /dev/null differ
diff --git a/authorization_services/images/policy/view.png b/authorization_services/images/policy/view.png
deleted file mode 100644
index 361ff3a25..000000000
Binary files a/authorization_services/images/policy/view.png and /dev/null differ
diff --git a/authorization_services/images/resource-mgmt-process.png b/authorization_services/images/resource-mgmt-process.png
deleted file mode 100644
index 72fba45b2..000000000
Binary files a/authorization_services/images/resource-mgmt-process.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/authz-export.png b/authorization_services/images/resource-server/authz-export.png
deleted file mode 100644
index 2ebd4acab..000000000
Binary files a/authorization_services/images/resource-server/authz-export.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/authz-settings.png b/authorization_services/images/resource-server/authz-settings.png
deleted file mode 100644
index 695f2b7ee..000000000
Binary files a/authorization_services/images/resource-server/authz-settings.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/client-create.png b/authorization_services/images/resource-server/client-create.png
deleted file mode 100644
index 4344ac163..000000000
Binary files a/authorization_services/images/resource-server/client-create.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/client-enable-authz.png b/authorization_services/images/resource-server/client-enable-authz.png
deleted file mode 100644
index fa43196df..000000000
Binary files a/authorization_services/images/resource-server/client-enable-authz.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/client-list.png b/authorization_services/images/resource-server/client-list.png
deleted file mode 100644
index d92fa7916..000000000
Binary files a/authorization_services/images/resource-server/client-list.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/create.png b/authorization_services/images/resource-server/create.png
deleted file mode 100644
index 3940e1f5b..000000000
Binary files a/authorization_services/images/resource-server/create.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/default-permission.png b/authorization_services/images/resource-server/default-permission.png
deleted file mode 100644
index f9632a742..000000000
Binary files a/authorization_services/images/resource-server/default-permission.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/default-policy.png b/authorization_services/images/resource-server/default-policy.png
deleted file mode 100644
index 40f4ed431..000000000
Binary files a/authorization_services/images/resource-server/default-policy.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/default-resource.png b/authorization_services/images/resource-server/default-resource.png
deleted file mode 100644
index e9a6a9779..000000000
Binary files a/authorization_services/images/resource-server/default-resource.png and /dev/null differ
diff --git a/authorization_services/images/resource-server/manage.png b/authorization_services/images/resource-server/manage.png
deleted file mode 100644
index d0d040f8b..000000000
Binary files a/authorization_services/images/resource-server/manage.png and /dev/null differ
diff --git a/authorization_services/images/resource/create.png b/authorization_services/images/resource/create.png
deleted file mode 100644
index 7280ed78f..000000000
Binary files a/authorization_services/images/resource/create.png and /dev/null differ
diff --git a/authorization_services/images/resource/view.png b/authorization_services/images/resource/view.png
deleted file mode 100644
index eeee62d91..000000000
Binary files a/authorization_services/images/resource/view.png and /dev/null differ
diff --git a/authorization_services/images/rs-r-scopes.png b/authorization_services/images/rs-r-scopes.png
deleted file mode 100644
index 527a9a8fa..000000000
Binary files a/authorization_services/images/rs-r-scopes.png and /dev/null differ
diff --git a/authorization_services/images/service/account-my-resource-detail.png b/authorization_services/images/service/account-my-resource-detail.png
deleted file mode 100644
index 062580969..000000000
Binary files a/authorization_services/images/service/account-my-resource-detail.png and /dev/null differ
diff --git a/authorization_services/images/service/account-my-resource.png b/authorization_services/images/service/account-my-resource.png
deleted file mode 100644
index 5ca3c5df3..000000000
Binary files a/authorization_services/images/service/account-my-resource.png and /dev/null differ
diff --git a/authorization_services/images/service/rs-uma-authorization-role.png b/authorization_services/images/service/rs-uma-authorization-role.png
deleted file mode 100644
index 4d7a2bfaa..000000000
Binary files a/authorization_services/images/service/rs-uma-authorization-role.png and /dev/null differ
diff --git a/authorization_services/images/service/rs-uma-protection-role.png b/authorization_services/images/service/rs-uma-protection-role.png
deleted file mode 100644
index ef460cd1c..000000000
Binary files a/authorization_services/images/service/rs-uma-protection-role.png and /dev/null differ
diff --git a/authorization_services/index.adoc b/authorization_services/index.adoc
deleted file mode 100644
index 7d98eeca6..000000000
--- a/authorization_services/index.adoc
+++ /dev/null
@@ -1,20 +0,0 @@
-:toc: left
-:toclevels: 3
-:sectanchors:
-:linkattrs:
-
-include::topics/templates/document-attributes.adoc[]
-
-:authorization_services_guide:
-:context: authorization_services_guide
-
-= {authorizationguide_name}
-
-:release_header_guide: {authorizationguide_name_short}
-:release_header_latest_link: {authorizationguide_link_latest}
-include::topics/templates/release-header.adoc[]
-
-include::topics.adoc[]
-
-:context:
-
diff --git a/authorization_services/pom.xml b/authorization_services/pom.xml
deleted file mode 100644
index 2126b52cb..000000000
--- a/authorization_services/pom.xml
+++ /dev/null
@@ -1,46 +0,0 @@
-
-
- 4.0.0
-
-
- org.keycloak.documentation
- documentation-parent
- 999.0.0-SNAPSHOT
- ../
-
-
- Authorization Services
- authorization-services
- pom
-
-
-
-
- org.keycloak.documentation
- header-maven-plugin
-
-
- add-file-headers
-
-
-
-
- org.asciidoctor
- asciidoctor-maven-plugin
-
-
- asciidoc-to-html
-
-
-
-
- maven-antrun-plugin
-
-
- echo-output
-
-
-
-
-
-
diff --git a/authorization_services/topics.adoc b/authorization_services/topics.adoc
deleted file mode 100644
index bfc081706..000000000
--- a/authorization_services/topics.adoc
+++ /dev/null
@@ -1,121 +0,0 @@
-include::topics/auth-services-overview.adoc[leveloffset=+1]
-
-include::topics/auth-services-architecture.adoc[leveloffset=+2]
-
-include::topics/auth-services-terminology.adoc[leveloffset=+2]
-
-include::topics/getting-started-overview.adoc[leveloffset=+1]
-
-include::topics/hello-world-overview.adoc[leveloffset=+2]
-
-include::topics/hello-world-create-realm.adoc[leveloffset=+2]
-
-include::topics/hello-world-create-resource-server.adoc[leveloffset=+2]
-
-include::topics/hello-world-deploy.adoc[leveloffset=+2]
-
-include::topics/authorization-quickstarts.adoc[leveloffset=+2]
-
-include::topics/resource-server-overview.adoc[leveloffset=+1]
-
-include::topics/resource-server-create-client.adoc[leveloffset=+2]
-
-include::topics/resource-server-enable-authorization.adoc[leveloffset=+2]
-
-include::topics/resource-server-default-config.adoc[leveloffset=+2]
-
-include::topics/resource-server-import-config.adoc[leveloffset=+2]
-
-include::topics/resource-overview.adoc[leveloffset=+1]
-
-include::topics/resource-view.adoc[leveloffset=+2]
-
-include::topics/resource-create.adoc[leveloffset=+2]
-
-include::topics/policy-overview.adoc[leveloffset=+1]
-
-include::topics/policy-user-policy.adoc[leveloffset=+2]
-
-include::topics/policy-role-policy.adoc[leveloffset=+2]
-
-include::topics/policy-role-policy-required-role.adoc[leveloffset=+3]
-
-include::topics/policy-js-policy.adoc[leveloffset=+2]
-
-include::topics/policy-time-policy.adoc[leveloffset=+2]
-
-include::topics/policy-aggregated-policy.adoc[leveloffset=+2]
-
-include::topics/policy-client-policy.adoc[leveloffset=+2]
-
-include::topics/policy-group-policy.adoc[leveloffset=+2]
-
-include::topics/policy-group-policy-extend-children.adoc[leveloffset=+3]
-
-include::topics/policy-client-scope-policy.adoc[leveloffset=+2]
-
-include::topics/policy-client-scope-policy-required-client-scope.adoc[leveloffset=+3]
-
-include::topics/policy-regex-policy.adoc[leveloffset=+2]
-
-include::topics/policy-logic.adoc[leveloffset=+2]
-
-include::topics/policy-evaluation-api.adoc[leveloffset=+2]
-
-include::topics/permission-overview.adoc[leveloffset=+1]
-
-include::topics/permission-create-resource.adoc[leveloffset=+2]
-
-include::topics/permission-typed-resource-permission.adoc[leveloffset=+3]
-
-include::topics/permission-create-scope.adoc[leveloffset=+2]
-
-include::topics/permission-decision-strategy.adoc[leveloffset=+2]
-
-include::topics/policy-evaluation-tool-overview.adoc[leveloffset=+1]
-
-include::topics/service-overview.adoc[leveloffset=+1]
-
-include::topics/service-authorization-discovery-document.adoc[leveloffset=+2]
-
-include::topics/service-authorization-obtaining-permission.adoc[leveloffset=+2]
-
-include::topics/service-authorization-obtaining-permission-authentication.adoc[leveloffset=+3]
-
-include::topics/service-authorization-pushing-claims.adoc[leveloffset=+3]
-
-include::topics/service-authorization-obtaining-permission-uma.adoc[leveloffset=+2]
-
-include::topics/service-authorization-uma-authz-process.adoc[leveloffset=+3]
-
-include::topics/service-authorization-uma-submiting-permission-requests.adoc[leveloffset=+3]
-
-include::topics/service-authorization-uma-account-my-resources.adoc[leveloffset=+3]
-
-include::topics/service-protection-protection-api.adoc[leveloffset=+2]
-
-include::topics/service-protection-whatis-obtain-pat.adoc[leveloffset=+3]
-
-include::topics/service-protection-resources-api-papi.adoc[leveloffset=+3]
-
-include::topics/service-protection-permission-api-papi.adoc[leveloffset=+3]
-
-include::topics/service-protection-policy-api.adoc[leveloffset=+3]
-
-include::topics/service-rpt-overview.adoc[leveloffset=+2]
-
-include::topics/service-rpt-token-introspection.adoc[leveloffset=+3]
-
-include::topics/service-client-api.adoc[leveloffset=+2]
-
-include::topics/enforcer-overview.adoc[leveloffset=+1]
-
-include::topics/enforcer-keycloak-enforcement-filter.adoc[leveloffset=+2]
-
-include::topics/enforcer-claim-information-point.adoc[leveloffset=+2]
-
-include::topics/enforcer-authorization-context.adoc[leveloffset=+2]
-
-include::topics/enforcer-js-adapter.adoc[leveloffset=+2]
-
-include::topics/enforcer-https.adoc[leveloffset=+2]
diff --git a/authorization_services/topics/auth-services-architecture.adoc b/authorization_services/topics/auth-services-architecture.adoc
deleted file mode 100644
index 09321d6ea..000000000
--- a/authorization_services/topics/auth-services-architecture.adoc
+++ /dev/null
@@ -1,130 +0,0 @@
-[[_overview_architecture]]
-= Architecture
-
-image:images/authz-arch-overview.png[alt="{project_name} AuthZ architecture overview"]
-
-From a design perspective, Authorization Services is based on a well-defined set of authorization patterns providing these capabilities:
-
-* **Policy Administration Point (PAP)**
-+
-Provides a set of UIs based on the {project_name} Administration Console to manage resource servers, resources, scopes, permissions, and policies.
-Part of this is also accomplished remotely through the use of the <<_service_protection_api, Protection API>>.
-+
-
-* **Policy Decision Point (PDP)**
-+
-Provides a distributable policy decision point to where authorization requests are sent and policies are evaluated accordingly with the permissions being requested.
-For more information, see <<_service_obtaining_permissions, Obtaining Permissions>>.
-+
-
-* **Policy Enforcement Point (PEP)**
-+
-Provides implementations for different environments to actually enforce authorization decisions at the resource server side.
-{project_name} provides some built-in <<_enforcer_overview, Policy Enforcers>>.
-+
-
-* **Policy Information Point (PIP)**
-+
-Being based on {project_name} Authentication Server, you can obtain attributes from identities and runtime environment during the evaluation of authorization policies.
-
-== The authorization process
-
-Three main processes define the necessary steps to understand how to use {project_name} to enable fine-grained authorization to your applications:
-
-* *Resource Management*
-* *Permission and Policy Management*
-* *Policy Enforcement*
-
-=== Resource management
-
-*Resource Management* involves all the necessary steps to define what is being protected.
-
-image:images/resource-mgmt-process.png[alt="Resource management overview"]
-
-First, you need to specify {project_name} what are you looking to protect, which usually represents a web application or a set of one or more services. For more information on resource servers see <<_overview_terminology, Terminology>>.
-
-Resource servers are managed using the {project_name} Administration Console. There you can enable any registered client application as a resource server and start managing the resources and scopes you want to protect.
-
-image:images/rs-r-scopes.png[alt="Resource Server overview"]
-
-A resource can be a web page, a RESTFul resource, a file in your file system, an EJB, and so on. They can represent a group of resources (just like a Class in Java) or they can represent a single and specific resource.
-
-For instance, you might have a _Bank Account_ resource that represents all banking accounts and use it to define the authorization policies that are common to all banking accounts. However, you might want to define specific policies for _Alice Account_ (a resource instance that belongs to a customer), where only the owner is allowed to access some information or perform an operation.
-
-Resources can be managed using the {project_name} Administration Console or the <<_service_protection_api, Protection API>>. In the latter case, resource servers are able to manage their resources remotely.
-
-Scopes usually represent the actions that can be performed on a resource, but they are not limited to that. You can also use scopes to represent one or more attributes within a resource.
-
-=== Permission and policy management
-
-Once you have defined your resource server and all the resources you want to protect, you must set up permissions and policies.
-
-This process involves all the necessary steps to actually define the security and access requirements that govern your resources.
-
-image:images/policy-mgmt-process.png[alt="Permission and policy management overview"]
-
-Policies define the conditions that must be satisfied to access or perform operations on something (resource or scope), but they are not tied to what they are protecting. They are generic and can be reused to build permissions or even more complex policies.
-
-For instance, to allow access to a group of resources only for users granted with a role "User Premium", you can use RBAC (Role-based Access Control).
-
-{project_name} provides a few built-in policy types (and their respective policy providers) covering the most common access control mechanisms. You can even create policies based on rules written using JavaScript.
-
-Once you have your policies defined, you can start defining your permissions. Permissions are coupled with the resource they are protecting. Here you specify
-what you want to protect (resource or scope) and the policies that must be satisfied to grant or deny permission.
-
-=== Policy enforcement
-
-*Policy Enforcement* involves the necessary steps to actually enforce authorization decisions to a resource server. This is achieved by enabling a *Policy Enforcement Point* or PEP at the resource server that is capable of communicating with the authorization server, ask for authorization data and control access to protected resources based on the decisions and permissions returned by the server.
-
-image:images/pep-pattern-diagram.png[alt="PEP overview"]
-
-{project_name} provides some built-in <<_enforcer_overview, Policy Enforcers>> implementations that you can use to protect your applications depending on the platform they are running on.
-
-
-== Authorization services
-
-Authorization services consist of the following RESTFul endpoints:
-
-* *Token Endpoint*
-* *Resource Management Endpoint*
-* *Permission Management Endpoint*
-
-Each of these services provides a specific API covering the different steps involved in the authorization process.
-
-=== Token endpoint
-
-OAuth2 clients (such as front end applications) can obtain access tokens from the server using the token endpoint and use
-these same tokens to access resources protected by a resource server (such as back end services). In the same way,
-{project_name} Authorization Services provide extensions to OAuth2 to allow access tokens to be issued based on the processing
-of all policies associated with the resource(s) or scope(s) being requested. This means that resource servers can enforce access
-to their protected resources based on the permissions granted by the server and held by an access token. In {project_name} Authorization Services
-the access token with permissions is called a Requesting Party Token or RPT for short.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_service_obtaining_permissions, Obtaining Permissions>>
-
-=== Protection API
-
-The *Protection API* is a set of https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-09.html[UMA-compliant] endpoint-providing operations
-for resource servers to help them manage their resources, scopes, permissions, and policies associated with them. Only resource servers are allowed to access this API, which also requires a
-*uma_protection* scope.
-
-The operations provided by the Protection API can be organized in two main groups:
-
-* *Resource Management*
- ** Create Resource
- ** Delete Resource
- ** Find by Id
- ** Query
-* *Permission Management*
- ** Issue Permission Tickets
-
-[NOTE]
-By default, Remote Resource Management is enabled. You can change that using the {project_name} Administration Console and only allow resource management through the console.
-
-When using the UMA protocol, the issuance of Permission Tickets by the Protection API is an important part of the whole authorization process. As described in a subsequent section, they represent the permissions being requested by the client and that are sent to the server to obtain a final token with all permissions granted during the evaluation of the permissions and policies associated with the resources and scopes being requested.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_service_protection_api, Protection API>>
diff --git a/authorization_services/topics/auth-services-overview.adoc b/authorization_services/topics/auth-services-overview.adoc
deleted file mode 100644
index 7f63d1bc8..000000000
--- a/authorization_services/topics/auth-services-overview.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-[[_overview]]
-= Authorization services overview
-
-:tech_feature_name: Authorization Services
-
-{project_name} supports fine-grained authorization policies and is able to combine different access control
-mechanisms such as:
-
-* **Attribute-based access control (ABAC)**
-* **Role-based access control (RBAC)**
-* **User-based access control (UBAC)**
-* **Context-based access control (CBAC)**
-* **Rule-based access control**
- ** Using JavaScript
-* **Time-based access control**
-* **Support for custom access control mechanisms (ACMs) through a Service Provider Interface (SPI)**
-
-{project_name} is based on a set of administrative UIs and a RESTful API, and provides the necessary means to create permissions
-for your protected resources and scopes, associate those permissions with authorization policies, and enforce authorization decisions in your applications and services.
-
-Resource servers (applications or services serving protected resources) usually rely on some kind of information to decide if access should be granted to a protected resource. For RESTful-based resource servers, that information is usually obtained from a security token, usually sent as a bearer token on every request to the server. For web applications that rely on a session to authenticate users, that information is usually stored in a user's session and retrieved from there for each request.
-
-Frequently, resource servers only perform authorization decisions based on role-based access control (RBAC), where the roles granted to the user trying to access protected resources are checked against the roles mapped to these same resources. While roles are very useful and used by applications, they also have a few limitations:
-
-* Resources and roles are tightly coupled and changes to roles (such as adding, removing, or changing an access context) can impact multiple resources
-* Changes to your security requirements can imply deep changes to application code to reflect these changes
-* Depending on your application size, role management might become difficult and error-prone
-* It is not the most flexible access control mechanism. Roles do not represent who you are and lack contextual information. If you have been granted a role, you have at least some access.
-
-Considering that today we need to consider heterogeneous environments where users are distributed across different regions, with different local policies,
-using different devices, and with a high demand for information sharing, {project_name} Authorization Services can help you improve the authorization capabilities of your applications and services by providing:
-
-* Resource protection using fine-grained authorization policies and different access control mechanisms
-* Centralized Resource, Permission, and Policy Management
-* Centralized Policy Decision Point
-* REST security based on a set of REST-based authorization services
-* Authorization workflows and User-Managed Access
-* The infrastructure to help avoid code replication across projects (and redeploys) and quickly adapt to changes in your security requirements.
diff --git a/authorization_services/topics/auth-services-terminology.adoc b/authorization_services/topics/auth-services-terminology.adoc
deleted file mode 100644
index d8b3efd84..000000000
--- a/authorization_services/topics/auth-services-terminology.adoc
+++ /dev/null
@@ -1,76 +0,0 @@
-[[_overview_terminology]]
-= Terminology
-
-Before going further, it is important to understand these terms and concepts introduced by {project_name} Authorization Services.
-
-[[_overview_terminology_resource_server]]
-== Resource Server
-
-Per OAuth2 terminology, a resource server is the server hosting the protected resources and capable of accepting and responding to protected resource requests.
-
-Resource servers usually rely on some kind of information to decide whether access to a protected resource should be granted. For RESTful-based resource servers,
-that information is usually carried in a security token, typically sent as a bearer token along with every request to the server. Web applications that rely on a session to
-authenticate users usually store that information in the user's session and retrieve it from there for each request.
-
-In {project_name}, any *confidential* client application can act as a resource server. This client's resources and their respective scopes are protected and governed by a set of authorization policies.
-
-== Resource
-
-A resource is part of the assets of an application and the organization. It can be a set of one or more endpoints, a classic web resource such as an HTML page, and so on.
-In authorization policy terminology, a resource is the _object_ being protected.
-
-Every resource has a unique identifier that can represent a single resource or a set of resources. For instance, you can manage a _Banking Account Resource_ that represents and defines a set of authorization policies for all banking accounts. But you can also have a different resource named _Alice's Banking Account_, which represents a single resource owned by a single customer, which can have its own set of authorization policies.
-
-== Scope
-
-A resource's scope is a bounded extent of access that is possible to perform on a resource. In authorization policy terminology, a scope is one of the potentially many _verbs_ that can logically apply to a resource.
-
-It usually indicates what can be done with a given resource. Example of scopes are view, edit, delete, and so on. However, scope can also be related to specific information provided by a resource. In this case, you can have a project resource and a cost scope, where the cost scope is used to define specific policies and permissions for users to access a project's cost.
-
-== Permission
-
-Consider this simple and very common permission:
-
-A permission associates the object being protected with the policies that must be evaluated to determine whether access is granted.
-
-* *X* CAN DO *Y* ON RESOURCE *Z*
-** where ...
-*** *X* represents one or more users, roles, or groups, or a combination of them. You can also use claims and context here.
-*** *Y* represents an action to be performed, for example, write, view, and so on.
-*** *Z* represents a protected resource, for example, "/accounts".
-
-{project_name} provides a rich platform for building a range of permission strategies ranging from simple to very complex, rule-based dynamic permissions. It provides flexibility and helps to:
-
-* Reduce code refactoring and permission management costs
-* Support a more flexible security model, helping you to easily adapt to changes in your security requirements
-* Make changes at runtime; applications are only concerned about the resources and scopes being protected and not how they are protected.
-
-== Policy
-
-A policy defines the conditions that must be satisfied to grant access to an object. Unlike permissions, you do not specify the object being protected
-but rather the conditions that must be satisfied for access to a given object (for example, resource, scope, or both).
-Policies are strongly related to the different access control mechanisms (ACMs) that you can use to protect your resources.
-With policies, you can implement strategies for attribute-based access control (ABAC), role-based access control (RBAC), context-based access control, or any combination of these.
-
-{project_name} leverages the concept of policies and how you define them by providing the concept of aggregated policies, where you can build a "policy of policies" and still control the behavior of the evaluation.
-Instead of writing one large policy with all the conditions that must be satisfied for access to a given resource, the policies implementation in {project_name} Authorization Services follows the divide-and-conquer technique.
-That is, you can create individual policies, then reuse them with different permissions and build more complex policies by combining individual policies.
-
-== Policy provider
-
-Policy providers are implementations of specific policy types. {project_name} provides built-in policies, backed by their corresponding
-policy providers, and you can create your own policy types to support your specific requirements.
-
-{project_name} provides an SPI (Service Provider Interface) that you can use to plug in your own policy provider implementations.
-
-[[_overview_terminology_permission_ticket]]
-== Permission ticket
-
-A permission ticket is a special type of token defined by the User-Managed Access (UMA) specification that provides an opaque structure whose form is determined by the authorization server. This
-structure represents the resources and/or scopes being requested by a client, the access context, as well as the policies that must be applied to a request for authorization data (requesting party token [RPT]).
-
-In UMA, permission tickets are crucial to support person-to-person sharing and also person-to-organization sharing. Using permission tickets for authorization workflows enables a range of scenarios from simple to complex, where resource owners and resource servers have complete control over their resources based on fine-grained policies that govern the access to these resources.
-
-In the UMA workflow, permission tickets are issued by the authorization server to a resource server, which returns the permission ticket to the client trying to access a protected resource. Once the client receives the ticket, it can make a request for an RPT (a final token holding authorization data) by sending the ticket back to the authorization server.
-
-For more information on permission tickets, see <<_service_user_managed_access, User-Managed Access>> and the https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html[UMA] specification.
diff --git a/authorization_services/topics/authorization-quickstarts.adoc b/authorization_services/topics/authorization-quickstarts.adoc
deleted file mode 100644
index 3f360999e..000000000
--- a/authorization_services/topics/authorization-quickstarts.adoc
+++ /dev/null
@@ -1,35 +0,0 @@
-[[_authorization_quickstarts]]
-= Authorization quickstarts
-
-In addition to the *app-authz-jee-vanilla* quickstart that was used as a sample application in the previous section, the
-link:{quickstartRepo_link}[{quickstartRepo_name}] contains other applications that make use of the authorization services
-described in this documentation.
-
-The authorization quickstarts have been designed so that authorization services are displayed in different scenarios and
-using different technologies and integrations. It is not meant as a comprehensive set of all the possible use cases involving
-authorization but they should provide a starting point for users interested in understanding how the authorization services
-can be used in their own applications.
-
-Each quickstart has a `README` file with instructions on how to build, deploy, and test the sample application. The following
-table provides a brief description of the available authorization quickstarts:
-
-.Authorization quickstarts
-|===
-|Name |Description
-
-| {quickstartRepo_link}/tree/latest/app-authz-jee-servlet[app-authz-jee-servlet]
-| Demonstrates how to enable fine-grained authorization to a Jakarta EE application in order to protect specific resources and build a dynamic menu based on the permissions obtained from a {Project_Name} Server.
-
-| {quickstartRepo_link}/tree/latest/app-authz-jee-vanilla[app-authz-jee-vanilla]
-| Demonstrates how to enable fine-grained authorization to a Jakarta EE application and use the default authorization settings to protect all resources in the application.
-
-| {quickstartRepo_link}/tree/latest/app-authz-rest-springboot[app-authz-rest-springboot]
-| Demonstrates how to protect a SpringBoot REST service using {Project_Name} Authorization Services.
-
-| {quickstartRepo_link}/tree/latest/app-authz-springboot[app-authz-springboot]
-| Demonstrates how to write a SpringBoot Web application where both authentication and authorization aspects are managed by {Project_Name}.
-
-| {quickstartRepo_link}/tree/latest/app-authz-uma-photoz[app-authz-uma-photoz]
-| A simple application based on HTML5+AngularJS+JAX-RS that demonstrates how to enable User-Managed Access to your application and let users manage permissions for their resources.
-
-|===
diff --git a/authorization_services/topics/enforcer-authorization-context.adoc b/authorization_services/topics/enforcer-authorization-context.adoc
deleted file mode 100644
index b38e4d463..000000000
--- a/authorization_services/topics/enforcer-authorization-context.adoc
+++ /dev/null
@@ -1,71 +0,0 @@
-[[_enforcer_authorization_context]]
-= Obtaining the authorization context
-
-When policy enforcement is enabled, the permissions obtained from the server are available through `org.keycloak.AuthorizationContext`.
-This class provides several methods you can use to obtain permissions and ascertain whether a permission was granted for a particular resource or scope.
-
-Obtaining the Authorization Context in a Servlet Container
-```java
- HttpServletRequest request = ... // obtain javax.servlet.http.HttpServletRequest
- KeycloakSecurityContext keycloakSecurityContext =
- (KeycloakSecurityContext) request
- .getAttribute(KeycloakSecurityContext.class.getName());
- AuthorizationContext authzContext =
- keycloakSecurityContext.getAuthorizationContext();
-```
-
-[NOTE]
-For more details about how you can obtain a `KeycloakSecurityContext` consult the adapter configuration. The example above should be sufficient
-to obtain the context when running an application using any of the servlet containers supported by {project_name}.
-
-The authorization context helps give you more control over the decisions made and returned by the server. For example, you can use it
-to build a dynamic menu where items are hidden or shown depending on the permissions associated with a resource or scope.
-
-```java
-if (authzContext.hasResourcePermission("Project Resource")) {
- // user can access the Project Resource
-}
-
-if (authzContext.hasResourcePermission("Admin Resource")) {
- // user can access administration resources
-}
-
-if (authzContext.hasScopePermission("urn:project.com:project:create")) {
- // user can create new projects
-}
-```
-
-The `AuthorizationContext` represents one of the main capabilities of {project_name} Authorization Services. From the examples above, you can see that the protected resource is not directly associated with the policies that govern them.
-
-Consider some similar code using role-based access control (RBAC):
-
-```java
-if (User.hasRole('user')) {
- // user can access the Project Resource
-}
-
-if (User.hasRole('admin')) {
- // user can access administration resources
-}
-
-if (User.hasRole('project-manager')) {
- // user can create new projects
-}
-```
-
-Although both examples address the same requirements, they do so in different ways. In RBAC, roles only _implicitly_ define access for their resources. With {project_name} you gain the capability to create more manageable code that focuses directly on your resources whether you are using RBAC, attribute-based access control (ABAC), or any other BAC variant. Either you have the permission for a given resource or scope, or you don't.
-
-Now, suppose your security requirements have changed and in addition to project managers, PMOs can also create new projects.
-
-Security requirements change, but with {project_name} there is no need to change your application code to address the new requirements. Once your application is based on the resource and scope identifier, you need only change the configuration of the permissions or policies associated with a particular resource in the authorization server. In this case, the permissions and policies associated with the `Project Resource` and/or the scope `urn:project.com:project:create` would be changed.
-
-= Using the AuthorizationContext to obtain an Authorization Client Instance
-
-The ```AuthorizationContext``` can also be used to obtain a reference to the <<_service_client_api, Authorization Client API>> configured to your application:
-
-```java
- ClientAuthorizationContext clientContext = ClientAuthorizationContext.class.cast(authzContext);
- AuthzClient authzClient = clientContext.getClient();
-```
-
-In some cases, resource servers protected by the policy enforcer need to access the APIs provided by the authorization server. With an ```AuthzClient``` instance in hands, resource servers can interact with the server in order to create resources or check for specific permissions programmatically.
diff --git a/authorization_services/topics/enforcer-claim-information-point.adoc b/authorization_services/topics/enforcer-claim-information-point.adoc
deleted file mode 100644
index 62eae6a14..000000000
--- a/authorization_services/topics/enforcer-claim-information-point.adoc
+++ /dev/null
@@ -1,165 +0,0 @@
-[[_enforcer_claim_information_point]]
-= Claim Information Point
-
-A Claim Information Point (CIP) is responsible for resolving claims and pushing these claims to the {project_name} server
-in order to provide more information about the access context to policies. They can be defined as a configuration option
-to the policy-enforcer in order to resolve claims from different sources, such as:
-
-* HTTP Request (parameters, headers, body, etc)
-* External HTTP Service
-* 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 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.
-
-== Obtaining information from the HTTP request
-
-Here are several examples showing how you can extract claims from an HTTP request:
-
-.keycloak.json
-```json
-"policy-enforcer": {
- "paths": [
- {
- "path": "/protected/resource",
- "claim-information-point": {
- "claims": {
- "claim-from-request-parameter": "{request.parameter['a']}",
- "claim-from-header": "{request.header['b']}",
- "claim-from-cookie": "{request.cookie['c']}",
- "claim-from-remoteAddr": "{request.remoteAddr}",
- "claim-from-method": "{request.method}",
- "claim-from-uri": "{request.uri}",
- "claim-from-relativePath": "{request.relativePath}",
- "claim-from-secure": "{request.secure}",
- "claim-from-json-body-object": "{request.body['/a/b/c']}",
- "claim-from-json-body-array": "{request.body['/d/1']}",
- "claim-from-body": "{request.body}",
- "claim-from-static-value": "static value",
- "claim-from-multiple-static-value": ["static", "value"],
- "param-replace-multiple-placeholder": "Test {keycloak.access_token['/custom_claim/0']} and {request.parameter['a']} "
- }
- }
- }
- ]
- }
-```
-
-== Obtaining information from an external HTTP service
-
-Here are several examples showing how you can extract claims from an external HTTP Service:
-
-.keycloak.json
-```json
-"policy-enforcer": {
- "paths": [
- {
- "path": "/protected/resource",
- "claim-information-point": {
- "http": {
- "claims": {
- "claim-a": "/a",
- "claim-d": "/d",
- "claim-d0": "/d/0",
- "claim-d-all": ["/d/0", "/d/1"]
- },
- "url": "http://mycompany/claim-provider",
- "method": "POST",
- "headers": {
- "Content-Type": "application/x-www-form-urlencoded",
- "header-b": ["header-b-value1", "header-b-value2"],
- "Authorization": "Bearer {keycloak.access_token}"
- },
- "parameters": {
- "param-a": ["param-a-value1", "param-a-value2"],
- "param-subject": "{keycloak.access_token['/sub']}",
- "param-user-name": "{keycloak.access_token['/preferred_username']}",
- "param-other-claims": "{keycloak.access_token['/custom_claim']}"
- }
- }
- }
- }
- ]
- }
-```
-
-== Static claims
-
-.keycloak.json
-```json
-"policy-enforcer": {
- "paths": [
- {
- "path": "/protected/resource",
- "claim-information-point": {
- "claims": {
- "claim-from-static-value": "static value",
- "claim-from-multiple-static-value": ["static", "value"],
- }
- }
- }
- ]
- }
-```
-
-== Claim information provider SPI
-
-The Claim Information Provider SPI can be used by developers to support different claim information points in case none of the
-built-ins providers are enough to address their requirements.
-
-For example, to implement a new CIP provider you need to implement `org.keycloak.adapters.authorization.ClaimInformationPointProviderFactory`
-and `ClaimInformationPointProvider` and also provide the file `META-INF/services/org.keycloak.adapters.authorization.ClaimInformationPointProviderFactory`
-in your application`s classpath.
-
-Example of `org.keycloak.adapters.authorization.ClaimInformationPointProviderFactory`:
-
-```java
-public class MyClaimInformationPointProviderFactory implements ClaimInformationPointProviderFactory {
-
- @Override
- public String getName() {
- return "my-claims";
- }
-
- @Override
- public void init(PolicyEnforcer policyEnforcer) {
-
- }
-
- @Override
- public MyClaimInformationPointProvider create(Map config) {
- return new MyClaimInformationPointProvider(config);
- }
-}
-```
-
-Every CIP provider must be associated with a name, as defined above in the `MyClaimInformationPointProviderFactory.getName` method. The name
-will be used to map the configuration from the `claim-information-point` section in the `policy-enforcer` configuration to the implementation.
-
-When processing requests, the policy enforcer will call the MyClaimInformationPointProviderFactory.create method in order to obtain an
-instance of MyClaimInformationPointProvider. When called, any configuration defined for this particular CIP provider
-(via claim-information-point) is passed as a map.
-
-Example of `ClaimInformationPointProvider`:
-
-```java
-public class MyClaimInformationPointProvider implements ClaimInformationPointProvider {
-
- private final Map config;
-
- public MyClaimInformationPointProvider(Map config) {
- this.config = config;
- }
-
- @Override
- public Map> resolve(HttpFacade httpFacade) {
- Map> claims = new HashMap<>();
-
- // put whatever claim you want into the map
-
- return claims;
- }
-}
-```
diff --git a/authorization_services/topics/enforcer-https.adoc b/authorization_services/topics/enforcer-https.adoc
deleted file mode 100644
index a737df04a..000000000
--- a/authorization_services/topics/enforcer-https.adoc
+++ /dev/null
@@ -1,18 +0,0 @@
-[[_enforcer_filter_using_https]]
-= Configuring TLS/HTTPS
-
-When the server is using HTTPS, ensure your adapter is configured as follows:
-
-.keycloak.json
-```json
-{
- "truststore": "path_to_your_trust_store",
- "truststore-password": "trust_store_password"
-}
-```
-
-The configuration above enables TLS/HTTPS to the Authorization Client, making possible to access a
-{project_name} Server remotely using the HTTPS scheme.
-
-[NOTE]
-It is strongly recommended that you enable TLS/HTTPS when accessing the {project_name} Server endpoints.
diff --git a/authorization_services/topics/enforcer-js-adapter.adoc b/authorization_services/topics/enforcer-js-adapter.adoc
deleted file mode 100644
index ad7a9dd62..000000000
--- a/authorization_services/topics/enforcer-js-adapter.adoc
+++ /dev/null
@@ -1,149 +0,0 @@
-[[_enforcer_js_adapter]]
-= JavaScript integration
-
-The {project_name} Server comes with a JavaScript library you can use to interact with a resource server protected by a policy enforcer.
-This library is based on the {project_name} JavaScript adapter, which can be integrated to allow your client to obtain permissions from a {project_name} Server.
-
-You can obtain this library from a running a {project_name} Server instance by including the following `script` tag in your web page:
-
-[source,html,subs="attributes+"]
-----
-
-----
-Once you do that, you can create a `KeycloakAuthorization` instance as follows:
-
-```javascript
-const keycloak = ... // obtain a Keycloak instance from keycloak.js library
-const authorization = new KeycloakAuthorization(keycloak);
-```
-The *keycloak-authz.js* library provides two main features:
-
-* Obtain permissions from the server using a permission ticket, if you are accessing a UMA protected resource server.
-
-* Obtain permissions from the server by sending the resources and scopes the application wants to access.
-
-In both cases, the library allows you to easily interact with both resource server and {project_name} Authorization Services to obtain tokens with
-permissions your client can use as bearer tokens to access the protected resources on a resource server.
-
-== Handling authorization responses from a UMA-Protected resource server
-
-If a resource server is protected by a policy enforcer, it responds to client requests based on the permissions carried along with a bearer token.
-Typically, when you try to access a resource server with a bearer token that is lacking permissions to access a protected resource, the resource server
-responds with a *401* status code and a `WWW-Authenticate` header.
-
-[source,bash,subs="attributes+"]
-----
-HTTP/1.1 401 Unauthorized
-WWW-Authenticate: UMA realm="${realm}",
- as_uri="https://${host}:${port}{kc_realms_path}/${realm}",
- ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de"
-----
-
-See <<_service_uma_authorization_process, UMA Authorization Process>> for more information.
-
-What your client needs to do is extract the permission ticket from the ```WWW-Authenticate``` header returned by the resource server
-and use the library to send an authorization request as follows:
-
-```javascript
-// prepare a authorization request with the permission ticket
-const authorizationRequest = {};
-authorizationRequest.ticket = ticket;
-
-// send the authorization request, if successful retry the request
-Identity.authorization.authorize(authorizationRequest).then(function (rpt) {
- // onGrant
-}, function () {
- // onDeny
-}, function () {
- // onError
-});
-```
-
-The `authorize` function is completely asynchronous and supports a few callback functions to receive notifications from the server:
-
-* `onGrant`: The first argument of the function. If authorization was successful and the server returned an RPT with the requested permissions, the callback receives the RPT.
-* `onDeny`: The second argument of the function. Only called if the server has denied the authorization request.
-* `onError`: The third argument of the function. Only called if the server responds unexpectedly.
-
-Most applications should use the `onGrant` callback to retry a request after a 401 response. Subsequent requests should include the RPT as a bearer token for retries.
-
-== Obtaining entitlements
-
-The ```keycloak-authz.js``` library provides an `entitlement` function that you can use to obtain an RPT from the server by providing
-the resources and scopes your client wants to access.
-
-.Example about how to obtain an RPT with permissions for all resources and scopes the user can access
-```javascript
-authorization.entitlement('my-resource-server-id').then(function (rpt) {
- // onGrant callback function.
- // If authorization was successful you'll receive an RPT
- // with the necessary permissions to access the resource server
-});
-```
-
-.Example about how to obtain an RPT with permissions for specific resources and scopes
-```javascript
-authorization.entitlement('my-resource-server', {
- "permissions": [
- {
- "id" : "Some Resource"
- }
- ]
-}).then(function (rpt) {
- // onGrant
-});
-```
-
-When using the `entitlement` function, you must provide the _client_id_ of the resource server you want to access.
-
-The `entitlement` function is completely asynchronous and supports a few callback functions to receive notifications from the server:
-
-* `onGrant`: The first argument of the function. If authorization was successful and the server returned an RPT with the requested permissions, the callback receives the RPT.
-* `onDeny`: The second argument of the function. Only called if the server has denied the authorization request.
-* `onError`: The third argument of the function. Only called if the server responds unexpectedly.
-
-== Authorization request
-
-Both ```authorize``` and ```entitlement``` functions accept an authorization request object. This object can be set with the following
-properties:
-
-* *permissions*
-+
-An array of objects representing the resource and scopes. For instance:
-+
-```javascript
-const authorizationRequest = {
- "permissions": [
- {
- "id" : "Some Resource",
- "scopes" : ["view", "edit"]
- }
- ]
-}
-```
-+
-* *metadata*
-+
-An object where its properties define how the authorization request should be processed by the server.
-+
-** *response_include_resource_name*
-+
-A boolean value indicating to the server if resource names should be included in the RPT's permissions. If false, only the resource
-identifier is included.
-** *response_permissions_limit*
-+
-An integer N that defines a limit for the amount of permissions an RPT can have. When used together with
-`rpt` parameter, only the last N requested permissions will be kept in the RPT
-+
-* *submit_request*
-+
-A boolean value indicating whether the server should create permission requests to the resources and scopes referenced by a permission ticket.
-This parameter will only take effect when used together with the `ticket` parameter as part of a UMA authorization process.
-
-== Obtaining the RPT
-
-If you have already obtained an RPT using any of the authorization functions provided by the library, you can always obtain the RPT as follows from the authorization object (assuming that it has been initialized by one of the techniques shown earlier):
-
-```javascript
-const rpt = authorization.rpt;
-```
diff --git a/authorization_services/topics/enforcer-keycloak-enforcement-filter.adoc b/authorization_services/topics/enforcer-keycloak-enforcement-filter.adoc
deleted file mode 100644
index 9d6bca0bf..000000000
--- a/authorization_services/topics/enforcer-keycloak-enforcement-filter.adoc
+++ /dev/null
@@ -1,166 +0,0 @@
-[[_enforcer_filter]]
-= Configuration
-
-To enable policy enforcement for your application, add the following property to your *keycloak.json* file:
-
-.keycloak.json
-```json
-{
- "policy-enforcer": {}
-}
-```
-Or a little more verbose if you want to manually define the resources being protected:
-
-```json
-{
- "policy-enforcer": {
- "user-managed-access" : {},
- "enforcement-mode" : "ENFORCING",
- "paths": [
- {
- "path" : "/someUri/*",
- "methods" : [
- {
- "method": "GET",
- "scopes" : ["urn:app.com:scopes:view"]
- },
- {
- "method": "POST",
- "scopes" : ["urn:app.com:scopes:create"]
- }
- ]
- },
- {
- "name" : "Some Resource",
- "path" : "/usingPattern/{id}",
- "methods" : [
- {
- "method": "DELETE",
- "scopes" : ["urn:app.com:scopes:delete"]
- }
- ]
- },
- {
- "path" : "/exactMatch"
- },
- {
- "name" : "Admin Resources",
- "path" : "/usingWildCards/*"
- }
- ]
- }
-}
-```
-
-Here is a description of each configuration option:
-
-* *policy-enforcer*
-+
-Specifies the configuration options that define how policies are actually enforced and optionally the paths you want to protect. If not specified, the policy enforcer queries the server
-for all resources associated with the resource server being protected. In this case, you need to ensure the resources are properly configured with a <<_resource_create_uri, URIS>> property that matches the paths you want to protect.
-+
-** *user-managed-access*
-+
-Specifies that the adapter uses the UMA protocol. If specified, the adapter queries the server for permission tickets and returns them to clients according to the UMA specification. If not specified, the policy enforcer will be able to enforce permissions based on regular access tokens or RPTs. In this case,
-before denying access to the resource when the token lacks permission, the policy enforcer will try to obtain permissions directly from the server.
-+
-** *enforcement-mode*
-+
-Specifies how policies are enforced.
-+
-*** *ENFORCING*
-+
-(default mode) Requests are denied by default even when there is no policy associated with a given resource.
-+
-*** *PERMISSIVE*
-+
-Requests are allowed even when there is no policy associated with a given resource.
-+
-*** *DISABLED*
-+
-Completely disables the evaluation of policies and allows access to any resource. When `enforcement-mode` is `DISABLED`
-applications are still able to obtain all permissions granted by {project_name} through the <<_enforcer_authorization_context, Authorization Context>>
-+
-** *on-deny-redirect-to*
-+
-Defines a URL where a client request is redirected when an "access denied" message is obtained from the server. By default, the adapter responds with a 403 HTTP status code.
-+
-** *path-cache*
-+
-Defines how the policy enforcer should track associations between paths in your application and resources defined in {project_name}. The cache is needed to avoid
-unnecessary requests to a {project_name} server by caching associations between paths and protected resources.
-+
-*** *lifespan*
-+
-Defines the time in milliseconds when the entry should be expired. If not provided, default value is *30000*. A value equal to 0 can be set to completely disable the cache. A value equal to -1 can be set to disable the expiry of the cache.
-+
-*** *max-entries*
-+
-Defines the limit of entries that should be kept in the cache. If not provided, default value is *1000*.
-+
-** *paths*
-+
-Specifies the paths to protect. This configuration is optional. If not defined, the policy enforcer will discover all paths by fetching the resources you defined to your application in {project_name}, where these resources are defined with `URIS` representing some paths in your application.
-+
-*** *name*
-+
-The name of a resource on the server that is to be associated with a given path. When used in conjunction with a *path*, the policy enforcer ignores the resource's *URIS* property and uses the path you provided instead.
-*** *path*
-+
-(required) A URI relative to the application's context path. If this option is specified, the policy enforcer queries the server for a resource with a *URI* with the same value.
-Currently a very basic logic for path matching is supported. Examples of valid paths are:
-+
-**** Wildcards: `/*`
-**** Suffix: `/*.html`
-**** Sub-paths: `/path/*`
-**** Path parameters: /resource/{id}
-**** Exact match: /resource
-**** Patterns: /{version}/resource, /api/{version}/resource, /api/{version}/resource/*
-+
-*** *methods*
-+
-The HTTP methods (for example, GET, POST, PATCH) to protect and how they are associated with the scopes for a given resource in the server.
-+
-**** *method*
-+
-The name of the HTTP method.
-+
-**** *scopes*
-+
-An array of strings with the scopes associated with the method. When you associate scopes with a specific method, the client trying to access a protected resource (or path) must provide an RPT that grants permission to all scopes specified in the list. For example, if you define a method _POST_ with a scope _create_, the RPT must contain a permission granting access to the _create_ scope when performing a POST to the path.
-+
-**** *scopes-enforcement-mode*
-+
-A string referencing the enforcement mode for the scopes associated with a method. Values can be *ALL* or *ANY*. If *ALL*,
-all defined scopes must be granted in order to access the resource using that method. If *ANY*, at least one scope should be
-granted in order to gain access to the resource using that method. By default, enforcement mode is set to *ALL*.
-+
-*** *enforcement-mode*
-+
-Specifies how policies are enforced.
-+
-**** *ENFORCING*
-+
-(default mode) Requests are denied by default even when there is no policy associated with a given resource.
-+
-**** *DISABLED*
-+
-*** *claim-information-point*
-+
-Defines a set of one or more claims that must be resolved and pushed to the {project_name} server in order to make these claims available to policies. See <<_enforcer_claim_information_point, Claim Information Point>> for more details.
-+
-** *lazy-load-paths*
-+
-Specifies how the adapter should fetch the server for resources associated with paths in your application. If *true*, the policy
-enforcer is going to fetch resources on-demand accordingly with the path being requested. This configuration is specially useful
-when you don't want to fetch all resources from the server during deployment (in case you have provided no `paths`) or in case
-you have defined only a sub set of `paths` and want to fetch others on-demand.
-+
-** *http-method-as-scope*
-+
-Specifies how scopes should be mapped to HTTP methods. If set to *true*, the policy enforcer will use the HTTP method from the current request to
-check whether or not access should be granted. When enabled, make sure your resources in {project_name} are associated with scopes representing each HTTP method you are protecting.
-+
-** *claim-information-point*
-+
-Defines a set of one or more *global* claims that must be resolved and pushed to the {project_name} server in order to make these claims available to policies. See <<_enforcer_claim_information_point, Claim Information Point>> for more details.
diff --git a/authorization_services/topics/enforcer-overview.adoc b/authorization_services/topics/enforcer-overview.adoc
deleted file mode 100644
index e9c108afa..000000000
--- a/authorization_services/topics/enforcer-overview.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-[[_enforcer_overview]]
-= Policy enforcers
-
-Policy Enforcement Point (PEP) is a design pattern and as such you can implement it in different ways. {project_name} provides all the necessary means
-to implement PEPs for different platforms, environments, and programming languages. {project_name} Authorization Services presents a RESTful API,
-and leverages OAuth2 authorization capabilities for fine-grained authorization using a centralized authorization server.
-
-image:images/pep-pattern-diagram.png[alt="PEP overview"]
-
-A PEP is responsible for enforcing access decisions from the {project_name} server where these decisions are taken by evaluating the policies
-associated with a protected resource. It acts as a filter or interceptor in your application in order to check whether or not a particular request
-to a protected resource can be fulfilled based on the permissions granted by these decisions.
-
-Permissions are enforced depending on the protocol you are using. When using UMA, the policy enforcer always expects an RPT as a bearer token in order
-to decide whether or not a request can be served. That means clients should first obtain an RPT from {project_name} before sending requests to the resource server.
-
-However, if you are not using UMA, you can also send regular access tokens to the resource server. In this case, the policy enforcer will try to obtain permissions directly from the server.
-
-If you are using any of the {project_name} OIDC adapters, you can easily enable the policy enforcer by adding the following property to your *keycloak.json* file:
-
-.keycloak.json
-```json
-{
- "policy-enforcer": {}
-}
-```
-
-When you enable the policy enforcer all requests sent to your application are intercepted and access to protected resources will be granted
-depending on the permissions granted by {project_name} to the identity making the request.
-
-Policy enforcement is strongly linked to your application's paths and the <<_resource_overview, resources>> you created for a resource server using the {project_name} Administration Console. By default,
-when you create a resource server, {project_name} creates a <<_resource_server_default_config, default configuration>> for your resource server so you can enable policy enforcement quickly.
diff --git a/authorization_services/topics/getting-started-overview.adoc b/authorization_services/topics/getting-started-overview.adoc
deleted file mode 100644
index 2d5fb7b5c..000000000
--- a/authorization_services/topics/getting-started-overview.adoc
+++ /dev/null
@@ -1,26 +0,0 @@
-[[_getting_started_overview]]
-= Getting started
-
-Before you can use this tutorial, you need to complete the installation of {project_name} and create the initial admin user as shown in the link:{gettingstarted_link}[{gettingstarted_name}] tutorial.
-There is one caveat to this. You have to run a separate {appserver_name} instance on the same machine as {project_name} Server. This separate instance will run your Java Servlet application. Because of this you will have to run the {project_name} under a different port so that there are no port conflicts when running on the same machine. Use the `jboss.socket.binding.port-offset` system property on the command line. The value of this property is a number that will be added to the base value of every port opened by {project_name} Server.
-
-To boot {project_name} Server:
-
-.Linux/Unix
-[source]
-----
-$ .../bin/kc.sh start-dev --http-port 8180
-----
-
-.Windows
-[source]
-----
-> ...\bin\kc.bat start-dev --http-port 8180
-----
-
-After installing and booting both servers you should be able to access {project_name} Admin Console at http://localhost:8180/auth/admin/ and also the {appserver_name} instance at
-http://localhost:8080.
-
-[role="_additional-resources"]
-.Additional resources
-* For more details about installing and configuring {appserver_name} instances, see link:{adapterguide_link}[{adapterguide_name}].
diff --git a/authorization_services/topics/hello-world-before-start.adoc b/authorization_services/topics/hello-world-before-start.adoc
deleted file mode 100644
index ecc95b105..000000000
--- a/authorization_services/topics/hello-world-before-start.adoc
+++ /dev/null
@@ -1,15 +0,0 @@
-= Before you start
-
-This guide is based on the *{project_name} Demo Distribution*. Download the demo distribution before proceeding.
-
-[NOTE]
-This guide assumes that you are already familiar with {project_name} and that you are able to install and boot a {project_name} Server. For more information, see https://keycloak.gitbooks.io/getting-started-tutorials/content/[the Getting Started tutorials].
-
-Ensure you have a {project_name} instance running; the default configuration is http://localhost:8080/auth[http://localhost:8080/auth]. After logging in to the
-Administration Console, a page similar to this one is displayed:
-
-.{project_name} Admin Console
-image:images/getting-started/kc-start-page.png[alt="{project_name} Admin Console"]
-
-The source code for the getting started tutorials can be obtained from the demo distributions. The authorization-related examples
-are located at *${KEYCLOAK_DEMO_SERVER_DIR}/examples/authz*.
diff --git a/authorization_services/topics/hello-world-create-realm.adoc b/authorization_services/topics/hello-world-create-realm.adoc
deleted file mode 100644
index 4fa336586..000000000
--- a/authorization_services/topics/hello-world-create-realm.adoc
+++ /dev/null
@@ -1,33 +0,0 @@
-[[_getting_started_hello_world_create_realm]]
-= Creating a realm and a user
-
-The first step in this tutorial is to create a realm and a user in that realm. Then, within the realm we will create a single client application, which then becomes a <<_overview_terminology, resource server>> for which you need to enable authorization services.
-
-.Procedure
-
-. Create a realm with a name *hello-world-authz*. Once created, a page similar to the following is displayed:
-+
-.Realm hello-world-authz
-image:images/getting-started/hello-world/create-realm.png[alt="Realm hello-world-authz"]
-
-. Click *Users*.
-+
-The user list page displays where you can create a user.
-
-. Click *Create user*.
-. Complete the *Username*, *Email*, *First Name*, and *Last Name* fields.
-. Toggle *User Enabled* to *ON*.
-. Click *Create*.
-+
-.Add User
-image:images/getting-started/hello-world/create-user.png[alt="Add User"]
-
-. Set a password for the user by clicking the *Credentials* tab.
-+
-.Set user password
-image:images/getting-started/hello-world/reset-user-pwd.png[alt="Set user password"]
-
-. Complete the *New Password* and *Password Confirmation* fields and toggle *Temporary* to *OFF*.
-
-. Click *Save*.
-. Click *Save password*.
diff --git a/authorization_services/topics/hello-world-create-resource-server.adoc b/authorization_services/topics/hello-world-create-resource-server.adoc
deleted file mode 100644
index ad608b29a..000000000
--- a/authorization_services/topics/hello-world-create-resource-server.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-[[_getting_started_hello_world_enabling_authz_services]]
-= Enabling authorization services
-
-You can enable authorization services in an existing client application configured to use the OpenID Connect Protocol. You can also create a client using the following procedure.
-
-.Procedure
-
-. Click *Clients* in the menu.
-
-. Fill in the *Client type*.
-. Click *Next*.
-. Toggle *Client authentication* to *ON*.
-. Toggle *Authorization* to *ON*.
-. Click *Save*.
-. Scroll down to the *Capability config* section.
-. Fill in the *Root URL* field.
-. Click *Save*.
-+
-.Create client application
-image:images/getting-started/hello-world/create-client.png[alt="Create client application"]
-+
-A new *Authorization* tab is displayed for the client.
-+
-.Client Settings
-image:images/getting-started/hello-world/enable-authz.png[alt="Client Settings"]
-
-. Click the *Authorization* tab.
-+
-An Authorization Settings page similar to the following is displayed:
-+
-.Authorization settings
-image:images/getting-started/hello-world/authz-settings.png[alt="Authorization settings"]
-
-When you enable authorization services for a client application, {project_name} automatically creates several default settings for your client authorization configuration.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_resource_server_enable_authorization, Enabling authorization services>>
-* <<_resource_server_default_config, Default configuration>>
diff --git a/authorization_services/topics/hello-world-deploy.adoc b/authorization_services/topics/hello-world-deploy.adoc
deleted file mode 100644
index d7f6635b6..000000000
--- a/authorization_services/topics/hello-world-deploy.adoc
+++ /dev/null
@@ -1,129 +0,0 @@
-[[_getting_started_hello_world_deploy]]
-= Build, deploy, and test your application
-
-Now that the *app-authz-vanilla* resource server (or client) is properly configured and authorization services are enabled, it can be deployed to the server.
-
-The project and code for the application you are going to deploy is available in link:{quickstartRepo_link}[{quickstartRepo_name}]. You will need the following
-installed on your machine and available in your PATH before you can continue:
-
-* Java JDK 8
-* Apache Maven 3.1.1 or higher
-* Git
-
-ifeval::[{project_community}==true]
-You can obtain the code by cloning the repository at {quickstartRepo_link}. The quickstarts are designed to work with the most recent Keycloak release.
-endif::[]
-
-ifeval::[{project_product}==true]
-You can obtain the code by cloning the repository at {quickstartRepo_link}. Use the branch matching the version of {project_name} in use.
-endif::[]
-
-Follow these steps to download the code.
-
-.Clone Project
-[source, subs="attributes"]
-----
-$ git clone {quickstartRepo_link}
-----
-
-The application we are about to build and deploy is located at
-
-[source, subs="attributes"]
-----
-$ cd {quickstartRepo_dir}/app-authz-jee-vanilla
-----
-
-== Obtaining the adapter configuration
-
-You must first obtain the adapter configuration before building and deploying the application.
-
-.Procedure
-
-. Log into the Admin Console.
-
-. Click *Clients* in the menu.
-
-. In the client listing, click the *app-authz-vanilla* client application. The Client Settings page opens.
-+
-.Client Settings
-image:images/getting-started/hello-world/enable-authz.png[alt="Client Settings"]
-
-. From the *Action* list, select *Download adapter config*.
-. From the Format Option list, select *Keycloak OIDC JSON*.
-+
-The adapter configuration is displayed in JSON format.
-
-. Click *Download*.
-+
-.Adapter configuration
-image:images/getting-started/hello-world/adapter-config.png[alt="Adapter configuration"]
-
-. Move the file `keycloak.json` to the `app-authz-jee-vanilla/config` directory.
-
-. Optionally, specify a redirection URL.
-+
-By default, the policy enforcer responds with a `403` status code when the user lacks permission to access protected resources on the resource server. However, you can also specify a redirection URL for unauthorized users. To specify a redirection URL, edit the *keycloak.json* file that you updated and replace the `policy-enforcer` configuration with the following:
-+
-```json
-"policy-enforcer": {
- "on-deny-redirect-to" : "/app-authz-vanilla/error.jsp"
-}
-```
-+
-This change specifies to the policy enforcer to redirect users to a `/app-authz-vanilla/error.jsp` page if a user does not have the necessary permissions to access a protected resource, rather than an unhelpful `403 Unauthorized` message.
-
-== Building and deploying the application
-
-To build and deploy the application execute the following command:
-
-[source, subs="attributes"]
-----
-$ cd {quickstartRepo_dir}/app-authz-jee-vanilla
-$ mvn clean package wildfly:deploy
-----
-
-== Testing the application
-
-If your application was successfully deployed, you can access it at http://localhost:8080/app-authz-vanilla[http://localhost:8080/app-authz-vanilla]. The {project_name} Login page opens.
-
-.Login page
-image:images/getting-started/hello-world/login-page.png[alt="Login page"]
-
-.Procedure
-
-. Log in as *alice* using the password you specified for that user. The following page is displayed:
-+
-.Hello World Authz main page
-image:images/getting-started/hello-world/main-page.png[alt="Hello World Authz main page"]
-+
-The <<_resource_server_default_config, default settings>> defined by {project_name} when you enable authorization services for a client application provide a simple
-policy that always grants access to the resources protected by this policy.
-
-You can start by changing the default permissions and policies and test how your application responds, or even create new policies using the different
-<<_policy_overview, policy types>> provided by {project_name}.
-
-There are a plenty of things you can do now to test this application. For example, you can change the default policy by clicking
-the `Authorization` tab for the client, then client on the `Policies` tab, then click on the `Default Policy` in the list.
-Now we are going to change the `Logic` to `Negative` using the dropdown list in this page.
-
-. Log out of the demo application and log in again.
-+
-You can no longer access the application.
-+
-image:images/getting-started/hello-world/access-denied-page.png[alt="Access Denied page"]
-
-[role="_additional-resources"]
-.Additional resources
-* <<_policy_overview, Policy types>>
-
-== Next steps
-
-There are additional things you can do, such as:
-
-* Create a scope, define a policy and permission for it, and test it on the application side. Can the user perform an action (or anything else represented by the scope you created)?
-* Create different types of policies and associate these policies with the `Default Permission`.
-* Apply multiple policies to the `Default Permission` and test the behavior. For example, combine multiple policies and change the `Decision Strategy` accordingly.
-
-[role="_additional-resources"]
-.Additional resources
-* For more information about how to view and test permissions inside your application see <<_enforcer_authorization_context, Obtaining the authorization context>>.
diff --git a/authorization_services/topics/hello-world-overview.adoc b/authorization_services/topics/hello-world-overview.adoc
deleted file mode 100644
index 472ec7272..000000000
--- a/authorization_services/topics/hello-world-overview.adoc
+++ /dev/null
@@ -1,14 +0,0 @@
-[[_getting_started_hello_world_overview]]
-= Securing a servlet application
-
-The purpose of this getting started guide is to get you up and running as quickly as possible so that you can experiment with and test various authorization features provided by {project_name}.
-This quick tour relies heavily on the default database and server configurations and does not cover complex deployment options.
-For more information on features or configuration options, see the appropriate sections in this documentation.
-
-This guide explains key concepts about {project_name} Authorization Services:
-
-* Enabling fine-grained authorization for a client application
-* Configuring a client application to be a resource server, with protected resources
-* Defining permissions and authorization policies to govern access to protected resources
-* Enabling policy enforcement in your applications.
-
diff --git a/authorization_services/topics/permission-create-resource.adoc b/authorization_services/topics/permission-create-resource.adoc
deleted file mode 100644
index b547d5d89..000000000
--- a/authorization_services/topics/permission-create-resource.adoc
+++ /dev/null
@@ -1,42 +0,0 @@
-[[_permission_create_resource]]
-= Creating resource-based permission
-
-A resource-based permission defines a set of one or more resources to protect using a set of one or more authorization policies.
-
-To create a new resource-based permission, select *Create resource-based permission* from the *Create permission* dropdown.
-
-.Add Resource Permission
-image:images/permission/create-resource.png[alt="Add Resource Permission"]
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string describing the permission. A best practice is to use names that are closely related to your business and security requirements, so you
-can identify them more easily.
-+
-* *Description*
-+
-A string containing details about this permission.
-
-[[_permission_create_resource_apply_resource_type]]
-* *Apply To Resource Type*
-+
-Specifies if the permission is applied to all resources with a given type. When selecting this field, you are prompted to enter the resource type to protect.
-+
-** Resource Type
-+
-Defines the resource type to protect. When defined, this permission is evaluated for all resources matching that type.
-+
-* *Resources*
-+
-Defines a set of one or more resources to protect.
-
-* *Policy*
-+
-Defines a set of one or more policies to associate with a permission. To associate a policy you can either select an existing policy
-or create a new one by selecting the type of the policy you want to create.
-
-* *Decision Strategy*
-+
-The <<_permission_decision_strategies, Decision Strategy>> for this permission.
diff --git a/authorization_services/topics/permission-create-scope.adoc b/authorization_services/topics/permission-create-scope.adoc
deleted file mode 100644
index 3991e362a..000000000
--- a/authorization_services/topics/permission-create-scope.adoc
+++ /dev/null
@@ -1,37 +0,0 @@
-[[_permission_create_scope]]
-= Creating scope-based permissions
-
-A scope-based permission defines a set of one or more scopes to protect using a set of one or more authorization policies. Unlike resource-based permissions, you can use this permission type to create permissions not only for a resource, but also for the scopes associated with it, providing more granularity when defining the permissions that govern your resources and the actions that can be performed on them.
-
-To create a new scope-based permission, select *Create scope-based permission* from the *Create permission* dropdown.
-
-.Add Scope Permission
-image:images/permission/create-scope.png[alt="Add Scope Permission"]
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string describing the permission. A best practice is to use names that are closely related to your business and security requirements, so you
-can identify them more easily.
-+
-* *Description*
-+
-A string containing details about this permission.
-+
-* *Resource*
-+
-Restricts the scopes to those associated with the selected resource. If none is selected, all scopes are available.
-+
-* *Scopes*
-+
-Defines a set of one or more scopes to protect.
-
-* *Policy*
-+
-Defines a set of one or more policies to associate with a permission. To associate a policy you can either select an existing policy
-or create a new one by selecting the type of the policy you want to create.
-
-* *Decision Strategy*
-+
-The <<_permission_decision_strategies, Decision Strategy>> for this permission.
diff --git a/authorization_services/topics/permission-decision-strategy.adoc b/authorization_services/topics/permission-decision-strategy.adoc
deleted file mode 100644
index e862cf9a0..000000000
--- a/authorization_services/topics/permission-decision-strategy.adoc
+++ /dev/null
@@ -1,16 +0,0 @@
-[[_permission_decision_strategies]]
-= Policy decision strategies
-
-When associating policies with a permission, you can also define a decision strategy to specify how to evaluate the outcome of the associated policies to determine access.
-
-* *Unanimous*
-+
-The default strategy if none is provided. In this case, _all_ policies must evaluate to a positive decision for the final decision to be also positive.
-+
-* *Affirmative*
-+
-In this case, _at least one_ policy must evaluate to a positive decision for the final decision to be also positive.
-+
-* *Consensus*
-+
-In this case, the number of positive decisions must be greater than the number of negative decisions. If the number of positive and negative decisions is equal, the final decision will be negative.
diff --git a/authorization_services/topics/permission-overview.adoc b/authorization_services/topics/permission-overview.adoc
deleted file mode 100644
index 41b2abcad..000000000
--- a/authorization_services/topics/permission-overview.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-[[_permission_overview]]
-= Managing permissions
-
-A permission associates the object being protected and the policies that must be evaluated to decide whether access should be granted.
-
-After creating the resources you want to protect and the policies you want to use to protect these resources,
-you can start managing permissions. To manage permissions, click the *Permissions* tab when editing a resource server.
-
-.Permissions
-image:images/permission/view.png[alt="Permissions"]
-
-Permissions can be created to protect two main types of objects:
-
-* *Resources*
-* *Scopes*
-
-To create a permission, select the permission type you want to create from the item list in the upper right corner of the permission listing. The following sections describe these two types of objects in more detail.
diff --git a/authorization_services/topics/permission-typed-resource-permission.adoc b/authorization_services/topics/permission-typed-resource-permission.adoc
deleted file mode 100644
index da0cd9fa0..000000000
--- a/authorization_services/topics/permission-typed-resource-permission.adoc
+++ /dev/null
@@ -1,16 +0,0 @@
-[[_permission_typed_resource]]
-= Typed resource permission
-
-Resource permissions can also be used to define policies that are to be applied to all resources with a given <<_resource_create_type, type>>. This form of resource-based permission can be useful when you have resources sharing common access requirements and constraints.
-
-Frequently, resources within an application can be categorized (or typed) based on the data they encapsulate or the functionality they provide. For example, a financial application can manage different banking accounts where each one belongs to a specific customer. Although they are different banking accounts, they share common security requirements and constraints that are globally defined by the banking organization. With typed resource permissions, you can define common policies to apply to all banking accounts, such as:
-
-* Only the owner can manage his account
-* Only allow access from the owner's country and/or region
-* Enforce a specific authentication method
-
-To create a typed resource permission, click <<_permission_create_resource_apply_resource_type, Apply to Resource Type>> when creating a new resource-based permission. With `Apply to Resource Type` set to `On`,
-you can specify the type that you want to protect as well as the policies that are to be applied to govern access to all resources with type you have specified.
-
-.Example of a typed resource permission
-image:images/permission/typed-resource-perm-example.png[alt="Example of a typed resource permission"]
diff --git a/authorization_services/topics/policy-aggregated-policy.adoc b/authorization_services/topics/policy-aggregated-policy.adoc
deleted file mode 100644
index 7c5f76814..000000000
--- a/authorization_services/topics/policy-aggregated-policy.adoc
+++ /dev/null
@@ -1,66 +0,0 @@
-[[_policy_aggregated]]
-= Aggregated policy
-
-As mentioned previously, {project_name} allows you to build a policy of policies, a concept referred to as policy aggregation. You can use policy aggregation to reuse existing policies to build more complex ones and keep your permissions even more decoupled from the policies that are evaluated during the processing of authorization requests.
-
-ifeval::[{project_community}==true]
-To create a new aggregated policy, select *Aggregated* from the policy type list.
-endif::[]
-ifeval::[{project_product}==true]
-To create a new aggregated policy, select *Aggregated* in the item list located in the right upper corner of the policy listing.
-endif::[]
-
-.Add an aggregated policy
-image:images/policy/create-aggregated.png[alt="Add aggregated policy"]
-
-Let's suppose you have a resource called _Confidential Resource_ that can be accessed only by users from the _keycloak.org_ domain and from a certain range of IP addresses.
-You can create a single policy with both conditions. However, you want to reuse the domain part of this policy to apply to permissions that operates regardless of the originating network.
-
-You can create separate policies for both domain and network conditions and create a third policy based on the combination of these two policies. With an aggregated policy, you can freely combine other policies and then apply the new aggregated policy to any permission you want.
-
-[NOTE]
-When creating aggregated policies, be mindful that you are not introducing a circular reference or dependency between policies. If a circular dependency is detected, you cannot create or update the policy.
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string describing the policy. We strongly suggest that you use names that are closely related with your business and security requirements, so you
-can identify them more easily and also know what they mean.
-+
-* *Description*
-+
-A string with more details about this policy.
-+
-* *Apply Policy*
-+
-Defines a set of one or more policies to associate with the aggregated policy. To associate a policy you can either select an existing policy
-or create a new one by selecting the type of the policy you want to create.
-+
-* *Decision Strategy*
-+
-The decision strategy for this permission.
-+
-* *Logic*
-+
-The logic of this policy to apply after the other conditions have been evaluated.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_policy_logic, Positive and negative logic>>
-
-== Decision strategy for aggregated policies
-
-When creating aggregated policies, you can also define the decision strategy that will be used to determine the final decision based on the outcome from each policy.
-
-* *Unanimous*
-+
-The default strategy if none is provided. In this case, _all_ policies must evaluate to a positive decision for the final decision to be also positive.
-+
-* *Affirmative*
-+
-In this case, _at least one_ policy must evaluate to a positive decision in order for the final decision to be also positive.
-+
-* *Consensus*
-+
-In this case, the number of positive decisions must be greater than the number of negative decisions. If the number of positive and negative decisions is the same, the final decision will be negative.
diff --git a/authorization_services/topics/policy-client-policy.adoc b/authorization_services/topics/policy-client-policy.adoc
deleted file mode 100644
index aa9a7095c..000000000
--- a/authorization_services/topics/policy-client-policy.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-[[_policy_client]]
-= Client-based policy
-
-You can use this type of policy to define conditions for your permissions where a set of one or more clients is permitted to access an object.
-
-To create a new client-based policy, select *Client* from the policy type list.
-
-.Add a Client Policy
-image:images/policy/create-client.png[alt="Add a Client Policy"]
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string identifying the policy. A best practice is to use names that are closely related to your business and security requirements, so you
-can identify them more easily.
-+
-* *Description*
-+
-A string containing details about this policy.
-+
-* *Clients*
-+
-Specifies which clients have givenGroup-based policy access by this policy.
-+
-* *Logic*
-+
-The logic of this policy to apply after the other conditions have been evaluated.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_policy_logic, Positive and negative logic>>
diff --git a/authorization_services/topics/policy-client-scope-policy-required-client-scope.adoc b/authorization_services/topics/policy-client-scope-policy-required-client-scope.adoc
deleted file mode 100644
index dd07fed24..000000000
--- a/authorization_services/topics/policy-client-scope-policy-required-client-scope.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-[[_policy_client_scope_required]]
-= Defining a client scope as required
-
-When creating a client scope-based policy, you can specify a specific client scope as `Required`. When you do that, the policy will grant access only if the client requesting access has been granted *all* the *required* client scopes.
-
-.Example of required client scope
-image:images/policy/create-client-scope.png[alt="Example of required client scope"]
-
-To specify a client scope as required, select the `Required` checkbox for the client scope you want to configure as required.
-
-Required client scopes can be useful when your policy defines multiple client scopes but only a subset of them are mandatory.
diff --git a/authorization_services/topics/policy-client-scope-policy.adoc b/authorization_services/topics/policy-client-scope-policy.adoc
deleted file mode 100644
index 18f6db629..000000000
--- a/authorization_services/topics/policy-client-scope-policy.adoc
+++ /dev/null
@@ -1,33 +0,0 @@
-[[_policy_client_scope]]
-= Client scope-based policy
-
-You can use this type of policy to define conditions for your permissions where a set of one or more client scopes is permitted to access an object.
-
-By default, client scopes added to this policy are not specified as required and the policy will grant access if the client requesting access has been granted any of these client scopes. However, you can specify a specific client scope as <<_policy_client_scope_required, required>> if you want to enforce a specific client scope.
-
-To create a new client scope-based policy, select *Client Scope* from the policy type list.
-
-.Add Client Scope Policy
-image:images/policy/create-client-scope.png[alt="Add Client Scope Policy"]
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string describing the policy. A best practice is to use names that are closely related to your business and security requirements, so you can identify them more easily.
-+
-* *Description*
-+
-A string containing details about this policy.
-+
-* *Client Scopes*
-+
-Specifies which client scopes are permitted by this policy.
-+
-* *Logic*
-+
-The logic of this policy to apply after the other conditions have been evaluated.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_policy_logic, Positive and negative logic>>
diff --git a/authorization_services/topics/policy-evaluation-api.adoc b/authorization_services/topics/policy-evaluation-api.adoc
deleted file mode 100644
index 5fbacbe7b..000000000
--- a/authorization_services/topics/policy-evaluation-api.adoc
+++ /dev/null
@@ -1,121 +0,0 @@
-[[_policy_evaluation_api]]
-= Policy evaluation API
-
-When writing rule-based policies using JavaScript, {project_name} provides an Evaluation API that provides useful information to help determine whether a permission should be granted.
-
-This API consists of a few interfaces that provide you access to information, such as
-
-* The permission being evaluated, representing both the resource and scopes being requested.
-* The attributes associated with the resource being requested
-* Runtime environment and any other attribute associated with the execution context
-* Information about users such as group membership and roles
-
-The main interface is *org.keycloak.authorization.policy.evaluation.Evaluation*, which defines the following contract:
-
-```java
-public interface Evaluation {
-
- /**
- * Returns the {@link ResourcePermission} to be evaluated.
- *
- * @return the permission to be evaluated
- */
- ResourcePermission getPermission();
-
- /**
- * Returns the {@link EvaluationContext}. Which provides access to the whole evaluation runtime context.
- *
- * @return the evaluation context
- */
- EvaluationContext getContext();
-
- /**
- * Returns a {@link Realm} that can be used by policies to query information.
- *
- * @return a {@link Realm} instance
- */
- Realm getRealm();
-
- /**
- * Grants the requested permission to the caller.
- */
- void grant();
-
- /**
- * Denies the requested permission.
- */
- void deny();
-}
-```
-
-When processing an authorization request, {project_name} creates an `Evaluation` instance before evaluating any policy. This instance is then passed to each policy to determine whether access is *GRANT* or *DENY*.
-
-Policies determine this by invoking the `grant()` or `deny()` methods on an `Evaluation` instance. By default, the state of the `Evaluation` instance is denied, which means that your policies must explicitly invoke the `grant()` method to indicate to the policy evaluation engine that permission should be granted.
-
-.Additional resources
-
-* {apidocs_link}[JavaDocs Documentation].
-
-== The evaluation context
-
-The evaluation context provides useful information to policies during their evaluation.
-
-```java
-public interface EvaluationContext {
-
- /**
- * Returns the {@link Identity} that represents an entity (person or non-person) to which the permissions must be granted, or not.
- *
- * @return the identity to which the permissions must be granted, or not
- */
- Identity getIdentity();
-
- /**
- * Returns all attributes within the current execution and runtime environment.
- *
- * @return the attributes within the current execution and runtime environment
- */
- Attributes getAttributes();
-}
-```
-
-From this interface, policies can obtain:
-
-* The authenticated `Identity`
-* Information about the execution context and runtime environment
-
-The `Identity` is built based on the OAuth2 Access Token that was sent along with the authorization request, and this construct has access to all claims
-extracted from the original token. For example, if you are using a _Protocol Mapper_ to include a custom claim in an OAuth2 Access Token you can also access this claim
-from a policy and use it to build your conditions.
-
-The `EvaluationContext` also gives you access to attributes related to both the execution and runtime environments. For now, there only a few built-in attributes.
-
-.Execution and Runtime Attributes
-|===
-|Name |Description | Type
-
-| kc.time.date_time
-| Current date and time
-| String. Format `MM/dd/yyyy hh:mm:ss`
-
-| kc.client.network.ip_address
-| IPv4 address of the client
-| String
-
-| kc.client.network.host
-| Client's host name
-| String
-
-| kc.client.id
-| The client id
-| String
-
-| kc.client.user_agent
-| The value of the 'User-Agent' HTTP header
-| String[]
-
-| kc.realm.name
-| The name of the realm
-| String
-
-|===
diff --git a/authorization_services/topics/policy-evaluation-tool-overview.adoc b/authorization_services/topics/policy-evaluation-tool-overview.adoc
deleted file mode 100644
index d93948089..000000000
--- a/authorization_services/topics/policy-evaluation-tool-overview.adoc
+++ /dev/null
@@ -1,24 +0,0 @@
-[[_policy_evaluation_overview]]
-= Evaluating and testing policies
-
-When designing your policies, you can simulate authorization requests to test how your policies are being evaluated.
-
-You can access the Policy Evaluation Tool by clicking the `Evaluate` tab when editing a resource server. There you can specify different inputs to simulate real authorization requests and test the effect of your policies.
-
-.Policy evaluation tool
-image:images/policy-evaluation-tool/policy-evaluation-tool.png[alt="Policy evaluation tool"]
-
-== Providing identity information
-
-The *Identity Information* filters can be used to specify the user requesting permissions.
-
-== Providing contextual information
-
-The *Contextual Information* filters can be used to define additional attributes to the evaluation context, so that policies can obtain these same attributes.
-
-== Providing the permissions
-
-The *Permissions* filters can be used to build an authorization request. You can request permissions for a set of one or more resources and scopes. If you want
-to simulate authorization requests based on all protected resources and scopes, click *Add* without specifying any `Resources` or `Scopes`.
-
-When you've specified your desired values, click *Evaluate*.
diff --git a/authorization_services/topics/policy-group-policy-extend-children.adoc b/authorization_services/topics/policy-group-policy-extend-children.adoc
deleted file mode 100644
index 952b0f8f0..000000000
--- a/authorization_services/topics/policy-group-policy-extend-children.adoc
+++ /dev/null
@@ -1,12 +0,0 @@
-[[_policy_group_extend_access_children]]
-= Extending access to child groups
-
-By default, when you add a group to this policy, access restrictions will only apply to members of the selected group.
-
-Under some circumstances, it might be necessary to allow access not only to the group itself but to any child group in the hierarchy. For any group
-added you can mark a checkbox *Extend to Children* in order to extend access to child groups.
-
-.Extending access to child groups
-image:images/policy/create-group-extend-children.png[alt="Extending access to child groups"]
-
-In the example above, the policy is granting access for any user member of *IT* or any of its children.
diff --git a/authorization_services/topics/policy-group-policy.adoc b/authorization_services/topics/policy-group-policy.adoc
deleted file mode 100644
index 9efaead26..000000000
--- a/authorization_services/topics/policy-group-policy.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-[[_policy_group]]
-= Group-based policy
-
-You can use this type of policy to define conditions for your permissions where a set of one or more groups (and their hierarchies) is permitted to access an object.
-
-To create a new group-based policy, select *Group* from the policy type list.
-
-.Group Policy
-image:images/policy/create-group.png[alt="Add Group Policy"]
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string describing the policy. A best practice is to use names that are closely related to your business and security requirements, so you
-can identify them more easily.
-+
-* *Description*
-+
-A string containing details about this policy.
-+
-* *Groups Claim*
-+
-Specifies the name of the claim in the token holding the group names and/or paths. Usually, authorization requests are processed based on an ID Token or Access Token
-previously issued to a client acting on behalf of some user. If defined, the token must include a claim from where this policy is going to obtain the groups
-the user is a member of. If not defined, user's groups are obtained from your realm configuration.
-+
-* *Groups*
-+
-Allows you to select the groups that should be enforced by this policy when evaluating permissions. After adding a group, you can extend access to children of the group
-by marking the checkbox *Extend to Children*. If left unmarked, access restrictions only applies to the selected group.
-+
-* *Logic*
-+
-The logic of this policy to apply after the other conditions have been evaluated.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_policy_logic, Positive and negative logic>>
diff --git a/authorization_services/topics/policy-js-policy.adoc b/authorization_services/topics/policy-js-policy.adoc
deleted file mode 100644
index 248d6533c..000000000
--- a/authorization_services/topics/policy-js-policy.adoc
+++ /dev/null
@@ -1,152 +0,0 @@
-[[_policy_js]]
-= 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].
-
-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>>.
-
-To create a new JavaScript-based policy, select *JavaScript* in the item list in the upper right corner of the policy listing.
-
-NOTE: By default, JavaScript Policies can not be uploaded to the server. You should prefer deploying your JS Policies directly to
-the server as described in link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}].
-
-== Creating a JS policy from a deployed JAR file
-
-{project_name} allows you to deploy a JAR file in order to deploy scripts to the server. Please, take a look at link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}]
-for more details.
-
-Once you have your scripts deployed, you should be able to select the scripts you deployed from the list of available policy providers.
-
-== Examples
-
-=== Checking for attributes from the evaluation context
-Here is a simple example of a JavaScript-based policy that uses attribute-based access control (ABAC) to define a condition based on an attribute
-obtained from the execution context:
-
-```javascript
-const context = $evaluation.getContext();
-const contextAttributes = context.getAttributes();
-
-if (contextAttributes.containsValue('kc.client.network.ip_address', '127.0.0.1')) {
- $evaluation.grant();
-}
-```
-
-=== Checking for attributes from the current identity
-Here is a simple example of a JavaScript-based policy that uses attribute-based access control (ABAC) to define a condition based on an attribute
-obtained associated with the current identity:
-
-```javascript
-const context = $evaluation.getContext();
-const identity = context.getIdentity();
-const attributes = identity.getAttributes();
-const email = attributes.getValue('email').asString(0);
-
-if (email.endsWith('@keycloak.org')) {
- $evaluation.grant();
-}
-```
-
-Where these attributes are mapped from whatever claim is defined in the token that was used in the authorization request.
-
-=== Checking for roles granted to the current identity
-You can also use Role-Based Access Control (RBAC) in your policies. In the example below, we check if a user is granted with a `keycloak_user` *realm* role:
-
-```javascript
-const context = $evaluation.getContext();
-const identity = context.getIdentity();
-
-if (identity.hasRealmRole('keycloak_user')) {
- $evaluation.grant();
-}
-```
-
-Or you can check if a user is granted with a `my-client-role` *client* role, where `my-client` is the client id of the client application:
-
-```javascript
-const context = $evaluation.getContext();
-const identity = context.getIdentity();
-
-if (identity.hasClientRole('my-client', 'my-client-role')) {
- $evaluation.grant();
-}
-```
-
-=== Checking for roles granted to a user
-To check for realm roles granted to a user:
-
-```javascript
-const realm = $evaluation.getRealm();
-
-if (realm.isUserInRealmRole('marta', 'role-a')) {
- $evaluation.grant();
-}
-```
-
-Or for client roles granted to a user:
-
-```javascript
-const realm = $evaluation.getRealm();
-
-if (realm.isUserInClientRole('marta', 'my-client', 'some-client-role')) {
- $evaluation.grant();
-}
-```
-
-=== Checking for roles granted to a group
-To check for realm roles granted to a group:
-
-```javascript
-const realm = $evaluation.getRealm();
-
-if (realm.isGroupInRole('/Group A/Group D', 'role-a')) {
- $evaluation.grant();
-}
-```
-
-=== Pushing arbitrary claims to the resource server
-To push arbitrary claims to the resource server in order to provide additional information on how permissions should be
-enforced:
-
-```javascript
-const permission = $evaluation.getPermission();
-
-// decide if permission should be granted
-
-if (granted) {
- permission.addClaim('claim-a', 'claim-a');
- permission.addClaim('claim-a', 'claim-a1');
- permission.addClaim('claim-b', 'claim-b');
-}
-
-```
-
-=== Checking for group membership
-
-```javascript
-const realm = $evaluation.getRealm();
-
-if (realm.isUserInGroup('marta', '/Group A/Group B')) {
- $evaluation.grant();
-}
-```
-
-=== Mixing different access control mechanisms
-You can also use a combination of several access control mechanisms. The example below shows how roles(RBAC) and
-claims/attributes(ABAC) checks can be used within the same policy. In this case we check if user is granted with `admin` role
-or has an e-mail from `keycloak.org` domain:
-
-```javascript
-const context = $evaluation.getContext();
-const identity = context.getIdentity();
-const attributes = identity.getAttributes();
-const email = attributes.getValue('email').asString(0);
-
-if (identity.hasRealmRole('admin') || email.endsWith('@keycloak.org')) {
- $evaluation.grant();
-}
-```
-
-NOTE: When writing your own rules, keep in mind that the *$evaluation* object is an object implementing *org.keycloak.authorization.policy.evaluation.Evaluation*. For more information about what you can access from this interface, see the <<_policy_evaluation_api, Evaluation API>>.
diff --git a/authorization_services/topics/policy-logic.adoc b/authorization_services/topics/policy-logic.adoc
deleted file mode 100644
index cfdd88e79..000000000
--- a/authorization_services/topics/policy-logic.adoc
+++ /dev/null
@@ -1,8 +0,0 @@
-[[_policy_logic]]
-= Positive and negative logic
-
-Policies can be configured with positive or negative logic. Briefly, you can use this option to define whether the policy result should be kept as it is or be negated.
-
-For example, suppose you want to create a policy where only users *not* granted with a specific role should be given access. In this case,
-you can create a role-based policy using that role and set its *Logic* field to *Negative*. If you keep *Positive*, which
-is the default behavior, the policy result will be kept as it is.
diff --git a/authorization_services/topics/policy-overview.adoc b/authorization_services/topics/policy-overview.adoc
deleted file mode 100644
index 5bb8fc27b..000000000
--- a/authorization_services/topics/policy-overview.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-[[_policy_overview]]
-= Managing policies
-
-As mentioned previously, policies define the conditions that must be satisfied before granting access to an object.
-
-.Procedure
-
-. Click the *Policy* tab to view all policies associated with a resource server.
-+
-.Policies
-image:images/policy/view.png[alt="Policies"]
-+
-On this tab, you can view the list of previously created policies as well as create and edit a policy.
-
-To create a new policy, click *Create policy*, then select a policy type from the list.
-
-Details about each policy type are described in this section.
diff --git a/authorization_services/topics/policy-regex-policy.adoc b/authorization_services/topics/policy-regex-policy.adoc
deleted file mode 100644
index a3fa5f6bc..000000000
--- a/authorization_services/topics/policy-regex-policy.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-[[_policy_regex]]
-= Regex-Based Policy
-
-You can use this type of policy to define regex conditions for your permissions.
-
-To create a new regex-based policy, select *Regex* from the policy type list.
-
-This policy resolves attributes available from the current identity.
-
-.Add Regex Policy
-image:images/policy/create-regex.png[alt="Add Regex Policy"]
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string describing the policy. A best practice is to use names that are closely related to your business and security requirements, so you can identify them more easily.
-+
-* *Description*
-+
-A string containing details about this policy.
-+
-* *Target Claim*
-+
-Specifies the name of the target claim in the token. For JSON-based claims, you can use dot notation for nesting and square brackets to access array fields by index. For example, contact.address[0].country. If the target claim references a JSON
-object, the first path (for example, `contact`) should map to the attribute name holding the JSON object.
-+
-* *Regex Pattern*
-+
-Specifies the regex pattern.
-+
-* *Logic*
-+
-The <<_policy_logic, Logic>> of this policy to apply after the other conditions have been evaluated.
diff --git a/authorization_services/topics/policy-role-policy-required-role.adoc b/authorization_services/topics/policy-role-policy-required-role.adoc
deleted file mode 100644
index 3a4aecba7..000000000
--- a/authorization_services/topics/policy-role-policy-required-role.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-[[_policy_rbac_required]]
-= Defining a role as required
-
-When creating a role-based policy, you can specify a specific role as `Required`. When you do that, the policy will grant access
-only if the user requesting access has been granted *all* the *required* roles. Both realm and client roles can be configured as such.
-
-.Example of a required role
-image:images/policy/create-role.png[alt="Example of a required role"]
-
-To specify a role as required, select the `Required` checkbox for the role you want to configure as required.
-
-Required roles can be useful when your policy defines multiple roles but only a subset of them are mandatory. In this case, you can combine realm and client roles to enable an
-even more fine-grained role-based access control (RBAC) model for your application. For example, you can have policies specific for a client and require a specific client role associated with that client. Or you can enforce that access is granted only in the presence of a specific realm role. You can also combine both approaches within the same policy.
diff --git a/authorization_services/topics/policy-role-policy.adoc b/authorization_services/topics/policy-role-policy.adoc
deleted file mode 100644
index 06510d3be..000000000
--- a/authorization_services/topics/policy-role-policy.adoc
+++ /dev/null
@@ -1,40 +0,0 @@
-[[_policy_rbac]]
-= Role-based policy
-
-You can use this type of policy to define conditions for your permissions where a set of one or more roles is permitted to access an object.
-
-By default, roles added to this policy are not specified as required and the policy will grant access if the user requesting access has been granted any of these roles. However, you can specify a specific role as <<_policy_rbac_required, required>> if you want to enforce a specific role. You can also combine required and non-required roles, regardless of whether they are realm or client roles.
-
-Role policies can be useful when you need more restricted role-based access control (RBAC), where specific roles must be enforced to grant access to an object. For instance, you can enforce that a user must consent to allowing a client application (which is acting on the user's behalf) to access the user's resources. You can use {project_name} Client Scope Mapping to enable consent pages or even enforce clients to explicitly provide a scope when obtaining access tokens from a {project_name} server.
-
-To create a new role-based policy, select *Role* from the policy type list.
-
-.Add Role Policy
-image:images/policy/create-role.png[alt="Add Role Policy"]
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string describing the policy. A best practice is to use names that are closely related to your business and security requirements, so you
-can identify them more easily.
-+
-* *Description*
-+
-A string containing details about this policy.
-+
-* *Realm Roles*
-+
-Specifies which *realm* roles are permitted by this policy.
-+
-* *Client Roles*
-+
-Specifies which *client* roles are permitted by this policy. To enable this field must first select a `Client`.
-+
-* *Logic*
-+
-The logic of this policy to apply after the other conditions have been evaluated.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_policy_logic, Positive and negative logic>>
diff --git a/authorization_services/topics/policy-time-policy.adoc b/authorization_services/topics/policy-time-policy.adoc
deleted file mode 100644
index 6acd14ab9..000000000
--- a/authorization_services/topics/policy-time-policy.adoc
+++ /dev/null
@@ -1,52 +0,0 @@
-[[_policy_time]]
-= Time-based policy
-
-You can use this type of policy to define time conditions for your permissions.
-
-To create a new time-based policy, select *Time* in the item list in the upper right corner of the policy listing.
-
-.Add Time Policy
-image:images/policy/create-time.png[alt="Add Time Policy"]
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string describing the policy. A best practice is to use names that are closely related to your business and security requirements, so you
-can identify them more easily.
-+
-* *Description*
-+
-A string containing details about this policy.
-+
-* *Start time*
-+
-Defines the time before which access must *not* be granted. Permission is granted only if the current date/time is later than or equal to this value.
-* *Expire time*
-+
-Defines the time after which access must *not* be granted. Permission is granted only if the current date/time is earlier than or equal to this value. Select *Repeat* to repeat access being granted on a specific *Day of Month*, *Month*, *Year*, *Hour* or *Minute*.
-
-* *Day of Month*
-+
-Defines the day of month that access must be granted. You can also specify a range of dates. In this case, permission is granted only if the current day of the month is between or equal to the two values specified.
-* *Month*
-+
-Defines the month that access must be granted. You can also specify a range of months. In this case, permission is granted only if the current month is between or equal to the two values specified.
-* *Year*
-+
-Defines the year that access must be granted. You can also specify a range of years. In this case, permission is granted only if the current year is between or equal to the two values specified.
-* *Hour*
-+
-Defines the hour that access must be granted. You can also specify a range of hours. In this case, permission is granted only if current hour is between or equal to the two values specified.
-* *Minute*
-+
-Defines the minute that access must be granted. You can also specify a range of minutes. In this case, permission is granted only if the current minute is between or equal to the two values specified.
-* *Logic*
-+
-The logic of this policy to apply after the other conditions have been evaluated.
-
-Access is only granted if all conditions are satisfied. {project_name} will perform an _AND_ based on the outcome of each condition.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_policy_logic, Positive and negative logic>>
diff --git a/authorization_services/topics/policy-user-policy.adoc b/authorization_services/topics/policy-user-policy.adoc
deleted file mode 100644
index ec4e5cc18..000000000
--- a/authorization_services/topics/policy-user-policy.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-[[_policy_user]]
-= User-based policy
-
-You can use this type of policy to define conditions for your permissions where a set of one or more users is permitted to access an object.
-
-To create a new user-based policy, select *User* in the item list in the upper right corner of the policy listing.
-
-.Add a User Policy
-image:images/policy/create-user.png[alt="Add User Policy"]
-
-== Configuration
-
-* *Name*
-+
-A human-readable and unique string identifying the policy. A best practice is to use names that are closely related to your business and security requirements, so you
-can identify them more easily.
-+
-* *Description*
-+
-A string containing details about this policy.
-+
-* *Users*
-+
-Specifies which users are given access by this policy.
-+
-* *Logic*
-+
-The logic of this policy to apply after the other conditions have been evaluated.
-
-[role="_additional-resources"]
-.Additional resources
-* <<_policy_logic, Positive and negative logic>>
diff --git a/authorization_services/topics/resource-create.adoc b/authorization_services/topics/resource-create.adoc
deleted file mode 100644
index 3c1e34a1c..000000000
--- a/authorization_services/topics/resource-create.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-[[_resource_create]]
-= Creating resources
-
-Creating a resource is straightforward and generic. Your main concern is the granularity of the resources you create. In other words, resources can
-be created to represent a set of one or more resources and the way you define them is crucial to managing permissions.
-
-To create a new resource, click *Create resource*.
-
-.Add resource
-image:images/resource/create.png[alt="Add resource"]
-
-In {project_name}, a resource defines a small set of information that is common to different types of resources, such as:
-
-* *Name*
-+
-A human-readable and unique string describing this resource.
-
-[[_resource_create_type]]
-* *Type*
-+
-A string uniquely identifying the type of a set of one or more resources. The type is a _string_ used to group different resource instances.
-For example, the default type for the default resource that is automatically created is `urn:resource-server-name:resources:default`
-
-[[_resource_create_uri]]
-* *URIS*
-+
-URIS that provides the locations/addresses for the resource. For HTTP resources, the URIS
-are usually the relative paths used to serve these resources.
-+
-* *Scopes*
-+
-One or more scopes to associate with the resource.
-
-== Resource attributes
-
-Resources may have attributes associated with them. These attributes can be used to provide additional information about
-a resource and to provide additional information to policies when evaluating permissions associated with a resource.
-
-Each attribute is a key and value pair where the value can be a set of one or many strings. Multiple values can be defined for an attribute by separating each value with a comma.
-
-
-== Typed resources
-
-The type field of a resource can be used to group different resources together, so they can be protected using a common set of permissions.
-
-== Resource owners
-
-Resources also have an owner. By default, resources are owned by the resource server.
-
-However, resources can also be associated with users, so you can create permissions based on the resource owner. For example, only the resource owner is allowed to delete or update a given resource.
-
-== Managing resources remotely
-
-Resource management is also exposed through the <<_service_protection_api, Protection API>> to allow resource servers to remotely manage their resources.
-
-When using the Protection API, resource servers can be implemented to manage resources owned by their users. In this case, you can
-specify the user identifier to configure a resource as belonging to a specific user.
-
-[NOTE]
-{project_name} provides resource servers complete control over their resources. In the future, we should be able to
-allow users to control their own resources as well as approve authorization requests and manage permissions, especially when using the UMA protocol.
diff --git a/authorization_services/topics/resource-overview.adoc b/authorization_services/topics/resource-overview.adoc
deleted file mode 100644
index f52b1ddb6..000000000
--- a/authorization_services/topics/resource-overview.adoc
+++ /dev/null
@@ -1,5 +0,0 @@
-[[_resource_overview]]
-= Managing resources and scopes
-
-Resource management is straightforward and generic. After creating a resource server, you can start creating the resources and scopes that you want to protect.
-Resources and scopes can be managed by navigating to the *Resource* and *Authorization Scopes* tabs, respectively.
diff --git a/authorization_services/topics/resource-server-create-client.adoc b/authorization_services/topics/resource-server-create-client.adoc
deleted file mode 100644
index 6e296f4d8..000000000
--- a/authorization_services/topics/resource-server-create-client.adoc
+++ /dev/null
@@ -1,38 +0,0 @@
-[[_resource_server_create_client]]
-= Creating a client application
-
-The first step to enable {project_name} Authorization Services is to create the client application that you want to turn into a resource server.
-
-.Procedure
-
-. Click *Clients*.
-+
-.Clients
-image:images/resource-server/client-list.png[Clients]
-
-ifeval::[{project_community}==true]
-. On this page, click *Create client*.
-endif::[]
-ifeval::[{project_product}==true]
-. On this page, click *Create*.
-endif::[]
-+
-.Add Client
-image:images/resource-server/client-create.png[Add Client]
-
-. Type the `Client ID` of the client. For example, _my-resource-server_.
-ifeval::[{project_community}==true]
-. Click *Next*.
-. Toggle *Client authentication* to ON.
-. Click *Save*.
-endif::[]
-. Type the `Root URL` for your application. For example:
-+
-```
-http://${host}:${port}/my-resource-server
-```
-
-. Click *Save*. The client is created and the client Settings page opens. A page similar to the following is displayed:
-+
-.Client Settings
-image:images/resource-server/client-enable-authz.png[alt="Client Settings"]
diff --git a/authorization_services/topics/resource-server-default-config.adoc b/authorization_services/topics/resource-server-default-config.adoc
deleted file mode 100644
index 66fcebb5a..000000000
--- a/authorization_services/topics/resource-server-default-config.adoc
+++ /dev/null
@@ -1,52 +0,0 @@
-[[_resource_server_default_config]]
-= Default Configuration
-
-When you create a resource server, {project_name} creates a default configuration for your newly created resource server.
-
-The default configuration consists of:
-
-* A default protected resource representing all resources in your application.
-* A policy that always grants access to the resources protected by this policy.
-* A permission that governs access to all resources based on the default policy.
-
-The default protected resource is referred to as the *default resource* and you can view it if you navigate to the *Resources* tab.
-
-.Default resource
-image:images/resource-server/default-resource.png[alt="Default resource"]
-
-This resource defines a `Type`, namely `urn:my-resource-server:resources:default` and a `URI` `/*`. Here, the `URI` field defines a
-wildcard pattern that indicates to {project_name} that this resource represents all the paths in your application. In other words,
-when enabling <<_enforcer_overview, policy enforcement>> for your application, all the permissions associated with the resource
-will be examined before granting access.
-
-The `Type` mentioned previously defines a value that can be used to create <<_permission_typed_resource, typed resource permissions>> that must be applied
-to the default resource or any other resource you create using the same type.
-
-The default policy is referred to as the *only from realm policy* and you can view it if you navigate to the *Policies* tab.
-
-.Default policy
-image:images/resource-server/default-policy.png[alt="Default policy"]
-
-This policy is a <<_policy_js, JavaScript-based policy>> defining a condition that always grants access to the resources protected by this policy. If you click this policy you can see that it defines a rule as follows:
-
-```js
-// by default, grants any permission associated with this policy
-$evaluation.grant();
-```
-
-Lastly, the default permission is referred to as the *default permission* and you can view it if you navigate to the *Permissions* tab.
-
-.Default Permission
-image:images/resource-server/default-permission.png[alt="Default Permission"]
-
-This permission is a <<_permission_create_resource, resource-based permission>>, defining a set of one or more policies that are applied to all resources with a given type.
-
-== Changing the default configuration
-
-You can change the default configuration by removing the default resource, policy, or permission definitions and creating your own.
-
-The default resource is created with a **URI** that maps to any resource or path in your application using a **/*** pattern. Before creating your own resources, permissions and policies, make
-sure the default configuration doesn't conflict with your own settings.
-
-[NOTE]
-The default configuration defines a resource that maps to all paths in your application. If you are about to write permissions to your own resources, be sure to remove the *Default Resource* or change its ```URIS``` fields to a more specific paths in your application. Otherwise, the policy associated with the default resource (which by default always grants access) will allow {project_name} to grant access to any protected resource.
diff --git a/authorization_services/topics/resource-server-enable-authorization.adoc b/authorization_services/topics/resource-server-enable-authorization.adoc
deleted file mode 100644
index 3659e7bb2..000000000
--- a/authorization_services/topics/resource-server-enable-authorization.adoc
+++ /dev/null
@@ -1,75 +0,0 @@
-[[_resource_server_enable_authorization]]
-= Enabling authorization services
-
-You can turn your OIDC client into a resource server and enable fine-grained authorization.
-
-.Procedure
-. Toggle *Authorization Enabled* to *`On*.
-. Click *Save*.
-+
-.Enabling authorization services
-image:images/resource-server/client-enable-authz.png[Enabling authorization services]
-+
-A new Authorization tab is displayed for this client. Click the *Authorization* tab and a page similar to the following is displayed:
-+
-.Resource server settings
-image:images/resource-server/authz-settings.png[alt="Resource server settings"]
-
-The Authorization tab contains additional sub-tabs covering the different steps that you must follow to actually protect your application's resources. Each tab is covered separately by a specific topic in this documentation. But here is a quick description about each one:
-
-* *Settings*
-+
-General settings for your resource server. For more details about this page see the xref:resource_server_settings[Resource Server Settings] section.
-
-* *Resource*
-+
-From this page, you can manage your application's <<_resource_overview, resources>>.
-
-* *Authorization Scopes*
-+
-From this page, you can manage <<_resource_overview, scopes>>.
-
-* *Policies*
-+
-From this page, you can manage <<_policy_overview, authorization policies>> and define the conditions that must be met to grant a permission.
-
-* *Permissions*
-+
-From this page, you can manage the <<_permission_overview, permissions>> for your protected resources and scopes by linking them with the policies you created.
-
-* *Evaluate*
-+
-From this page, you can <<_policy_evaluation_overview, simulate authorization requests>> and view the result of the evaluation of the permissions and authorization policies you have defined.
-
-* *Export Settings*
-+
-From this page, you can <<_resource_server_import_config, export>> the authorization settings to a JSON file.
-
-[[resource_server_settings]]
-== Resource server settings
-
-On the Resource Server Settings page, you can configure the policy enforcement mode, allow remote resource management, and export the authorization configuration settings.
-
-* *Policy Enforcement Mode*
-+
-Specifies how policies are enforced when processing authorization requests sent to the server.
-+
-** *Enforcing*
-+
-(default mode) Requests are denied by default even when there is no policy associated with a given resource.
-+
-** *Permissive*
-+
-Requests are allowed even when there is no policy associated with a given resource.
-+
-** *Disabled*
-+
-Disables the evaluation of all policies and allows access to all resources.
-+
-* *Decision Strategy*
-+
-This configurations changes how the policy evaluation engine decides whether or not a resource or scope should be granted based on the outcome from all evaluated permissions. `Affirmative` means that at least one permission must evaluate to a positive decision in order grant access to a resource and its scopes. `Unanimous` means that all permissions must evaluate to a positive decision in order for the final decision to be also positive. As an example, if two permissions for a same resource or scope are in conflict (one of them is granting access and the other is denying access), the permission to the resource or scope will be granted if the chosen strategy is `Affirmative`. Otherwise, a single deny from any permission will also deny access to the resource or scope.
-+
-* *Remote Resource Management*
-+
-Specifies whether resources can be managed remotely by the resource server. If false, resources can be managed only from the administration console.
diff --git a/authorization_services/topics/resource-server-import-config.adoc b/authorization_services/topics/resource-server-import-config.adoc
deleted file mode 100644
index 085ab435d..000000000
--- a/authorization_services/topics/resource-server-import-config.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-[[_resource_server_import_config]]
-= Export and import authorization configuration
-
-The configuration settings for a resource server (or client) can be exported and downloaded. You can also import an existing configuration file for a resource server. Importing and exporting a configuration file is helpful when you want to create an initial configuration for a resource server or to update an existing configuration. The configuration file contains definitions for:
-
-* Protected resources and scopes
-* Policies
-* Permissions
-
-== Exporting a configuration file
-
-.Procedure
-
-. Click *Clients* in the menu.
-. Click the client you created as a resource server.
-. Click the *Export* tab.
-+
-.Export Settings
-image:images/resource-server/authz-export.png[Export Settings]
-
-The configuration file is exported in JSON format and displayed in a text area, from which you can copy and paste. You can also click *Download* to download the configuration file and save it.
-
-== Importing a configuration file
-
-You can import a configuration file for a resource server.
-
-.Procedure
-
-. Navigate to the *Resource Server Settings* page.
-+
-.Import Settings
-image:images/resource-server/authz-settings.png[Import Settings]
-
-. Click *Import* and choose a file containing the configuration that you want to import.
diff --git a/authorization_services/topics/resource-server-overview.adoc b/authorization_services/topics/resource-server-overview.adoc
deleted file mode 100644
index 52ef538b9..000000000
--- a/authorization_services/topics/resource-server-overview.adoc
+++ /dev/null
@@ -1,8 +0,0 @@
-[[_resource_server_overview]]
-= Managing resource servers
-
-According to the OAuth2 specification, a resource server is a server hosting the protected resources and capable of accepting and responding to protected resource requests.
-
-In {project_name}, resource servers are provided with a rich platform for enabling fine-grained authorization for their protected resources, where authorization decisions can be made based on different access control mechanisms.
-
-Any client application can be configured to support fine-grained permissions. In doing so, you are conceptually turning the client application into a resource server.
diff --git a/authorization_services/topics/resource-view.adoc b/authorization_services/topics/resource-view.adoc
deleted file mode 100644
index 3cf8433c8..000000000
--- a/authorization_services/topics/resource-view.adoc
+++ /dev/null
@@ -1,20 +0,0 @@
-[[_resource_view]]
-= Viewing resources
-
-On the *Resource* page, you see a list of the resources associated with a resource server.
-
-.Resources
-image:images/resource/view.png[alt="Resources"]
-
-The resource list provides information about the protected resources, such as:
-
-* Type
-* URIS
-* Owner
-* Associated scopes, if any
-* Associated permissions
-
-From this list, you can also directly create a permission by clicking *Create Permission* for the resource for which you want to create the permission.
-
-[NOTE]
-Before creating permissions for your resources, be sure you have already defined the policies that you want to associate with the permission.
diff --git a/authorization_services/topics/service-authorization-discovery-document.adoc b/authorization_services/topics/service-authorization-discovery-document.adoc
deleted file mode 100644
index ec96c73a9..000000000
--- a/authorization_services/topics/service-authorization-discovery-document.adoc
+++ /dev/null
@@ -1,55 +0,0 @@
-[[_service_authorization_api]]
-= Discovering authorization services endpoints and metadata
-
-{project_name} provides a discovery document from which clients can obtain all necessary information to interact with
-{project_name} Authorization Services, including endpoint locations and capabilities.
-
-The discovery document can be obtained from:
-
-[source,bash,subs="attributes+"]
-----
-curl -X GET \
- http://${host}:${port}{kc_realms_path}/${realm}/.well-known/uma2-configuration
-----
-
-Where `${host}:${port}` is the hostname (or IP address) and port where {project_name} is running and `${realm}` is the name of
-a realm in {project_name}.
-
-As a result, you should get a response as follows:
-
-[source,json,subs="attributes+"]
-----
-{
-
- // some claims are expected here
-
- // these are the main claims in the discovery document about Authorization Services endpoints location
- "token_endpoint": "http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token",
- "token_introspection_endpoint": "http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token/introspect",
- "resource_registration_endpoint": "http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/resource_set",
- "permission_endpoint": "http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/permission",
- "policy_endpoint": "http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy"
-}
-----
-
-Each of these endpoints expose a specific set of capabilities:
-
-* **token_endpoint**
-+
-A OAuth2-compliant Token Endpoint that supports the `urn:ietf:params:oauth:grant-type:uma-ticket` grant type. Through this
-endpoint clients can send authorization requests and obtain an RPT with all permissions granted by {project_name}.
-+
-* **token_introspection_endpoint**
-+
-A OAuth2-compliant Token Introspection Endpoint which clients can use to query the server to determine the active state of an RPT
-and to determine any other information associated with the token, such as the permissions granted by {project_name}.
-+
-* **resource_registration_endpoint**
-+
-A UMA-compliant Resource Registration Endpoint which resource servers can use to manage their protected resources and scopes. This endpoint provides
-operations create, read, update and delete resources and scopes in {project_name}.
-+
-* **permission_endpoint**
-+
-A UMA-compliant Permission Endpoint which resource servers can use to manage permission tickets. This endpoint provides
-operations create, read, update, and delete permission tickets in {project_name}.
diff --git a/authorization_services/topics/service-authorization-obtaining-permission-authentication.adoc b/authorization_services/topics/service-authorization-obtaining-permission-authentication.adoc
deleted file mode 100644
index cd3885644..000000000
--- a/authorization_services/topics/service-authorization-obtaining-permission-authentication.adoc
+++ /dev/null
@@ -1,37 +0,0 @@
-[[_authentication_methods]]
-= Client authentication methods
-
-Clients need to authenticate to the token endpoint in order to obtain an RPT. When using the `urn:ietf:params:oauth:grant-type:uma-ticket`
-grant type, clients can use any of these authentication methods:
-
-* *Bearer Token*
-+
-Clients should send an access token as a Bearer credential in an HTTP Authorization header to the token endpoint.
-+
-.Example: an authorization request using an access token to authenticate to the token endpoint
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \
- -H "Authorization: Bearer ${access_token}" \
- --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket"
-----
-+
-This method is especially useful when the client is acting on behalf of a user.
-In this case, the bearer token is an access token previously issued by {project_name} to some client acting on behalf
-of a user (or on behalf of itself). Permissions will be evaluated considering the access context represented by the access token.
-For instance, if the access token was issued to Client A acting on behalf of User A, permissions will be granted depending on
-the resources and scopes to which User A has access.
-
-* *Client Credentials*
-+
-Clients can use any of the client authentication methods supported by {project_name}. For instance, client_id/client_secret or JWT.
-+
-.Example: an authorization request using client id and client secret to authenticate to the token endpoint
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \
- -H "Authorization: Basic cGhvdGg6L7Jl13RmfWgtkk==pOnNlY3JldA==" \
- --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket"
-----
diff --git a/authorization_services/topics/service-authorization-obtaining-permission-uma.adoc b/authorization_services/topics/service-authorization-obtaining-permission-uma.adoc
deleted file mode 100644
index 334bcf125..000000000
--- a/authorization_services/topics/service-authorization-obtaining-permission-uma.adoc
+++ /dev/null
@@ -1,42 +0,0 @@
-[[_service_user_managed_access]]
-= User-managed access
-
-{project_name} Authorization Services is based on User-Managed Access or UMA for short. UMA is a specification that
-enhances OAuth2 capabilities in the following ways:
-
-* *Privacy*
-+
-Nowadays, user privacy is becoming a huge concern, as more and more data and devices are available and connected to the cloud. With
-UMA and {project_name}, resource servers can enhance their capabilities in order to improve how their resources are protected in respect
-to user privacy where permissions are granted based on policies defined by the user.
-+
-* *Party-to-Party Authorization*
-+
-Resource owners (e.g.: regular end-users) can manage access to their resources and authorize other parties (e.g: regular end-users)
-to access these resources. This is different than OAuth2 where consent is given to a client application acting on behalf of a user, with UMA
-resource owners are allowed to consent access to other users, in a completely asynchronous manner.
-+
-* *Resource Sharing*
-+
-Resource owners are allowed to manage permissions to their resources and decide who can access a particular resource and how.
-{project_name} can then act as a sharing management service from which resource owners can manage their resources.
-
-{project_name} is a UMA 2.0 compliant authorization server that provides most UMA capabilities.
-
-As an example, consider a user Alice (resource owner) using an Internet Banking Service (resource server) to manage her Bank Account (resource). One day, Alice decides
-to open her bank account to Bob (requesting party), an accounting professional. However, Bob should only have access to view (scope) Alice's account.
-
-As a resource server, the Internet Banking Service must be able to protect Alice's Bank Account. For that, it relies on {project_name}
-Resource Registration Endpoint to create a resource in the server representing Alice's Bank Account.
-
-At this moment, if Bob tries to access Alice's Bank Account, access will be denied. The Internet Banking Service defines a few default
-policies for banking accounts. One of them is that only the owner, in this case Alice, is allowed to access her bank account.
-
-However, Internet Banking Service in respect to Alice's privacy also allows her to change specific policies for the banking account. One of these
-policies that she can change is to define which people are allowed to view her bank account. For that, Internet Banking Service relies on {project_name}
-to provide to Alice a space where she can select individuals and the operations (or data) they are allowed to access. At any time, Alice
-can revoke access or grant additional permissions to Bob.
-
-
-
-
diff --git a/authorization_services/topics/service-authorization-obtaining-permission.adoc b/authorization_services/topics/service-authorization-obtaining-permission.adoc
deleted file mode 100644
index 6e98e8993..000000000
--- a/authorization_services/topics/service-authorization-obtaining-permission.adoc
+++ /dev/null
@@ -1,158 +0,0 @@
-[[_service_obtaining_permissions]]
-= Obtaining permissions
-
-To obtain permissions from {project_name} you send an authorization request to the token endpoint. As a result, {project_name} will
-evaluate all policies associated with the resource(s) and scope(s) being requested and issue an RPT with all permissions
-granted by the server.
-
-Clients are allowed to send authorization requests to the token endpoint using the following parameters:
-
-* *grant_type*
-+
-This parameter is *required*. Must be `urn:ietf:params:oauth:grant-type:uma-ticket`.
-+
-* **ticket**
-+
-This parameter is *optional*. The most recent permission ticket received by the client as part of the UMA authorization process.
-+
-* **claim_token**
-+
-This parameter is *optional*. A string representing additional claims that should be considered by the server when evaluating
-permissions for the resource(s) and scope(s) being requested. This parameter allows clients to push claims to {project_name}. For more details about all supported token formats see `claim_token_format` parameter.
-+
-* **claim_token_format**
-+
-This parameter is *optional*. A string indicating the format of the token specified in the `claim_token` parameter. {project_name} supports two token
-formats: `urn:ietf:params:oauth:token-type:jwt` and `https://openid.net/specs/openid-connect-core-1_0.html#IDToken`. The `urn:ietf:params:oauth:token-type:jwt` format
-indicates that the `claim_token` parameter references an access token. The `https://openid.net/specs/openid-connect-core-1_0.html#IDToken` indicates that the
-`claim_token` parameter references an OpenID Connect ID Token.
-+
-* **rpt**
-+
-This parameter is *optional*. A previously issued RPT which permissions should also be evaluated and added in a new one. This parameter
-allows clients in possession of an RPT to perform incremental authorization where permissions are added on demand.
-+
-* **permission**
-+
-This parameter is *optional*. A string representing a set of one or more resources and scopes the client is seeking access. This parameter can be defined multiple times
-in order to request permission for multiple resource and scopes. This parameter is an extension to `urn:ietf:params:oauth:grant-type:uma-ticket` grant type in order to allow clients to send authorization requests without a
-permission ticket. The format of the string must be: `RESOURCE_ID#SCOPE_ID`. For instance: `Resource A#Scope A`, `Resource A#Scope A, Scope B, Scope C`, `Resource A`, `#Scope A`.
-+
-* **audience**
-+
-This parameter is *optional*. The client identifier of the resource server to which the client is seeking access. This parameter is mandatory
-in case the `permission` parameter is defined. It serves as a hint to {project_name} to indicate the context in which permissions should be evaluated.
-+
-* **response_include_resource_name**
-+
-This parameter is *optional*. A boolean value indicating to the server whether resource names should be included in the RPT's permissions. If false, only the resource
-identifier is included.
-+
-* **response_permissions_limit**
-+
-This parameter is *optional*. An integer N that defines a limit for the amount of permissions an RPT can have. When used together with
-`rpt` parameter, only the last N requested permissions will be kept in the RPT.
-+
-* **submit_request**
-+
-This parameter is *optional*. A boolean value indicating whether the server should create permission requests to the resources and scopes referenced by a permission ticket.
-This parameter only has effect if used together with the `ticket` parameter as part of a UMA authorization process.
-+
-* **response_mode**
-+
-This parameter is *optional*. A string value indicating how the server should respond to authorization requests. This parameter is specially useful when
-you are mainly interested in either the overall decision or the permissions granted by the server, instead of a standard OAuth2 response. Possible values are:
-+
-*** `decision`
-+
-Indicates that responses from the server should only represent the overall decision by returning a JSON with the following format:
-+
-```json
-{
- 'result': true
-}
-```
-+
-If the authorization request does not map to any permission, a `403` HTTP status code is returned instead.
-+
-*** `permissions`
-+
-Indicates that responses from the server should contain any permission granted by the server by returning a JSON with the following format:
-+
-```json
-[
- {
- 'rsid': 'My Resource'
- 'scopes': ['view', 'update']
- },
-
- ...
-]
-```
-+
-If the authorization request does not map to any permission, a `403` HTTP status code is returned instead.
-
-Example of an authorization request when a client is seeking access to two resources protected by a resource server.
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \
- -H "Authorization: Bearer ${access_token}" \
- --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
- --data "audience={resource_server_client_id}" \
- --data "permission=Resource A#Scope A" \
- --data "permission=Resource B#Scope B"
-----
-
-Example of an authorization request when a client is seeking access to any resource and scope protected by a resource server.
-NOTE: This will not evaluate the permissions for all resources. Instead, the permissions for resources owned by the resource server, owned by the requesting user,
-and explicitly granted to the requesting user by other owners are evaluated.
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \
- -H "Authorization: Bearer ${access_token}" \
- --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
- --data "audience={resource_server_client_id}"
-----
-
-Example of an authorization request when a client is seeking access to a UMA protected resource after receiving a permission ticket from
-the resource server as part of the authorization process:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \
- -H "Authorization: Bearer ${access_token}" \
- --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
- --data "ticket=${permission_ticket}
-----
-
-If {project_name} assessment process results in issuance of permissions, it issues the RPT with which it has associated
-the permissions:
-
-.{project_name} responds to the client with the RPT
-```bash
-HTTP/1.1 200 OK
-Content-Type: application/json
-...
-{
- "access_token": "${rpt}",
-}
-```
-
-The response from the server is just like any other response from the token endpoint when using some other grant type. The RPT can be obtained from
-the `access_token` response parameter. If the client is not authorized, {project_name} responds with a `403` HTTP status code:
-
-.{project_name} denies the authorization request
-```bash
-HTTP/1.1 403 Forbidden
-Content-Type: application/json
-...
-{
- "error": "access_denied",
- "error_description": "request_denied"
-}
-```
diff --git a/authorization_services/topics/service-authorization-pushing-claims.adoc b/authorization_services/topics/service-authorization-pushing-claims.adoc
deleted file mode 100644
index a943f938a..000000000
--- a/authorization_services/topics/service-authorization-pushing-claims.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-[[_service_pushing_claims]]
-= Pushing claims
-
-When obtaining permissions from the server you can push arbitrary claims in order to have these
-claims available to your policies when evaluating permissions.
-
-If you are obtaining permissions from the server *without* using a permission ticket (UMA flow), you can send
-an authorization request to the token endpoint as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \
- --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
- --data "claim_token=ewogICAib3JnYW5pemF0aW9uIjogWyJhY21lIl0KfQ==" \
- --data "claim_token_format=urn:ietf:params:oauth:token-type:jwt" \
- --data "client_id={resource_server_client_id}" \
- --data "client_secret={resource_server_client_secret}" \
- --data "audience={resource_server_client_id}"
-----
-
-The `claim_token` parameter expects a BASE64 encoded JSON with a format similar to the example below:
-
-```json
-{
- "organization" : ["acme"]
-}
-```
-
-The format expects one or more claims where the value for each claim must be an array of strings.
-
-== Pushing claims Using UMA
-
-For more details about how to push claims when using UMA and permission tickets, please take a look at <<_service_protection_permission_api_papi, Permission API>>
diff --git a/authorization_services/topics/service-authorization-uma-account-my-resources.adoc b/authorization_services/topics/service-authorization-uma-account-my-resources.adoc
deleted file mode 100644
index 2f10032f4..000000000
--- a/authorization_services/topics/service-authorization-uma-account-my-resources.adoc
+++ /dev/null
@@ -1,42 +0,0 @@
-[[_service_authorization_my_resources]]
-= Managing access to users resources
-
-Users can manage access to their resources using the {project_name} Account Console. To enable
-this functionality, you must first enable User-Managed Access for your realm.
-
-.Procedure
-
-. Log into the Admin Console.
-
-. Click *Realm Settings* in the menu.
-
-. Toggle *User-Managed Access* to *ON*.
-
-. Click the user name at the top right of the Admin Console and select *Manage Account*.
-+
-image:images/service/account-my-resource.png[alt="My Resources"]
-
-. Click *My Resources* in the menu option. A page displays with the following options.
-* Manage *My resources*
-+
-This section contains a list of all resources owned by the user. Users can click on a resource for more details
-and share the resource with others.
-When there is a permission requests awaiting approval an icon is put next to the name of the resource.
-These requests are connected to the parties (users) requesting access to a particular resource.
-Users are allowed to approve or deny these requests. You can do so by clicking the icon
-+
-image:images/service/account-my-resource-detail.png[alt="Resource Detail"]
-+
-* Manage *Resources shared with me*
-+
-This section contains a list of all resources shared with the user.
-+
-
-* Manage *People with access to this resource*
-+
-This section contains a list of people with access to this resource. Users are allowed to revoke access by clicking
-on the `Revoke` button or by removing a specific `Permission`.
-+
-* Share the resource with others
-+
-By typing the username or e-mail of another user, the user is able to share the resource and select the permissions he wants to grant access.
diff --git a/authorization_services/topics/service-authorization-uma-authz-process.adoc b/authorization_services/topics/service-authorization-uma-authz-process.adoc
deleted file mode 100644
index 7991c0852..000000000
--- a/authorization_services/topics/service-authorization-uma-authz-process.adoc
+++ /dev/null
@@ -1,68 +0,0 @@
-[[_service_uma_authorization_process]]
-= Authorization process
-
-In UMA, the authorization process starts when a client tries to access a UMA protected resource server.
-
-A UMA protected resource server expects a bearer token in the request where the token is an RPT. When a client requests
-a resource at the resource server without an RPT:
-
-.Client requests a protected resource without sending an RPT
-```bash
-curl -X GET \
- http://${host}:${port}/my-resource-server/resource/1bfdfe78-a4e1-4c2d-b142-fc92b75b986f
-```
-
-The resource server sends a response back to the client with a permission `ticket` and a `as_uri` parameter with the location
-of a {project_name} server to where the ticket should be sent in order to obtain an RPT.
-
-.Resource server responds with a permission ticket
-[source,bash,subs="attributes+"]
-----
-HTTP/1.1 401 Unauthorized
-WWW-Authenticate: UMA realm="${realm}",
- as_uri="https://${host}:${port}{kc_realms_path}/${realm}",
- ticket="016f84e8-f9b9-11e0-bd6f-0021cc6004de"
-----
-
-The permission ticket is a special type of token issued by {project_name} Permission API. They represent the permissions being requested (e.g.: resources and scopes)
-as well any other information associated with the request. Only resource servers are allowed to create those tokens.
-
-Now that the client has a permission ticket and also the location of a {project_name} server, the client can use the discovery document
-to obtain the location of the token endpoint and send an authorization request.
-
-.Client sends an authorization request to the token endpoint to obtain an RPT
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \
- -H "Authorization: Bearer ${access_token}" \
- --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
- --data "ticket=${permission_ticket}
-----
-
-If {project_name} assessment process results in issuance of permissions, it issues the RPT with which it has associated
-the permissions:
-
-.{project_name} responds to the client with the RPT
-```bash
-HTTP/1.1 200 OK
-Content-Type: application/json
-...
-{
- "access_token": "${rpt}",
-}
-```
-
-The response from the server is just like any other response from the token endpoint when using some other grant type. The RPT can be obtained from
-the `access_token` response parameter. In case the client is not authorized to have permissions {project_name} responds with a `403` HTTP status code:
-
-.{project_name} denies the authorization request
-```bash
-HTTP/1.1 403 Forbidden
-Content-Type: application/json
-...
-{
- "error": "access_denied",
- "error_description": "request_denied"
-}
-```
diff --git a/authorization_services/topics/service-authorization-uma-submiting-permission-requests.adoc b/authorization_services/topics/service-authorization-uma-submiting-permission-requests.adoc
deleted file mode 100644
index ebc1e53a5..000000000
--- a/authorization_services/topics/service-authorization-uma-submiting-permission-requests.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-[[_service_authorization_aat]]
-= Submitting permission requests
-
-As part of the authorization process, clients need first to obtain a permission ticket from a UMA protected resource server in order
-to exchange it with an RPT at the {project_name} Token Endpoint.
-
-By default, {project_name} responds with a `403` HTTP status code and a `request_denied` error in case the client can not be issued with an RPT.
-
-.{project_name} denies the authorization request
-```bash
-HTTP/1.1 403 Forbidden
-Content-Type: application/json
-...
-{
- "error": "access_denied",
- "error_description": "request_denied"
-}
-```
-
-Such response implies that {project_name} could not issue an RPT with the permissions represented by a permission ticket.
-
-In some situations, client applications may want to start an asynchronous authorization flow and let the owner of the resources
-being requested decide whether or not access should be granted. For that, clients can use the `submit_request` request parameter along
-with an authorization request to the token endpoint:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm}/protocol/openid-connect/token \
- -H "Authorization: Bearer ${access_token}" \
- --data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
- --data "ticket=${permission_ticket} \
- --data "submit_request=true"
-----
-
-When using the `submit_request` parameter, {project_name} will persist a permission request for each resource to which access was denied.
-Once created, resource owners can check their account and manage their permissions requests.
-
-You can think about this functionality as a `Request Access` button in your application, where users can ask other users for access to their resources.
\ No newline at end of file
diff --git a/authorization_services/topics/service-client-api.adoc b/authorization_services/topics/service-client-api.adoc
deleted file mode 100644
index 7d3b1d81b..000000000
--- a/authorization_services/topics/service-client-api.adoc
+++ /dev/null
@@ -1,158 +0,0 @@
-[[_service_client_api]]
-= Authorization client java API
-
-Depending on your requirements, a resource server should be able to manage resources remotely or even check for permissions programmatically.
-If you are using Java, you can access the {project_name} Authorization Services using the Authorization Client API.
-
-It is targeted for resource servers that want to access the different endpoints provided by the server such as the Token Endpoint, Resource, and Permission management endpoints.
-
-== Maven dependency
-
-```xml
-
-
- org.keycloak
- keycloak-authz-client
- ${KEYCLOAK_VERSION}
-
-
-```
-
-== Configuration
-
-The client configuration is defined in a ``keycloak.json`` file as follows:
-
-[source,json,subs="attributes+"]
-----
-{
- "realm": "hello-world-authz",
- "auth-server-url" : "http://localhost:8080{kc_base_path}",
- "resource" : "hello-world-authz-service",
- "credentials": {
- "secret": "secret"
- }
-}
-----
-
-* *realm* (required)
-+
-The name of the realm.
-
-* *auth-server-url* (required)
-+
-The base URL of the {project_name} server. All other {project_name} pages and REST service endpoints are derived from this. It is usually in the form https://host:port{kc_base_path}.
-
-* *resource* (required)
-+
-The client-id of the application. Each application has a client-id that is used to identify the application.
-
-* *credentials* (required)
-+
-Specifies the credentials of the application. This is an object notation where the key is the credential type and the value is the value of the credential type.
-
-The configuration file is usually located in your application's classpath, the default location from where the client is going to try to find a ```keycloak.json``` file.
-
-== Creating the authorization client
-
-Considering you have a ```keycloak.json``` file in your classpath, you can create a new ```AuthzClient``` instance as follows:
-
-```java
- // create a new instance based on the configuration defined in a keycloak.json located in your classpath
- AuthzClient authzClient = AuthzClient.create();
-```
-
-== Obtaining user entitlements
-
-Here is an example illustrating how to obtain user entitlements:
-
-```java
-// create a new instance based on the configuration defined in keycloak.json
-AuthzClient authzClient = AuthzClient.create();
-
-// create an authorization request
-AuthorizationRequest request = new AuthorizationRequest();
-
-// send the entitlement request to the server in order to
-// obtain an RPT with all permissions granted to the user
-AuthorizationResponse response = authzClient.authorization("alice", "alice").authorize(request);
-String rpt = response.getToken();
-
-System.out.println("You got an RPT: " + rpt);
-
-// now you can use the RPT to access protected resources on the resource server
-```
-
-Here is an example illustrating how to obtain user entitlements for a set of one or more resources:
-
-```java
-// create a new instance based on the configuration defined in keycloak.json
-AuthzClient authzClient = AuthzClient.create();
-
-// create an authorization request
-AuthorizationRequest request = new AuthorizationRequest();
-
-// add permissions to the request based on the resources and scopes you want to check access
-request.addPermission("Default Resource");
-
-// send the entitlement request to the server in order to
-// obtain an RPT with permissions for a single resource
-AuthorizationResponse response = authzClient.authorization("alice", "alice").authorize(request);
-String rpt = response.getToken();
-
-System.out.println("You got an RPT: " + rpt);
-
-// now you can use the RPT to access protected resources on the resource server
-```
-
-== Creating a resource using the protection API
-
-```java
-// create a new instance based on the configuration defined in keycloak.json
-AuthzClient authzClient = AuthzClient.create();
-
-// create a new resource representation with the information we want
-ResourceRepresentation newResource = new ResourceRepresentation();
-
-newResource.setName("New Resource");
-newResource.setType("urn:hello-world-authz:resources:example");
-
-newResource.addScope(new ScopeRepresentation("urn:hello-world-authz:scopes:view"));
-
-ProtectedResource resourceClient = authzClient.protection().resource();
-ResourceRepresentation existingResource = resourceClient.findByName(newResource.getName());
-
-if (existingResource != null) {
- resourceClient.delete(existingResource.getId());
-}
-
-// create the resource on the server
-ResourceRepresentation response = resourceClient.create(newResource);
-String resourceId = response.getId();
-
-// query the resource using its newly generated id
-ResourceRepresentation resource = resourceClient.findById(resourceId);
-
-System.out.println(resource);
-```
-
-== Introspecting an RPT
-
-```java
-// create a new instance based on the configuration defined in keycloak.json
-AuthzClient authzClient = AuthzClient.create();
-
-// send the authorization request to the server in order to
-// obtain an RPT with all permissions granted to the user
-AuthorizationResponse response = authzClient.authorization("alice", "alice").authorize();
-String rpt = response.getToken();
-
-// introspect the token
-TokenIntrospectionResponse requestingPartyToken = authzClient.protection().introspectRequestingPartyToken(rpt);
-
-System.out.println("Token status is: " + requestingPartyToken.getActive());
-System.out.println("Permissions granted by the server: ");
-
-for (Permission granted : requestingPartyToken.getPermissions()) {
- System.out.println(granted);
-}
-```
diff --git a/authorization_services/topics/service-overview.adoc b/authorization_services/topics/service-overview.adoc
deleted file mode 100644
index 55dc27d78..000000000
--- a/authorization_services/topics/service-overview.adoc
+++ /dev/null
@@ -1,14 +0,0 @@
-[[_service_overview]]
-= Authorization services
-
-{project_name} Authorization Services are built on top of well-known standards such as the OAuth2 and User-Managed Access specifications.
-
-OAuth2 clients (such as front end applications) can obtain access tokens from the server using the token endpoint and use
-these same tokens to access resources protected by a resource server (such as back end services). In the same way,
-{project_name} Authorization Services provide extensions to OAuth2 to allow access tokens to be issued based on the processing
-of all policies associated with the resource(s) or scope(s) being requested. This means that resource servers can enforce access
-to their protected resources based on the permissions granted by the server and held by an access token. In {project_name} Authorization Services
-the access token with permissions is called a Requesting Party Token or RPT for short.
-
-In addition to the issuance of RPTs, {project_name} Authorization Services also provides a set of RESTful endpoints that allow resources servers to manage their protected
-resources, scopes, permissions and policies, helping developers to extend or integrate these capabilities into their applications in order to support fine-grained authorization.
\ No newline at end of file
diff --git a/authorization_services/topics/service-protection-permission-api-papi.adoc b/authorization_services/topics/service-protection-permission-api-papi.adoc
deleted file mode 100644
index 58155d19e..000000000
--- a/authorization_services/topics/service-protection-permission-api-papi.adoc
+++ /dev/null
@@ -1,140 +0,0 @@
-[[_service_protection_permission_api_papi]]
-= Managing permission requests
-
-Resource servers using the UMA protocol can use a specific endpoint to manage permission requests. This endpoint provides a UMA-compliant flow for registering permission requests and obtaining a permission ticket.
-
-[source,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission
-----
-
-A <<_overview_terminology_permission_ticket, permission ticket>> is a special security token type representing a permission request. Per the UMA specification, a permission ticket is:
-
-`A correlation handle that is conveyed from an authorization server to a resource server, from a resource server to a client, and ultimately from a client back to an authorization server, to enable the authorization server to assess the correct policies to apply to a request for authorization data.`
-
-In most cases, you won't need to deal with this endpoint directly. {project_name} provides a <<_enforcer_overview, policy enforcer>> that enables UMA for your
-resource server so it can obtain a permission ticket from the authorization server, return this ticket to client application, and enforce authorization decisions based on a final requesting party token (RPT).
-
-The process of obtaining permission tickets from {project_name} is performed by resource servers and not regular client applications,
-where permission tickets are obtained when a client tries to access a protected resource without the necessary grants to access the resource. The issuance of
-permission tickets is an important aspects when using UMA as it allows resource servers to:
-
-* Abstract from clients the data associated with the resources protected by the resource server
-* Register in the {project_name} authorization requests which in turn can be used later in workflows to grant access based on the resource's owner consent
-* Decouple resource servers from authorization servers and allow them to protect and manage their resources using different authorization servers
-
-Client wise, a permission ticket has also important aspects that its worthy to highlight:
-
-* Clients don't need to know about how authorization data is associated with protected resources. A permission ticket is completely opaque to clients.
-* Clients can have access to resources on different resource servers and protected by different authorization servers
-
-These are just some of the benefits brought by UMA where other aspects of UMA are strongly based on permission tickets, specially regarding
-privacy and user controlled access to their resources.
-
-== Creating permission ticket
-
-To create a permission ticket, send an HTTP POST request as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission \
- -H 'Authorization: Bearer '$pat \
- -H 'Content-Type: application/json' \
- -d '[
- {
- "resource_id": "{resource_id}",
- "resource_scopes": [
- "view"
- ]
- }
-]'
-----
-
-When creating tickets you can also push arbitrary claims and associate these claims with the ticket:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission \
- -H 'Authorization: Bearer '$pat \
- -H 'Content-Type: application/json' \
- -d '[
- {
- "resource_id": "{resource_id}",
- "resource_scopes": [
- "view"
- ],
- "claims": {
- "organization": ["acme"]
- }
- }
-]'
-----
-
-Where these claims will be available to your policies when evaluating permissions for the resource and scope(s) associated
-with the permission ticket.
-
-== Other non UMA-compliant endpoints
-
-=== Creating permission ticket
-
-To grant permissions for a specific resource with id {resource_id} to a user with id {user_id}, as an owner of the resource send an HTTP POST request as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission/ticket \
- -H 'Authorization: Bearer '$access_token \
- -H 'Content-Type: application/json' \
- -d '{
- "resource": "{resource_id}",
- "requester": "{user_id}",
- "granted": true,
- "scopeName": "view"
- }'
-----
-
-=== Getting permission tickets
-
-[source,bash,subs="attributes+"]
-----
-curl http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission/ticket \
- -H 'Authorization: Bearer '$access_token
-----
-
-You can use any of these query parameters:
-
-* `scopeId`
-* `resourceId`
-* `owner`
-* `requester`
-* `granted`
-* `returnNames`
-* `first`
-* `max`
-
-=== Updating permission ticket
-
-[source,bash,subs="attributes+"]
-----
-curl -X PUT \
- http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission/ticket \
- -H 'Authorization: Bearer '$access_token \
- -H 'Content-Type: application/json' \
- -d '{
- "id": "{ticket_id}"
- "resource": "{resource_id}",
- "requester": "{user_id}",
- "granted": false,
- "scopeName": "view"
- }'
-----
-
-=== Deleting permission ticket
-
-[source,bash,subs="attributes+"]
-----
-curl -X DELETE http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/permission/ticket/{ticket_id} \
- -H 'Authorization: Bearer '$access_token
-----
\ No newline at end of file
diff --git a/authorization_services/topics/service-protection-policy-api.adoc b/authorization_services/topics/service-protection-policy-api.adoc
deleted file mode 100644
index 91902a059..000000000
--- a/authorization_services/topics/service-protection-policy-api.adoc
+++ /dev/null
@@ -1,167 +0,0 @@
-[[_service_authorization_uma_policy_api]]
-= Managing resource permissions using the Policy API
-
-{project_name} leverages the UMA Protection API to allow resource servers to manage permissions for their users. In addition
-to the Resource and Permission APIs, {project_name} provides a Policy API from where permissions can be set to resources by resource
-servers on behalf of their users.
-
-The Policy API is available at:
-
-[source,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/uma-policy/{resource_id}
-----
-
-This API is protected by a bearer token that must represent a consent granted by the user to the resource server to manage permissions on his behalf. The bearer token can be a regular access token obtained from the
-token endpoint using:
-
-* Resource Owner Password Credentials Grant Type
-* Token Exchange, in order to exchange an access token granted to some client (public client) for a token
-where audience is the resource server
-
-== Associating a permission with a resource
-
-To associate a permission with a specific resource you must send a HTTP POST request as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{resource_id} \
- -H 'Authorization: Bearer '$access_token \
- -H 'Cache-Control: no-cache' \
- -H 'Content-Type: application/json' \
- -d '{
- "name": "Any people manager",
- "description": "Allow access to any people manager",
- "scopes": ["read"],
- "roles": ["people-manager"]
-}'
-----
-
-In the example above we are creating and associating a new permission to a resource represented by `resource_id` where
-any user with a role `people-manager` should be granted with the `read` scope.
-
-You can also create policies using other access control mechanisms, such as using groups:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{resource_id} \
- -H 'Authorization: Bearer '$access_token \
- -H 'Cache-Control: no-cache' \
- -H 'Content-Type: application/json' \
- -d '{
- "name": "Any people manager",
- "description": "Allow access to any people manager",
- "scopes": ["read"],
- "groups": ["/Managers/People Managers"]
-}'
-----
-
-Or a specific client:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{resource_id} \
- -H 'Authorization: Bearer '$access_token \
- -H 'Cache-Control: no-cache' \
- -H 'Content-Type: application/json' \
- -d '{
- "name": "Any people manager",
- "description": "Allow access to any people manager",
- "scopes": ["read"],
- "clients": ["my-client"]
-}'
-----
-
-Or even using a custom policy using JavaScript:
-
-:tech_feature_name: Upload Scripts
-:tech_feature_setting: -Dkeycloak.profile.feature.upload_scripts=enabled
-include::./templates/deprecated.adoc[]
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{resource_id} \
- -H 'Authorization: Bearer '$access_token \
- -H 'Cache-Control: no-cache' \
- -H 'Content-Type: application/json' \
- -d '{
- "name": "Any people manager",
- "description": "Allow access to any people manager",
- "scopes": ["read"],
- "condition": "my-deployed-script.js"
-}'
-----
-
-It is also possible to set any combination of these access control mechanisms.
-
-To update an existing permission, send an HTTP PUT request as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -X PUT \
- http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{permission_id} \
- -H 'Authorization: Bearer '$access_token \
- -H 'Content-Type: application/json' \
- -d '{
- "id": "21eb3fed-02d7-4b5a-9102-29f3f09b6de2",
- "name": "Any people manager",
- "description": "Allow access to any people manager",
- "type": "uma",
- "scopes": [
- "album:view"
- ],
- "logic": "POSITIVE",
- "decisionStrategy": "UNANIMOUS",
- "owner": "7e22131a-aa57-4f5f-b1db-6e82babcd322",
- "roles": [
- "user"
- ]
-}'
-----
-
-== Removing a permission
-
-To remove a permission associated with a resource, send an HTTP DELETE request as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -X DELETE \
- http://localhost:8180{kc_realms_path}/photoz/authz/protection/uma-policy/{permission_id} \
- -H 'Authorization: Bearer '$access_token
-----
-
-== Querying permission
-
-To query the permissions associated with a resource, send an HTTP GET request as follows:
-
-[source,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy?resource={resource_id}
-----
-
-To query the permissions given its name, send an HTTP GET request as follows:
-
-[source,bash,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy?name=Any people manager
-----
-
-To query the permissions associated with a specific scope, send an HTTP GET request as follows:
-
-[source,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy?scope=read
-----
-
-To query all permissions, send an HTTP GET request as follows:
-
-[source,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm}/authz/protection/uma-policy
-----
-
-When querying the server for permissions use parameters `first` and `max` results to limit the result.
diff --git a/authorization_services/topics/service-protection-protection-api.adoc b/authorization_services/topics/service-protection-protection-api.adoc
deleted file mode 100644
index e13540878..000000000
--- a/authorization_services/topics/service-protection-protection-api.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-[[_service_protection_api]]
-= Protection API
-
-The Protection API provides a UMA-compliant set of endpoints providing:
-
-* *Resource Management*
-+
-With this endpoint, resource servers can manage their resources remotely and enable <<_enforcer_overview, policy enforcers>> to query the server for the resources that need protection.
-
-* *Permission Management*
-+
-In the UMA protocol, resource servers access this endpoint to create permission tickets. {project_name} also provides
-endpoints to manage the state of permissions and query permissions.
-
-* *Policy API*
-+
-{project_name} leverages the UMA Protection API to allow resource servers to manage permissions for their users. In addition
-to the Resource and Permission APIs, {project_name} provides a Policy API from where permissions can be set to resources by resource
-servers on behalf of their users.
-
-An important requirement for this API is that _only_ resource servers are allowed to access its endpoints using a special OAuth2 access token called a protection API token (PAT).
-In UMA, a PAT is a token with the scope *uma_protection*.
diff --git a/authorization_services/topics/service-protection-resources-api-papi.adoc b/authorization_services/topics/service-protection-resources-api-papi.adoc
deleted file mode 100644
index cfcea104a..000000000
--- a/authorization_services/topics/service-protection-resources-api-papi.adoc
+++ /dev/null
@@ -1,161 +0,0 @@
-[[_service_protection_resources_api]]
-= Managing resources
-
-Resource servers can manage their resources remotely using a UMA-compliant endpoint.
-
-[source,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set
-----
-
-This endpoint provides operations outlined as follows (entire path omitted for clarity):
-
-* Create resource set description: POST /resource_set
-* Read resource set description: GET /resource_set/{_id}
-* Update resource set description: PUT /resource_set/{_id}
-* Delete resource set description: DELETE /resource_set/{_id}
-* List resource set descriptions: GET /resource_set
-
-For more information about the contract for each of these operations, see https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-09.html#reg-api[UMA Resource Registration API].
-
-== Creating a resource
-
-To create a resource you must send an HTTP POST request as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -v -X POST \
- http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set \
- -H 'Authorization: Bearer '$pat \
- -H 'Content-Type: application/json' \
- -d '{
- "name":"Tweedl Social Service",
- "type":"http://www.example.com/rsrcs/socialstream/140-compatible",
- "icon_uri":"http://www.example.com/icons/sharesocial.png",
- "resource_scopes":[
- "read-public",
- "post-updates",
- "read-private",
- "http://www.example.com/scopes/all"
- ]
- }'
-----
-
-By default, the owner of a resource is the resource server. If you want to define a different owner, such as a
-specific user, you can send a request as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -v -X POST \
- http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set \
- -H 'Authorization: Bearer '$pat \
- -H 'Content-Type: application/json' \
- -d '{
- "name":"Alice Resource",
- "owner": "alice"
- }'
-----
-
-Where the property `owner` can be set with the username or the identifier of the user.
-
-== Creating user-managed resources
-
-By default, resources created via Protection API can not be managed by resource owners through the <<_service_authorization_my_resources, Account Console>>.
-
-To create resources and allow resource owners to manage these resources, you must set `ownerManagedAccess` property as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -v -X POST \
- http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set \
- -H 'Authorization: Bearer '$pat \
- -H 'Content-Type: application/json' \
- -d '{
- "name":"Alice Resource",
- "owner": "alice",
- "ownerManagedAccess": true
- }'
-----
-
-== Updating resources
-
-To update an existing resource, send an HTTP PUT request as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -v -X PUT \
- http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set/{resource_id} \
- -H 'Authorization: Bearer '$pat \
- -H 'Content-Type: application/json' \
- -d '{
- "_id": "Alice Resource",
- "name":"Alice Resource",
- "resource_scopes": [
- "read"
- ]
- }'
-----
-
-== Deleting resources
-
-To delete an existing resource, send an HTTP DELETE request as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -v -X DELETE \
- http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set/{resource_id} \
- -H 'Authorization: Bearer '$pat
-----
-
-== Querying resources
-
-To query the resources by `id`, send an HTTP GET request as follows:
-
-[source,bash,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set/{resource_id}
-----
-
-To query resources given a `name`, send an HTTP GET request as follows:
-
-[source,bash,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?name=Alice Resource
-----
-
-By default, the `name` filter will match any resource with the given pattern. To restrict the query to only return resources with an exact match, use:
-
-[source,bash,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?name=Alice Resource&exactName=true
-----
-
-To query resources given an `uri`, send an HTTP GET request as follows:
-
-[source,bash,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?uri=/api/alice
-----
-
-To query resources given an `owner`, send an HTTP GET request as follows:
-
-[source,bash,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?owner=alice
-----
-
-To query resources given an `type`, send an HTTP GET request as follows:
-
-[source,bash,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?type=albums
-----
-
-To query resources given an `scope`, send an HTTP GET request as follows:
-
-[source,bash,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/authz/protection/resource_set?scope=read
-----
-
-When querying the server for permissions use parameters `first` and `max` results to limit the result.
\ No newline at end of file
diff --git a/authorization_services/topics/service-protection-whatis-obtain-pat.adoc b/authorization_services/topics/service-protection-whatis-obtain-pat.adoc
deleted file mode 100644
index aec60533c..000000000
--- a/authorization_services/topics/service-protection-whatis-obtain-pat.adoc
+++ /dev/null
@@ -1,37 +0,0 @@
-[[_service_protection_whatis_obtain_pat]]
-= What is a PAT and how to obtain it
-
-A *protection API token* (PAT) is a special OAuth2 access token with a scope defined as *uma_protection*. When you create a resource server, {project_name} automatically
-creates a role, _uma_protection_, for the corresponding client application and associates it with the client's service account.
-
-.Service Account granted with *uma_protection* role
-image:images/service/rs-uma-protection-role.png[alt="Service Account granted with uma_protection role"]
-
-Resource servers can obtain a PAT from {project_name} like any other OAuth2 access token. For example, using curl:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- -H "Content-Type: application/x-www-form-urlencoded" \
- -d 'grant_type=client_credentials&client_id=${client_id}&client_secret=${client_secret}' \
- "http://localhost:8080{kc_realms_path}/${realm_name}/protocol/openid-connect/token"
-----
-
-The example above is using the *client_credentials* grant type to obtain a PAT from the server. As a result, the server returns a response similar to the following:
-
-```json
-{
- "access_token": ${PAT},
- "expires_in": 300,
- "refresh_expires_in": 1800,
- "refresh_token": ${refresh_token},
- "token_type": "bearer",
- "id_token": ${id_token},
- "not-before-policy": 0,
- "session_state": "ccea4a55-9aec-4024-b11c-44f6f168439e"
-}
-```
-
-[NOTE]
-{project_name} can authenticate your client application in different ways. For simplicity, the *client_credentials* grant type is used here,
-which requires a _client_id_ and a _client_secret_. You can choose to use any supported authentication method.
diff --git a/authorization_services/topics/service-rpt-overview.adoc b/authorization_services/topics/service-rpt-overview.adoc
deleted file mode 100644
index 2c1ddc39c..000000000
--- a/authorization_services/topics/service-rpt-overview.adoc
+++ /dev/null
@@ -1,32 +0,0 @@
-[[_service_rpt_overview]]
-= Requesting party token
-
-A requesting party token (RPT) is a https://datatracker.ietf.org/doc/html/rfc7519[JSON web token (JWT)] digitally signed using https://datatracker.ietf.org/doc/html/rfc7515[JSON web signature (JWS)]. The token is built based on the OAuth2 access token previously issued by {project_name} to a specific client acting on behalf of a user
-or on its own behalf.
-
-When you decode an RPT, you see a payload similar to the following:
-
-```json
-{
- "authorization": {
- "permissions": [
- {
- "resource_set_id": "d2fe9843-6462-4bfc-baba-b5787bb6e0e7",
- "resource_set_name": "Hello World Resource"
- }
- ]
- },
- "jti": "d6109a09-78fd-4998-bf89-95730dfd0892-1464906679405",
- "exp": 1464906971,
- "nbf": 0,
- "iat": 1464906671,
- "sub": "f1888f4d-5172-4359-be0c-af338505d86c",
- "typ": "kc_ett",
- "azp": "hello-world-authz-service"
-}
-```
-
-From this token you can obtain all permissions granted by the server from the *permissions* claim.
-
-Also note that permissions are directly related with the resources/scopes you are protecting and completely decoupled from
-the access control methods that were used to actually grant and issue these same permissions.
diff --git a/authorization_services/topics/service-rpt-token-introspection.adoc b/authorization_services/topics/service-rpt-token-introspection.adoc
deleted file mode 100644
index 672cceabc..000000000
--- a/authorization_services/topics/service-rpt-token-introspection.adoc
+++ /dev/null
@@ -1,86 +0,0 @@
-[[_service_protection_token_introspection]]
-= Introspecting a requesting party token
-
-Sometimes you might want to introspect a requesting party token (RPT) to check its validity or obtain the permissions within the token to enforce authorization decisions on the resource server side.
-
-There are two main use cases where token introspection can help you:
-
-* When client applications need to query the token validity to obtain a new one with the same or additional permissions
-* When enforcing authorization decisions at the resource server side, especially when none of the built-in <<_enforcer_overview, policy enforcers>> fits your application
-
-= Obtaining Information about an RPT
-
-The token introspection is essentially a https://datatracker.ietf.org/doc/html/rfc7662[OAuth2 token introspection]-compliant endpoint from which you can obtain information about an RPT.
-
-[source,subs="attributes+"]
-----
-http://${host}:${port}{kc_realms_path}/${realm_name}/protocol/openid-connect/token/introspect
-----
-
-To introspect an RPT using this endpoint, you can send a request to the server as follows:
-
-[source,bash,subs="attributes+"]
-----
-curl -X POST \
- -H "Authorization: Basic aGVsbG8td29ybGQtYXV0aHotc2VydmljZTpzZWNyZXQ=" \
- -H "Content-Type: application/x-www-form-urlencoded" \
- -d 'token_type_hint=requesting_party_token&token=${RPT}' \
- "http://localhost:8080{kc_realms_path}/hello-world-authz/protocol/openid-connect/token/introspect"
-----
-
-[NOTE]
-The request above is using HTTP BASIC and passing the client's credentials (client ID and secret) to authenticate the client attempting to introspect the token, but you can use any other client authentication method supported by {project_name}.
-
-The introspection endpoint expects two parameters:
-
-* *token_type_hint*
-+
-Use *requesting_party_token* as the value for this parameter, which indicates that you want to introspect an RPT.
-+
-* *token*
-+
-Use the token string as it was returned by the server during the authorization process as the value for this parameter.
-
-As a result, the server response is:
-
-```json
-{
- "permissions": [
- {
- "resource_id": "90ccc6fc-b296-4cd1-881e-089e1ee15957",
- "resource_name": "Hello World Resource"
- }
- ],
- "exp": 1465314139,
- "nbf": 0,
- "iat": 1465313839,
- "aud": "hello-world-authz-service",
- "active": true
-}
-```
-
-If the RPT is not active, this response is returned instead:
-
-```json
-{
- "active": false
-}
-```
-
-= Do I need to invoke the server every time I want to introspect an RPT?
-
-No. Just like a regular access token issued by a {project_name} server, RPTs also use the
-JSON web token (JWT) specification as the default format.
-
-If you want to validate these tokens without a call to the remote introspection endpoint, you can decode the RPT and query for its validity locally. Once you decode the token,
-you can also use the permissions within the token to enforce authorization decisions.
-
-This is essentially what the policy enforcers do. Be sure to:
-
-* Validate the signature of the RPT (based on the realm's public key)
-* Query for token validity based on its _exp_, _iat_, and _aud_ claims
-
-[role="_additional-resources"]
-.Additional resources
-* https://datatracker.ietf.org/doc/html/rfc7519[JSON web token (JWT)]
-* <<_enforcer_overview, policy enforcers>>
diff --git a/authorization_services/topics/templates b/authorization_services/topics/templates
deleted file mode 120000
index d19126411..000000000
--- a/authorization_services/topics/templates
+++ /dev/null
@@ -1 +0,0 @@
-../../topics/templates
\ No newline at end of file
diff --git a/build-auto.sh b/build-auto.sh
deleted file mode 100755
index 35a1dd55a..000000000
--- a/build-auto.sh
+++ /dev/null
@@ -1,9 +0,0 @@
-#!/bin/bash
-
-OPTS=$1
-
-while true; do
- CHANGED=`inotifywait -r -e modify,move,create,delete authorization_services getting_started securing_apps server_admin server_development server_installation upgrading --format %w`
- GUIDE=`echo $CHANGED | cut -d '/' -f 1`
- mvn clean install -f $GUIDE $OPTS
-done
diff --git a/dist/assembly.xml b/dist/assembly.xml
deleted file mode 100644
index 9c27b6728..000000000
--- a/dist/assembly.xml
+++ /dev/null
@@ -1,19 +0,0 @@
-
-
- docs-dist
-
-
- zip
-
-
- true
-
-
-
- ../target
-
-
-
-
-
\ No newline at end of file
diff --git a/dist/pom.xml b/dist/pom.xml
deleted file mode 100644
index 915bb047c..000000000
--- a/dist/pom.xml
+++ /dev/null
@@ -1,38 +0,0 @@
-
-
- 4.0.0
-
-
- org.keycloak.documentation
- documentation-parent
- 999.0.0-SNAPSHOT
- ../
-
-
- Keycloak Documentation dist
- keycloak-documentation
- pom
-
-
-
-
- maven-assembly-plugin
-
-
- assemble
- package
-
- single
-
-
-
- assembly.xml
-
- false
-
-
-
-
-
-
-
diff --git a/get-version.sh b/get-version.sh
deleted file mode 100755
index 805d9269b..000000000
--- a/get-version.sh
+++ /dev/null
@@ -1,3 +0,0 @@
-#!/bin/bash -e
-
-awk '/:project_version:/ { print $2 }' topics/templates/document-attributes.adoc
diff --git a/header-maven-plugin/pom.xml b/header-maven-plugin/pom.xml
deleted file mode 100644
index 13fc1f635..000000000
--- a/header-maven-plugin/pom.xml
+++ /dev/null
@@ -1,73 +0,0 @@
-
-
- 4.0.0
-
- documentation-parent
- org.keycloak.documentation
- 999.0.0-SNAPSHOT
-
-
- org.keycloak.documentation
- header-maven-plugin
- 999.0.0-SNAPSHOT
- maven-plugin
-
- github-maven-plugin
-
-
- UTF-8
-
-
-
-
- org.apache.maven
- maven-project
- 2.2.1
-
-
- org.apache.maven
- maven-plugin-api
- 3.0
-
-
- org.apache.maven.plugin-tools
- maven-plugin-annotations
- 3.1
- provided
-
-
- org.codehaus.plexus
- plexus-utils
- 3.0.24
-
-
-
-
-
-
- org.apache.maven.plugins
- maven-plugin-plugin
- 3.4
-
- header
- true
-
-
-
- mojo-descriptor
-
- descriptor
-
-
-
- header-goal
-
- helpmojo
-
-
-
-
-
-
-
diff --git a/header-maven-plugin/src/main/java/sample/plugin/HeaderMojo.java b/header-maven-plugin/src/main/java/sample/plugin/HeaderMojo.java
deleted file mode 100644
index aa5dc0a1d..000000000
--- a/header-maven-plugin/src/main/java/sample/plugin/HeaderMojo.java
+++ /dev/null
@@ -1,133 +0,0 @@
-package sample.plugin;
-
-/*
- * Copyright 2001-2005 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-import org.apache.maven.plugin.AbstractMojo;
-import org.apache.maven.plugin.MojoExecutionException;
-import org.apache.maven.plugins.annotations.LifecyclePhase;
-import org.apache.maven.plugins.annotations.Mojo;
-import org.apache.maven.plugins.annotations.Parameter;
-import org.apache.maven.project.MavenProject;
-
-import java.io.BufferedReader;
-import java.io.File;
-import java.io.FileOutputStream;
-import java.io.FileReader;
-import java.io.IOException;
-import java.io.PrintStream;
-import java.nio.file.Files;
-import java.nio.file.StandardCopyOption;
-
-/**
- * Goal which touches a timestamp file.
- */
-@Mojo(name = "header", defaultPhase = LifecyclePhase.PROCESS_SOURCES)
-public class HeaderMojo extends AbstractMojo {
-
- @Parameter(defaultValue = "${project}", readonly = true)
- private MavenProject mavenProject;
-
- @Parameter(defaultValue = "index", property = "masterFile", required = true)
- private String masterFileName;
-
- @Parameter(defaultValue = "${project.build.directory}/sources", property = "outputDir", required = true)
- private File outputDir;
-
- private File baseDir;
-
- private File topicsDir;
-
- public void execute() throws MojoExecutionException {
- try {
- baseDir = mavenProject.getBasedir();
-
- copy(new File(baseDir, masterFileName + ".adoc"));
- copy(new File(baseDir, "topics.adoc"));
-
- File docInfo = new File(baseDir, "docinfo.html");
- if (docInfo.isFile()) {
- copy(docInfo);
- copy(new File(baseDir, "docinfo-footer.html"));
- }
-
- topicsDir = new File(baseDir, "topics");
-
- processTopics(topicsDir);
- } catch (IOException e) {
- e.printStackTrace();
- throw new MojoExecutionException(e.getMessage(), e);
- }
- }
-
- private void copy(File file) throws IOException {
- File out = new File(outputDir, file.getName());
- out.mkdirs();
- Files.copy(file.toPath(), out.toPath(), StandardCopyOption.REPLACE_EXISTING);
- }
-
- private void processTopics(File f) throws IOException {
- String topicsAbsolutePath = f.getAbsolutePath();
- String topicsParentDirPath = topicsDir.getParentFile().getAbsolutePath();
- if (isWindows()) {
- topicsAbsolutePath = topicsAbsolutePath.replace("\\", "/");
- topicsParentDirPath = topicsParentDirPath.replace("\\", "/");
- }
- File out = new File(outputDir, topicsAbsolutePath.replaceFirst(topicsParentDirPath, ""));
-
- if (f.isFile() && topicsAbsolutePath.contains("/templates/")) {
- out.getParentFile().mkdirs();
- Files.copy(f.toPath(), out.toPath(), StandardCopyOption.REPLACE_EXISTING);
- } else if (f.isDirectory()) {
- File[] files = f.listFiles();
- if(files != null){
- for (File c : files) {
- processTopics(c);
- }
- }
- } else if (f.getName().endsWith(".adoc")) {
- out.getParentFile().mkdirs();
-
- String filePath = f.getAbsolutePath().replace(baseDir.getParent(), "").substring(1);
- if (isWindows()) {
- filePath = filePath.replace("\\", "/");
- }
- String includeHeaderPath = filePath.substring(baseDir.getName().length() + 7);
- includeHeaderPath = includeHeaderPath.substring(0, includeHeaderPath.lastIndexOf('/'));
- includeHeaderPath = includeHeaderPath.replaceAll("/[^/]+", "../");
- includeHeaderPath = includeHeaderPath + "templates/header.adoc";
-
- String header = "\n\n:include_filename: " + filePath + "\ninclude::" + includeHeaderPath + "[]\n\n";
- try(PrintStream ps = new PrintStream(new FileOutputStream(out));BufferedReader br = new BufferedReader(new FileReader(f));){
- for (String l = br.readLine(); l != null; l = br.readLine()) {
- ps.println(l);
- if (l.startsWith("=")) {
- break;
- }
- }
- ps.print(header);
-
- for (String l = br.readLine(); l != null; l = br.readLine()) {
- ps.println(l);
- }
- }
- }
- }
- private boolean isWindows(){
- String osName = System.getProperty("os.name");
- return osName != null && osName.toLowerCase().startsWith("windows");
- }
-}
diff --git a/internal_resources/README.md b/internal_resources/README.md
deleted file mode 100644
index efc41c8c0..000000000
--- a/internal_resources/README.md
+++ /dev/null
@@ -1,26 +0,0 @@
-Keycloak Documentation Guidelines
-======================
-
-This folder contains guidelines for writers.
-
-Contributor's Guide
--------------------
-
-See our [Contributor's Guide](contributing.adoc) to learn the procedure for making contributions to documentation.
-
-Templates
----------
-
-We have templates that we ask you to please use for your new content. When:
-
-* I want to do X
- * Use the [brief task template](template_task_brief.adoc). The [detailed task template](template_task.adoc) has a wealth of resources and tips that you may find useful.
-* I want to understand X
- * Use the [Concept Template](template_concept.adoc)
-* I want to know X
- * Use the [Reference Template](template_reference.adoc)
-
-Styles
-------
-
-When writing content we use the IBM Style Guide.
\ No newline at end of file
diff --git a/internal_resources/contributing.adoc b/internal_resources/contributing.adoc
deleted file mode 100644
index 0d247eb9d..000000000
--- a/internal_resources/contributing.adoc
+++ /dev/null
@@ -1,84 +0,0 @@
-[[contributing]]
-= Contributor's Guide
-
-This guide will help new contributors use `git` and GitHub for Keycloak documentation submissions and suggestions.
-
-Before you start, please take a look at our writing templates contained in the link:https://github.com/keycloak/keycloak-documentation/tree/main/internal_resources[internal resources directory], which also describes each template file with information about when to use which. We are working to update our documentation to put procedural content, conceptual content, and reference content into separate .adoc files, and we kindly request that new contributions please use these templates.
-
-There are two ways to start. The first is the easiest, but it is less flexible. The second is more powerful, but requires setting up. For either method, you must already have a GitHub account, as described in link:https://github.com/join[Join GitHub].
-
-[[simple]]
-== Simple and Infrequent Contributions (Method One)
-
-This method is useful for quick fixes or simple additions.
-
-. Find the file you want to edit in the GitHub web interface.
-. Click the file name to open it in GitHub.
-. Click the edit icon near the top right of the page contents. The icon looks like a pencil.
-. Make your edits.
-. Enter a title and description of your changes in the *Commit Changes* section at the bottom of the page. Enter enough detail for reviewers to know what you have changed and why.
-. Select *Create a new branch for this commit and start a pull request*.
-. Click *Commit changes*.
-
-[[sustained]]
-== Larger and Sustained Contributions (Method Two)
-
-This method is useful for any type of contribution, but necessary for larger and more complex ones. If you expect to participate often, this is the recommended method.
-
-[[initialsetup]]
-=== Initial Setup
-
-You only need to perform these tasks once, when preparing to contribute.
-
-. Fork the link:https://github.com/keycloak/keycloak-documentation[Keycloak documentation repository]. This will create your own version of the repository which you can find at `https://github.com/{yourusername}/keycloak-documentation` where `{yourusername}` is the username you created in GitHub.
-. Install `git` on your local machine. The procedure differs by operating system as described in link:https://git-scm.com/book/en/v2/Getting-Started-Installing-Git[Installing Git]. Follow up with initial Git setup tasks, as described in link:https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup[First Time Git Setup].
-. Clone from your fork to create a copy on your local machine and then navigate to the new directory by entering the following from the command line on your local machine:
-+
-[source,bash]
-----
-$ git clone https://github.com/{yourusername}/keycloak-documentation
-$ cd keycloak-documentation
-----
-+
-. Add a git remote to your local repository to link to the upstream version of the documentation. This makes it easier to update your fork and local version of the documentation.
-+
-[source,bash]
-----
-$ git remote add upstream https://github.com/keycloak/keycloak-documentation
-----
-+
-. Check your settings.
-+
-[source,bash]
-----
-$ git remote -v
-origin https://github.com/{yourusername}/keycloak-documentation.git (fetch)
-origin https://github.com/{yourusername}/keycloak-documentation.git (push)
-upstream https://github.com/keycloak/keycloak-documentation (fetch)
-upstream https://github.com/keycloak/keycloak-documentation (push)
-----
-+
-
-NOTE: It is possible to clone using SSH so you don't have to enter a username/password every time you push. Find instructions at link:https://help.github.com/articles/connecting-to-github-with-ssh/[Connecting to GitHub with SSH] and link:https://help.github.com/articles/which-remote-url-should-i-use/[Which Remote URL Should I Use]. When using SSH, the origin lines will appear like this:
-`git@github.com:{yourusername}/keycloak-documentation.git`
-
-[[workflow]]
-=== Typical Workflow for Keycloak Documentation Contributions
-
-When contributing, follow this procedure. Enter commands from the command line on your local machine in the `keycloak-documentation` directory created earlier when cloning the repository.
-
-. Enter `git checkout main` to checkout the main branch locally.
-. Enter `git fetch upstream` to download the current files from the upstream repository.
-. Enter `git rebase upstream/main` to update your cloned branch on your local machine with the most current content from the upstream repository.
-. Enter `git push origin main` to update your fork in GitHub with the most current content from the upstream repository.
-. Enter `git checkout -b {branchname}` where you create a `{branchname}` that describes the work you are about to do.
-. Make your changes
-. (Optional) Enter `git status` now or at any time to see what branch you are on, what files you have changed, and whether those files are staged to be committed.
-. Enter `git add -A` to stage your changes to the commit you are about to make.
-. Enter `git commit -m 'KEYCLOAK-XXXX include meaningful information about changes'` where `KEYCLOAK-XXXX` refers to the link:https://issues.redhat.com/projects/KEYCLOAK/issues[Jira issue] being fixed in this commit (if any) and where you add a short sentence that clearly describes what the commit contains.
-. Follow the steps in the link:https://github.com/keycloak/keycloak-documentation/blob/main/README.md[README] to create a test build locally and confirm that your changes look correct. Make more changes and repeat steps to here, as needed.
-. Enter `git push origin {branchname}` to push your changes to your fork in GitHub.
-. Use the GitHub web interface to create a pull request. First, navigate to your branch in the web UI and click *Compare*. This will show you a diff of the changes. Examine them one more time. If necessary, make more changes locally and repeat the steps to here. When you are ready, click *Create a pull request*. Enter a title and a description with enough detail for reviewers to know what you have changed and why. Click *Submit*.
-. Wait. The documentation team will usually review pull requests within a few days. Often suggestions and changes are requested of you to help the contribution better fit within the style guidelines for the project or to fill in information that may have been missed. If this happens, repeat the steps from making your changes to `git push origin {branchname}`. No need to create another PR as the existing one will be updated automatically.
-
-Once the PR has been merged or rejected, you can remove your feature branch `{newbranchname}` from both the remote fork and your local machine. GitHub provides a button for removing from the fork in the UI of the PR once it is merged. Remove from your local machine with `git branch -d {branchname}`.
diff --git a/internal_resources/screenshots.adoc b/internal_resources/screenshots.adoc
deleted file mode 100644
index fd379bc67..000000000
--- a/internal_resources/screenshots.adoc
+++ /dev/null
@@ -1,140 +0,0 @@
-[[screenshot_guidelines]]
-= Documentation Screenshots Guidelines
-
-[[summary]]
-== Summary
-* Images should be saved as *PNG* or *JPG*, with a width of at least *660 px*, at *110 dpi*. Try to keep file size less than *300 KB*.
-* Screenshots supplement the text, not replace it. *Do not rely on images to provide information or context*.
-* *Do not include any testing/pre-release labels*.
-* *Do not include any personally identifying information*.
-* Capture just the part of the screen or window that users must focus on; *do not include window headers in the final screenshots unless completely necessary*.
-* Manipulate your screenshots to *condense important information* in them and limit empty GUI space and other inconsequential parts.
-
-[[general]]
-== General Guidelines
-* Screen captures can be useful and successful when they achieve one or more of these objectives:
-** Illustrate a user interface that is fairly complex or difficult to explain in text
-** Help the user find a small element in a complex user interface
-** Show the results of a series of steps or user actions
-** Orient readers who are reading the publication without the user interface in front of them
-* Use the smallest number of screenshots possible.
-* Use screenshots to provide verification for the reader, rather than instruction. In other words, screenshots supplement the text, not replace it. *Do not rely on images to provide information or context*. Instead, use them only to provide the reader with orientation.
-
-[NOTE]
-=====================================================================
-Example 1: Do not tell the reader to fill out a form according to the image; instead list the values needed for the form in text.
-=====================================================================
-
-[NOTE]
-=====================================================================
-Example 2: Do not include an image of the directory tree; instead tell the user exactly where to find the file in running text (…/standalone/configuration/standalone.xml).
-=====================================================================
-* Bearing in mind the impact on localization and accessibility, you should aim to write your document so that, were you to remove all screenshots from the book, the text would still make sense.
-
-[NOTE]
-=====================================================================
-For example: Do not write "see image below" or "as is shown in the image"
-=====================================================================
-* When you are snapping a GUI form, fill it with relevant input first.
-* Make sure the screenshots *do not include any testing/pre-release labels*.
-* Make sure the screenshots *do not include any personally identifying information*.
-
-[NOTE]
-=====================================================================
-For example: Always use 'test' as the username or fake contact information. If including the browser title bar hide your bookmarks and use a default browser theme.
-=====================================================================
-
-[TIP]
-=====================================================================
-Use Chrome Dev Tools to select elements on the page and rewrite their contents.
-=====================================================================
-* Include the cursor, mouse pointer, or menus only when their presence is significant.
-* Increase font size in the browser if it is hard to read before snapping the image.
-* Capture just the part of the screen or window that users must focus on.
-
-[NOTE]
-=====================================================================
-For example: Unless necessary, *do not include window headers in the final screenshots* to indicate your currently used window manager or desktop environment.
-=====================================================================
-* If possible, try not to cut any elements on the screen.
-* Show the user interface elements exactly as they are displayed for most users for quick recognition.
-
-[NOTE]
-=====================================================================
-For example: If you have a custom theme on your system, disable it and take the screenshot using the default theme.
-=====================================================================
-* Do not add borders around or drop shadows to your screenshots.
-* Do not use rounded corners. If the screenshot contains rounded corners, then that's ok, of course. But, the screenshot itself should remain squared.
-
-[[specs]]
-== Tech Specs
-* Image width should be at least *660 px* (internal tools will automatically resize the image to a max width of 660 px).
-* The preferred format is *PNG* or *JPG* .
-* The output resolution of images should be *110 dpi* to ensure good quality in the generated PDF.
-
-[TIP]
-=====================================================================
-In GIMP, select Image/Scale Image... to set resolution
-=====================================================================
-* If possible, try to keep screenshot size less than *300 KB*.
-* If possible, avoid snapping images in various terminals with 8-bit color scale or less.
-* Manipulate your screenshots to condense important information in them and limit empty GUI space and other inconsequential parts.
-
-[NOTE]
-=====================================================================
-For example: You can do this by setting a low screen resolution or resizing your browser window to a smaller size. Keep in mind that you should only do this if it does not adversely affect the readability of the image.
-=====================================================================
-
-[NOTE]
-=====================================================================
-If you need to take a screenshot of the entire window, use a tool such as the https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh?hl=en[_Window Resizer_] Google Chrome extension to ensure the browser window is a set size before taking the screenshot. This helps ensure that all full window screenshots are of standard dimensions.
-=====================================================================
-* If necessary, call attention to hard to find parts of the screenshot with red outlines (border: #C00, width:1px) or with a transparent gray (#ECECEC) layer over unimportant parts of the picture.
-
-[[accessibility]]
-== Accessibility
-* Section 508 compliance requires that all of the information is available in a text format for accessibility reasons (for instance, screen readers can not extract information from images).
-* Also, a large number of screenshots can possibly slow download of docs for those on very slow connections (rarer for most enterprises these days).
-
-[[asciidoc]]
-== AsciiDoc Syntax
-* Insert a block-level image, which uses a double colon (::). Good for screenshots, diagrams, etc.
-
-** Example 1: Include an image title in title case (which automatically appends a Figure #).
-+
-----
-.Image Title
-image::icon.png[Alt text, 50, 50]
-----
-
-** Example 2: Insert an inline image. Note, there is only one colon (:) used here.
-+
-----
-This is an inline image. image:icon.png[Alt text] Cool!
-----
-
-[[questions]]
-== Additional Questions
-* When should I add a screenshot to my book?
-** When introducing a new part of the UI.
-** When the UI is suboptimal and some elements are difficult to find, located in unusual places, hidden, or somehow less visible.
-* When, in the development cycle, should I add my screenshots?
-** Add them as late in the cycle as possible, preferably during the review process. At this late stage, hopefully there will be fewer UI changes to the product.
-
-[TIP]
-=====================================================================
-Add a placeholder for the screenshot early on in the development cycle. This way it will not be forgotten.
-=====================================================================
-* What image editor should I use?
-** The recommended graphical editor is GIMP.
-
-[[extensions]]
-== Browser Extensions
-
-[[resizing]]
-=== Resizing
-There are a couple simple browser extensions that can assist in resizing your browser to the appropriate dimensions.
-
-* Google Chrome extension: https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh?hl=en[_Window Resizer_]
-* Firefox add-on: https://addons.mozilla.org/en-US/firefox/addon/firesizer/[_Firesizer_]
-** You will also need to install the Addon Bar: https://addons.mozilla.org/en-US/firefox/addon/the-addon-bar/[_The Addon Bar (Restored)_]
diff --git a/internal_resources/styleguide.adoc b/internal_resources/styleguide.adoc
deleted file mode 100644
index bbca32ef7..000000000
--- a/internal_resources/styleguide.adoc
+++ /dev/null
@@ -1,52 +0,0 @@
-= Documentation Style Guide
-
-== Style Guides to Follow
-
-. IBM Style Guide (printed)
-. This document
-
-Writers will also refer to these:
-. link:https://www.ibm.com/developerworks/library/styleguidelines/[IBM DeveloperWorks Editorial Style Guide]
-. link:http://brand.redhat.com/elements/[RH Corporate]
-
-
-== Style Guidelines
-
-* Use title case for headings.
-** Unsure of the proper capitalization? See link:http://titlecase.com/[http://titlecase.com/]
-* Write clear, short sentences.
-* Use definite and indefinite articles like _an_ and _the_.
-+
-*Incorrect:* Create project. Delete object from editor. +
-*Correct:* Create a project. Delete an object from the editor.
-+
-* Start steps with an active verb, such as *Enter*, *Edit*, and *Click*.
-* Start headings with gerunds (verbs that end in -ing), such as *Configuring*, *Creating*, and *Installing*.
-* Use *bold* for GUI items. Match the capitalization you see in the GUI.
-* End entries in bulleted and numbered lists with periods when the entries are complete sentences.
-* Use `$ sudo`, not `#` for superuser terminal commands.
-* Don't use contractions.
-+
-*Incorrect:* Don't use contractions. +
-*Correct:* Do not use contractions.
-+
-* Use `++_italics_++` for emphasis, not `++*bold*++`.
-* Spell out integers that are less than 10, such as "four", not "4".
-** Always use numerals in ranges, even when either or both of the numbers are less than 10.
-* 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".
-** Instead of i.e. use "that is".
-** Instead of e.g. use "for example" or "such as".
-* Do not use "&" in place of "and".
-* Do not use "and/or". Pick one.
-
-
-== See Also
-
-* link:http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/[AsciiDoc Syntax Quick Reference]
-* link:screenshots.adoc[Screenshot Guide]
-* link:terms_conventions.adoc[RH-SSO Terms and Conventions]
-* link:http://ccs-jenkins.gsslab.brq.redhat.com:8080/job/glossary-of-terms-and-conventions-for-product-documentation-branch-master/lastSuccessfulBuild/artifact/index.html[Red Hat Glossary of Terms and Conventions]
-* link:https://mojo.redhat.com/docs/DOC-1136272[Red Hat Style Guide and Writers Checklist]
\ No newline at end of file
diff --git a/internal_resources/template_concept.adoc b/internal_resources/template_concept.adoc
deleted file mode 100644
index bc1c1a295..000000000
--- a/internal_resources/template_concept.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-[[concept_module]]
-
-= Concept Template and Guidelines
-
-_In the title, include nouns that are used in the body text -- this helps readers and search engines find information quickly._
-
-A concept module describes and explains things such as a product, subsystem, or feature -- what a customer needs to understand to do a task. A concept module may also explain how things relate and interact with other things. The use of graphics and diagrams can speed up understanding of a concept.
-
-* Look at nouns and noun phrases in related task modules and user story assemblies to find the concepts to explain to users.
-
-* A concept module in product documentation should explain only things that are visible to users.
-
-* If a product concept is interesting, but not visible to users, the concept probably does not require explanation in a concept module.
-
-* A concept module should NOT include numbered steps or other wording that instructs a user to execute a command or perform an action. Instead, put that information in a separate task module or user story assembly.
-
-
diff --git a/internal_resources/template_reference.adoc b/internal_resources/template_reference.adoc
deleted file mode 100644
index b137278dc..000000000
--- a/internal_resources/template_reference.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-[[reference_module]]
-
-= Reference Template and Guidelines
-
-_In the title, include nouns that are used in the body text — this helps readers and search engines find information quickly._
-
-A reference module lists things (such as a list of commands) or has a very regimented structure (such as the consistent structure of man pages). A reference module explains the details that a customer needs to know to do a task. A reference module is well-organized if users can scan it to quickly find the details they want.
-
-* A reference module that is a list of things may be made easier to scan if its content is organized alphabetically or formatted as a table. Think of an alphabetical list of commands that can be used with an application, or of an alphabetical list of system components with brief definitions formatted as a 2-column table.
-
-* If you have a large volume of the same type of information to document, figure out a consistent structure that the information details can fit into and then document each logical unit of information as 1 reference module. Think of man pages, which document very different information details, but that use consistent titles and formats to present those details in a consistent information structure.
-
-
diff --git a/internal_resources/template_task.adoc b/internal_resources/template_task.adoc
deleted file mode 100644
index 5ecbfbc4c..000000000
--- a/internal_resources/template_task.adoc
+++ /dev/null
@@ -1,59 +0,0 @@
-[[task_module]]
-
-= Do One Task
-
-_Start title with verb form such as Creating. Use the gerund form (noun form of verb) for titles, not the imperative form._
-
-_Avoid using the word 'Configuring' over and over. Other words might include:_
-
-* _Specifying_
-* _Adding_
-* _Constructing_
-* _Arranging_
-* _Building_
-* _Setting_
-* _Managing_
-* _Defining_
-* _Customizing_
-* _Or instead of using synonyms (which becomes obvious) 'verb-alize' a word and refactor the heading - limiting (instead of 'setting resource limits')_
-
-_The standard for all Red Hat documentation is title case for all headings and titles._
-
-_A task module is a procedure written with numbered steps -- what a customer needs to do to accomplish a goal successfully._
-
-This paragraph explains why the user performs the task, sets the context of the task, and may explain or list special considerations specific to this task. Keep the information brief and focused on what is needed for this specific task. Suggested length is 1 to 3 sentences, can be longer if needed.
-
-
-.Prerequisites _(if needed)_
-
-* Sentence or a bulleted list of prerequisites that must be in place or done before the user starts this task.
-
-* Delete section title and bullets if the task has no required prerequisites.
-
-* Text can be a link to a prerequisite task that the user must do before starting this task.
-
-
-.Procedure
-
-_Start title with verb form such as Creating. Use the gerund form (noun form of verb) for titles, not the imperative form._
-
-_Put steps in a numbered list. The step sequence is important to a repeatable successful outcome._
-
-. Start each step with an active verb, because each step corresponds to one user action.
-
-. Include one command or action per step.
-
-. Format the step line as an unnumbered bullet if the procedure includes only 1 step (exception to numbering the steps).
-
-. Include one command or action per step.
-
-. Include one command or action per step.
-
-
-.Related Information _(if needed)_
-
-* Bulleted list of links to concepts, reference, or other tasks closely related to this task.
-
-* Include only the most relevant items as links, not every possible related item.
-
-* Delete section title and bullets if no related information is needed.
diff --git a/internal_resources/template_task_brief.adoc b/internal_resources/template_task_brief.adoc
deleted file mode 100644
index 2e41865a2..000000000
--- a/internal_resources/template_task_brief.adoc
+++ /dev/null
@@ -1,20 +0,0 @@
-[[task_module]]
-
-= Do One Task
-
-This paragraph explains why the user performs the task, sets the context of the task, and may explain or list special considerations specific to this task. Keep the information brief and focused on what is needed for this specific task. Suggested length is 1 to 3 sentences, can be longer if needed.
-
-
-.Prerequisites _(if needed)_
-
-* List
-
-
-.Procedure
-
-. List
-
-
-.Related Information _(if needed)_
-
-* List
diff --git a/internal_resources/terms_conventions.adoc b/internal_resources/terms_conventions.adoc
deleted file mode 100644
index 4e35074ab..000000000
--- a/internal_resources/terms_conventions.adoc
+++ /dev/null
@@ -1,146 +0,0 @@
-[[red-hat-single-sign-on-conventions]]
-=== Red Hat Single Sign-On Terms and Conventions
-
-[discrete]
-==== ID (noun)
-[[ssoID]]
-*Description*: as in, service ID
-
-*Use it*: with caution
-
-*Incorrect forms*: id
-
-*See also*:
-
-
-[discrete]
-==== identity management (noun)
-[[identitymanage]]
-*Description*:
-
-*Use it*: yes
-
-*Incorrect forms*:
-
-*See also*: xref:idm[IdM]
-
-[discrete]
-==== IdM (noun)
-[[idm]]
-*Description*: acceptable abbreviation for identity management
-
-*Use it*: yes
-
-*Incorrect forms*: IDM, idm
-
-*See also*: xref:identitymanage[identity management]
-
-[discrete]
-==== identity provider (noun)
-[[identityprovider]]
-*Description*:
-
-*Use it*: yes
-
-*Incorrect forms*:
-
-*See also*: xref:idp[IdP]
-
-[discrete]
-==== IdP (noun)
-[[idp]]
-*Description*: acceptable abbreviation for identity provider
-
-*Use it*: yes
-
-*Incorrect forms*: IDP, idp
-
-*See also*: xref:identityprovider[identity provider]
-
-[discrete]
-==== Red Hat Single Sign-On (noun)
-[[redhatsinglesignon]]
-*Description*: Product name for Red Hat Single Sign-On
-
-*Use it*: yes
-
-*Incorrect forms*: Red Hat single sign-on, Red Hat Single Sign-on, single sign-on
-
-*See also*: xref:rhsso[RH-SSO]
-
-[discrete]
-==== Red Hat Single Sign-On Server (noun)
-[[redhatsinglesignonserver]]
-*Description*: Product name for Red Hat Single Sign-On Server
-
-*Use it*: yes
-
-*Incorrect forms*: Red Hat single sign-on server, Red Hat Single Sign-on server, single sign-on server
-
-*See also*:
-
-[discrete]
-==== RH-SSO (noun)
-[[rhsso]]
-*Description*: Product abbreviation for Red Hat Single Sign-On
-
-*Use it*: yes
-
-*Incorrect forms*: RHSSO, SSO
-
-*See also*: xref:redhatsinglesignon[Red Hat Single Sign-On]
-
-[discrete]
-==== SAML (noun)
-[[saml]]
-*Description*: Abbreviation for Security Assertion Markup Language
-
-*Use it*: yes
-
-*Incorrect forms*: saml
-
-*See also*:
-
-[discrete]
-==== service provider (noun)
-[[serviceprovider]]
-*Description*:
-
-*Use it*: yes
-
-*Incorrect forms*: Service Provider
-
-*See also*: xref:sp[SP]
-
-[discrete]
-==== single sign-on (noun)
-[[sso]]
-*Description*: Generic term for single sign-on
-
-*Use it*: yes
-
-*Incorrect forms*: sso
-
-*See also*:
-
-[discrete]
-==== SP (noun)
-[[sp]]
-*Description*: Acceptable abbreviation for service provider
-
-*Use it*: yes
-
-*Incorrect forms*: sp
-
-*See also*: xref:serviceprovider[service provider]
-
-[discrete]
-==== SSSD (noun)
-[[sssd]]
-*Description*: Abbreviation for system security services daemon
-
-*Use it*: yes
-
-*Incorrect forms*: sssd
-
-*See also*:
diff --git a/internal_resources/testing.adoc b/internal_resources/testing.adoc
deleted file mode 100644
index ce998977c..000000000
--- a/internal_resources/testing.adoc
+++ /dev/null
@@ -1,110 +0,0 @@
-= Testing
-
-The `tests` directory contains a testsuite for the documentation. It has a separate test for each guide.
-
-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 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.
-
-By default the tests run against the locally built documentation. It is also possible to run the test against an
-externally built and hosted version of the documentation.
-
-
-== Running the tests
-
-The tests are ran with a regular build:
-
-[source,bash]
-----
-# mvn clean install
-----
-
-The tests are also ran when building the product documentation:
-
-[source,bash]
-----
-# mvn clean install -Dproduct
-----
-
-You can also run the tests from within your IDE, but you have to manually build the guides first.
-
-== Testing externally built and hosted
-
-The tests can check externally built and hosted documentation instead of the locally built version. To do this set
-the `guideBaseUrl` system property to the base URL of the externally hosted documentation.
-
-For example to test Keycloak documentation run:
-[source,bash]
-----
-mvn -f test test -DguideBaseUrl=http:///docs/{version}
-----
-
-Or for example to test RH-SSO documentation run:
-[source,bash]
-----
-mvn -f test test -DguideBaseUrl=https:///documentation/en-us/red_hat_single_sign-on/{version}/html-single/
-----
-
-NOTE: `{version}` is replaced with `{project_versionDoc}` from document-attributes.
-
-== Travis
-
-Travis will run the tests both for community and product versions of the documentation for every PR and against
-branches when they are updated.
-
-
-== Tests
-
-=== Variables
-
-Missing variables are detected by looking for '{name}' in the built documentation. There are some cases where we
-want to have these though, so the following are excluded:
-
-* If prefixed with `$` (for example `${name}`)
-* If prefixed with `/` (for example `http://localhost:8080/{realm-name}`)
-* If listed in `tests/src/resources/ignored-variables`
-
-=== Includes
-
-Checking for missing includes is pretty simple as AsciiDoctor will output _Unresolved directive..._ in the generated
-HTML so we're just searching for that.
-
-=== Images
-
-Missing images are checked by searching for `` tags and checking that they src attribute refers to an existing
-image.
-
-=== Internal links
-
-Internal links are checked by searching for `` and checking that the built documentation contains a
-corresponding `` element.
-
-=== External links
-
-External links are checked by searching for `` then a connection is opened to verify if the link
-is valid. If the returned status is 200 we're all good and we also check the returned document to see if it contains
-a corresponding `` element or `` element.
-
-Specific URLs can be excluded by adding them to `tests/src/resources/ignored-links`. This is used for example for
-`http://localhost:8080` which won't be available unless Keycloak is running on the machine where the tests are ran.
-
-For 302 redirects there is some special handling. The returned `Location` header needs to be added to
-`tests/src/resources/ignored-link-redirects` otherwise the link will be marked as failed. It's important to verify the
-redirected link before you add it to this file though as in some cases it redirects to some generic moved or unavailable
-page.
-
-To prevent the checking of links being to slow to execute there is a cache file with valid links. This is stored in
-`.verified-links`. The first time you run the tests you will notice that the checking links is fairly slow, but this
-will be faster the second time you run it. Entries are purged from the cache after 1 day.
-
-Links to other guides within the documentation are handled specially. When testing local builds the link to the guide as
-specified within document-attributes is replaced with the link to the locally built HTML file. When testing externally
-built and hosted guides the base part of the links are replaced with `guideBaseUrl`. This allows leaving the links
-in document-attributes to point to the location the documentation will eventually be published to while also allowing
-testing cross referencing between guides.
\ No newline at end of file
diff --git a/pom.xml b/pom.xml
deleted file mode 100644
index df016822b..000000000
--- a/pom.xml
+++ /dev/null
@@ -1,208 +0,0 @@
-
-
- 4.0.0
-
- Keycloak Documentation Parent
- org.keycloak.documentation
- documentation-parent
- 999.0.0-SNAPSHOT
- pom
-
-
- index
- keycloak-images
-
- UTF-8
- 1.5.5
- 3.0.0
- 3.0.2
- 3.0.1
- 1.8
- 3.6.1
- 3.0.2
- 2.5.2
- 2.22.2
-
- 1.8
- 1.8
-
- archive
-
-
-
- header-maven-plugin
- api_documentation
- authorization_services
- securing_apps
- server_admin
- server_development
- release_notes
- upgrading
- aggregation
- dist
-
-
-
-
- tests
-
-
- !skipProjectTests
-
-
-
- tests
-
-
-
- latest
-
-
- latest
-
-
-
- latest
-
-
-
-
-
-
-
-
- org.apache.maven.plugins
- maven-compiler-plugin
- ${version.compiler.plugin}
-
- ${maven.compiler.target}
- ${maven.compiler.source}
-
-
-
- org.apache.maven.plugins
- maven-jar-plugin
- ${version.jar.plugin}
-
-
- org.apache.maven.plugins
- maven-install-plugin
- ${version.install.plugin}
-
-
- org.apache.maven.plugins
- maven-antrun-plugin
- ${version.plugin.antrun}
-
-
- echo-output
- generate-resources
-
- run
-
-
-
- OUTPUT: file://${project.build.directory}/generated-docs/${masterFile}.html ${projectLatestBuild}
-
-
-
-
-
-
- org.apache.maven.plugins
- maven-dependency-plugin
- ${version.plugin.dependency}
-
-
- org.apache.maven.plugins
- maven-surefire-plugin
- ${version.surefire.plugin}
-
-
- org.keycloak.documentation
- header-maven-plugin
- 999.0.0-SNAPSHOT
-
-
- add-file-headers
-
- header
-
-
- ${masterFile}
-
-
-
-
-
- org.asciidoctor
- asciidoctor-maven-plugin
- ${version.plugin.asciidoctor}
-
-
- asciidoc-to-html
- generate-resources
-
- process-asciidoc
-
-
- ${basedir}/target/sources
- ${masterFile}.adoc
- html5
- coderay
-
-
- ./
- left
- left
- font
- true
-
- -
- true
- ${masterFile}
- ${buildType}
-
-
-
- ${project.basedir}
-
- images/**/*.png
- ${imagesDir}/**/*.png
-
-
-
-
-
-
-
-
-
- org.apache.maven.plugins
- maven-resources-plugin
- ${version.plugin.resources}
-
-
- asciidoc-copy-resources
- process-resources
-
- copy-resources
-
-
-
-
- target/generated-docs
-
-
-
-
-
-
- org.apache.maven.plugins
- maven-assembly-plugin
- ${version.plugin.assembly}
-
-
-
-
-
diff --git a/release-details b/release-details
deleted file mode 100644
index 791d78ebf..000000000
--- a/release-details
+++ /dev/null
@@ -1,3 +0,0 @@
-VERSION=15.0.2
-SHORT_VERSION=15.0
-NPM_VERSION=15.0.2
diff --git a/release_notes/.asciidoctorconfig b/release_notes/.asciidoctorconfig
deleted file mode 100644
index acb09a095..000000000
--- a/release_notes/.asciidoctorconfig
+++ /dev/null
@@ -1 +0,0 @@
-:imagesdir: {asciidoctorconfigdir}
diff --git a/release_notes/docinfo-footer.html b/release_notes/docinfo-footer.html
deleted file mode 120000
index a39d3bd0f..000000000
--- a/release_notes/docinfo-footer.html
+++ /dev/null
@@ -1 +0,0 @@
-../aggregation/navbar.html
\ No newline at end of file
diff --git a/release_notes/docinfo.html b/release_notes/docinfo.html
deleted file mode 120000
index 14514f94d..000000000
--- a/release_notes/docinfo.html
+++ /dev/null
@@ -1 +0,0 @@
-../aggregation/navbar-head.html
\ No newline at end of file
diff --git a/release_notes/index.adoc b/release_notes/index.adoc
deleted file mode 100644
index e7de48672..000000000
--- a/release_notes/index.adoc
+++ /dev/null
@@ -1,115 +0,0 @@
-:toc: left
-:toclevels: 3
-:sectanchors:
-:linkattrs:
-
-include::topics/templates/document-attributes.adoc[]
-
-:release_notes:
-
-= {releasenotes_name}
-
-:release_header_guide: {releasenotes_name_short}
-:release_header_latest_link: {releasenotes_link_latest}
-include::topics/templates/release-header.adoc[]
-
-== {project_name_full} 21.0.0
-include::topics/21_0_0.adoc[leveloffset=2]
-
-
-== {project_name_full} 20.0.0
-include::topics/20_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 19.0.0
-include::topics/19_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 18.0.0
-include::topics/18_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 17.0.0
-include::topics/17_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 16.1.0
-include::topics/16_1_0.adoc[leveloffset=2]
-
-== {project_name_full} 16.0.0
-include::topics/16_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 15.1.0
-include::topics/15_1_0.adoc[leveloffset=2]
-
-== {project_name_full} 15.0.1
-include::topics/15_0_1.adoc[leveloffset=2]
-
-== {project_name_full} 15.0.0
-include::topics/15_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 14.0.0
-include::topics/14_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 13.0.0
-include::topics/13_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 12.0.0
-include::topics/12_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 11.0.0
-include::topics/11_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 10.0.0
-include::topics/10_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 9.0.1
-include::topics/9_0_1.adoc[leveloffset=2]
-
-== {project_name_full} 9.0.0
-include::topics/9_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 8.0.2
-include::topics/8_0_2.adoc[leveloffset=2]
-
-== {project_name_full} 8.0.1
-include::topics/8_0_1.adoc[leveloffset=2]
-
-== {project_name_full} 8.0.0
-include::topics/8_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 7.0.1
-include::topics/7_0_1.adoc[leveloffset=2]
-
-== {project_name_full} 7.0.0
-include::topics/7_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 6.0.0
-include::topics/6_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 5.0.0
-include::topics/5_0_0.adoc[leveloffset=2]
-
-== {project_name_full} 4.8.0.Final
-include::topics/4_8_0_final.adoc[leveloffset=2]
-
-== {project_name_full} 4.7.0.Final
-include::topics/4_7_0_final.adoc[leveloffset=2]
-
-== {project_name_full} 4.6.0.Final
-include::topics/4_6_0_final.adoc[leveloffset=2]
-
-== {project_name_full} 4.5.0.Final
-include::topics/4_5_0_final.adoc[leveloffset=2]
-
-== {project_name_full} 4.4.0.Final
-include::topics/4_4_0_final.adoc[leveloffset=2]
-
-== {project_name_full} 4.3.0.Final
-include::topics/4_3_0_final.adoc[leveloffset=2]
-
-== {project_name_full} 4.2.0.Final
-include::topics/4_2_0_final.adoc[leveloffset=2]
-
-== {project_name_full} 4.1.0.Final
-include::topics/4_1_0_final.adoc[leveloffset=2]
-
-== {project_name_full} 4.0.0.Final
-include::topics/4_0_0_final.adoc[leveloffset=2]
-include::topics/4_0_0_beta3.adoc[leveloffset=2]
diff --git a/release_notes/pom.xml b/release_notes/pom.xml
deleted file mode 100644
index 9387b1307..000000000
--- a/release_notes/pom.xml
+++ /dev/null
@@ -1,40 +0,0 @@
-
-
- 4.0.0
-
-
- org.keycloak.documentation
- documentation-parent
- 999.0.0-SNAPSHOT
- ../
-
-
- Release Notes
- release-notes
- pom
-
-
-
-
- org.asciidoctor
- asciidoctor-maven-plugin
-
-
- asciidoc-to-html
-
- ${basedir}
-
-
-
-
-
- maven-antrun-plugin
-
-
- echo-output
-
-
-
-
-
-
diff --git a/release_notes/topics/10_0_0.adoc b/release_notes/topics/10_0_0.adoc
deleted file mode 100644
index 3f4fea782..000000000
--- a/release_notes/topics/10_0_0.adoc
+++ /dev/null
@@ -1,44 +0,0 @@
-= Highlights
-
-== Identity Brokering Sync Mode
-
-With Identity Brokering Sync Mode it is now possible to control if user profiles are updated on first login, or
-every login from an external Identity Provider. It is also possible to override this behaviour on individual mappers.
-
-Thanks to https://github.com/Martin-Idel-SI[Martin Idel]
-
-
-== Client Session Timeout for OpenID Connect / OAuth 2.0
-
-Typically, an SSO session last for days if not months, while individual client sessions should ideally be a lot shorter.
-With the introduction of client session timeout it is now possible to configure a separate timeout for individual clients,
-as well as a default for all clients within a realm.
-
-Thanks to https://github.com/y-tabata[Yoshiyuki Tabata]
-
-
-== OAuth 2.0 Token Revocation (RFC 7009)
-
-For applications that use Keycloak as an OAuth 2.0 Authorization Server there is now support to revoke refresh tokens
-through the token revocation endpoint.
-
-Thanks to https://github.com/y-tabata[Yoshiyuki Tabata]
-
-
-== Security Headers SPI and Response Filter
-
-A new SPI was introduced to allow better flexibility when setting security related headers on responses. This provides
-a cleaner implementation within Keycloak, but also allows full customisation if needed. Security headers are now set
-by a response filter instead of within the code itself, which makes it less error-prone, removing the chance that
-some response are missing headers.
-
-
-== Upgrade to WildFly 19
-
-Keycloak server was upgraded to use WildFly 19 under the covers.
-
-
-== Other improvements
-
-* Support for invoking Application Initiated Actions added to Keycloak JavaScript adapter
-* Performance improvements to fetching resources and policies during evaluation
\ No newline at end of file
diff --git a/release_notes/topics/11_0_0.adoc b/release_notes/topics/11_0_0.adoc
deleted file mode 100644
index 22bfd5ab6..000000000
--- a/release_notes/topics/11_0_0.adoc
+++ /dev/null
@@ -1,40 +0,0 @@
-= Highlights
-
-== LDAPv3 password modify operation
-
-Support for LDAPv3 password modify operation was added. Also the ability in the admin console to request metadata from the configured
-LDAP server to see if it supports LDAPv3 password modify operation.
-
-Thanks to https://github.com/cachescrubber[cachescrubber]
-
-== Namespace support for LDAP group mapper
-
-Namespace support for LDAP group mapper allows you to map groups from LDAP under specified branch (namespace) of the Keycloak groups tree.
-Previously groups from LDAP were always added as the top level groups in Keycloak.
-
-Thanks to https://github.com/tjuerge[Torsten Juergeleit]
-
-
-== Upgrade to WildFly 20
-
-Keycloak server was upgraded to use WildFly 20.0.1.Final under the covers. For more details,
-please take a look at link:{upgradingguide_link_latest}[{upgradingguide_name}].
-
-
-== SAML POST binding is broken in the latest versions of browsers
-
-The `SameSite` value `None` for `JSESSIONID` cookie is necessary for correct behavior of the {project_name} SAML adapter.
-Usage of a different value is causing resetting of the container's session with each request to {project_name}, when
-the SAML POST binging is used. Refer to the following steps for
-link:{adapterguide_link}#_saml-jboss-adapter-samesite-setting[Wildfly] and
-link:{adapterguide_link}#_saml-tomcat-adapter-samesite-setting[Tomcat] to keep the correct behavior. Notice, that this
-workaround should be working also with the previous versions of the adapter.
-
-== Other improvements
-
-
-* Support for client offline session lifespan. Thanks to https://github.com/y-tabata[Yoshiyuki Tabata]
-* Czech translation. Thanks to https://github.com/jakubknejzlik[Jakub Knejzlík]
-* Possibility to fetch additional fields from the Facebook identity provider. Thanks to https://github.com/BartoszSiemienczuk[Bartosz Siemieńczuk]
-* Support for AES 192 and AES 256 algorithms used for signed and encrypted ID tokens. Thanks to https://github.com/tnorimat[Takashi Norimatsu]
-* Ability to specify signature algorithm in Signed JWT Client Authentication. Thanks to https://github.com/tnorimat[Takashi Norimatsu]
\ No newline at end of file
diff --git a/release_notes/topics/12_0_0.adoc b/release_notes/topics/12_0_0.adoc
deleted file mode 100644
index 981373dc5..000000000
--- a/release_notes/topics/12_0_0.adoc
+++ /dev/null
@@ -1,50 +0,0 @@
-= Highlights
-
-== Keycloak.X distribution preview
-
-Introduction a preview of the new and upcoming Keycloak.X distribution. This distribution is powered by Quarkus, bringing
-significant improvements to startup time and memory consumption, as well as making it a lot easier to configure Keycloak.
-
-== New Account console is now the default
-
-The new account console is no longer a preview feature and is now the default account console in Keycloak. The old account
-console will stay around for a while. For those that have a custom theme for the old account console the old console
-will be used by default, giving you the time to update your custom theme to the new account console.
-
-== OpenID Connect Back-Channel Logout
-
-Support for OpenID Connect Back-Channel Logout is now available, thanks to https://github.com/DaSmoo[DaSmoo] and
-https://github.com/benjamin37[benjamin37].
-
-== Upgrade to Wildfly 21
-
-The {project_name} server was upgraded to use Wildfly 21 as the underlying container.
-
-== Ability to request AuthnContext in SAML identity provider
-
-Support for specification of AuthnContext section in authentication requests issued by SAML identity provider has been added.
-
-Thanks to https://github.com/lscorcia[lscorcia]
-
-== FAPI RW support and initial support to Client policies
-
-There was lots of the work done to have support for Financial-grade API Read and Write API Security Profile (FAPI RW). This is available
-with the usage of Client policies and it is still in the preview state. You can expect more polishing in the next releases.
-Thanks to https://github.com/tnorimat[Takashi Norimatsu] and all the members of the https://github.com/keycloak/kc-sig-fapi[FAPI Special interest group].
-
-== Upgrade login theme to PatternFly 4
-
-The {project_name} login theme components have been upgraded to PatternFly 4.
-The old PatternFly 3 runs simultaneously with the new one, so it's possible to have PF3 components there.
-
-There are also design changes in the login theme for better user experience.
-You can even define an icon for your custom Identity providers.
-For details, please refer to the link:{developerguide_link}#custom-identity-providers-icons[docs].
-
-== Gatekeeper EOL
-Gatekeeper reached end of life, in November 21. This means that we no longer support, or update it. The announcement is available https://www.keycloak.org/2020/08/sunsetting-louketo-project.adoc[here].
-
-== Other improvements
-
-* Support for OAuth2 Client Credentials grant without refresh token and without user session. Thanks to https://github.com/thomasdarimont[Thomas Darimont]
-* Support for send access tokens to the OAuth2 Revocation endpoint
diff --git a/release_notes/topics/13_0_0.adoc b/release_notes/topics/13_0_0.adoc
deleted file mode 100644
index 9aed3c0e8..000000000
--- a/release_notes/topics/13_0_0.adoc
+++ /dev/null
@@ -1,43 +0,0 @@
-= Highlights
-
-== Upgrade to Wildfly 23
-
-The {project_name} server was upgraded to use Wildfly 23.0.2.Final as the underlying container.
-
-== OAuth 2.0 Device Authorization Grant (RFC 8628)
-
-Support for OAuth 2.0 Device Authorization Grant is now available.
-
-Thanks to
-// https://github.com/wadahiro [Hiroyuki Wada] <-- URL fails
-Hiroyuki Wada, https://github.com/splatch[Łukasz Dywicki]
-and https://github.com/Michito-Okai[Michito Okai].
-
-== OpenID Connect Client Initiated Backchannel Authentication (CIBA)
-
-Support for OpenID Connect Client Initiated Backchannel Authentication (CIBA) is now available.
-
-Thanks to https://github.com/tnorimat[Takashi Norimatsu],
-https://github.com/andriimurashkin[Andrii Murashkin], https://github.com/c4r1570p4e[Christophe Lannoy] and members of the FAPI WG for the implementation and feedback.
-
-== SAML Artifact binding in server to client communication
-
-Keycloak now supports communication with clients using SAML _Artifact_ binding. A new `Force Artifact Binding` option
-was introduced in the client configuration, that forces communication with the client using artifact messages. For more
-details proceed to link:{adminguide_link}#_client-saml-configuration[{adminguide_name}]. Please note, that with
-this version, Keycloak SAML client adapter does NOT support Artifact binding.
-
-Thanks to https://github.com/AlistairDoswald[AlistairDoswald] and https://github.com/harture[harture].
-
-== Support PKCE for identity brokering
-
-Keycloak can now leverage PKCE when brokering to an external OpenID Connect IdP.
-
-Thanks to https://github.com/thomasdarimont[thomasdarimont].
-
-== Default roles processing improvement
-
-Default roles are now internally stored as composite roles of a new role usually named `default-roles-`. Instead of assigning
-both realm and all client default roles directly to newly created users or users imported through Identity Brokering, just the role is
-assigned to them and the rest of default roles are assigned as effective roles. This change improves performance of default roles processing,
-especially with larger number of clients, because it is no longer necessary to go through all clients.
diff --git a/release_notes/topics/14_0_0.adoc b/release_notes/topics/14_0_0.adoc
deleted file mode 100644
index 7a750d8dd..000000000
--- a/release_notes/topics/14_0_0.adoc
+++ /dev/null
@@ -1,33 +0,0 @@
-= Highlights
-
-== Client Policies and Financial-grade API (FAPI) Support
-
-The {project_name} server has now official support for client policies and Financial-grade API (FAPI). This capability was previewed in earlier versions, but now
-it is more polished and properly documented. Thanks to https://github.com/tnorimat[Takashi Norimatsu], who did most of the work on this. Also thanks
-to https://github.com/DmitryMishchuk[Dmytro Mishchuk], https://github.com/andriimurashkin[Andrii Murashkin] and https://github.com/HryhoriiHevorkian[Hryhorii Hevorkian], who did a great deal of the work on this feature as well.
-Finally thanks to all the members of the https://github.com/keycloak/kc-sig-fapi/blob/main/members.adoc[FAPI Special interest group] for their help and feedback.
-
-== Improvements to User Profile SPI and support for declarative configuration
-
-In this version, there were several improvements to the User Profile SPI in order
-to prepare the ground on how users profiles are managed in {project_name}.
-
-One of these improvements is the support for configuring user profiles through the administration console. For more
-details proceed to link:{adminguide_link}#user-profile[{adminguide_name}]
-
-Thanks to the community and all the individuals involved in this effort.
-
-== Improvements to offline sessions
-
-Offline session preloading has been improved and should be faster thanks to https://github.com/Flintholm[Peter Flintholm].
-
-ifeval::[{project_community}==true]
-As a preview feature, offline session preloading can be skipped in favor of lazy loading thanks
-to https://github.com/thomasdarimont[Thomas Darimont]'s efforts. This feature has to be explicitly
-activated in the server configuration, see Server administration guide for details.
-endif::[]
-
-
-== Other improvements
-
-* The support for configuring maximum number of active authentication sessions. The default value is set to 300 authentication sessions (browser tabs) per a browser's session
diff --git a/release_notes/topics/15_0_0.adoc b/release_notes/topics/15_0_0.adoc
deleted file mode 100644
index cbc348822..000000000
--- a/release_notes/topics/15_0_0.adoc
+++ /dev/null
@@ -1,9 +0,0 @@
-= Highlights
-
-== Financial-grade API (FAPI) Improvements, FAPI CIBA and Open Banking Brasil
-
-The {project_name} server has improved support for the Financial-grade API (FAPI). More specifically, {project_name} is now compliant with FAPI CIBA and with OpenBanking Brasil.
-We also have support for CIBA ping mode. Thanks to https://github.com/tnorimat[Takashi Norimatsu], who did most of the work on FAPI CIBA and who is
-continually doing a really awesome job for the {project_name} project. Also thanks to https://github.com/DmitryMishchuk[Dmytro Mishchuk],
-https://github.com/andriimurashkin[Andrii Murashkin], https://github.com/HryhoriiHevorkian[Hryhorii Hevorkian] and https://github.com/leandrobortoli[Leandro José de Bortoli], who did a great deal of
-the work on the FAPI compliance as well. Finally thanks to all the members of the https://github.com/keycloak/kc-sig-fapi/blob/main/members.adoc[FAPI Special interest group] for their help and feedback.
diff --git a/release_notes/topics/15_0_1.adoc b/release_notes/topics/15_0_1.adoc
deleted file mode 100644
index b42ea8e5b..000000000
--- a/release_notes/topics/15_0_1.adoc
+++ /dev/null
@@ -1,4 +0,0 @@
-= Highlights
-
-This release contains some important bug fixes. In addition, We would like to thank https://github.com/leandrobortoli[Leandro José de Bortoli] for his contributions to the
-FAPI related functionalities such as JARM support and improvements in CIBA.
\ No newline at end of file
diff --git a/release_notes/topics/15_1_0.adoc b/release_notes/topics/15_1_0.adoc
deleted file mode 100644
index bb801ab41..000000000
--- a/release_notes/topics/15_1_0.adoc
+++ /dev/null
@@ -1,44 +0,0 @@
-= Highlights
-
-== Quarkus distribution preview
-
-Without comparison the biggest highlight of this release is all the improvements that have been made to the Quarkus distribution. So many in fact, that it will be hard to list them all.
-
-The CLI has been polished to hell and back, and we believe it now provides a very simple and convenient approach to configuring and running Keycloak. It's almost so simple that documentation shouldn't be needed.
-
-To get started, just unpack the distribution, then type `bin/kc.[sh|bat] -h` to discover awesomeness!
-
-That doesn't mean we don't plan to provide documentation for configuring Keycloak, but it didn't quite make it this time around. In lack of documentation expect a blog post to follow the release introducing all the changes to the Quarkus distribution, as well as an overview on how to use it.
-
-We are rapidly moving towards making the Quarkus distribution our default distribution, and will soon deprecate the WildFly distribution. With this in mind it is important that as many people as possible give it a test-run and provide us with feedback if you find any usability issues, are not able to configure something with it, or if you discover any bugs.
-
-We'd love to hear your thoughts and get your feedback in https://github.com/keycloak/keycloak/discussions/8654[GitHub Discussions]!
-
-== New Admin Console preview
-
-The new admin console is shaping up really nicely, and a preview is included in the main distribution. It is not quite feature complete yet, but there are still loads of things to try out.
-
-== WildFly update
-
-Upgrading from WildFly 23 to WildFly 25 has taken a lot longer than we would have liked. We're still working hard on this and are hoping to release Keycloak 16 as soon as possible with the upgrade, but as we wanted to get the updates to the Quarkus distribution out there we are doing this release in the meantime.
-
-== WildFly adapter deprecation
-
-In WildFly 25 there is now excellent native OpenID Connect support without the need for the Keycloak adapter. With this in mind we are deprecating our WildFly adapter and will not support WildFly 25, but it will be around for a while for older WildFly versions and Red Hat JBoss Enterprise Application Platform 7.y.
-
-== Spring Security and Boot adapter deprecation
-
-A long time ago, with Spring Security 5.0, there is now native support for OAuth 2.0 and OpenID Connect in Spring. With this in mind now is the time to start deprecating our Spring Boot and Security adapters.
-
-== OpenID Connect Front-Channel Logout Support
-
-{project_name} now supports https://openid.net/specs/openid-connect-frontchannel-1_0.html[OpenID Connect Front-Channel Logout 1.0].
-
-For more details, take a look at link:{adminguide_link}#_oidc-logout[{adminguide_name}].
-
-Thanks to https://github.com/rhyamada[Ronaldo Yamada] for the contribution.
-
-== Deprecated features in the {project_operator}
-
-With this release, we have deprecated and/or marked as unsupported some features in the {project_operator}. This
-concerns the Backup CRD and the operator managed Postgres Database.
diff --git a/release_notes/topics/16_0_0.adoc b/release_notes/topics/16_0_0.adoc
deleted file mode 100644
index fdbd3772b..000000000
--- a/release_notes/topics/16_0_0.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-= Highlights
-
-== Upgrade to Wildfly 25.0.1
-
-Keycloak server was upgraded to use Wildfly 25.0.1.Final as the underlying container.
-
-WildFly 25 drops support for the legacy security subsystem, which is being replaced fully by Elytron. This requires significant changes to how Keycloak is configured. Please, refer to the migration guide for more details.
-
-For more information on WildFly 25 refer to the https://www.wildfly.org/news/2021/10/05/WildFly25-Final-Released/[WildFly 25 release notes].
-
-== Upgrade to Quarkus 2.5.3
-
-Keycloak.X Quarkus preview distribution was upgraded to Quarkus 2.5.3.
\ No newline at end of file
diff --git a/release_notes/topics/16_1_0.adoc b/release_notes/topics/16_1_0.adoc
deleted file mode 100644
index ae35abafd..000000000
--- a/release_notes/topics/16_1_0.adoc
+++ /dev/null
@@ -1,7 +0,0 @@
-= Highlights
-
-== Upgrade to Wildfly 26.0.0
-
-Keycloak server was upgraded to use Wildfly 26.0.0.Final as the underlying container.
-
-For more information on WildFly 26 refer to the https://www.wildfly.org/news/2021/12/16/WildFly26-Final-Released/[WildFly 26 release notes].
\ No newline at end of file
diff --git a/release_notes/topics/17_0_0.adoc b/release_notes/topics/17_0_0.adoc
deleted file mode 100644
index 99b71242a..000000000
--- a/release_notes/topics/17_0_0.adoc
+++ /dev/null
@@ -1,37 +0,0 @@
-= Highlights
-
-== Quarkus distribution is now fully supported
-
-The default Keycloak distribution is now based on Quarkus. The new distribution is faster, leaner, and a lot easier to configure!
-
-We appreciate migrating from the WildFly distribution is not going to be straightforward for everyone, since how you start and configure Keycloak has radically changed. With that in mind we will continue to support the WildFly distribution until June 2022.
-
-For information on how to migrate to the new distribution check out the https://www.keycloak.org/migration/migrating-to-quarkus[Quarkus Migration Guide].
-
-== Quarkus distribution updates
-
-A lot of effort went into polishing and improving the Quarkus distribution to make it as good as an experience as possible. A few highlights include:
-
-* A new approach to documentation in form of server guides to help you install and configure Keycloak
-* Upgraded Quarkus to 2.7.0.Final
-* Configuration file is no longer Java specific, and aligns configuration keys with CLI arguments
-* Clearer separation between `build options` and `runtime configuration`.
-* `h2-mem` and `h2-file` databases renamed to `dev-mem` and `dev-file`.
-* Simplified enabling and disabling features
-* Custom, and unsupported, Quarkus configuration is done through `conf/quarkus.properties`.
-* Ability to add custom Java Options via JAVA_OPTS_APPEND (thanks to https://github.com/dasniko[dasniko])
-* Initial logging capabilities
-* Initial support for Cross-DC
-* User-defined profiles are no longer supported but using different configuration files to achieve the same goal
-* Quickstarts updated to use the new distribution
-== Other improvements
-
-=== Offline sessions lazy loaded
-
-The offline sessions are now lazily fetched from the database by default instead of preloading during the server startup.
-To change the default behavior, see link:{adminguide_link}#offline-sessions-preloading[{adminguide_name}].
-
-=== Improved User Search
-
-{project_name} now supports a glob-like syntax for the user search when listing users in the Admin Console,
-which allows for three different types of searches: prefix (`foo*` which became the default search), infix (`\*foo*`), and exact `"foo"`)
diff --git a/release_notes/topics/18_0_0.adoc b/release_notes/topics/18_0_0.adoc
deleted file mode 100644
index a9ca945e1..000000000
--- a/release_notes/topics/18_0_0.adoc
+++ /dev/null
@@ -1,118 +0,0 @@
-= New Operator preview
-
-With this release, we're introducing a brand new {project_operator} as a preview. Apart from being rewritten from
-scratch, the main user-facing change from the legacy Operator is the used {project_name} distribution – the new Operator
-uses the Quarkus distribution of {project_name}. With that, the API (in form of Custom Resource Definitions) has changed.
-For details, incl. installation and migration instructions, see the https://www.keycloak.org/guides#operator[Operator related guides].
-
-The link:{operatorRepo_link}[legacy Operator] will receive updates until Keycloak 20 when the {project_name} WildFly
-distribution reaches EOL.
-
-== OperatorHub versioning scheme
-To avoid version conflicts with the legacy Operator, the 18.0.0 version of the new Operator is released as version
-`20.0.0-alpha.1` on OperatorHub. The legacy Operator versioning scheme remains the same, i.e. it is released as 18.0.0.
-
-The same pattern will apply for future {project_name} 18 and 19 releases, until version 20 where the legacy Operator
-reaches EOL.
-
-= New Admin Console preview
-
-The new Admin Console is now graduated to preview, with the plan for it to become the default admin console in Keycloak 19.
-
-If you find any issues with the new console, or have some suggestions for improvements, please let us know through https://github.com/keycloak/keycloak/discussions/categories/new-admin-console[GitHub Discussions].
-
-= Step-up authentication
-
-{project_name} now supports Step-up authentication. This feature was added in Keycloak 17, and was further polished in this version.
-
-For more details, see link:{adminguide_link}#_step-up-flow[{adminguide_name}].
-
-Thanks to https://github.com/CorneliaLahnsteiner[Cornelia Lahnsteiner] and https://github.com/romge[Georg Romstorfer] for the contribution.
-
-= Client secret rotation
-
-{project_name} now supports Client Secret Rotation through customer policies. This feature is now available as a preview feature and allows that confidential clients can be provided with realm policies allowing the use up to two secrets simultaneously.
-
-For more details, see link:{adminguide_link}#_secret_rotation[{adminguide_name}].
-
-= Recovery Codes
-
-Recovery Codes as another way to do two-factor authentication is now available as a preview feature.
-
-= OpenID Connect Logout Improvements
-
-Some fixes and improvements were made to make sure that {project_name} is now fully compliant with all the OpenID Connect logout specifications:
-
-* OpenID Connect RP-Initiated Logout 1.0
-* OpenID Connect Front-Channel Logout 1.0
-* OpenID Connect Back-Channel Logout 1.0
-* OpenID Connect Session Management 1.0
-
-For more details, see link:{adminguide_link}#_oidc-logout[{adminguide_name}].
-
-= WebAuthn improvements
-
-{project_name} now supports WebAuthn id-less authentication. This feature allows that WebAuthn Security Key will identify the user during authentication as long as the
-security key supports Resident Keys. For more details, see link:{adminguide_link}#_webauthn_loginless[{adminguide_name}].
-Thanks to https://github.com/vanrar68[Joaquim Fellmann] for the contribution.
-
-There are more WebAuthn improvements and fixes in addition to that.
-
-= The deprecated `upload-script` feature was removed
-
-The `upload-script` feature has been marked as deprecated for a very long time. In this release, it was completely removed, and it is no longer supported.
-
-If you are using any of these capabilities:
-
-* OpenID Connect Script Mapper
-* Script Authenticator (Authentication Execution)
-* JavaScript Policies
-
-You should consider reading this https://www.keycloak.org/docs/latest/server_development/#_script_providers[documentation] in order to understand how to still rely
-on these capabilities but deploying your scripts to the server rather than managing them through the management interfaces.
-
-= Session limits
-
-{project_name} now supports limits on the number of sessions a user can have. Limits can be placed at the realm level or at the client level.
-
-For more details, see link:{adminguide_link}#_user_session_limits[{adminguide_name}].
-Thanks to https://github.com/mfdewit[Mauro de Wit] for the contribution.
-
-= SAML ECP Profile is disabled by default
-
-To mitigate the risk of abusing SAML ECP Profile, {project_name} now blocks
-this flow for all SAML clients that do not allow it explicitly. The profile
-can be enabled using _Allow ECP Flow_ flag within client configuration,
-see link:{adminguide_link}#_client-saml-configuration[{adminguide_name}].
-
-= Quarkus distribution
-
-== Import realms at startup
-
-The {project_name} Quarkus distribution now supports importing your realms directly at start-up. For more information, check the corresponding https://www.keycloak.org/server/importExport[guide].
-
-== JSON and File Logging improvements
-
-The {project_name} Quarkus distribution now initially supports logging to a File and logging structured data using JSON.
-
-For more information on the improvements, check the corresponding https://www.keycloak.org/server/logging[guide].
-
-=== Environment variable expansion for values in keycloak.conf
-
-The {project_name} Quarkus distribution now supports expanding values in keycloak.conf from environment variables.
-
-For more information, check the corresponding https://www.keycloak.org/server/configuration[guide].
-
-== New Option db-url-port
-
-You can now change the port of your jdbc connection string explicitly by setting the new `db-url-port` configuration option. As for the other convenience options, this option will be overridden by the value of a full `db-url`, if set.
-
-== Split metrics-enabled option into health-enabled and metrics-enabled
-The `metrics-enabled` option now only enables the metrics for {project_name}. To enable the readiness and liveness probe, there's the new build option `health-enabled`. This allows more fine-grained usage of these options.
-
-= Other improvements
-
-* Account console alignments with latest PatternFly release.
-* Support for encrypted User Info endpoint response. Thanks to https://github.com/giacomoa[Giacomo Altiero]
-* Support for the algorithm RSA-OAEP with A256GCM used for encryption keys. Thanks to https://github.com/fbrissi[Filipe Bojikian Rissi]
-* Support for login with GitHub Enterprise server. Thanks to https://github.com/nngo[Neon Ngo]
diff --git a/release_notes/topics/19_0_0.adoc b/release_notes/topics/19_0_0.adoc
deleted file mode 100644
index 431090a27..000000000
--- a/release_notes/topics/19_0_0.adoc
+++ /dev/null
@@ -1,95 +0,0 @@
-= OpenID Connect and SAML Adapters End-of-life
-
-Some Keycloak OpenID Connect adapters have reached end-of-life and are not included in this release.
-
-== Fuse 6 and 7 (OpenID Connect)
-
-Keycloak will no longer be providing adapters for Fuse 6 or 7. If you need adapters for Fuse please leverage https://access.redhat.com/products/red-hat-single-sign-on[Red Hat Single Sign-On] 7.x adapters.
-
-== JBoss AS 7 and EAP 6 (OpenID Connect and SAML)
-
-JBoss AS 7 has been unmaintained for a very long time. If you are still using JBoss AS 7 we recommend migrating to WildFly and leveraging the native OIDC support in WildFly.
-
-Red Hat customers using Red Hat JBoss Enterprise Application Platform 6.x should use https://access.redhat.com/products/red-hat-single-sign-on[Red Hat Single Sign-On] 7.x adapters. These can be used in combination with the Keycloak server.
-
-== Jetty 9.2 and 9.3 (OpenID Connect and SAML)
-
-Jetty 9.2 reached end of life in 2018, while Jetty 9.3 reached end of life in 2020. If you are still using these versions we recommend upgrading to Jetty 9.4 as soon as possible.
-
-== Spring Boot 1 (OpenID Connect)
-
-Spring Boot 1.x reached end of life in 2019. If you are still using Spring Boot 1 we recommend upgrading to Spring Boot 2 as soon as possible.
-
-== WildFly legacy security layer (OpenID Connect and SAML)
-
-In WildFly 25 the legacy security layer was removed, going forward only Elytron will be supported. We recommend anyone using an older version of WildFly to upgrade and leverage native OIDC support in WildFly.
-
-Red Hat customers using Red Hat JBoss Enterprise Application Platform 7.x should use https://access.redhat.com/products/red-hat-single-sign-on[Red Hat Single Sign-On] 7.x adapters. These can be used in combination with the Keycloak server.
-
-= New Admin Console graduation
-
-The new Admin Console is now graduated to the default admin console, with the old console now deprecated. The old console will be removed in Keycloak 21.
-
-= Changes in Keycloak storage
-
-The Keycloak storage is changing, and the current storage, while still supported, will eventually be replaced with a brand-new implementation.
-This change brings better support for cloud-native storages, no-downtime abilities, and better support for implementing custom storages for additional areas apart from users.
-
-It means several deep changes in the supported features of the current store will become _legacy_ features.
-The legacy store and the new store cannot be used simultaneously; only one store can be active at a time.
-
-The most visible change is that the User Storage SPI is incompatible with the new storage API, the Map Storage API.
-Thus, the User Storage SPI will be deprecated with legacy store and will move to a separate module called `keycloak-model-legacy`.
-This change impacts several areas, especially areas related to user federation and custom user providers.
-
-Furthermore, APIs have been consolidated so that the details of the storage layer will be transparent to the REST service layer.
-Specifically, the services will not be able to differentiate cached and non-cached objects, nor specifically access federated versus local storage.
-
-Hence, custom extensions that access objects in local storage or cache through `KeycloakSession`
-methods must be reviewed.
-See link:{upgradingguide_link}[{upgradingguide_name}] for details.
-
-= OIDC Logout changes
-
-In the previous release, we added support for OIDC logout. This release contains a few other fixes and polishing. The highlights include:
-
-- Support for the `client_id` parameter, which was added in recent draft of the OIDC RP-Initiated Logout specification. As a result, no need exists to use the `Consent Required` flag of the
-client to show the logout confirmation screen.
-- Configuration option `Valid Post Logout Redirect URIs` added to the OIDC client. This change is aligned with the OIDC specification, which allows you to use a different set of redirect URIs for redirect after login and logout.
-Value `+` used for `Valid Post Logout Redirect URIs` means that the logout will use the same set of redirect URIs as specified by the option of `Valid Redirect URIs`. This change also matches the default behavior when migrating
-from a previous version due to backwards compatibility.
-
-For more details, see the link:{adminguide_link}#_oidc-logout[{adminguide_name}].
-
-= Update Email Workflow
-
-There is new preview feature `UPDATE_EMAIL`. When it is enabled and corresponding flag enabled in the realm, the users will be required
-to confirm updating their email by clicking the link, which will be sent to their new email address. For more details, see the link:{adminguide_link}#_update-email-workflow[{adminguide_name}].
-Thanks to https://github.com/reda-alaoui[Réda Housni Alaoui] for the contribution.
-
-= Deprecated `podDisruptionBudget` in the legacy {project_operator}
-
-With this release, we have deprecated `podDisruptionBudget` field in the Keycloak CR of the https://github.com/keycloak/keycloak-operator[legacy {project_operator}].
-This optional field will be ignored when the Operator is deployed on Kubernetes version 1.25 and higher.
-
-As a workaround, you can manually create the Pod Disruption Budget in your cluster, for example:
-```yaml
-apiVersion: policy/v1
-kind: PodDisruptionBudget
-metadata:
- labels:
- app: keycloak
- name: keycloak
-spec:
- maxUnavailable: 1
- selector:
- matchLabels:
- component: keycloak
-```
-See also the https://kubernetes.io/docs/tasks/run-application/configure-pdb/[Kubernetes Documentation].
-
-= Initial Support for centralized logging
-
-Starting with version 19, Keycloak supports sending logs using GELF to centralized logging solutions like ELK, EFK or Graylog out of the box.
-
-You can find the documentation and examples to get you up and running quickly in the https://www.keycloak.org/server/logging#_centralized_logging_using_gelf[logging guide]
\ No newline at end of file
diff --git a/release_notes/topics/20_0_0.adoc b/release_notes/topics/20_0_0.adoc
deleted file mode 100644
index c1fc63a83..000000000
--- a/release_notes/topics/20_0_0.adoc
+++ /dev/null
@@ -1,93 +0,0 @@
-= WildFly distribution removed
-
-In Keycloak 17.0.0 the new Quarkus based distribution of Keycloak, while the WildFly based distribution was deprecated.
-With this release the WildFly distribution has been removed, and is no longer supported.
-
-If you are still using the WildFly distribution we highly encourage migrating to the Quarkus distribution as soon as
-possible, see the https://www.keycloak.org/migration/migrating-to-quarkus[Migration Guide] for more details.
-
-= New Keycloak Operator upgrade
-
-We are happy to announce that the new Keycloak Operator for the Quarkus based distribution is no longer a preview
-feature. We added new functionality as well as a number of improvements, some which has resulted in breaking changes.
-
-== Realm Operator
-
-As the new Operator currently lacks some of the CRs (e.g. Client and User), we're introducing a temporary workaround in
-the form of a Realm Operator. Please see its https://github.com/keycloak/keycloak-realm-operator[GitHub Repository] for
-more details. See also https://www.keycloak.org/2022/09/operator-crs["The future of Keycloak Operator CRs" blogpost].
-
-= Supported OpenJDK versions
-
-Keycloak now supports OpenJDK 17 both for the server and adapters.
-
-With the removal of the WildFly based distribution there is no longer support for running the Keycloak server on OpenJDK 8.
-We also plan to remove support for Keycloak adapters on OpenJDK 8 in Keycloak 21.
-
-Starting with Keycloak 22 we plan to only support the latest OpenJDK LTS release and aiming to quickly also support the
-latest OpenJDK release. That means we will be also removing OpenJDK 11 support for the Keycloak server in Keycloak 22.
-
-= Hostname provider now supports configuring the complete base URL
-
-In this release, we are introducing two additional server options to set the base URL for frontend request and the Admin
-Console:
-
-* `hostname-url`
-* `hostname-admin-url`
-
-More details can be found at the https://www.keycloak.org/server/hostname[Configuring the Hostname Guide].
-
-= Improvements to `kc.bat` when running Keycloak on Windows
-
-In this release, we are making important changes to `kc.bat` to give the same experience as when running on Linux.
-
-= Upgrade of embedded H2 database
-
-{project_name} ships for development purposes with an H2 database driver. As it is intended for development purposes
-only, it should never be used in a production environment.
-
-In this release, the H2 driver has been upgraded from version 1.x to version 2.x.
-
-= Feature guard for hosting the Keycloak JavaScript adapter
-
-Applications are able to load `keycloak.js` directly from the Keycloak server. As it's not considered a best-practice
-to load JavaScript libraries this way there is now a feature guard that allows disabling this ability.
-
-In Keycloak 21 we will deprecate this option, and in Keycloak 22 we plan to completely remove the ability to load
-`keycloak.js` from the Keycloak server.
-
-= OTP Application SPI
-
-In previous releases the list of OTP applications displayed to users was hard-coded in Keycloak. With the introduction of
-the OTP Application SPI it is now possible to disable built-in OTP applications, as well as adding custom OTP Applications.
-
-= Custom Identity Providers can now set an icon for the provider
-
-A custom identity provider can now set the icon used on the login pages. Thanks to https://github.com/klausbetz[Klaus Betz],
-who happens also to maintain
-https://github.com/klausbetz/apple-identity-provider-keycloak[an extension to Keycloak to support log in with AppleID].
-
-= FIPS 140-2 experimental support
-
-There is now experimental support for deploying Keycloak into a FIPS 140-2 enabled environment. There will be a blog post
-with the details shortly after the release with the details how you can try it. Feedback is welcome!
-
-Thanks to https://github.com/david-rh[David Anderson], who contributed parts of this feature. Also, thanks to
-https://github.com/sudeepd[Sudeep Das] and https://github.com/isaacjensen[Isaac Jensen] for their initial prototype
- effort, which was used as an inspiration.
-
-= Search groups by attribute
-
-It is now possible to search groups by attribute through the Admin REST API. Thanks to
-https://github.com/Redhat-Alice[Alice] for this contribution.
-
-= View group membership in the account console
-
-It is now possible to allow users to view their group memberships in the account console. Thanks to
-https://github.com/cgeorgilakis[cgeorgilakis] for this contribution.
-
-= Deprecated methods from data providers and models were removed
-
-Several deprecated methods were removed from data providers and models. If not done already, their usage needs to be
-replaced with the corresponding replacement documented in Javadoc of Keycloak 19 release. See
-link:{upgradingguide_link}[{upgradingguide_name}] for more details.
diff --git a/release_notes/topics/21_0_0.adoc b/release_notes/topics/21_0_0.adoc
deleted file mode 100644
index 520812b26..000000000
--- a/release_notes/topics/21_0_0.adoc
+++ /dev/null
@@ -1,91 +0,0 @@
-= Old Admin Console removed
-
-In Keycloak 19 the new admin console was graduated to the new default admin console, and the old admin console was
-deprecated. In this release the old admin console has been removed completely.
-
-= Keycloak uses Micrometer for metrics
-
-Keycloak provides an optional a metrics endpoint which exports metrics in the Prometheus format.
-In this release the implementation to provide this data switched from SmallRye to Micrometer.
-Due to this change, metrics have been renamed.
-
-See the migration guide for details.
-
-= Java 11 support for Keycloak server deprecated
-
-Running the Keycloak server with Java 11 is now deprecated, and planned to be removed in Keycloak 22.
-
-Adapters remain supported on Java 8, Java 11, and Java 17. However, we are planning to remove support for Java 8 in the
-not too distant future.
-
-= Hashicop Vault no longer supported
-
-We removed the out-of-box support for Hashicorp vault in this release.
-
-See this https://github.com/keycloak/keycloak/discussions/16446[discussion] for more details.
-
-= SAML SP metadata changes
-
-Prior to this release, SAML SP metadata contained the same key for both
-signing and encryption use. Starting with this version of Keycloak,
-we include only encryption intended realm keys for encryption use
-in SP metadata. For each encryption key descriptor we also specify
-the algorithm that it is supposed to be used with. The following table shows
-the supported XML-Enc algorithms with the mapping to Keycloak realm keys.
-See the link:{upgradingguide_link}[{upgradingguide_name}] for more details.
-
-[cols="1,1"]
-|===
-|*XML-Enc algorithm*
-|*Keycloak realm key algorithm*
-
-|https://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#rsa-oaep-mgf1p[rsa-oaep-mgf1p]
-|RSA-OAEP
-
-|https://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#rsa-1_5[rsa-1_5]
-|RSA1_5
-|===
-
-= Deprecated methods from user session provider were removed
-
-Several deprecated methods were removed from user session provider. If not done already,
-their usage needs to be replaced with the corresponding replacement documented in Javadoc
-of Keycloak 20 release. See link:{upgradingguide_link}[{upgradingguide_name}] for more details.
-
-= New storage: `IS_CLIENT_ROLE` searchable field was deprecated
-
-The `IS_CLIENT_ROLE` searchable field from the `RoleModel` was deprecated. It
-should be replaced with the `CLIENT_ID` searchable field used with the operators
-`EXISTS` or `NOT_EXISTS`. See JavaDoc of Keycloak 21 for more details.
-
-= FIPS 140-2 preview support
-
-FIPS 140-2 support in Keycloak, which was experimental in the previous release, is now promoted to preview. There were many fixes and improvements to create this preview version.
-For the details, see the https://www.keycloak.org/guides#server[FIPS documentation]. Feedback is welcome!
-
-Thanks again to https://github.com/david-rh[David Anderson], https://github.com/sudeepd[Sudeep Das] and https://github.com/isaacjensen[Isaac Jensen]
-for their huge help with this feature.
-
-= Support for the standard `Forwarded` header when running behind a reverse proxy
-
-In addition to recognize the non-standard `X-Forwarded-*` to fetch information
-added by proxies that would otherwise be altered or lost when proxy servers are involved in the path of the request, Keycloak
-can now leverage the standard `Forwarded` header for the same purpose.
-
-For more details, see the https://www.keycloak.org/server/reverseproxy[Using a reverse proxy] guide.
-
-Please, make sure your proxy is also overriding the `Forwarded` header when making requests to Keycloak nodes.
-
-= The container image is now based on ubi9-micro
-
-To enhance security, the https://quay.io/repository/keycloak/keycloak?tab=info[Keycloak Container Image] has been modified in two ways: First, it is now based on UBI9, rather than UBI8. Second, we have switched to `+-micro+`, whereas `+-minimal+` was used before.
-
-The change to UBI9 will not have any impact on most users. In rare cases the glibc error https://github.com/keycloak/keycloak/issues/17290[CPU does not support x86-64-v2] may appear. `+x86-64-v2+` has been available from processors since 2009. You're most likely to encounter this issue when your virtualization environment is misconfigured.
-
-The change from `+-minimal+` to `+-micro+` has more potential impact. Users making simple customizations to the image won't notice any difference, however any user that installs RPMs will need to change how they do that. The https://www.keycloak.org/server/containers[container guide] has been updated to show you how.
-
-As a result of these changes, there has been an 82% reduction in known CVEs affecting the Keycloak Container Image!
-
-= Other improvements
-
-* Option to disable client registration access token rotation. Thanks to https://github.com/reda-alaoui[Réda Housni Alaoui]
diff --git a/release_notes/topics/4_0_0_beta3.adoc b/release_notes/topics/4_0_0_beta3.adoc
deleted file mode 100644
index 9a422b2c0..000000000
--- a/release_notes/topics/4_0_0_beta3.adoc
+++ /dev/null
@@ -1,49 +0,0 @@
-= Authorization Services
-
-== UMA 2.0
-
-UMA 2.0 is now supported for Authorization Services, including support for users to manage user access through
-the account management console. There are also other additions and improvements to authorization services.
-
-== Pushed Claims
-
-Clients can now push additional claims and have them used by policies when evaluating permissions.
-
-== Resource Attributes
-
-It is now possible to define attributes on resources in order to have them used by policies when evaluating permissions.
-
-= Themes and Theme Resources
-
-It is now possible to hot-deploy themes to Keycloak through a regular provider deployment. We have also added support for theme resources, which allows adding additional templates and resources without creating a theme. This is useful for custom authenticators that require additional pages to be added to the authentication flow.
-
-We have also added support to override the theme for specific clients. If that is not adequate for your needs, then there is also a new Theme Selector SPI that allows you to implement custom logic to select the theme.
-
-= Instagram Identity Provider
-
-We have added support to login with Instagram. Thanks to https://github.com/hguerrero[hguerrero] for the contribution.
-
-= Search by User ID in Admin Console
-
-To search for a user by id in the admin console you previously had to edit the URL. It is now possible to search
-directly in the user search field.
-
-= Adapters
-
-== Spring Boot 2
-
-We now have support for Spring Boot 2.
-
-== Fuse 7
-
-We now have support for Fuse 7.
-
-== JavaScript - Native Promise Support
-
-The JavaScript adapter now supports native promises. It retains support for the old style promises as well.
-Both can be used interchangeably.
-
-== JavaScript - Cordova Options
-
-It is now possible to pass Cordova-specific options to login and other methods in the JavaScript adapter.
-Thanks to https://github.com/looorent[loorent] for the contribution.
diff --git a/release_notes/topics/4_0_0_final.adoc b/release_notes/topics/4_0_0_final.adoc
deleted file mode 100644
index 9606955f9..000000000
--- a/release_notes/topics/4_0_0_final.adoc
+++ /dev/null
@@ -1,88 +0,0 @@
-= Client Scopes and support for OAuth 2 scope parameter
-
-We added support for Client Scopes, which replaces Client Templates. Client Scopes are a more flexible approach and also provides
-better support for the OAuth `scope` parameter.
-
-There are changes related to Client Scopes to the consent screen. The list on the consent screen is now linked to client scopes
-instead of protocol mappers and roles.
-
-See the documentation and migration guide for more details.
-
-= OAuth 2 Certificate Bound Access Tokens
-
-We now have a partial implementation of the specification
-https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-08[OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens] .
-More accurately we have support for the Certificate Bound Access Tokens. If your confidential client is able to use 2-way SSL,
-{project_name} will be able to add the hash of the client certificate into the tokens issued for the client. At this moment,
-it's just the {project_name} itself, which verifies the token hashes (for example during `refresh token` requests).
-We plan to add support to adapters as well. We also plan to add support for Mutual TLS Client Authentication.
-
-Thanks to https://github.com/tnorimat[tnorimat] for the contribution.
-
-= Authorization Services
-
-== UMA 2.0 Support
-
-UMA 2.0 is now supported for Authorization Services. Check the documentation for more details
-if you are coming from previous versions of {project_name}.
-
-=== User-Managed Access through the {project_name} Account Service
-
-Now end-users are able to manage their resources and the permissions associated with them through the {project_name} Account Service.
-From there, resource owners can now check their resources, share resources with another users as well approve requests from other users.
-
-=== Asynchronous Authorization Flow
-
-When using UMA, client applications can now choose whether or not an authorization request should start an authorization flow
-to ask for the resource owner approval. This functionality allows applications to ask for resource owner
-approval when trying to access one of his resources on behalf of another user.
-
-=== User-Managed Permission API
-
-Resource servers are now capable of associating additional policies to resources owned by a particular user. The new API provides
-operations to manage these permissions using different policy types such as role, group, user, client or a condition using JavaScript.
-
-== Pushed Claims
-
-Clients applications are now able to send arbitrary claims to {project_name} along with an authorization request in order to
-evaluate permissions based on these claims. This is a very handy addition when access
-should be granted (or denied) in the scope of a specific transaction or based on information about the runtime.
-
-== Resource Attributes
-
-It is now possible to associated attributes with resources protected by {project_name} and use these same attributes to evaluate permissions
-from your policies.
-
-== Policy enforcer now accepts regular access tokens
-
-In some situations, you may want to just send regular access tokens to a resource server but still be able to enforce policies on these resources.
-
-One of the main changes introduced by this release is that you are no longer required to exchange access tokens with RPTs in
-order to access resources protected by a resource server (when not using UMA). Depending on how the policy enforcer is configured on the resource server side, you can just send regular
-access tokens as a bearer token and permissions will still be enforced.
-
-== Policy enforcer can now load resources from the server on-demand
-
-Until now, when deploying an application configured with a `policy-enforcer`, the policy enforcer would either load all protected paths
-from the server or just map these paths from the adapter configuration. Users can now decide to load paths on-demand from the server and avoid
-map these resources in the adapter configuration. Depending on how many protected resources you have this functionality can also improve the time to
-deploy an application.
-
-== Policy enforcer now supports configuring the resource cache
-
-In order to avoid unnecessary hits to the server, the policy enforcer caches the mapping between protected resources and their corresponding paths
-in your application. Users can now configure the behaviour of the cache or even completely disable it.
-
-== Claim Information Points
-
-The `policy-enforcer` definition on the adapters (`keycloak.json`) was also updated to support the concept of pushed claims. There
-you have the concept of a `claim-information-point` which can be set to push claims from different sources such as the HTTP request or even
-from an external HTTP service.
-
-== Improvements to the Evaluation API
-
-The Evaluation API used to implement policies in {project_name}, especially JavaScript and Drools policies, provides now methods to:
-
-* Access information from the current realm such as check for user roles, groups and attributes
-* Push back arbitrary claims to the resource server in order to provide additional information on how a specific permissions should
-be enforced
\ No newline at end of file
diff --git a/release_notes/topics/4_1_0_final.adoc b/release_notes/topics/4_1_0_final.adoc
deleted file mode 100644
index 8e68ada79..000000000
--- a/release_notes/topics/4_1_0_final.adoc
+++ /dev/null
@@ -1,3 +0,0 @@
-= Making Spring Boot 2 the default starter
-
-Starting with release 4.1, the Spring Boot starter will be based on the Spring Boot 2 adapter. If you are using an older Spring Boot version, the keycloak-legacy-spring-boot-starter is available.
\ No newline at end of file
diff --git a/release_notes/topics/4_2_0_final.adoc b/release_notes/topics/4_2_0_final.adoc
deleted file mode 100644
index 3f4b5427e..000000000
--- a/release_notes/topics/4_2_0_final.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-= Browser tab support for Cordova
-
-We now have support for using browser tab and universal links in the JavaScript adapter for Cordova. This enables SSO
-between multiple applications as well as increases security.
-
-Thanks to https://github.com/gtudan[gtudan] for the contribution.
-
-
-= SAML adapter multitenancy support
-
-The SAML adapter can support multi-tenancy now just like the built-in adapter for OpenID Connect.
-
-
-= An option to create claims with dots (.) in them
-
-In previous versions, it was not possible to create claims in the token using a claim name containing a dot (.) character. Now it is
-possible to escape the dot character in the configuration, so a claim name with the dot character can be used.
\ No newline at end of file
diff --git a/release_notes/topics/4_3_0_final.adoc b/release_notes/topics/4_3_0_final.adoc
deleted file mode 100644
index fb8c65dcc..000000000
--- a/release_notes/topics/4_3_0_final.adoc
+++ /dev/null
@@ -1,59 +0,0 @@
-= Hostname SPI
-
-The hostname SPI introduces a more flexible way to configure the hostname for {project_name}. There are two
-built-in providers. The first is request, which uses the request headers to determine the hostname. The second
-is fixed, which allows configuring a fixed hostname. The latter makes sure that only valid hostnames can be
-used and also allows internal applications to invoke {project_name} through an alternative URL.
-
-For more details refer to the threat mitigation section in the link:{adminguide_link}[{adminguide_name}].
-
-= X509 Client Authenticator
-
-The newly added Client Authenticator uses X509 Client Certificates and Mutual TLS to secure a connection from the client. In addition to that
-the Keycloak Server validates Subject DN field of the client's certificate.
-
-= Performance improvements to Authorization Services
-
-For this release, we improved policy evaluation performance across the board, increasing reliability and throughput. The main
-changes we did were related with trying to optimize the policy evaluation path by avoiding unnecessary flows and collect decisions
-as soon as they happen. We also introduced a policy decision cache on a per-request basis, avoiding redundant decisions from policies
-previously evaluated.
-
-We are also working on other layers of cache which should give a much better experience. See https://issues.redhat.com/browse/KEYCLOAK-7952[KEYCLOAK-7952].
-
-= Choosing the response mode when obtaining permissions from the server
-
-In previous versions, permissions were always returned from the server using standard OAuth2 response, containing the access and refresh tokens. In this release,
-clients can use a `response_mode` parameter to specify how the server should respond to an authorization request. This parameter accepts two values:
-
-* `decision`
-+
-Indicating that responses should only contain a flag indicating whether or not permissions were granted by the server. Otherwise a `403` HTTP status code is returned.
-+
-* `permissions`
-+
-Indicating that a response should contain every single permission granted by the server using a JSON format.
-
-= NodeJS Policy Enforcer
-
-The https://github.com/keycloak/keycloak-nodejs-connect[keycloak-nodejs-connect], an adapter for NodeJS, now supports constructs to protect
-resources based on decisions taken from the server. The new construct allows users to protect their resources using fine-grained permissions as follows:
-
-```js
-app.get('/protected/resource', keycloak.enforcer('resource:view'), function (req, res) {
- res.json({message: 'access granted'});
-});
-```
-
-= Support hosted domain for Google logins
-
-Login with Google now supports the `hd` parameter to restrict Google logins to a specific hosted domain at Google. When
-this is specified in the identity provider any login from a different domain is rejected.
-
-Thanks to https://github.com/brushmate[brushmate] for the contribution.
-
-= Escape unsafe tags in HTML output
-
-Most HTML output is already escaped for HTML tags, but there are some places where HTML tags are permitted.
-These are only where admin access is needed to update the value. Even though it would require admin access to update such
-fields we have added an extra layer of defence and are now escaping unsafe elements like `
-
-
-
-
-
-