867eff3e5d
* [KEYCLOAK-3169] - Updating authz services doc * [KEYCLOAK-3169] - Section about changes to user account service * [KEYCLOAK-3169] - Removing UMA 1.0 references * [KEYCLOAK-3169] - RH-SSO images * [KEYCLOAK-3169] - Updating Keycloak images * [KEYCLOAK-3169] - Review * [KEYCLOAK-3169] - Review
81 lines
No EOL
2.9 KiB
Text
81 lines
No EOL
2.9 KiB
Text
[[_policy_js]]
|
|
= JavaScript-Based Policy
|
|
|
|
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 dropdown list in the upper right corner of the policy listing.
|
|
|
|
.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 <<_policy_logic, Logic>> of this policy to apply after the other conditions have been evaluated.
|
|
|
|
== Examples
|
|
|
|
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
|
|
var context = $evaluation.getContext();
|
|
var contextAttributes = context.getAttributes();
|
|
|
|
if (contextAttributes.containsValue('kc.client.network.ip_address', '127.0.0.1')) {
|
|
$evaluation.grant();
|
|
}
|
|
```
|
|
|
|
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
|
|
var context = $evaluation.getContext();
|
|
var 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
|
|
var context = $evaluation.getContext();
|
|
var identity = context.getIdentity();
|
|
|
|
if (identity.hasClientRole('my-client', 'my-client-role')) {
|
|
$evaluation.grant();
|
|
}
|
|
```
|
|
|
|
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
|
|
var context = $evaluation.getContext();
|
|
var identity = context.getIdentity();
|
|
var attributes = identity.getAttributes();
|
|
var 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>>. |