James Kobielus presents his thoughts on identity

Policies, rules, standards, procedures, groups, and roles: we’ve had a wide-ranging discussion over the past few issues involving your thoughts, dear readers, as well as mine. Today, I’d like to wrap up the major part of the series with the thoughts of one of my Network World colleagues.

James Kobielus, like myself, writes a column for Network World. His “Above the Cloud” column (https://www.nwfusion.com/columnists/kobielus.html) covers many of the same issues as this newsletter, but doesn’t appear as often. The overlap isn’t surprising, since Kobielus spends most of his time as a senior analyst with the Burton Group, which I think might better be known as ITT – the Identity Think Tank.

Kobielus first appeared in this newsletter a couple of years ago when he gently chided me for misusing a term related to Web services. As I said at the time (https://www.nwfusion.com/newsletters/dir/2002/01498830.html) Jim didn’t choose to perform the ‘nyah, nyah, look what you did!’ dance around my prostrate body while pointing and hooting simultaneously (he does have some dignity, after all). How much dignity, though, was called into question a year later (https://www.nwfusion.com/newsletters/dir/2003/0721ds1.html) when he next appeared in a review of the 2003 Catalyst conference. At that time I asked what did people have to do to get a string of beads from the IBM Mardi Gras booth, and why did Kobielus have so many?

Still, he’s always willing to share his well thought out opinion on identity and security issues. This discussion of rules and policies is no different, so here’s what Kobielus thinks about the various ideas that have been presented:

“I agree with you that the fundamental construct is ‘rule,’ not ‘policy.’

“We can conceptualize an information system (centralized, distributed, federated, etc.) as rules of various sorts (security, reliability, orchestration, integration, QoS, management, etc.) that execute on rules engines of various sorts (e.g., application server, proxy, firewall, access management, portal, integration broker) in various deployment roles (departmental, enterprise perimeter, etc.).

“We can conceptualize ‘policy’ as referring to any rule set (i.e., one or more rules) with a well-defined scope, role, engine, administrator, etc.

“A  ‘policy language’ is any language for expressing rules with a particular scope (e.g., XACML for access control, WS-BPEL for orchestration, etc.).

“We can distinguish between policy enforcement points (PEP), which are rules engines; policy administration points (PAP); and policy storage points (PSP).

“Identities (of people, hardware, applications, software components) are the keys to which policies are attached and against which they’re administered.

“A ‘policy access protocol’ would be any protocol or interface (e.g., LDAP, DSML, XQuery) for accessing PSPs, PEPs, and/or PEPs, and a ‘policy management protocol’ would support life-cycle creation, administration, version control, etc of rules/policies on those nodes

“No need to create new access protocols to support ‘policy access’; I’ve pointed to the leading current protocols/interfaces that serve that purpose here and now. As regards a ‘policy management protocol,’ isn’t that whatever version/concurrency/workflow controls are built into and/or supported by your PAP/PSP/PEP?”

We’ll take a break on policy and rules for a bit, now, but please keep sending me your thoughts. In a week or two I’ll do a final wrap-up on the issue (at least for this year). I know, by the way, that whenever I use the word “final” it’s a certainty that it won’t be final. Still, I have to try.