[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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: firstname.lastname@example.org [mailto:email@example.com] Sent: Friday, June 17, 2011 5:49 PM To: PTyson@bellhelicopter.textron.com; firstname.lastname@example.org; email@example.com 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; firstname.lastname@example.org; email@example.com 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: firstname.lastname@example.org [mailto:email@example.com] > Sent: Friday, June 17, 2011 15:38 > To: firstname.lastname@example.org; email@example.com > 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:firstname.lastname@example.org] > 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_workgroups.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.