OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] DLP & NAC Profilwe WD 7 updates and open issues


Hi Hal,

ALFA is extensible indeed. You can define your own data types and functions (in system.alfa to be precise).

Regards,
Srijith K. Nair, PhD
Director of Developer Relations, Axiomatics AB
Contact: +31 6 3433 8283 | srijith.nair@axiomatics.com
Connect with us on LinkedIn | Twitter | Google + | Facebook | YouTube

On 27 Jun 2014, at 15:09, Hal Lockhart <hal.lockhart@oracle.com> wrote:

Is the ALFA tool extensible? The problem is that I am making use of some new data types and functions (defined in the profile). The best way to find the changes is to run a diff between WD 6 and WD 7. Warning: some of changes are cosmetic – to make lines fit.
 
Hal
 
From: David Brossard [mailto:david.brossard@axiomatics.com] 
Sent: Friday, June 27, 2014 3:28 AM
To: Tolbert, John W
Cc: Hal Lockhart; XACML TC
Subject: Re: [xacml] DLP & NAC Profilwe WD 7 updates and open issues
 
Dear all,
 
I've now completed the XACML (and ALFA) policies for the profile. Please see attached.
 
Hal, you mentioned you made some edits to the policies. Could you highlight which specific ones so I can port them back to the ALFA source?
 
Thanks,
David.

 

On Thu, Jun 26, 2014 at 9:04 PM, Tolbert, John W <john.w.tolbert@boeing.com> wrote:
1.  We're still looking for a volunteer to populate the sample policies in 4.2.
2.  I think we want the attributes to be associated with the proper categories, such as recipient-subject, recipient-machine, and ip-address should be associated with recipient subject category.  We should fix this in the next WD, or pull -07 and re-submit it with the corrections.
3.  Agree that variation in algorithms would make better examples.
4.  I don't know that we would want to promote that as a best practice, unless it's called out specifically to force the behavior described.  The Indeterminate with Missing Attributes is definitely useful in many circumstances.




-----Original Message-----
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Hal Lockhart
Sent: Thursday, June 26, 2014 11:42 AM
To: XACML TC
Subject: [xacml] DLP & NAC Profilwe WD 7 updates and open issues

I fixed the typo in the definition of ipAddress-pattern (line 193). I cleaned up a variety of issues with the example policies. I believe the policies are now correct, match their summaries and are consistent with the attribute definitions in the profile.

I note the following open issues:

1. Section 4.2 (NAC) has two sections for sample policies, but no policies.

2. Section 2.3 raises questions about how we model Subject Categories. XACML defines 5 Subject category types: access subject, recipient subject, intermediary subject, codebase and requesting machine. The implication of this is that each of these are potentially autonomous actors with their own set of all kinds of subject attributes. In the profile we have attributes requesting-machine, recipient-machine, ip address and codebase. They are all listed at subject attributes and in the examples they are of category access subject. Is this the way we want it to work or should they be associated with the other subject category types?

It is clear that a person, a machine (smartphone) and a codebase can all have different ids and authentication methods, for example. Probably only a machine can have a ip address, so if we don't otherwise need to use requesting machine it seems ok to associate the ip address with the access subject. In the XACML scheme, source of the request can be decomposed into the three categories: access subject, requesting machine and codebase, but for recipient subject and intermediary subject person, code and machine are all lumped together.

3. The examples use the first applicable rule combining algorithm throughout. This works because every policy has only one rule. However if anyone modifies the policies either as an example or to use in their own PDP and introduces additional rules, the policies may not function as expected. Should we change the rule combining algorithm to something else, such as deny overrides?

4. All of the attribute designators in the examples set "must be present" to false. Since as far as I can see, all the attribute values are required to make a decision in each case, the effect of this will be to return Deny anytime the PEP omits an attribute value instead of returning Indeterminate with mussing attributes, allowing the PEP to retry. Is this what we should designate as best practice?

Hal


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



 
--
David Brossard, M.Eng, SCEA, CSTP
VP of Customer Relations
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
Axiomatics for developers: http://developers.axiomatics.com
Connect with us on LinkedIn | Twitter | Google + | Facebook | YouTube



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]