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
Telephone:
416.513.5652
E-mail:
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> 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
_______________________________________________
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/