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:]
> Sent: Tuesday, June 21, 2011 10:57 AM
> To: ; ;
> ;
> 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: [mailto:]
> Sent: Friday, June 17, 2011 5:49 PM
> To: ; ;
>
> 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:]
> Sent: Friday, June 17, 2011 2:35 PM
> To: Choy, David; ;
> 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: [mailto:]
> > Sent: Friday, June 17, 2011 15:38
> > To: ;
> > 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:]
> > 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
>
>
