Description
Certain apps require the ability to store and interact with data elements that should be hidden or otherwise restricted from the active user. The primary use case is to provide the receiving system and case owner with enough information to answer the case. Some of that information may be information not available to the active user, but available to the service owner owning the service.
The app should be able to create these data elements without the user gaining access to read the content.
Proposed implementation
With the current app authorization infrastructure, the app itself does not have an identity. For this reason, we cannot allow the app to read back the data of sensitive data elements without an appropriate token. Should the app require to read this data after initially writing it, an org-token (via Maskinporten) will be required.
- Create new properties for
Storage.DataType:
ActionRequiredToRead: An optional user-action that is required to read (get) data elements of this type. In addition to instance.read, which always requiredActionRequiredToWrite: An optional user-action that is required to write (post/put/del) data elements of this type. In addition to instance.write, which is always required
- The new properties are specified in
applicationmetadata.json along with the existing configuration in the dataTypes section
- The relevant user-actions are assigned to matching users in
policy.xml
App.DataController and Storage.DataController adds the following auth checks:
- Get: Requires
ActionRequiredToRead
- Post/put/patch/del: Required
ActionRequiredToWrite
- Every time the app returns a list of data elements, it should filter out items the current user does have read access to. This filtration will occur in the following general areas:
- Instance endpoint
Process endpoint- Datacontroller/Patch endpoints
- This filtration will incur additional calls to authorization, in order to determine if the user can read objects of certain types. However, these calls will only need to be performed if data elements of restricted types are found for a given task
- The filtration of data elements happens in the
App not in Storage, so the element IDs are more readily accessible for backend hooks (validators, etc) should they need to read this data.
- However, should the app need to read a restricted data element outside of an appropriate user context, an org-token must be generated with the
IMaskinportenClient to be used for this purpose
- This will come with additional setup requirements for the app developer
- Because of the abovemention filtration, the frontend code does not need to be adjusted to support this feature
Notes/questions
The Altinn Receipt app runs queries directly to Storage, which will in turn return a list of unfiltered data elements. If any of these elements are restricted in a way that prohibits the current user from reading them, how does the app respond or otherwise present this to the user? Should we implement filtering in this app as well?
Update: The Altinn Receipt app only queries the instance object for a given instance, which contains metadata for all data elements. This includes sensitive data elements. However, it only displays data elements without appLogic, and even then only provides a list the user may click to view the attachment.
The mere existence of a sensitive data element is not a secret, and the Storage service will continue to gatekeep read-access to these elements regardless of which front-end app is used.
In summary: This seems like non-issue from my perspective.
Affected libs and services
Description
Certain apps require the ability to store and interact with data elements that should be hidden or otherwise restricted from the active user. The primary use case is to provide the receiving system and case owner with enough information to answer the case. Some of that information may be information not available to the active user, but available to the service owner owning the service.
The app should be able to create these data elements without the user gaining access to read the content.
Proposed implementation
With the current app authorization infrastructure, the app itself does not have an identity. For this reason, we cannot allow the app to read back the data of sensitive data elements without an appropriate token. Should the app require to read this data after initially writing it, an org-token (via Maskinporten) will be required.
Storage.DataType:ActionRequiredToRead: An optional user-action that is required to read (get) data elements of this type. In addition toinstance.read, which always requiredActionRequiredToWrite: An optional user-action that is required to write (post/put/del) data elements of this type. In addition toinstance.write, which is always requiredapplicationmetadata.jsonalong with the existing configuration in thedataTypessectionpolicy.xmlApp.DataControllerandStorage.DataControlleradds the following auth checks:ActionRequiredToReadActionRequiredToWriteProcess endpointAppnot inStorage, so the element IDs are more readily accessible for backend hooks (validators, etc) should they need to read this data.IMaskinportenClientto be used for this purposeNotes/questions
The Altinn Receipt app runs queries directly to Storage, which will in turn return a list of unfiltered data elements. If any of these elements are restricted in a way that prohibits the current user from reading them, how does the app respond or otherwise present this to the user? Should we implement filtering in this app as well?Update: The Altinn Receipt app only queries the instance object for a given instance, which contains metadata for all data elements. This includes sensitive data elements. However, it only displays data elements without
appLogic, and even then only provides a list the user may click to view the attachment.The mere existence of a sensitive data element is not a secret, and the Storage service will continue to gatekeep read-access to these elements regardless of which front-end app is used.
In summary: This seems like non-issue from my perspective.
Affected libs and services
https://github.com/Altinn/altinn-receipt