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/