|
1 | 1 | # Access Control
|
2 | 2 |
|
3 |
| -By default, data sets in Synapse are private to your user account, but they can easily be shared with specific users, groups, or the public. |
| 3 | +Access Control Lists (ACLs) in Synapse are the foundation of data security and sharing. They determine who can access your data and what actions they can perform. By default, all entities in Synapse are private to your user account, but they can be easily shared with specific users, groups, or made publicly accessible. |
4 | 4 |
|
5 |
| -See: |
| 5 | +## Core Concepts |
6 | 6 |
|
| 7 | +### Access Control Lists (ACLs) |
| 8 | +An ACL is a set of permissions that define what actions specific users or groups can perform on a Synapse entity. Each ACL entry specifies: |
| 9 | + |
| 10 | +- **Principal**: The user, team, or special group being granted permissions |
| 11 | +- **Permissions**: The specific actions they can perform |
| 12 | + |
| 13 | +### Benefactors and Inheritance |
| 14 | +Every entity in Synapse has a **benefactor** - the entity from which it inherits its permissions: |
| 15 | + |
| 16 | +- **Default Inheritance**: New entities inherit permissions from their parent container |
| 17 | +- **Local ACLs**: When you create custom sharing settings, the entity becomes its own benefactor |
| 18 | +- **Permission Resolution**: Synapse traverses up the hierarchy to find the benefactor with ACL settings |
| 19 | + |
| 20 | +### Permission Types |
| 21 | +Synapse supports several permission types that can be combined: |
| 22 | + |
| 23 | +- **READ**: View entity metadata and basic information |
| 24 | +- **DOWNLOAD**: Download files and data (requires READ) |
| 25 | +- **UPDATE**: Modify entity metadata and upload new file versions |
| 26 | +- **CREATE**: Create new entities within containers |
| 27 | +- **DELETE**: Delete entities |
| 28 | +- **CHANGE_PERMISSIONS**: Modify ACL permissions |
| 29 | +- **CHANGE_SETTINGS**: Modify entity settings |
| 30 | +- **MODERATE**: Moderate forum discussions (for projects) |
| 31 | + |
| 32 | +Other synapse items like `Submission` and `Evaluation` support different permission types not covered in this document. |
| 33 | + |
| 34 | +### Special Principal IDs |
| 35 | +Synapse provides special principals for common sharing scenarios: |
| 36 | + |
| 37 | +- **273948**: All authenticated Synapse users |
| 38 | +- **273949**: Public access (anyone on the internet) |
| 39 | +- **Specific User ID**: Individual Synapse users (e.g., #######) |
| 40 | +- **Team ID**: Synapse teams for group-based permissions (e.g., #######) |
| 41 | + |
| 42 | +## Common Use Cases |
| 43 | + |
| 44 | +### Research Collaboration |
| 45 | +- **Internal Teams**: Grant READ/DOWNLOAD to collaborators |
| 46 | +- **Data Owners**: Maintain full permissions (including UPDATE/DELETE) |
| 47 | +- **Public Data**: Use public principal (273949) for open datasets |
| 48 | + |
| 49 | +### Hierarchical Access Control |
| 50 | +- **Project Level**: Set broad permissions for the entire project |
| 51 | +- **Folder Level**: Override with more restrictive permissions for sensitive data |
| 52 | +- **File Level**: Fine-grained control for specific datasets |
| 53 | + |
| 54 | +### Data Governance |
| 55 | +- **Sensitive Data**: Create local ACLs with restricted access |
| 56 | +- **Compliance**: Use teams for role-based access control |
| 57 | +- **Auditing**: Use `list_acl()` to review permission structures |
| 58 | + |
| 59 | +## Best Practices |
| 60 | + |
| 61 | +1. **Use Inheritance**: Leverage the default inheritance model when possible for easier management |
| 62 | +2. **Minimal Local ACLs**: Only create custom ACLs when you need different permissions than the parent |
| 63 | +3. **Team-Based Permissions**: Use Synapse teams for group permissions rather than individual users |
| 64 | +4. **Regular Audits**: Periodically review ACLs using `list_acl()` to ensure appropriate access |
| 65 | +5. **Dry Run Testing**: Use `dry_run=True` when deleting permissions to preview changes |
| 66 | +6. **Documentation**: Document your permission structure for team understanding |
| 67 | + |
| 68 | +## Security Considerations |
| 69 | + |
| 70 | +- **Principle of Least Privilege**: Grant only the minimum permissions necessary |
| 71 | +- **Regular Reviews**: Audit permissions regularly, especially for sensitive data |
| 72 | +- **Team Management**: Use teams to simplify permission management and reduce errors |
| 73 | +- **Public Access**: Be cautious when granting public access (273949) to ensure data is appropriate for public consumption |
| 74 | + |
| 75 | +## Learn More |
| 76 | + |
| 77 | +For hands-on experience with ACL management, follow the comprehensive [Sharing Settings Tutorial](../tutorials/python/sharing_settings.md), which demonstrates all aspects of permission management using real examples. |
| 78 | + |
| 79 | +## API References |
| 80 | + |
| 81 | +### Object-Oriented Models |
| 82 | +- [get_permissions()][synapseclient.models.protocols.access_control_protocol.AccessControllableSynchronousProtocol.get_permissions] |
| 83 | +- [get_acl()][synapseclient.models.protocols.access_control_protocol.AccessControllableSynchronousProtocol.get_acl] |
| 84 | +- [set_permissions()][synapseclient.models.protocols.access_control_protocol.AccessControllableSynchronousProtocol.set_permissions] |
| 85 | +- [list_acl()][synapseclient.models.protocols.access_control_protocol.AccessControllableSynchronousProtocol.list_acl] |
| 86 | +- [delete_permissions()][synapseclient.models.protocols.access_control_protocol.AccessControllableSynchronousProtocol.delete_permissions] |
| 87 | + |
| 88 | +### Legacy API Methods |
7 | 89 | - [synapseclient.Synapse.getPermissions][]
|
8 | 90 | - [synapseclient.Synapse.setPermissions][]
|
0 commit comments