Hi All.
Sorry to come in late to the conversation. While I
have been composing this email, you all have started
writing code...
Security means different things in different contexts,
but from following the discussion it seems that
Turbine's security needs are primarily: Authentication
-- verify the user's identity Authorization -- limit
what users are allowed to do
Many systems have those same needs, and Authorization
typically
includes some combination of the following:
abstractions for users,
abstractions for "stuff",
permissions, and
roles or groups
I've seen quite a few different security models. I
think the similarities are greater than the
differences. The fundamental differences boil down to
these issues: 1) are permissions attached to the user,
or attached to the stuff? 2) are users members of
groups, or do they have roles? 3) are the permissions
hierarchical?
For example, WinNT/2K ACLs have permissions attached to
the stuff, specifically to the files and directories.
By contrast, Turbine ACLs attach permissions to the
user (indirectly via roles). Java's Security (not JAAS)
is about protecting computer resources from malicious
programs -- permissions are granted to programs
("stuff") to gain access to system resources (other
"stuff"). Most databases grant permissions to users.
JAAS extends this idea to say that some chunk of code
is granted some permission provided that code is being
run by a particular user or to a user who is playing a
particular role. Permissions are attached to both
stuff and users.
Santiago already made this distinction earlier in the
thread, but I thought I would draw more attention to
it. User preferences and personalization confuse
security matters.
Personalization requires very similar programming to
authorization. Based on information you have about
the user you want to change the display to fit their
preferences, as opposed to their permissions.
Having said all of that, let me now comment directly
on a few items from the thread...
On Monday, January 14, 2002, at 10:15 PM, Jason van Zyl wrote:
> The security models used by Scarab and SourceCast are probably the most
> sophisticated security model that any application would ever need, that
> being the case I think it would be rare that many applications would
> need
> that level of sophistication.
I disagree. I happen to be building "enterprise
solutions". I know that not everyone else is but in my
experience, security needs quickly grow to require
sophisticated solutions, even in seemingly small webapps.
> I think trying to accommodate aspects of all security models into a
> single
> one is a lost cause. I think we should look for the places where
> security
> applies to Turbine and find a way for the core to use any model that a
> project wishes to use.
+1 I've tried to start that process above.
> From a simple password text file model all the way up
> to a sophisticated model like Scarab's. What we currently have is too
> complicated for most uses and we should allow application programmers to
> choose the model they wish to use.
Here I disagree in particular about the "too complicated" part.
In this area, the problem with what currently exists is a lack of
documentation and not one of complexity. And the TDK offers no
instructive example, so users are pointed at Scarab which isn't
using the default implementation anyway. Then add the misleading
name "TURBINE_GROUP" and all of it's associated confusion....
I favor adopting a more sophisticated model, provided we also
include sufficient documentation and examples. (And because I'm
sure *someone* will ask ;^) Yes, I am willing to contribute to
documentation once we agree on something.
> I think trying to accommodate aspects of all security models into a
> single
> one is a lost cause.
Agreed, which is why I like this suggestion from Santiago:
On Tuesday, January 15, 2002, at 04:55 AM, Santiago Gala wrote:
> Separating the service in this three components/subservices will help
> isolate clean interfaces between them (The work is partially done, as
> we have a UserManager in turbine, and also a AccessController). This
> will help clean any implementation we do, and will allow for easy
> interoperation of different implementations. It will also make audits
> simpler, since the code of each sub-component will be simpler and more
> focused.
I'm not sure how it will look in code, but I like the idea of
several specialized and loosely coupled security services.
Here's Santiago's three (I'll elaborate on this a bit below):
> 1- Authentication
> 2- AccessControl
> 3- User Management/Profiling
>
> 1 means giving a credential to the service and getting back a (set of)
> Principal/Subject, you name it.
> 2 means that, for a certain request and a certain authenticated User
> (Principal/Subject/whatever), you can derive a set of Permissions that
> are valid. Here is where things like Permission, Group, Role, ... belong
> 3 means ways to create, store, ... users and information related to
> users , like user preferences, etc.
I would like to expand on the AccessControl item in
particular. I'd like to see the system support either
user-centric or stuff-centric permissions.
Sometimes you want to build a cage around the crown
jewels (stuff-centric) and sometimes you want to
prevent people from entering a sensitive part of the
castle (user-centric). These are complementary but not
synonymous needs. And the AccessControl (or
Authorization) should support both modes.
I also like this list from Dan D
On Tuesday, January 15, 2002, at 12:38 PM, Dan Diephouse wrote:
> Permissions - read, write, delete, update...etc.
> Roles - Admin (has read,write,delete, update); User ( read, update) and
> so on.
> Group (or Application) - Project Management, Contact Database.
> ProjectGroup - Marketing Campaign for XXX, TV Ads for ABC Inc.
But we gotta clear up the "group" confusion:
Permissions
Roles - Admin, Editor, Contributor, User
Group - *
Project (or Module) - Project Management, Contact DB, Inventory...
Application - a collection of Projects (or Modules).
* Please! A "Group" must be a group of people. It is
completely counter-intuitive and confusing to use
"Group" to describe a collection of functional
elements, particularly in the context of user
authorization. This is the heart of the TURBINE_GROUP
confusion and one of the crucial things to be changed
by the new security framework.
Either use "group" to mean a group of people, or don't
use "group". (ProjectGroup is okay 'cos it's explicit
about what it's grouping.)
I would also prefer that the system allow permissions
to be attached to Roles or Groups or both. (This has
the potential to be confusing and will be another thing
that will require clear documentation).
Different people want to group people differently.
Some group by organizational units (Development,
Marketing, Finance), or by geographical region (US
West, US Central, EU North, Asia Pacific Rim,) or
whatever. Some prefer to assign Permissions along
these categories rather than by roles, or in
addition to roles within those groupings.
I've got more thoughts, but I should send this now and
see what you think before you get a complete system
implemented under my nose ;^)
-Eric
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
