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
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Locked
