-
Notifications
You must be signed in to change notification settings - Fork 43
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.
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
ADR for restricting access to content by organisation #2232
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,84 @@ | ||
# ADR011 - Restricting access to content by organisation | ||
|
||
Date 2024-XX-XX | ||
|
||
## Status | ||
|
||
Draft | ||
|
||
## Context | ||
|
||
Historically, access to Mainstream Publisher has been restricted to GDS content designers. There is a desire to open access up to content designers from other government departments, so that they can manage their own content in Mainstream Publisher, without them having access to all content. | ||
|
||
In order to achieve this, a mechanism needs to be implemented whereby access to Mainstream Publisher does not automatically grant access to all content within Mainstream Publisher. | ||
|
||
A limited number of content designers from HMRC have already been given access, and are being trusted not to edit content that they shouldn't. Before this access can be further widened, it's desired to have some form of restrictions in place within Mainstream Publisher. | ||
|
||
There is a wider piece of work looking at access and permissions across the Publishing estate, but access to Mainstream Publisher needs to be widened before that work will complete. | ||
|
||
Therefore, we need an interim solution that restricts access within Mainstream Publisher to a subset of the content held within it, acknowledging that how this works might change longer-term. | ||
|
||
In the immediate term, the requirement is to limit access, for non-GDS content designers, to that content which is managed by their own department. Signon does provide the organisation that a user belongs to, which Mainstream Publisher will use in order to make authorisation decisions when attempting to view and edit content. There are some cases where a content item would need to be managed by content designers from multiple organisations. | ||
|
||
For now the access rules can be binary, with users either given full access to a piece of content (view/edit/publish), or no access. | ||
|
||
This ADS focuses on the technical solution to restrict access, using the data supplied by Signon about the user (i.e. the organisation to which they belong). | ||
|
||
### Option 1: Use the primary publishing organisation | ||
|
||
All content that is published on GOV.UK by Mainstream Publisher has a `primary_publishing_organisation` association set on it. This is currently always set to GDS at the point of publishing the content, but we could store this association as part of the content item in Mainstream Publisher, and set it to the relevant organisation. When determining whether a user should have access to a content item, it's Primary Publishing Organisation field would be compared with the user's organisation. | ||
|
||
#### Disadvantages | ||
|
||
- The Primary Publishing Organisation association already exists for a purpose, and is not intended as a means of access control. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we specify this purpose? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not really sure what this association's purpose is! According to the publishing API content schema it's "The organisation that published the page" (it also goes on to say that it's only set by Whitehall, which is clearly not true!), but why it exists, and what other parts of the system might be using it, I don't know. If you have more knowledge about it, then I'm happy to update based on that. |
||
- A content item can only have a single Primary Publishing Organisation, so this solution would not enable content designers from different organisations to be able to see and edit the same content item. | ||
- Due to Primary Publishing Organisation being a one-to-one association with a content item, it doesn't really help us on the journey to supporting multiple-organisation access to a content item. | ||
|
||
#### Advantages | ||
|
||
- The Primary Publishing Organisation field is an existing field, and so this solution does not require introducing any new fields/concepts (though it is potentially changing the meaning of the association slightly by using it for access control). | ||
|
||
### Questions | ||
|
||
The Primary Publishing Organisation data flows through the Publishing API and into the content stored in the Content Store. Does it make sense to be changing this data to support access control within Mainstream Publisher (it introduces a level of coupling between two related, but not identical, concepts). | ||
|
||
### Option 2: Introducing a new field on content items | ||
|
||
A new field could be introduced to content items within Mainstream Publisher to store the organisation(s) whose members should have access to that content item. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe we could add a note to refer to slack thread pointing that even though this solution may be confusing for future devs, hardcoded PPO is currently not exposed to users, so they would not be aware of this potential data duplication. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've added some text. |
||
|
||
#### Disadvantages | ||
|
||
- This field will potentially be duplicating the Primary Publishing Organisation association (if there were to become a desire to have that field also reflect this change in which organisation is managing the content item), or tagging information. | ||
- This solution introduces a new field/concept that is not common to other publishing applications (though Manuals Publisher does to something similar to filter the data that is showed to users). | ||
|
||
#### Advantages | ||
|
||
- Since this is a new field, it can be made to store a one-to-many association, granting multiple organisations access to a content item. | ||
- This new field will be solely for the purposes of authorisation, it avoids conflating different concerns in a single field/association. | ||
- This field would not be propagated through the Publishing API and would be contained within Mainstream Publisher, eliminating any potential downstream effects. | ||
|
||
### Option 3: Use the organisation tagging data to manage permissions | ||
|
||
Content Items are "tagged" to organisations (on the "Tagging" tab when viewing an Edition). This tagging is done so that a Content Item will show up when a search is carried out on GOV.UK, filtered to certain organisations. | ||
|
||
This option would use that same tagging data to restrict access to a Content Item (i.e. tagging an organisation to a Content Item would grant access to it for users from that organisation). | ||
|
||
#### Disadvantages | ||
|
||
- Organisation tagging is not intended for limiting access within Mainstream Publisher; using it for such purposes could cause confusion. | ||
- It couples two separate concepts together—just because a Content Item is tagged to an organisation doesn't necessarily mean that content designers from that organisation should be able to see and edit that content. | ||
- Tagging data is not stored within Mainstream Publisher, but by the Publishing API. Tagging data for a content item is fetched when that Content Item is viewed—using it to restrict access from even seeing that content item (e.g. on the Publications page) would involve having to fetch the tagging information for all content items first (which would take far too long), or "back-porting" that data from Publishing API into Mainstream Publisher and then having a mechanism in place to keep that data in sync (which would be a significant piece of work). | ||
|
||
#### Advantages | ||
|
||
- The tagging data already exists to associate organisations with Content Items. | ||
|
||
## Decision | ||
|
||
We will implement [option 2](#option-2-introducing-a-new-field-on-content-items). This keeps the field focused on the purpose of authorisation, and also limits the impact to be purely within Mainstream Publisher. | ||
|
||
GDS content designers (i.e. those with the "Editor" permission in Signon) will continue to have full access to all Content Items in Mainstream Publisher. | ||
|
||
## Consequences | ||
|
||
The data for this new field will need to be populated somehow. This will likely be done by creating a rake task to populate the field. The actual data to be used will need to be sourced, for example, by using the existing tagging association to organisations. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should probably differentiate here between populating this field for existing content and populating it for the new content in the future. The latter is still being discussed with the option of setting it in the UI being most probable. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've added some text to explain this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add a note reg ongoing discussion about access to create new content - something yet to be decided about, but worth to reference it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some text to address this.