[Seaside] Implementing RBAC in Seaside

[Nevin Pratt]

Christopher Petrilli wrote:

>Before I start work on this myself, I was wondering if anyone has an
>existing authentication framework that also takes into account
>permissions and roles with objects? It seems to me that Seaside, and
>Smalltalk, are great for this, but I've seen no work done on it.
>
>Any thoughts?
>
>Chris
>  
>

I experimented with this some years ago.  I have always felt that the 
proper answer to a question depends on who is asking the question.  For 
example, if I were to ask what your salary is, or what your credit card 
number is, you are likely to give me an entirely different answer than 
if your wife asks you the same question.  By analogy, this would also 
mean that an object's response to a message send should depend on who 
the sender is.  Right now, Smalltalk just acts like a dumb parrot, and 
spews out a response to the message regardless of who sent the message.  
Not very intelligent, in my opinion.

The basic idea goes like this: first, use the Unix permissions as a 
model (e.g., "OWNER, GROUP, WORLD").  This means each class would have 
three groups of messages: (1) a group of messages that are valid if the 
sender is the OWNER (I'll define what is meant by OWNER in a minute), 
(2) a group of messages that are valid if the sender is in the GROUP, 
and (3) a group of messages that are valid if the sender is anyone else 
(eg, WORLD).

Each class would therefore have three different implementations of each 
selector (although some implementations might be empty; e.g. 
non-existant), and the correct implementation of a given selector would 
be dynamically chosen at runtime, depending on who the sender of the 
message is.

The OWNER of an object is anybody in a chain of authority over the 
object, and is role-specific.  Therefore, the OWNER is runtime selected 
based on the current role.  For example, if you were an instance of 
INDIVIDUAL, and you were currently in the role of EMPLOYEE, then your 
OWNER is your boss (and his OWNER under that same role would be his 
boss, etc.).

So, if you had an instance of INDIVIDUAL with a role of EMPLOYEE, then 
another INDIVIDUAL (i.e., the employee's boss) would be the OWNER.  
Thus, if the boss sent the message, your response would be different 
than if, say, a customer sent the message.

You could build an entire security model on this.  In fact, I did.  The 
way the system behaved for you would depend entirely on what your role 
was, which in turn would depend on what password you provided.  Your 
password determined your role, which in turn determined the system-wide 
behavior, right down to the object level.

It got a little funky, though, where the system didn't always do what I 
thought it should.  And, in every case, it turned out that it was doing 
exactly what it should.  It just wasn't particularly easy to debug 
without an entire set of tools (debugger, browser, etc.) specifically 
supporting these ideas.  Consequently, it was too complicated.  So, I 
shelved it.

I still think it's a good idea, though.

Nevin