Difference between revisions of "The CTP FileStorageService Access Mechanism"
|Line 1:||Line 1:|
This article describes the access control mechanism which is included in the CTP FileStorageService. The primary intended audience for this article is CTP administrators. A prerequisite for fully understanding this article is [[
This article describes the access control mechanism which is included in the CTP FileStorageService. The primary intended audience for this article is CTP administrators. A prerequisite for fully understanding this article is [[Clinical Trial Processor]].
Revision as of 18:16, 4 September 2008
This article describes the access control mechanism which is included in the CTP FileStorageService. The primary intended audience for this article is CTP administrators. A prerequisite for fully understanding this article is CTP-The RSNA Clinical Trial Processor.
1 The FileStorageService
The FileStorageService is a CTP pipeline stage which stores objects in a file storage device. Files are stored in a hierarchy of directories, grouping objects by study. An object is associated with a study by its study UID.
As described in The CTP FileStorageService Web Server, the FileStorageService can be configured to group studies into FileSystems based on the contents of elements in the objects contained in the studies. For example:
- A FileStorageService can be configured to group studies by PatientID elements in DICOM objects which are received for storage.
- A FileStorageService can be configured to group studies based on the AE Title (either sending or receiving) used in the transfer.
- If no grouping information is provided in the configuration of the FileStorageService, all studies are placed in the FileSystem called __default.
The FileStorageService web server can be configured to enforce access control at the level of a FileSystem. To do so, the require-authentication attribute must be set to yes in the FileStorageService's configuration element as described in CTP-The RSNA Clinical Trial Processor.
When authentication is required, the web server verifies that the user is authenticated on each transaction, and if not, displays a login page. After the login is successful, the user is directed to the original destination.
(Technical note: Once the user is authenticated, the system sets a session cookie on the client. The client must have cookies enabled for the authentication mechanism to work. It is not necessary to close the browser session to log in as another user, and it is also possible to log out. The home page of the web server provides links for both actions.)
Users are managed through the UserManagerServlet, which is available only to users with the admin privilege. This servlet is accessed on the main page of the CTP web server.
(Note: CTP has a separate web server used to monitor the application and to perform certain administrative tasks. That web server is independent of the FileStorageService web server. Further, if multiple FileStorageServices appear in the configuration, each will have a separate web server.)
Users may have zero or more of the following privileges:
- admin grants a user access to administrative functions that are restricted for security.
- delete grants a user the ability to delete studies in any FileSystem.
- guest identifies a user as someone who can be granted read access to a specific FileSystem by the owner of that FileSystem.
- proxy grants a user the ability to manage the guest list of any FileSystem.
- read grants a user the ability to view studies in any FileSystem.
A typical administrator would have all privileges.
In a system used to distribute studies to referring physicians, FileSystems would typically be organized by PatientID, and referring physicians would have the guest privilege. A technologist or secretary might be granted the proxy privilege to allow that person to add the appropriate physician to the guest list on behalf of the patient, thus granting the physician the ability to see the patient's studies.
In a system used for research data management, all users might be granted the read privilege, but only certain users might be granted the delete privilege, the latter just so that they can manage the storage of the system.
Unless a user has the read privilege, the user is allowed to access only his own FileSystem (the FileSystem with the same name as his username), the __default FileSystem, and any FileSystem which contains his username in its guest list. In addition, the user can access the GuestListServlet so that he may invite guests to view his FileSystem.
A user can always delete studies from his own FileSystem, but he can only delete other studies if he has the delete privilege.