From ed36367f13b6eda7b8cc9cb3fd7ef832eccc28fa Mon Sep 17 00:00:00 2001 From: Pedro Igor Date: Wed, 20 Apr 2022 09:25:22 -0300 Subject: [PATCH] Removing upload scripts features (#1462) Closes #1461 --- .../topics/hello-world-deploy.adoc | 22 +++---- .../topics/policy-js-policy.adoc | 29 +-------- .../topics/service-protection-policy-api.adoc | 2 +- release_notes/topics/18_0_0.adoc | 13 ++++ upgrading/topics/keycloak/changes-18_0_0.adoc | 60 +++++++++++++------ 5 files changed, 64 insertions(+), 62 deletions(-) diff --git a/authorization_services/topics/hello-world-deploy.adoc b/authorization_services/topics/hello-world-deploy.adoc index 1144f08b6c..1c553d41ff 100644 --- a/authorization_services/topics/hello-world-deploy.adoc +++ b/authorization_services/topics/hello-world-deploy.adoc @@ -100,16 +100,12 @@ image:{project_images}/getting-started/hello-world/main-page.png[alt="Hello Worl 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. -. Change the default permissions and policies and test how your application responds. You could also create new policies using the different policy types provided by {project_name}. -+ -You have many options to test this application. For example, you can change the default policy by clicking the *Authorization* tab for the client, then *Policies* tab, then click the *Default Policy* in the list to allow you to change it as follows: -+ -```js -// The default value is $evaluation.grant(), -// let's see what happens when we change it to $evaluation.deny() -$evaluation.deny(); +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. + @@ -117,10 +113,6 @@ You can no longer access the application. + image:{project_images}/getting-started/hello-world/access-denied-page.png[alt="Access Denied page"] -. Correct that problem by changing the *Logic* to *Negative* using the item list below the policy code text area. -+ -That re-enables access to the application as we are negating the result of that policy, which is by default denying all requests for access. Again, before testing this change, be sure to log out and log in again. - [role="_additional-resources"] .Additional resources * <<_policy_overview, Policy types>> @@ -129,8 +121,8 @@ That re-enables access to the application as we are negating the result of that 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 such as <<_policy_js, JavaScript-based>>, and associate these policies with the `Default Permission`. +* 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"] diff --git a/authorization_services/topics/policy-js-policy.adoc b/authorization_services/topics/policy-js-policy.adoc index 629fd7b1d0..e664c97fc2 100644 --- a/authorization_services/topics/policy-js-policy.adoc +++ b/authorization_services/topics/policy-js-policy.adoc @@ -10,34 +10,7 @@ supported by {project_name}, and provides flexibility to write any policy based 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}]. If you still want to use the -{project_name} Administration Console to manage your JS policies you should enable the `Upload Scripts` feature. - -.Add JavaScript policy -image:{project_images}/policy/create-js.png[alt="Add JavaScript 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. -+ -* *Code* -+ -The JavaScript code providing the conditions for 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>> +the server as described in link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}]. == Creating a JS policy from a deployed JAR file diff --git a/authorization_services/topics/service-protection-policy-api.adoc b/authorization_services/topics/service-protection-policy-api.adoc index 43062fa8c1..91902a0593 100644 --- a/authorization_services/topics/service-protection-policy-api.adoc +++ b/authorization_services/topics/service-protection-policy-api.adoc @@ -92,7 +92,7 @@ curl -X POST \ "name": "Any people manager", "description": "Allow access to any people manager", "scopes": ["read"], - "condition": "if (isPeopleManager()) {$evaluation.grant()}" + "condition": "my-deployed-script.js" }' ---- diff --git a/release_notes/topics/18_0_0.adoc b/release_notes/topics/18_0_0.adoc index c2561ed014..bf757ce549 100644 --- a/release_notes/topics/18_0_0.adoc +++ b/release_notes/topics/18_0_0.adoc @@ -60,6 +60,19 @@ 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. diff --git a/upgrading/topics/keycloak/changes-18_0_0.adoc b/upgrading/topics/keycloak/changes-18_0_0.adoc index 22a56a7ab5..4d36a7ab74 100644 --- a/upgrading/topics/keycloak/changes-18_0_0.adoc +++ b/upgrading/topics/keycloak/changes-18_0_0.adoc @@ -71,6 +71,30 @@ With this configuration, you can still use the format with the `redirect_uri` pa WARNING: The backwards compatibility switch will be removed in some future version - probably Keycloak 21. You are encouraged to update your clients as soon as possible as described above rather than rely on this switch. += Removal of the `upload-scripts` feature + +Previous versions of {project_name} had supported managing JavaScript code through the management interfaces like the administrations console and REST API. Starting from this version +this is no longer possible, and you should now deploy your scripts to the server in order to configure the following providers: + +* OpenID Connect Script Mapper +* Script Authenticator (Authentication Execution) +* JavaScript Policies + +More details about how to deploy scripts to the server are available in the https://www.keycloak.org/docs/latest/server_development/#_script_providers[documentation]. Note that to use scripts, you are still +required to enable the `scripts` technology preview feature. + +``` +kc.[sh|bat] start --auto-build --features=preview +``` + +When deploying scripts, the server is going to automatically create their corresponding providers so that you can select them when configuring authentication flows, mappers, and authorization policies. + +In general, the steps to update your realms are the following: + +* Before upgrading, remove any script provider you are using. +* After the upgrade, deploy your scripts following the instructions in the https://www.keycloak.org/docs/latest/server_development/#_script_providers[documentation]. +* Update your authentication flows, mappers, and the client authorization settings to use the providers created from the scripts deployed to the server. + = Account console Patternfly upgrade The Patternfly (PF) React libraries have been updated updated, `@patternfly/react-core` from v3.153.3 to v4.147.0, `@patternfly/react-icons` from v3.15.16 to v 4.11.8, and `@patternfly/react-styles` from v3.7.14 to v4.11.8. Several minor UI updates were made to bring the account console into alignment with PF design standards. @@ -80,44 +104,44 @@ Custom developed account UIs might not be compatible with these updates due to t Resources: - [Patternfly docs](https://www.patternfly.org) - + Components known to have breaking changes: - Alert - + - `action` prop changed to `actionClose` - + - Expandable - + - renamed to `ExpandableSection` - + - Title - + - size attr now uses `TitleSizes` - + - DataListContent - + - `noPadding` changed to `hasNoPadding` - + - Grid, Stack, Level, Gallery - + - `gutter` attr changed to `hasGutter` - + - Modal - + - sizing control changed from, e.g. `isLarge`, to use `ModalVariant`, e.g. `variant={ModalVariant.large}` - + - Select - + - `ariaLabelTypeAhead` to `typeAheadAriaLabel` - + - `isExpanded` to `isOpen` - + - `ariaLabelledBy` to `aria-labelledby` - + - DataListContent - + - `noPadding` to `hasNoPadding` = Quarkus distribution: Split metrics-enabled option into health-enabled and metrics-enabled