Authorization Models in
Medical Information Systems
Andrei Bretan
FAU
April 2, 2004
Definition of terms
Authorization and Authentication I
• Are separate concepts, sometimes misinterpreted (Example: Access
Authorization).
• Authentication allows entity A to convince entity B of A’s identity with
some degree of certainty.
• Entity A may be trying to perform some task (e.g., execute an
application, invoke a function, or access a file).
• B needs to know not “who A is” as much as “whether A should be
allowed to perform this task”
Definition of terms
Authorization and Authentication II
• Authorization allows B to make and enforce this decision.
• A’s identity may be almost irrelevant, useful for auditing purposes
only. Example: “all executives are allowed to see the quarterly
results before they are announced”
• Authentication answers the question “Who is this entity?”
• Authorization answers the question “Is this entity allowed to do what
it is trying to do?”
Authorization Architecture
• An Authorization Architecture is the set of components
and data that allows authorization decisions to be made
and enforced.
• A typical Authorization Model for such Architecture
includes the requesting subject/object, the protected
object/operation, the request interceptor and the entity
which holds access rights to objects/operations in the
system.
Attributes I
• An Attribute is a piece of information that may be
categorized as being associated with the subject, action,
resource, or environment in an authorization
architecture.
• Attributes may be static or dynamic.
• Static attributes of the subject are referred to by many
names in various discussions and contexts: privileges,
permissions, rights, authorizations, properties,
characteristics, entitlements, and grants.
• Static attributes can also be associated with resources
and with actions. Groups, roles, and document labels
are all examples of static attributes.
Attributes II
• Dynamic attributes are those whose values cannot be
relied upon to remain unchanged.
• Example of dynamic attributes of the subject include
current account balance, amount of credit remaining.
• Dynamic attributes of the resource include the number of
times it has been accessed.
Policies I
• An access control policy with respect to a specific
resource or set of resources is the set of rules governing
who can do what to those resources under what
conditions.
• The resources are data/information or
functions/operations that the subject requests to access.
• The functions/operations will eventually (in most cases)
translate to access to some data/information.
Policies II
• Policy expressions are at many levels of abstraction:
• Organizational goals, guidelines, compliance rules.
• Per-system operational policies and organization specific
or business specific rules.
• Atomic i.e. per-resource controls.
Example: An Extended Authorization Architecture
SA
RA
EA
PIP
PDP
S
PEP
PRP
R
S:subject, R:resource, PEP:policy enforcement point,
PDP:policy decision point, PIP:policy information point,
SA:subject authority, RA:resource authority,
EA:environment authority, PRP:policy retrieval point,
PAP:policy administration point.
PAP
Enforcing Policies I
• Mandatory Access Control (MAC): secures information by
assigning sensitivity labels on data/operations and comparing this to
the level of sensitivity a user is operating at.
• MAC is usually appropriate for extremely secure systems.
• Discretionary Access Control (DAC): is a means of restricting
access to data/operations based on the identity of users and/or
membership in certain groups.
• Access to information/operations is determined based on
authorizations specified by access control lists.
Enforcing Policies II
• Role Based Access Control (RBAC): access decisions are based
on an individual's roles and responsibilities within the organization.
• Determines who can perform what actions, when, from where, in
what order, and in some cases under what relational circumstances.
• Defining roles: based on analyzing the structure of an organization
and is usually linked to the security policy of that organization.
• Each role is designated a profile that includes all authorized
commands, transactions, operations and allowable information
access such as all access policies of that organization are enforced.
Research: Task Based Authorization (ARPA) I
• Multiple points of access, control, and decision making.
• Task-oriented or transaction-oriented perspective rather than the
traditional subject-object view of access control.
• Involves authorizations at various points during the completion of
tasks in accordance with some application logic.
• The subject-object view typically divorces access mediation from the
larger context in which a subject performs an operation on an object.
Research: Task Based Authorization (ARPA) II
• TBA actively takes part in access control management in contrast to
traditional passive subject-object models that merely store primitive
access control definition (tuples).
• In the subject-object view, the individual rights of subjects to various
objects are stored in an internal data structure such as an access
control matrix.
• The information in the access control matrix (or access control lists)
represents independent and unrelated access control information
(tuples).
Research: Task Based Authorization (ARPA) III
• TBA utilizes the emerging (flowing) context of activities as they
progress, when managing access control and authorizations.
• In contrast to the traditional subject-object view of access control
that usually responds to the question: “Is subject ‘S’ allowed access
‘A’ (or possess the right ‘A’) to object ‘O’ ?” a task-based view seeks
an answer to the following question: “Can task be authorized to
proceed?”
Research: Other types of Authorization Models I
• Multiple Authorization Model (MAM): limiting factors of current
access control systems is the dependence on a single subject for
authorization.
• It is usually not possible to directly involve other entities, i.e., other
people in a particular access control decision.
• The drawback is that any access decision occurs just on the behalf
of the single subject that makes the access.
• MAM Access control model that allows to include authorization of
multiple subjects thus overcoming this drawback.
Research: Other types of Authorization Models II
• Authorization Models for Metacomputing
Applications:
• Metacomputing systems cover large networks
connecting mutually suspicious domains, which are
independently administered.
• Public Key Infrastructure (PKI):
• Shows great promise.
• Use Public Key Infrastructure standards to identify users
and create digitally signed certificates.
Research: Other types of Authorization Models III
• Public Key Infrastructure (PKI) (cont.):
• Access based on policy statements made by stakeholders.
• Handle multiple independent stakeholders for a single resource.
• Provisional Authorization Models:
• Almost all studies in access control and authorization systems
have assumed the following model: “A user makes an access
request of a system in some context, and the system either
authorizes the access request or denies it.”
Research: Other types of Authorization Models IV
• Provisional Authorization Models (cont):
• The notion of a provisional authorization which tells the user that his
request will be authorized provided he (and/or the system) takes
certain security actions such as signing his statement prior to
authorization of his request.
• Examples: You are allowed to access confidential information, but
the access must be logged.
• You are allowed to read sensitive information, but you must sign a
terms and conditions statement first.
Research: Other types of Authorization Models V
• Team Based Access Control (TMAC) is a role based access
control in collaborative environments.
• Such an approach needs a hybrid type access control model that
incorporates the advantages of broad role-based permissions
across object types, yet requires fine-grained, identity-based control
on individual users in certain roles and to individual object instances.
• A second requirement is the need to recognize the context
associated with collaborative tasks and the ability to apply this
context to decisions regarding permission activation.
Medical Information Systems
Research I
• There are not many existing Authorization Models for
Medical Information Systems.
• The existing ones are mostly adaptations of existing
models to some aspects of the Medical Domain.
• There is no comprehensive model yet for security in the
Medical Domain.
• There are no sets of patterns (corresponding to sets of
policies) for the Medical Domain.
Medical Information Systems
Research II
• Examples: R.A.Kemmerer, “Formal specification of a mental
health delivery system”, Rept. TRCS89-31, Dept. of Computer
Science, University of California Santa Barbara, November 1989.
• J. Biskup, “Protection of privacy and confidentiality in medical
information systems: Problems and guidelines”, in Database
Security III, Status and Prospects, Elsevier Science Publishing.
• J. Biskup and G. Bleumer, “Reflections on Security of Database and
Datatransfer Systems in Health Care”, Procs. of the 13th World
Computer Congress, IFIP 1994.
Medical Information Systems
Research III
• I. Mavridis, G. Pangalos, M. Khair, and L. Bozios, “Defining access
control mechanisms for privacy protection in distributed medical
databases”, Procs. IFIP Working Conf. on User Identification and
Privacy Protection, June 1999.
• G. Pangalos, A. Pomportsis, L. Bozios, and M. Khair, “Development
of secure medical database systems”, Procs. of DEXA’94.
• M. Wilikens, S. Feriti, M. Masera, “A Context-Related Authorization
and Access Control Method Based on RBAC: A case study from the
health care domain”.
Medical Information Systems
Research IV
• Roshan K. Thomas, “Team-based Access Control (TMAC): A
Primitive for Applying Role-based Access Controls in Collaborative
Environments” , Odyssey Research Associates Cornell Business
and Technology Park.
• Longhua Zhang, Gail-Joon Ahn,Bei-Tseng Chu,” A Role-Based
Delegation Framework for Healthcare Information Systems”,
College of Information Technology, UNC Charlotte.
• E.B. Fernandez, M.M. Larrondo-Petrie, and T. Sorgente, "Security
models for medical and genetic information“. FAU, Boca Raton FL.
Medical Information Systems
Research and Implementations I
• Example: PCASSO (Patient Centered Access to Secure Systems
Online) is a research project and technology demonstration that
seeks to provide secure access to highly sensitive patient
information over the Internet.
• Developed by Science Applications International Corporation (SAIC)
and the University of California, San Diego, (UCSD) School of
Medicine and Healthcare Network.
• Funded by the National Library of Medicine (NLM) of the National
Institutes of Health (NIH) through its Health Applications for the
National Information Infrastructure (NII) initiative.
Medical Information Systems
Research and Implementations II
• All information in PCASSO is associated with a sensitivity label.
Information may be patient-specific (e.g. patient-record information)
or patient-independent (e.g. clinical research information).
• Individuals may access information only if they are acting in a role
authorized for the requested type of access (read, upgrade,
downgrade, etc).
• First, the type of information is used to determine the default
label i.e. certain HL7 message types have an associated intrinsic
sensitivity.
Medical Information Systems
Research and Implementations III
• Second, an individual acting in an authorized role (e.g., primary care
provider, PCASSO administrator) may explicitly assign a label.
• PCASSO uses label-based access control to separate five levels of
increasingly sensitive patient information:
Low, Standard, Deniable, Guardian Deniable, Patient Deniable.
• PCASSO also uses label-based controls to protect its system
software from malicious or misbehaving programs and its system
data from unauthorized disclosure.
Medical Information Systems
Research and Implementations IV
• Roles may be patient-specific (e.g., patient, primary care provider,
secondary care provider, emergency provider) or patient
independent (e.g., researcher, administrator).
• Each role is associated with a sensitivity level range, a set of rights,
and an access control list (ACL).