docs: Improve documentation about authorizations

docs/feature-guide/authorization-accesses.md

@@ -1,10 +1,16 @@
 # Authorization accesses: How it works ?
 
+## General
+
 The authorization accesses list coming from [ResourceHeaderOIDC](../configuration//structure.md#resourceheaderoidc) are accesses matrix by group or email. If not set, authenticated users will be authorized (no group or email validation will be performed if `authorizationOPAServer` isn't set).
 
 Moreover, this is based on the "OR" principle. Another way to say it is: you are authorized as soon as 1 thing (email or group) is matching.
 
-The example below explain this in detail.
+To conclude, if you want to have a **AND** accesses list (following the example before, only Jean Dupont is authorized), you will have to change the authorization mechanism to [OPAServerAuthorization](../configuration/structure.md#opaserverauthorization) and check feature guide [here](./opa.md).
+
+## Examples
+
+### Group matching
 
 Example of authorization accesses configuration:
 
@@ -24,14 +30,101 @@ targets:
 
 We consider those users:
 
-- Jean Dupont with `group1` and `group2`
-- Astérix with `group1` and `group3`
-- Obélix with `group3`
+- Jean Dupont with `group1` and `group2` groups
+- Astérix with `group1` and `group3` groups
+- Obélix with `group3` group
 
 Accesses will be:
 
 - Jean Dupont: Ok because he is in `group1` (and `group2` but this one isn't matching the first)
 - Astérix: Ok because he is in `group1`
 - Obélix: Forbidden because he isn't in any of `group1` or `group2`
 
-To conclude, if you want to have a **AND** accesses list (following the example before, only Jean Dupont is authorized), you will have to change the authorization mechanism to [OPAServerAuthorization](../configuration/structure.md#opaserverauthorization) and check feature guide [here](./opa.md).
+### Group regex matching
+
+Example of authorization accesses configuration:
+
+```yaml
+targets:
+  target1:
+    resources:
+      - path: /*
+        provider: provider1
+        oidc:
+          authorizationAccesses:
+            - group: valid.*
+              regex: true
+     bucket:
+       ...
+```
+
+We consider those users:
+
+- Jean Dupont with `valid1` and `valid2` groups
+- Astérix with `valid1` and `group3` groups
+- Obélix with `group3` group
+
+Accesses will be:
+
+- Jean Dupont: Ok because he is in `valid1` and `valid2`
+- Astérix: Ok because he is in `valid1`
+- Obélix: Forbidden because he isn't in any of `valid1` or `valid2`
+
+### Email matching
+
+Example of authorization accesses configuration:
+
+```yaml
+targets:
+  target1:
+    resources:
+      - path: /*
+        provider: provider1
+        oidc:
+          authorizationAccesses:
+            - email: [email protected]
+     bucket:
+       ...
+```
+
+We consider those users:
+
+- Jean Dupont with `[email protected]` email
+- Astérix with `[email protected]` email
+- Obélix with `[email protected]` email
+
+Accesses will be:
+
+- Jean Dupont: authorized
+- Astérix: forbidden
+- Obélix: forbidden
+
+### Email regex matching
+
+Example of authorization accesses configuration:
+
+```yaml
+targets:
+  target1:
+    resources:
+      - path: /*
+        provider: provider1
+        oidc:
+          authorizationAccesses:
+            - email: .*@fake.com
+              regex: true
+     bucket:
+       ...
+```
+
+We consider those users:
+
+- Jean Dupont with `[email protected]` email
+- Astérix with `[email protected]` email
+- Obélix with `[email protected]` email
+
+Accesses will be:
+
+- Jean Dupont: authorized
+- Astérix: authorized
+- Obélix: forbidden