RE: [xacml] F2F Agenda Topics

[Hal Lockhart <hal.lockhart@oracle.com>]

I have been touting Federated Administration as a capability of XACML for years. I believe is can be done today, with nothing more than some organization-wide conventions on structuring the enclosing policy sets. (Conventions that will likely differ from one organization to another and therefore are not suitable for standardization.)

I do not believe it is necessary to be using hierarchical resources to do this. I will be very interested to hear what specific additional XACML features are seen as being required.

Hal

> -----Original Message-----
> From: Radhakrishnan, Rakesh
> [mailto:rakesh.radhakrishnan@bankofamerica.com]
> Sent: Tuesday, June 21, 2011 10:57 AM
> To: david.choy@emc.com; PTyson@bellhelicopter.textron.com;
> bill@parducci.net; xacml@lists.oasis-open.org
> Cc: Radhakrishnan, Rakesh
> Subject: RE: [xacml] F2F Agenda Topics
> 
> 
> Very Interesting discussions on XACML in the lists.. 
> 
> Large Banks (global, distributed, heterogeneous, 
> complex/hierarchies, etc,) such a CB or BofA, etc; I can 
> imagine will have multiple XACML projects;
> 
> 
> a) for example a LOB having its own XACML PDP for the 
> HomeLoan&Fin apps its owns and there could be a few
> b) an Overarching Ent XACML PDP -- that is defining Global 
> Gov rules, Risk rules and Compliance controls -GRC oriented
> (that LOB XACM PDP consults for risky and sensitive data 
> (iTAR, PCI_DSS, etc)
> c) The Risk rules in item b) can actually be a large scale 
> Enterprise Risk PIP --> feeding into a Ent PDP
> d) a Network XACML PDP -- that is highly focusing on 
> capturing network context from network services (session 
> oriented, packet oriented, intrusion/inspection specific, 
> etc.) and aligning the Network Security Services in DMZ (this 
> PDP integrates heavily into AuthN, Adaptive AuthN, STS, etc., 
> as well - and acts as an added Subject Attribute Auth for the 
> Ent PDP) - it also acts as a Device and Communication Ctrl PDP
> e) In addition to this - we can have a Privileged Access PDP 
> -down the road - for OS/VM/Hypervisor (clients and server) 
> -integrates into IAAS type env via tools that implement such 
> AC and FW's.
> 
> 
> So essentially for most use cases - local LOB PDP is 
> touched... (user from within that LOB, context within the 
> LOB, resources within that LOB, etc.).. 
> The LOB PDP consult the master/Ent PDP for additional 
> Data/Risk/Compliance centric rules (when the context is iTAR 
> or Export Control or IP, etc)
> The ent PDP consults the Ent Risk PIP/PDP to ascertain 
> certain decisions..
> And more..
> 
> Divvying up the workload this way allows for parallel 
> progress from multiple perspectives (for large, global, 
> distributed, heterogeneous, complex/hierarchies, etc,)...
> 
> Hence --
> Combining algorithm for a distributed admin environment
> Delegated Admin to local PDP and Distributed PDP
> And more..
> Will all be usefull..
> 
> 
> Also discussions in this F2F around topics such as;
> 
> XACML PDP integration into DB FW 
> XACML PDP integration into DLP FW 
> XACML PDP integration into DRM FW
> (similar to XACML PDP integration into XML FW's) 
> 
> And its outcome - will be very useful..
> 
> Are the dates for the F2F finalized?
> 
> 
> Regards
> RR
> 
> 
> -----Original Message-----
> From: david.choy@emc.com [mailto:david.choy@emc.com] 
> Sent: Friday, June 17, 2011 5:49 PM
> To: PTyson@bellhelicopter.textron.com; bill@parducci.net; 
> xacml@lists.oasis-open.org
> Subject: RE: [xacml] F2F Agenda Topics
> 
> I have yet seen an enterprise that has a central admin for 
> all access control policies in the Enterprise. A workgroup 
> may administer access control policies for documents created 
> by the workgroup. But then there may be divisional or 
> corporate policies that govern internal documents. Retention, 
> records management, legal hold are examples of use case. A 
> workgroup may not be aware of all the corporate policies that 
> are in place, and corporate may not be aware of all the 
> policies created by all the workgroups in the company.
> 
> david
> 
> -----Original Message-----
> From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> Sent: Friday, June 17, 2011 2:35 PM
> To: Choy, David; bill@parducci.net; xacml@lists.oasis-open.org
> Subject: RE: [xacml] F2F Agenda Topics
> 
> This sounds like a very strange business case, and I don't 
> see how XACML can help.
> 
> It does not appear to be a rational model for policy 
> development if independent groups are making rules concerning 
> potentially overlapping instances of subject/resource/action. 
>  That is anarchy, not federation.
> 
> And even if some enterprises find it useful to develop 
> policies that way, the PDP implementation should allow 
> specifying one of the existing policy-combining algorithms 
> (or a custom one) at the notional "root" of the policy tree.
> 
> Regards,
> --Paul
> 
> > -----Original Message-----
> > From: david.choy@emc.com [mailto:david.choy@emc.com]
> > Sent: Friday, June 17, 2011 15:38
> > To: bill@parducci.net; xacml@lists.oasis-open.org
> > Subject: RE: [xacml] F2F Agenda Topics
> > 
> > I'd like to add another topic to the agenda list: combining 
> algorithm 
> > for a distributed admin environment.
> > 
> > Currently, combining algm is specified only within a container (a 
> > policy or a policy set). In an enterprise, policy admin is usually 
> > distributed among different organizational units, ranging 
> from small 
> > workgroups to the corporate level. For a given decision 
> request, there 
> > may be multiple applicable policies that are created by different
> admin
> > authorities. These policies may not know the existence of 
> each other, 
> > and may not be encapsulated in a single policyset. We need 
> a broader 
> > model for combining algm to resolve conflict in this case. I'll be
> glad
> > to give an example at the F2F.
> > 
> > David
> > 
> > -----Original Message-----
> > From: Bill Parducci [mailto:bill@parducci.net]
> > Sent: Friday, June 17, 2011 6:46 AM
> > To: XACML TC
> > Subject: [xacml] F2F Agenda Topics
> > 
> > With the F2f rapidly approaching, we need to start nailing down the 
> > agenda. In the past we have chunked up the discussion topics so that
> we
> > can make sure to cover as many of them as possible, while 
> driving the 
> > largest/most difficult issues to completion as the primary 
> driver. To 
> > that end I would like to propose that we again break the 
> days in half 
> > thus and then dissect from there as needed:
> > 
> >  Tuesday 8-12
> >  Tuesday 1-5
> >  Wednesday 8-12
> >  Wednesday 1-5
> >  Thursday 8-12
> > 
> > Below is a non-exhaustive list of open issues.
> > 
> >   Attribute Predicate
> >   BTG
> >   PIP Directive
> >   JSON Profile
> >   Obligation/Advice Combining
> >   PAP Interface
> >   RSA Interop
> >   "Web Friendly" Policy Ids
> >   "Sticky" Policies
> >   XACML Metadata Schema
> > 
> > I suggest that we begin by fleshing out this list, then 
> prioritize and 
> > schedule those topics that have the most interest and will have 
> > champions in attendance. My goal is to have a candidate 
> agenda for the 
> > TC call next Thursday so please take a few moments to chime in with 
> > your thoughts.
> > 
> > thanks
> > 
> > b
> > 
> ---------------------------------------------------------------------
> > 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
> 
> 
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 
> 
> ----------------------------------------------------------------------
> This message w/attachments (message) is intended solely for 
> the use of the intended recipient(s) and may contain 
> information that is privileged, confidential or proprietary. 
> If you are not an intended recipient, please notify the 
> sender, and then please delete and destroy all copies and 
> attachments, and be advised that any review or dissemination 
> of, or the taking of any action in reliance on, the 
> information contained in or attached to this message is prohibited. 
> Unless specifically indicated, this message is not an offer 
> to sell or a solicitation of any investment products or other 
> financial product or service, an official confirmation of any 
> transaction, or an official statement of Sender. Subject to 
> applicable law, Sender may intercept, monitor, review and 
> retain e-communications (EC) traveling through its 
> networks/systems and may produce any such EC to regulators, 
> law enforcement, in litigation and as required by law. 
> The laws of the country of each sender/recipient may impact 
> the handling of EC, and EC may be archived, supervised and 
> produced in countries other than the country in which you are 
> located. This message cannot be guaranteed to be secure or 
> free of errors or viruses. 
> 
> References to "Sender" are references to any subsidiary of 
> Bank of America Corporation. Securities and Insurance 
> Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * 
> May Lose Value * Are Not a Bank Deposit * Are Not a Condition 
> to Any Banking Service or Activity * Are Not Insured by Any 
> Federal Government Agency. Attachments that are part of this 
> EC may have additional important disclosures and disclaimers, 
> which you should read. This message is subject to terms 
> available at the following link: 
> http://www.bankofamerica.com/emaildisclaimer. By messaging 
> with Sender you consent to the foregoing.
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 
> 
>