Hi Mike,
thanks for the references
to the literature. I had a quick look into the mentioned models and thex seem
to address how to define separate roles to group different permission sets. The
example I gave addresses the issue of how to control which administrator is allowed
to define which rights for certain rules.
However the original
issue was if <PolicySet> Elements should not be supported below PPS.
Whatever the motivations
might be (performance, administrative rights, structural...) I argue that it
does not harm to make the XACML v3.0 RBAC profile more flexible in this
direction.
Best regards
Jan
--
Jan Herrmann
Dipl.-Inform., Dipl.-Geogr.
Scientific
Assistant
Chair for Applied
Informatics / Cooperative Systems
Technische Universität
München
Boltzmannstr. 3
85748 Garching
Germany
T: +49 89 289 18692
F: +49 89 289 18657
W: www11.in.tum.de
Von: Davis, John M. [mailto:]
Gesendet: Donnerstag, 28. April
2011 17:00
An: Jan Herrmann; Erik Rissanen
Cc:
Betreff: RE: [xacml] support of
<PolicySet> elements under PPS elements?
ANSI INCITS is
considering RBAC Engineering models that already exist for incorporation into
extensions of the RBAC core spec. There are existing models such as
Neuman-Strembeck available. HL7 has used this model successfully to
create and international “RBAC Permission Catalog”.
Regards,
Mike Davis, CISSP
Department
of Veterans Affairs
VHA Office of Health
Information
Security Architect
760-632-0294
From: Jan Herrmann [mailto:]
Sent: Thursday, April 28, 2011
6:56 AM
To: 'Erik Rissanen'
Cc:
Subject: AW: [xacml] support of
<PolicySet> elements under PPS elements?
Hi Erik,
the NIST model
doesn’t specify how to define the privileges associated with roles. Hence
independent of the requirements that might drive someone to build a Policytree
based on nested PS, I don’t see a reason why PS elements under PPS should
be forbidden.
Nevertheless a scenario
for PS under PPS elements could be:
When using XACML to
define the privileges it might be very convenient to provide a certain
PolicySet structure below the PPS. One could e.g. define <PolicySet>
elements under a PPS that test for specific resource types (e.g. services).
Below these service specific <PolicySet> elements you could than
structure your policy by the action type (e.g. different <PolicySet>
elements for each specific service type). Having such a predefined structure
and allowing the junior-policy administrators only to define <policy> and
<rule> elements below these predefined <PolicySet> elements will
ensure that they do not define rights out of their scope.
Best Regards
Jan
--
Jan Herrmann
Dipl.-Inform.,
Dipl.-Geogr.
Scientific
Assistant
Chair for Applied
Informatics / Cooperative Systems
Technische Universität
München
Boltzmannstr. 3
85748 Garching
Germany
T: +49 89 289 18692
F: +49 89 289 18657
W: www11.in.tum.de
Von: Erik Rissanen [mailto:]
Gesendet: Donnerstag, 28. April
2011 14:37
An:
Betreff: Re: [xacml] support of
<PolicySet> elements under PPS elements?
Hi Jan,
The RBAC profile has a very specific goal, namely to implement the NIST model
of RBAC. That goal is accomplished as it is, so there is no need to allow a
policy set elements. Why would you need it?
Best regards,
Erik
On 2011-04-25 10:19, Jan Herrmann wrote:
Hi there,
the XACML v3.0 RBAC profile states:
“...Permission
<PolicySet>
or PPS: a <PolicySet> that contains the actual
permissions
141
associated with a given role. It contains <Policy> elements and <Rules> that
describe the
142
resources and actions that subjects are permitted to access, along with any
further conditions on
143 that
access, such as time of day. ...”
From my point of view this PPS
definition is unnecessary limiting the structure below PPS. I would propose to
support <PolicySet> elements under PPS elements, unless there are good
reasons why this should be prohibited.
Best regards
Jan
--
Jan Herrmann
Dipl.-Inform.,
Dipl.-Geogr.
Scientific
Assistant
Chair for
Applied Informatics / Cooperative Systems
Technische Universität
München
Boltzmannstr. 3
85748 Garching
Germany
T: +49 89 289 18692
F: +49 89 289 18657
W: www11.in.tum.de
