1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
---
stage: Govern
group: Authentication and Authorization
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Authorization
## Where should permissions be checked?
When deciding where to check permissions, apply defense-in-depth by implementing multiple checks at
different layers. Starting with low-level layers, such as finders and services,
followed by high-level layers, such as GraphQL, public REST API, and controllers.
For more information, see [guidelines for reusing abstractions](../reusing_abstractions.md).
Protecting the same resources at many points means that if one layer of defense is compromised
or missing, customer data is still protected by the additional layers.
For more information on permissions, see the permissions section in the [secure coding guidelines](../secure_coding_guidelines.md#permissions).
### Considerations
Services or finders are appropriate locations because:
- Multiple endpoints share services or finders so downstream logic is more likely to be re-used.
- Sometimes authorization logic must be incorporated in DB queries to filter records.
- You should avoid permission checks at the display layer except to provide better UX,
and not as a security check. For example, showing and hiding non-data elements like buttons.
The downsides to defense-in-depth are:
- `DeclarativePolicy` rules are relatively performant, but conditions may perform database calls.
- Higher maintenance costs.
### Exceptions
Developers can choose to do authorization in only a single area after weighing
the risks and drawbacks for their specific case.
Prefer domain logic (services or finders) as the source of truth when making exceptions.
Logic, like backend worker logic, might not need authorization based on the current user.
If the service or finder's constructor does not expect `current_user`, then it typically does not
check permissions.
### Tips
If a class accepts `current_user`, then it may be responsible for authorization.
### Example: Adding a new API endpoint
By default, we authorize at the endpoint. Checking an existing ability may make sense; if not, then we probably need to add one.
As an aside, most endpoints can be cleanly categorized as a CRUD (create, read, update, destroy) action on a resource. The services and abilities follow suit, which is why many are named like `Projects::CreateService` or `:read_project`.
Say, for example, we extract the whole endpoint into a service. The `can?` check will now be in the service. Say the service reuses an existing finder, which we are modifying for our purposes. Should we make the finder check an ability?
- If the finder does not accept `current_user`, and therefore does not check permissions, then probably no.
- If the finder accepts `current_user`, and does not check permissions, then you should double-check other usages of the finder, and you might consider adding authorization.
- If the finder accepts `current_user`, and already checks permissions, then either we need to add our case, or the existing checks are appropriate.
|
