Ian GlazerYesterday, I delivered the keynote to a federated attribute-based access control (ABAC) symposium. For those of you keeping score at home this is the 3rd of *BAC approaches for authorizing individuals. The 1st *BAC, IBAC – identity-based access control – was essentially so trivial that it never got any good marketing*. The 2nd, RBAC – role-based access control – was so popular as to get its own site at NIST.
The idea behind ABAC is that a policy-decision point (PDP) using a set of evaluation criteria examines the attributes that a digital persona presents. The PDP decides whether given the set of attributes if the persona is authorized to perform the requested action. (I’m using persona here but keep in mind that this could be a device or service asking to do something and not strictly a person-like object.) This style of architecture allows the PDP to consider context as well, such a time of day, authenticator time, transaction value, and so on. Just in case you think you seen this before under and different name – finer-grained authorization systems can perform ABAC and depending on who you talk to people will freely swap between the two concepts. (This is damn confusing btw.)
I heard something at this symposium that bothered me. Participants swept under the rug the matters of the relationships between the individual, their home organization, and the relying parties. Instead, I heard people saying, “Well as long as the attributes are good, that’s all I care about.” This reminded me of the following blog post I read.
True, relationships can be represented as an attribute, but the two are different things. Not considering relationships and only focusing on which attributes mean what puts you in a situation to loose the identity forest for the trees. Focusing solely on relationships won’t enable you to write meaningful authorization policies. You’ve got to consider both attributes and relationships.
For your reading pleasure, here’s the presentation I gave. It contains a sneak-peak at Bob’s presentation on the emerging identity architecture. BTW, if you come to Catalyst next week, you’ll get to hear him deliver the complete version which is something not to miss!
PS – I will not be giving out a prize for someone who comments that I didn’t mention ZBAC. That includes wise-ass Catalyst speakers… you know who you are.
* Yes, I know that’s a major over-simplification…
Category: Identity Management Market Tags: #cat10, #fedabac, abac, federation, fga, idm
8 responses so far ↓
1 Tweets that mention Attributes and relationships: Federated ABAC -- Topsy.com July 20, 2010 at 6:34 pm
[...] This post was mentioned on Twitter by Gartner, Ian Glazer. Ian Glazer said: Here's the link to the post: http://bit.ly/cOrD4x #fedabac [...]
2 Saqib Ali July 21, 2010 at 12:02 am
Not to be too critical, but the slideshare presentation is not easy to follow. I have an IdM background, and I had a hard time following the slides. Slideshare presentation usually stand on their own, and usually not require someone speaking to them. If this is too complex of a subject to explain without speaking to the slides, than I would suggest adding audio to the slides – like what Chris Messina usually does.
Just a suggestion…..
3 Dave Kearns July 21, 2010 at 11:15 am
Actually, ABAC should be 4th – CBAC (Context BAC) was 3rd. ABAC is simply a extension of RBAC incorporating CBAC – but it certainly is a step in the right direction!
4 Ian July 21, 2010 at 11:50 am
Referring to ABAC as “simply” anything is a bit of a stretch.
Good point Dave.
5 shrdlu July 21, 2010 at 9:06 pm
Good point on the relationships, and thanks for the link. I think of relationships more as the local interpretation of the relevant attributes. An identity with attributes B+C might equal entitlement D in my business rules at org B because of the nature of our current relationship with org C, but nowhere else. Relationships can be extremely fluid and so can’t always be managed in the *BAC system well. I’m building an RDBMS right now to manage attributes and their relationships for this very reason.
6 Ian Glazer July 22, 2010 at 10:57 am
@shrdlu – You are exactly right about relationships being fluid. My concern is that when people attempt to render a relationship into a *BAC representation the loss in fidelity is major. I worry that people think that their representations of relationships are high-fidelity when in fact they are not.
R-cards are one approach to representing relationships with a higher level of fidelity but I’m not sure if they really fit the bill. I’ll let @Windley address that.
7 Robin Wilton July 22, 2010 at 11:11 am
ABAC and CBAC are clearly not disjunct sets, as Dave points out. While, in one sense, “context” data is ‘just another attribute’, it’s also almost always the case that a given authentication or authorization decision will factor in more attributes than are conveyed by the protocol in question.
I think that over the last 9 years or so (particularly in Federation Land), “attribute” has tended to be used (whether knowingly/explicitly or not) as shorthand for “piece of data about an entity which is exchanged because it happens to be part of a credential, or as a discrete assertion”.
To that extent, “attribute” has, I think, tended to mean “data in motion between IDPs/APs and SPs”, rather than ‘other contextual data which might be factored into the decision’.
8 shrdlu July 23, 2010 at 3:49 pm
@Ian — then again, the loss of fidelity is major for just about *everything* in life that you try to capture in computer data
@Robin — yes, it’s clear that we have to keep resetting our understanding of the word “attribute” (along with other IdM jargon) every so often. My personal feeling is if you have a consensus on interpretation within your own enterprise, it’s okay to “misuse” it for your own ends. Of course, that gets blown out of the water again as soon as you federate …