I've "simplified" the choices somewhat, and added a few items based on the feedback. Please review at your leisure. Thanks http://kantarainitiative.org/confluence/display/concordia/Authorization+surv...
PDP and PEP acronyms will need expansion. Real life examples in brackets would help. If the survey is for a business person, he would not understand PDP/PEP "Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement. IMHO if PEP and PDP must exist (it does not matter from which vendor they are as the IT has to pay the cost), then the real problem is application integration and migration. /Shivaram On Tue, Oct 6, 2009 at 9:51 AM, Tolbert, John W <john.w.tolbert@boeing.com>wrote:
I've "simplified" the choices somewhat, and added a few items based on the feedback. Please review at your leisure. Thanks
http://kantarainitiative.org/confluence/display/concordia/Authorization+surv...
_______________________________________________ Dg-concordia mailing list Dg-concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
-- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/
"Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement.
Would respectfully disagree.. This is a clear and continuing issue, even after the XACML TC sponsored interop that happened at Burton Catalyst a couple of years ago. http://bit.ly/4NATB http://bit.ly/6HfEn I wrote the above two blog entries more than a year ago. AFAIK, this situation has not changed to any great degree (I am very willing, and hope that I will be, corrected on this!) If both my PEP vendor(s) (XML Security GW Vendors as well as Software based PEPs) as well as my PDP Vendors (Entitlement/Policy Decisioning engines) trumpet their support for XACML and their ability to exist in a standards based environment, why should I continue to pay for integration between a PEP and a PDP, especially if I've made a decision to externalize my AuthZ (The decision to do so and implement is, as noted, a continuing policy and education problem) ? Regards, - Anil From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of Shivaram Mysore Sent: Tuesday, October 06, 2009 2:03 PM To: Tolbert, John W Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes PDP and PEP acronyms will need expansion. Real life examples in brackets would help. If the survey is for a business person, he would not understand PDP/PEP "Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement. IMHO if PEP and PDP must exist (it does not matter from which vendor they are as the IT has to pay the cost), then the real problem is application integration and migration. /Shivaram On Tue, Oct 6, 2009 at 9:51 AM, Tolbert, John W <john.w.tolbert@boeing.com<mailto:john.w.tolbert@boeing.com>> wrote: I've "simplified" the choices somewhat, and added a few items based on the feedback. Please review at your leisure. Thanks http://kantarainitiative.org/confluence/display/concordia/Authorization+surv... _______________________________________________ Dg-concordia mailing list Dg-concordia@kantarainitiative.org<mailto:Dg-concordia@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-concordia -- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/
I would like to offer the following questions for consideration for addition to the AuthZ survey: 1) What access control models are supported by your authorization system? a) Role Based Access Control (RBAC) b) Attribute Based Access Control (ABAC) c) Other? 2) What are the types of factors/attributes/claims that are supported by your authorization system? a) Identity and Authority based b) Resource based c) Environmental based d) Other 3) Does your authorization system provide any mechanisms for the lifecycle management of AuthZ policies? a) Yes b) No 4) Does your authorization system provide any mechanisms for the sharing/distribution of AuthZ policies? a) Yes b) No Regards, - Anil From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of John, Anil Sent: Tuesday, October 06, 2009 4:30 PM To: Shivaram Mysore; Tolbert, John W Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes
"Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement.
Would respectfully disagree.. This is a clear and continuing issue, even after the XACML TC sponsored interop that happened at Burton Catalyst a couple of years ago. http://bit.ly/4NATB http://bit.ly/6HfEn I wrote the above two blog entries more than a year ago. AFAIK, this situation has not changed to any great degree (I am very willing, and hope that I will be, corrected on this!) If both my PEP vendor(s) (XML Security GW Vendors as well as Software based PEPs) as well as my PDP Vendors (Entitlement/Policy Decisioning engines) trumpet their support for XACML and their ability to exist in a standards based environment, why should I continue to pay for integration between a PEP and a PDP, especially if I've made a decision to externalize my AuthZ (The decision to do so and implement is, as noted, a continuing policy and education problem) ? Regards, - Anil From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of Shivaram Mysore Sent: Tuesday, October 06, 2009 2:03 PM To: Tolbert, John W Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes PDP and PEP acronyms will need expansion. Real life examples in brackets would help. If the survey is for a business person, he would not understand PDP/PEP "Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement. IMHO if PEP and PDP must exist (it does not matter from which vendor they are as the IT has to pay the cost), then the real problem is application integration and migration. /Shivaram On Tue, Oct 6, 2009 at 9:51 AM, Tolbert, John W <john.w.tolbert@boeing.com<mailto:john.w.tolbert@boeing.com>> wrote: I've "simplified" the choices somewhat, and added a few items based on the feedback. Please review at your leisure. Thanks http://kantarainitiative.org/confluence/display/concordia/Authorization+surv... _______________________________________________ Dg-concordia mailing list Dg-concordia@kantarainitiative.org<mailto:Dg-concordia@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-concordia -- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/
Anil, I believe you misunderstood what I said. What I really meant was that the problem exists and *business folks* may not understand what PEP and PDP means. Many may not even understand XACML or other alphabet soup means.
From a problem perspective in simple language: there is significant application integration and migration problem due to currently deployed Policy infrastructure.
The solution to which could be: Deploy XACML Standards based products which will greatly reduce and possibly eliminate application integration & migration costs. /Shivaram On Tue, Oct 6, 2009 at 1:29 PM, John, Anil <Anil.John@jhuapl.edu> wrote:
"Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement.
Would respectfully disagree.. This is a clear and continuing issue, even after the XACML TC sponsored interop that happened at Burton Catalyst a couple of years ago.
I wrote the above two blog entries more than a year ago. AFAIK, this situation has not changed to any great degree (I am very willing, and hope that I will be, corrected on this!)
If both my PEP vendor(s) (XML Security GW Vendors as well as Software based PEPs) as well as my PDP Vendors (Entitlement/Policy Decisioning engines) trumpet their support for XACML and their ability to exist in a standards based environment, why should I continue to pay for integration between a PEP and a PDP, especially if I’ve made a decision to externalize my AuthZ (The decision to do so and implement is, as noted, a continuing policy and education problem) ?
Regards,
- Anil
*From:* dg-concordia-bounces@kantarainitiative.org [mailto: dg-concordia-bounces@kantarainitiative.org] *On Behalf Of *Shivaram Mysore *Sent:* Tuesday, October 06, 2009 2:03 PM *To:* Tolbert, John W *Cc:* kantara Initiative *Subject:* Re: [Dg-concordia] AuthZ survey changes
PDP and PEP acronyms will need expansion. Real life examples in brackets would help. If the survey is for a business person, he would not understand PDP/PEP
"Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement.
IMHO if PEP and PDP must exist (it does not matter from which vendor they are as the IT has to pay the cost), then the real problem is application integration and migration.
/Shivaram
On Tue, Oct 6, 2009 at 9:51 AM, Tolbert, John W < john.w.tolbert@boeing.com> wrote:
I've "simplified" the choices somewhat, and added a few items based on the feedback. Please review at your leisure. Thanks
http://kantarainitiative.org/confluence/display/concordia/Authorization+surv...
_______________________________________________ Dg-concordia mailing list Dg-concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia
-- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/
-- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/
Shivaram, Concur w/ you on the potential lack of understanding of the value of externalized AuthZ by certain business folks. Having said that, the impression I get is that this survey was targeted to folks who were more on the technology side rather than the business side. John? Regards, - Anil From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of Shivaram Mysore Sent: Wednesday, October 07, 2009 7:35 PM To: John, Anil Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes Anil, I believe you misunderstood what I said. What I really meant was that the problem exists and business folks may not understand what PEP and PDP means. Many may not even understand XACML or other alphabet soup means.
From a problem perspective in simple language: there is significant application integration and migration problem due to currently deployed Policy infrastructure.
The solution to which could be: Deploy XACML Standards based products which will greatly reduce and possibly eliminate application integration & migration costs. /Shivaram On Tue, Oct 6, 2009 at 1:29 PM, John, Anil <Anil.John@jhuapl.edu<mailto:Anil.John@jhuapl.edu>> wrote:
"Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement.
Would respectfully disagree.. This is a clear and continuing issue, even after the XACML TC sponsored interop that happened at Burton Catalyst a couple of years ago. http://bit.ly/4NATB http://bit.ly/6HfEn I wrote the above two blog entries more than a year ago. AFAIK, this situation has not changed to any great degree (I am very willing, and hope that I will be, corrected on this!) If both my PEP vendor(s) (XML Security GW Vendors as well as Software based PEPs) as well as my PDP Vendors (Entitlement/Policy Decisioning engines) trumpet their support for XACML and their ability to exist in a standards based environment, why should I continue to pay for integration between a PEP and a PDP, especially if I've made a decision to externalize my AuthZ (The decision to do so and implement is, as noted, a continuing policy and education problem) ? Regards, - Anil From: dg-concordia-bounces@kantarainitiative.org<mailto:dg-concordia-bounces@kantarainitiative.org> [mailto:dg-concordia-bounces@kantarainitiative.org<mailto:dg-concordia-bounces@kantarainitiative.org>] On Behalf Of Shivaram Mysore Sent: Tuesday, October 06, 2009 2:03 PM To: Tolbert, John W Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes PDP and PEP acronyms will need expansion. Real life examples in brackets would help. If the survey is for a business person, he would not understand PDP/PEP "Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement. IMHO if PEP and PDP must exist (it does not matter from which vendor they are as the IT has to pay the cost), then the real problem is application integration and migration. /Shivaram On Tue, Oct 6, 2009 at 9:51 AM, Tolbert, John W <john.w.tolbert@boeing.com<mailto:john.w.tolbert@boeing.com>> wrote: I've "simplified" the choices somewhat, and added a few items based on the feedback. Please review at your leisure. Thanks http://kantarainitiative.org/confluence/display/concordia/Authorization+surv... _______________________________________________ Dg-concordia mailing list Dg-concordia@kantarainitiative.org<mailto:Dg-concordia@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-concordia -- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/ -- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/
Yes, we're targeting technologists and/or technical business analysts for this survey. ________________________________ From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of John, Anil Sent: Thursday, October 08, 2009 6:48 AM To: Shivaram Mysore Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes Shivaram, Concur w/ you on the potential lack of understanding of the value of externalized AuthZ by certain business folks. Having said that, the impression I get is that this survey was targeted to folks who were more on the technology side rather than the business side. John? Regards, - Anil From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of Shivaram Mysore Sent: Wednesday, October 07, 2009 7:35 PM To: John, Anil Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes Anil, I believe you misunderstood what I said. What I really meant was that the problem exists and business folks may not understand what PEP and PDP means. Many may not even understand XACML or other alphabet soup means.
From a problem perspective in simple language: there is significant application integration and migration problem due to currently deployed Policy infrastructure.
The solution to which could be: Deploy XACML Standards based products which will greatly reduce and possibly eliminate application integration & migration costs. /Shivaram On Tue, Oct 6, 2009 at 1:29 PM, John, Anil <Anil.John@jhuapl.edu<mailto:Anil.John@jhuapl.edu>> wrote:
"Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement.
Would respectfully disagree.. This is a clear and continuing issue, even after the XACML TC sponsored interop that happened at Burton Catalyst a couple of years ago. http://bit.ly/4NATB http://bit.ly/6HfEn I wrote the above two blog entries more than a year ago. AFAIK, this situation has not changed to any great degree (I am very willing, and hope that I will be, corrected on this!) If both my PEP vendor(s) (XML Security GW Vendors as well as Software based PEPs) as well as my PDP Vendors (Entitlement/Policy Decisioning engines) trumpet their support for XACML and their ability to exist in a standards based environment, why should I continue to pay for integration between a PEP and a PDP, especially if I've made a decision to externalize my AuthZ (The decision to do so and implement is, as noted, a continuing policy and education problem) ? Regards, - Anil From: dg-concordia-bounces@kantarainitiative.org<mailto:dg-concordia-bounces@kantarainitiative.org> [mailto:dg-concordia-bounces@kantarainitiative.org<mailto:dg-concordia-bounces@kantarainitiative.org>] On Behalf Of Shivaram Mysore Sent: Tuesday, October 06, 2009 2:03 PM To: Tolbert, John W Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes PDP and PEP acronyms will need expansion. Real life examples in brackets would help. If the survey is for a business person, he would not understand PDP/PEP "Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement. IMHO if PEP and PDP must exist (it does not matter from which vendor they are as the IT has to pay the cost), then the real problem is application integration and migration. /Shivaram On Tue, Oct 6, 2009 at 9:51 AM, Tolbert, John W <john.w.tolbert@boeing.com<mailto:john.w.tolbert@boeing.com>> wrote: I've "simplified" the choices somewhat, and added a few items based on the feedback. Please review at your leisure. Thanks http://kantarainitiative.org/confluence/display/concordia/Authorization+surv... _______________________________________________ Dg-concordia mailing list Dg-concordia@kantarainitiative.org<mailto:Dg-concordia@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-concordia -- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/ -- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/
BTW, since we're not necessarily going for the *exact same* populations for the next two surveys, if we announce/market this right, we might not confuse people if we really need to run them simultaneously. But it's still probably better if we separate them in time. The more we can pre- qualify the audience(s) for survey-taking, the better. Eve On 8 Oct 2009, at 10:56 AM, Tolbert, John W wrote: > Yes, we're targeting technologists and/or technical business > analysts for this survey. > > From: dg-concordia-bounces@kantarainitiative.org [mailto:dg- > concordia-bounces@kantarainitiative.org] On Behalf Of John, Anil > Sent: Thursday, October 08, 2009 6:48 AM > To: Shivaram Mysore > Cc: kantara Initiative > Subject: Re: [Dg-concordia] AuthZ survey changes > > Shivaram, > > Concur w/ you on the potential lack of understanding of the value of > externalized AuthZ by certain business folks. Having said that, the > impression I get is that this survey was targeted to folks who were > more on the technology side rather than the business side. > > John? > > Regards, > > - Anil > > From: dg-concordia-bounces@kantarainitiative.org [mailto:dg- > concordia-bounces@kantarainitiative.org] On Behalf Of Shivaram Mysore > Sent: Wednesday, October 07, 2009 7:35 PM > To: John, Anil > Cc: kantara Initiative > Subject: Re: [Dg-concordia] AuthZ survey changes > > Anil, > > I believe you misunderstood what I said. What I really meant was > that the problem exists and business folks may not understand what > PEP and PDP means. Many may not even understand XACML or other > alphabet soup means. > > >From a problem perspective in simple language: there is significant > application integration and migration problem due to currently > deployed Policy infrastructure. > > The solution to which could be: Deploy XACML Standards based > products which will greatly reduce and possibly eliminate > application integration & migration costs. > > > /Shivaram > > On Tue, Oct 6, 2009 at 1:29 PM, John, Anil <Anil.John@jhuapl.edu> > wrote: > >"Ability to mix and match PDPs and PEPs from different vendors __" > - may be too heavy a statement. > > Would respectfully disagree.. This is a clear and continuing issue, > even after the XACML TC sponsored interop that happened at Burton > Catalyst a couple of years ago. > > http://bit.ly/4NATB > http://bit.ly/6HfEn > > I wrote the above two blog entries more than a year ago. AFAIK, this > situation has not changed to any great degree (I am very willing, > and hope that I will be, corrected on this!) > > If both my PEP vendor(s) (XML Security GW Vendors as well as > Software based PEPs) as well as my PDP Vendors (Entitlement/Policy > Decisioning engines) trumpet their support for XACML and their > ability to exist in a standards based environment, why should I > continue to pay for integration between a PEP and a PDP, especially > if I’ve made a decision to externalize my AuthZ (The decision to do > so and implement is, as noted, a continuing policy and education > problem) ? > > Regards, > > - Anil > > > > > From: dg-concordia-bounces@kantarainitiative.org [mailto:dg- > concordia-bounces@kantarainitiative.org] On Behalf Of Shivaram Mysore > Sent: Tuesday, October 06, 2009 2:03 PM > To: Tolbert, John W > Cc: kantara Initiative > Subject: Re: [Dg-concordia] AuthZ survey changes > > PDP and PEP acronyms will need expansion. Real life examples in > brackets would help. If the survey is for a business person, he > would not understand PDP/PEP > > "Ability to mix and match PDPs and PEPs from different vendors __" - > may be too heavy a statement. > > IMHO if PEP and PDP must exist (it does not matter from which vendor > they are as the IT has to pay the cost), then the real problem is > application integration and migration. > > /Shivaram > > On Tue, Oct 6, 2009 at 9:51 AM, Tolbert, John W <john.w.tolbert@boeing.com > > wrote: > I've "simplified" the choices somewhat, and added a few items based > on the feedback. Please review at your leisure. Thanks > > http://kantarainitiative.org/confluence/display/concordia/Authorization+survey+draft > > _______________________________________________ > Dg-concordia mailing list > Dg-concordia@kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/dg-concordia > > > > > -- > Strong Authentication, SOA, Web Services, PKI, Software > Architecture, Product Strategy and Management Consultants: > http://www.truststix.com/ > > > > -- > Strong Authentication, SOA, Web Services, PKI, Software > Architecture, Product Strategy and Management Consultants: > http://www.truststix.com/ > _______________________________________________ > Dg-concordia mailing list > Dg-concordia@kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/dg-concordia Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog
John: I hope I'm not out-of-line commenting on your survey here, since I just joined this DG and I don't know what its status is right now. That point aside, it seems to me that you are assuming that your audience can distinguish between AuthN, AuthZ and 'access management', 'access control' or other variant on the term. It's very easy to confound the term authorization with access management. Example: Q2: Do you currently have a centralized authorization system? To my mind, the Q would make more sense if it were re-stated to 'access management system' That would include some sort of AuthZ sub-system. That in turn would make replies to Q3 easier - What type of authorization system do you use? Wouldn't most people understand the Q better if it said What type of access management system do you use? So, it may be useful to have a short explanation at the beginning to clarify these terms. Then there is the fact that AuthZ can be divided up into coarse and fine-grained. It's one thing to externalize coarse-grained AuthZ via AD Security Groups or similar, but fine-grained is another story. For example, many of our CICS-based financial apps implement a local registry to manage permissions on CICS transactions. This is where the complexity/expense starts (esp. if you're thinking about generalizing AuthZ across a range of such apps). Wouldn't it be useful if you could tease out what installations are doing to decouple fine/coarse grained AuthZ? Or are they leaving these apps in place and building or buying a permissions layer that will map to app-level permissions? Gavin Illingworth Enterprise Architecture, Technology Development | BMO Financial Group | 120 Bloor St E, Toronto, ON M4W 3X1 Telephone: 416.513.5652 E-mail: gavin.illingworth@bmo.com<mailto:gavin.illingworth@bmo.com> ________________________________ From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of Tolbert, John W Sent: October 8, 2009 1:57 PM To: John, Anil; Shivaram Mysore Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes Yes, we're targeting technologists and/or technical business analysts for this survey. ________________________________ From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of John, Anil Sent: Thursday, October 08, 2009 6:48 AM To: Shivaram Mysore Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes Shivaram, Concur w/ you on the potential lack of understanding of the value of externalized AuthZ by certain business folks. Having said that, the impression I get is that this survey was targeted to folks who were more on the technology side rather than the business side. John? Regards, - Anil From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of Shivaram Mysore Sent: Wednesday, October 07, 2009 7:35 PM To: John, Anil Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes Anil, I believe you misunderstood what I said. What I really meant was that the problem exists and business folks may not understand what PEP and PDP means. Many may not even understand XACML or other alphabet soup means.
From a problem perspective in simple language: there is significant application integration and migration problem due to currently deployed Policy infrastructure.
The solution to which could be: Deploy XACML Standards based products which will greatly reduce and possibly eliminate application integration & migration costs. /Shivaram On Tue, Oct 6, 2009 at 1:29 PM, John, Anil <Anil.John@jhuapl.edu<mailto:Anil.John@jhuapl.edu>> wrote:
"Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement.
Would respectfully disagree.. This is a clear and continuing issue, even after the XACML TC sponsored interop that happened at Burton Catalyst a couple of years ago. http://bit.ly/4NATB http://bit.ly/6HfEn I wrote the above two blog entries more than a year ago. AFAIK, this situation has not changed to any great degree (I am very willing, and hope that I will be, corrected on this!) If both my PEP vendor(s) (XML Security GW Vendors as well as Software based PEPs) as well as my PDP Vendors (Entitlement/Policy Decisioning engines) trumpet their support for XACML and their ability to exist in a standards based environment, why should I continue to pay for integration between a PEP and a PDP, especially if I've made a decision to externalize my AuthZ (The decision to do so and implement is, as noted, a continuing policy and education problem) ? Regards, - Anil From: dg-concordia-bounces@kantarainitiative.org<mailto:dg-concordia-bounces@kantarainitiative.org> [mailto:dg-concordia-bounces@kantarainitiative.org<mailto:dg-concordia-bounces@kantarainitiative.org>] On Behalf Of Shivaram Mysore Sent: Tuesday, October 06, 2009 2:03 PM To: Tolbert, John W Cc: kantara Initiative Subject: Re: [Dg-concordia] AuthZ survey changes PDP and PEP acronyms will need expansion. Real life examples in brackets would help. If the survey is for a business person, he would not understand PDP/PEP "Ability to mix and match PDPs and PEPs from different vendors __" - may be too heavy a statement. IMHO if PEP and PDP must exist (it does not matter from which vendor they are as the IT has to pay the cost), then the real problem is application integration and migration. /Shivaram On Tue, Oct 6, 2009 at 9:51 AM, Tolbert, John W <john.w.tolbert@boeing.com<mailto:john.w.tolbert@boeing.com>> wrote: I've "simplified" the choices somewhat, and added a few items based on the feedback. Please review at your leisure. Thanks http://kantarainitiative.org/confluence/display/concordia/Authorization+surv... _______________________________________________ Dg-concordia mailing list Dg-concordia@kantarainitiative.org<mailto:Dg-concordia@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-concordia -- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/ -- Strong Authentication, SOA, Web Services, PKI, Software Architecture, Product Strategy and Management Consultants: http://www.truststix.com/
participants (5)
-
Eve Maler -
Illingworth, Gavin -
John, Anil -
Shivaram Mysore -
Tolbert, John W