Skip to content

Minor tweaks to the CAP-level Authorization topic page #2568

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
qmacro wants to merge 4 commits into
base: main
Choose a base branch
from
+3 −3
Open

Minor tweaks to the CAP-level Authorization topic page #2568

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
8bacb20
Minor tweak to wording for auth
qmacro May 11, 2026
8b4fead
fix hyperlink title ref
qmacro May 11, 2026
e53c5ec
more accurate assessment of multi privilege example
qmacro May 11, 2026
9ba9b96
Merge branch 'main' into qmacro-patch-1
qmacro May 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions guides/security/authorization.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,7 +96,7 @@ service SomeService {

#### Events to Auto-Exposed Entities { #events-and-auto-expose}

In general, entities can be exposed in services in different ways: they can be **explicitly exposed** by the modeler (for example, by a projection), or they can be [**auto-exposed**](../../cds/cdl#auto-exposed-entities) by the CDS compiler for some reason.
In general, entities can be exposed in services in different ways: they can be **explicitly exposed** by the modeler (for example, by a projection), or they can be [**auto-exposed**](../../cds/cdl#auto-exposed-entities) by the CDS compiler in certain circumstances.
Access to auto-exposed entities needs to be controlled in a specific way. Consider the following example:

```cds
Expand Down Expand Up @@ -205,7 +205,7 @@ The following values are supported:

- The `to` property lists all [user roles](cap-users#roles) or [pseudo roles](cap-users#pseudo-roles) that the privilege applies to. Note that the `any` pseudo-role applies for all users and is the default if no value is provided.

- The `where`-clause can contain a Boolean expression in [CQL](../../cds/cql)-syntax that filters the instances that the event applies to. As it allows user values (name, attributes, etc.) and entity data as input, it's suitable for *dynamic authorizations based on the business domain*. Supported expressions and typical use cases are presented in [instance-based authorization](#instance-based-auth).
- The `where`-clause can contain a Boolean expression in [CQL](../../cds/cql)-syntax that filters the instances that the event applies to. As it allows user values (name, attributes, etc.) and entity data as input, it's suitable for *dynamic authorizations based on the business domain*. Supported expressions and typical use cases are presented in [instance-based access control](#instance-based-auth).

A privilege is met, if and only if **all properties are fulfilled** for the current request. In the following example, orders can only be read by an `Auditor` who meets `AuditBy` element of the instance:

Expand Down Expand Up @@ -245,7 +245,7 @@ entity Orders @(restrict: [
]) {/*...*/}
```

Here an `Auditor` user can read all orders with matching `country` or that they have created.
Here, users can read and write orders they've created, and `Auditor` users can read all orders with matching `country`.

> Annotations such as @requires or @readonly are just convenience shortcuts for @restrict, for example:
- `@requires: 'Viewer'` is equivalent to `@restrict: [{grant:'*', to: 'Viewer'}]`
Expand Down
Loading