Yes exactly. Thoughts?
On Dec 13, 2013 4:02 PM, "Bill Parducci" <> wrote:
Hi David,
So you are proposing something like the following…
Action-id: read
Action-protocol: http
Action-method: get
…or
Action-id: read
Action-method: http-get
Thanks
b
On Dec 13, 2013, at 1:59 AM, David Brossard <> wrote:
Also, John, the value HTTP for action-id is quite odd. At best an action id would be the protocol's method (GET, POST, PUT...) and HTTP would be the protocol type. That could still be expressed in the action category.
Also the transport / protocol action is perhaps not what is interesting. Rather a business action (view, edit...) that reflects the original English policy seems more adequate.
Thoughts?
On Fri, Dec 13, 2013 at 2:58 AM, Steven Legg <> wrote:
Hi John,
On 13/12/2013 8:04 AM, Tolbert, John W wrote:
Proposal in draft. Suggestions welcome.
Use case:
1.1.1.1
Prevent sensitive data from
being read/modified by unauthorized applications
Policies may stipulate which applications
can read or modify resources to prevent insecure applications
or malware-compromised applications from contaminating or
exfiltrating sensitive data. This use case assumes that the
Policy Decision Point (PDP) can call an external configuration
management database to determine if the application is on the
approved list.
Attribute:
1.1.2
Authorized-Application
This identifier indicates whether or not
the requesting application is approved for the actions
requested.
urn:oasis:names:tc:xacml:3.0:subject:authorized-application
The DataType
of this attribute is
http://www.w3.org/2001/XMLSchema#boolean.
This is not a natural access-subject attribute. Its value does not
depend on the access-subject
at all and a context handler would not be looking in the same place
for this attribute that it
would be for other access-subject attributes. The obvious lookup key
for access-subject
attributes is subject-id, but that wouldn't be useful for fetching
an approved applications list
(the PEP could provide the attribute, but if we are concerned that
the application may be
compromised, then perhaps we shouldn't be taking its word that it is
an authorized application).
A better category would be "codebase" or "intermediary-subject".
Even "environment"
would be a better choice than "access-subject".
A context handler could look up the authorized-application attribute
using the subject-id
attribute in the codebase category, but if the authorized
applications are maintained as
a list, then it would be more appropriate to have that list appear
as an environment
attribute and policies would test if the subject-id in the codebase
category is one of the
values in the list.
A single list is also very coarse. An application is either approved
or not regardless of the
circumstances. If policies test the codebase subject-id against bags
of values in their conditions,
then it is possible to be more subtle. For example, an application
is approved for read actions
but not write actions, or is approved if it's running on a company
desktop but not if it is
running on a smartphone.
It is worth saying in the Security Considerations that the context
handler should take steps
to verify the authenticity of the subject-id in the codebase
category by, for example,
cross-checking with the authenticated identity of the PEP, or by
ignoring any provided value
and generating the value itself using the authenticated identity.
Regards,
Steven
Example:
1.1.3
Prevent sensitive data from being
read/modified by unauthorized applications
Acme security
policy prohibits unapproved applications from reading and
modifying sensitive data. Alice attempts to open a sensitive
document with an unauthorized application. The request fails.
Sample attributes and values are listed below.
Resource
Attributes
Values
Resource-ID
http://confidential.acme.com/eyes-only.xml
Resource-location
webserver1.acme.com
Subject
Attributes
Values
Subject-ID
Alice
Subject-ID-qualifier
acme.com
Authorized-application
False
Action
Attributes
Values
Action-ID
HTTP
1.1.3.1
Description
This sample policy
can be summarized as follows:
Target:
This policy is only applicable to
Resource-location = “webserver1.acme.com”
AND Resource-ID contains “confidential\.acme\.com”
Rule: This
rule is only applicable if
Action-ID contains “HTTP”
Then if
Subject-ID-qualifier = “acme.com” AND
Authorized-application = false
DENY
Obligation:
On DENY log
attempt to use an authorized application
Sample Policy….
To be added
--
David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
LinkedIn: http://www.linkedin.com/companies/536082
Web: http://www.axiomatics.com
Twitter: http://twitter.com/axiomatics
Google Plus: https://plus.google.com/u/1/109113357550030353531/
