Study Permission functionalities

A "StudyPermission" entity, with a N:1 relation ship to the Study entity, with a "role", an an "action" attribute.
When an association is accepted, one or several roles are associated with that association, based on the identity of the association initiator: In the simplest version, it may be a lookup in the existing roles table with the Called AET as user_id. If the Association initiator supports negotiation of the user identity in the A-Associate RQ, instead of the AET, the user id can be used for the lookup. And there will be an extension point, to get the associated roles to that association initator from other sources than the roles TABLE.
When a Study is created on receive of its first object, permissions will be created and linked to this Study according a configurable policy, which may consider not only the roles associated with the STORE SCU as described above, but also attributes of the object, in particular request attributes (e.g. Requesting Service) fetched from a specified MWL SCP and merged into the received object.
Consideration of Storage or Retrieve permissions is even simpler, because the operation will fail if the association initiator has not assigned a role with the permission to perform the requested operation.
For retrieve you may have to distinguish between a 'read' permission for the Storage SCP acting as Move Destination and a 'retrieve' permission for the Move SCU.
Permissions are defined by the relationship from StudyIUID to role and actions.

Possible Actions are:

Q (Query) – Query Study
R (Read) – Retrieve Study
E (Export) – Export Study to XDS/TCE
A (Append) – Append data to study
U (Updated) – Update Attributes in Webinterface
D (Delete) – Delete Study in Webinterface

Services involved

series-permission.xsl sample:

<!-- Sample configuration for grant/revoke Study Permissions on Series Stored event -->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:output method="xml"/>
  <xsl:param name="calling" select="'SAMPLE_MOD'"/>
  <xsl:template match="/dataset">
    <permissions>
        <xsl:variable name="studyUID" select="attr[@tag='0020000D']" />
        <xsl:variable name="seriesMOD" select="attr[@tag='00080060']" />
        <xsl:variable name="patIssuer" select="attr[@tag='00100021']" />
       <xsl:choose>
<!--
        Configuration for CT stored in client2 - Neurosurgery
-->
        <xsl:when test="$seriesMOD='CT' and not(contains(@patIssuer,'DCM4CHEE'))">
                <!-- grant Query, Read and Append permission on Study to client2 in special case -->
                <grant role="client2" action="Q,R,A" suid="{attr[@tag='0020000D']}"/>
        </xsl:when>
<!--
        Configuration for CT stored in client1 - Radiology (having ISSUER set to DCM4CHEE)
-->
       <xsl:when test="$seriesMOD='CT' and contains(@patIssuer,'DCM4CHEE')">
                <!-- grant Query, Read and Append permission on Study to client2 in special case -->
                <grant role="client1" action="Q,R,A" suid="{attr[@tag='0020000D']}"/>
        </xsl:when>
<!--
        all other Modalities stored client1 - Radiology (having ISSUER set to DCM4CHEE)
-->
        <xsl:otherwise>
                <!-- grant Query, Read and Append permission on Study to client1 per default -->
                <grant role="client1" action="Q,R,A" suid="{attr[@tag='0020000D']}"/>
        </xsl:otherwise>
      </xsl:choose>

PITFALLS:
Make sure that your WebViewer is able to show files after enabling the Security Features.