Hi Mohammad,
I am not familiar w any specific examples where these subject
sub-categories
have been used, although they seem like they could be quite useful.
I think for the scenario you have described, that I would choose the
category:recipient-subject, because, while both the sub-categories
apply in the sense that the Consumer System is an intermediary,
in the use case you describe the Consumer System also is the
intended recipient of the data.
Also, I think it is more "important" that the Consumer System is the
intended recipient of the customer's private data, as opposed to
the somewhat obvious fact that the Consumer System is an
intermediary passing along the user's request, at least from
the perspective of the Service Provider. However, I am sure
someone could come up w a counter example, so I think
the bottom line is that the final choice is a judgement call
based on the needs of the participating organizations.
A final comment is that this example seems quite analogous
to the general OAuth 2.0 scenario, where an end user requests
a client application to perform some service whereby the
client appl needs to access a resource belonging to the
end user that is hosted on some resource server and the
client effectively has to pass its own identity info to the
authorization server, and the authorization server also
needs explicit authorization from the end user to allow
this client to access the end user's resource.
In the OpenAz project, we have demo'd the use of OAuth2.0
in conjunction w a xacml-based authorization server, with
xacml policies that take into account both the end user's
identity and the client appl identity, plus the end user's
authorization for a particular "scope" of resources that
the client is allowed to access.
http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/test/OAuthSimulator.html
Thanks,
Rich
On 7/23/2013 8:29 PM, Mohammad Jafari
wrote:
Thanks Rich.
Considering the
XSPA use case (see below) there is an end user who sends the
original access request, and there is also the Consumer
Organization who sends the request to acquire the health
record from the Service Provider. So, the attributes that
appear in the request to the Service Provider PDP include
attributes for both the end-user and the Consumer System
which sends the request for the data exchange on her/his
behalf. For example, the user ID of the end user and the
identifier of the Consumer organization, both appear in the
request and are both factors in making policy decisions.
I had seen the
definitions that you have quoted and from the informal
explanation it seems to me, it is appropriate to use
access-subject for the end user and recipient-subject or
intermediate-subject for the Consumer Organization. I am
wondering if anyone else have made such distinction in their
use-cases and whether they can share how they made the
decision to use what category for what kind of subjects.
Thanks again.
Mohammad
From:
rich levinson [mailto:]
Sent: Tuesday, July 23, 2013 1:14 PM
To: Mohammad Jafari
Cc:
Subject: Re: [xacml] subject categories
Hi Mohammad,
I am not sure I understand the full extent of your question
w/o more context
as to what you are trying to achieve.
However, it does seem to me that the defns in the core spec,
which were also
in the 2.0 spec seem fairly obvious, so possibly you missed
it in section B.2,
lines 5183-5200:
"Attributes previously placed in the
Subject section of a request are placed in an attribute
category 5183 which is identical of the subject category in
XACML 2.0, as defined below. It is RECOMMENDED that 5184
they are used to list attributes of subjects when authoring
XACML 3.0 policies or requests. 5185
This identifier indicates the system entity that initiated
the access request.
That is, the initial entity in a request chain.
If subject category is not specified in XACML 2.0, this is
the default translation value.
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject
This identifier indicates the system entity that will
receive the results of the request
(used when it is distinct from the access-subject). 5190
urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject
This identifier indicates a system entity through which the
access request was passed.
urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject
This identifier indicates a system entity associated with a
local or remote codebase
that generated the request.
Corresponding subject attributes might include the URL from
which it was loaded
and/or the identity of the code-signer.
urn:oasis:names:tc:xacml:1.0:subject-category:codebase
This identifier indicates a system entity associated with
the computer that initiated the access request. 5198
An example would be an IPsec identity. 5199
urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine"
Note that
the language in the defns uses the term "system entity" to
describe these
different "categories" of subject. This should be taken to
mean a distinct "entity",
whether it be a human actor or a physical machine.
Personally, I interpret "category" to mean a type of object,
which probably could
be characterized semantically by its own set of allowable
attributes. Basically,
I consider the "category", a collection of attributes w some
enterprise or organization
semantic meaning, as in this collection of attributes are
about "something" where
"something" is the business or system or organization
"entity" that warrants
being described by this particular collection of attributes.
(Please pardon the
verbose abstraction language I am using as it is intended to
be generic and
not assuming any particular concrete representation wrt
"entities".)
So, I think the original xacml authors were not trying to
specify
exactly what the different subject subcategories were
actually
about, but just giving an indication of a suggested way in
which
they could be used to characterize entities in the overall
network
that might be of interest for particular security use cases.
Hope this helps,
Thanks,
Rich
On 7/22/2013 11:09 PM, Mohammad Jafari
wrote:
Hello,
As we are trying to update the XSPA
XACML profiles, one of the tasks is to support XACML
version 3. I noticed that for “subject” attributes, there
are now 4 different categories defined in the core. The
mandatory category:
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject
and the optional categories:
urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject
urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject
urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine
But the core does not provide any
definition or discussion about the differences between
these categories. I was wondering if anyone can comment
about the differences or refer me to a definition so that
we can make a better decision on which category to use for
which attributes.
Thanks.
Regards,
Mohammad
--
Thanks, Rich
Rich
Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017
Oracle
Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Oracle
is committed to developing practices and products that
help protect the environment
--
Thanks, Rich
Rich Levinson | Internet Standards Security
Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Oracle is committed to developing practices
and products that help protect the environment
