Added guidance for default policies and an example 'empty' policy showing how to grant access to an image server without providing permisisons.

security.authorization.md

@@ -73,7 +73,7 @@ Series ACL management:
 
 **Note**: User and Group policies share nearly identical request/response structures, differing only in that user policies use a User key (containing the Sonador user UID), whereas group policies use a Group key (with the group UID).
 
-#### Guidance for Developers and Users
+#### Guidance for Developers
 When creating integrations or writing code against these APIs, consider:
 * **Precision**: Always prefer local, resource-specific policies for better security. Use global policies sparingly and cautiously.
 * **API Compatibility**: The global and local APIs use slightly different URL structures and JSON schemas due to their placement within different application contexts (Sonador web app vs. Orthanc cloud plugin). Pay close attention to these syntactic differences when building integrations or automation scripts.
@@ -83,6 +83,20 @@ This approach ensures accurate, secure, and compliant data-sharing scenarios tai
 
 **Resource requests are processed by Sonador and take into account first global policies and then local policies.** Requests are sent from Orthanc to the Sonador authorization API (an implementation of the Orthanc advanced authorization service API) when a user attempts to request a resource from Orthanc. If a policy is found which matches the requested resource, Sonador grants access; if not the request is denied and Orthanc will return a 403 error.
 
+**For a user within a group to gain access to an imaging server, they must be associated with at least one global resource policy tied to that server.** As a best practice, it's generally recommended to create an "empty" global policy with the pattern `resource=*`, explicitly setting all permissions to false. This approach grants minimal baseline access necessary for server connection without unintentionally authorizing broad data access. Blanket policies that provide wide-ranging permissions (e.g., full read or write access) should typically be reserved exclusively for system-level users or administrative tasks. Most data access policies should instead be defined as local Orthanc policies attached to specific resources (patients, studies, series), ensuring tighter security and better control.
+
+Example blank policy:
+
+```json
+{
+  "group": 3,
+  "resource": "*"
+}
+```
+
+_Permissions left blank will default to `false`._
+
+
 #### API Structure
 **Global policies** are associated with an imaging server and group and are sent to the Sonador web application. Requests have the following general schema: