> I have been
> unable to connect to cvs.apache.org, so I really cannot comment about
> the current state of the code.
I was finally able to update my working copy. Here are my comments.
It is not a good idea that there are lots of files in o.a.t.security.
If I ever said "go ahead", I was wrong.
I have finally understood Eric's proposal regarding Subjects and
Principals. A Subject (a user) can be known by many names (Principals),
such as Joe, uid=42, whatever; each name is associated with a set of
permissions; it doesn't make any sense to ask what a Subject's set of
permissions is; it makes sense to ask what a Subject's Principal's
set of permissions is. Is that a correct understanding? Now, could
anybody show a real-life example of the use of this? Because I would
have thought that, no matter how a Subject is known, the permissions
for that Subject should be the same.
I concur in disliking Policy as a replacement for SecurityManager.
I don't really see the idea of Project as belonging in a generic security
implementation.
To summarize, here is the way I still think things should be approached:
* An empty SecurityManager in o.a.t.s, and NOTHING ELSE (we still haven't
thought how we will make this part pluggable; for now, Turbine will
have to instantiate an object of an specific class, something like
TurbineSecurityManager).
* A default implementation under o.a.t.s.turbine, with the following
characteristics:
1. As simple as possible.
2. Knows how to answer "is this a valid user?".
3. Knows how to answer "can this user do this?".
Period, nothing else, nada, zilch, niente, rien.
* Pluggability would be nice for the default implementation. My ideas
along these lines, and regarding the previous point, are:
1. Basic objects: Subject, Permission, Credentials.
2. "logic" objects: Authenticator (knows how to answer the "valid user"
question) and Authorizer (knows how to answer the "can do this"
question).
3. The default SecurityManager knows how to read from a config file
the names for the concrete classes to be used as Subject,
Permission, Credentials, Authenticator and Authorizer.
4. The default implementation for all this is a null security
manager: users are ALWAYS valid, and can do ANYTHING.
The only part missing from what I had committed is point 3; TSM was
returning fixed classes for the objects. But it still can be used
as an empty SM.
> > I am about get the fulcrum security stuff working so I would
> like to push
> > all currently proposed security code into o.a.t.security.turbine so it's
> > self contained and make a new o.a.t.security.fulcrum package
> where I will
> > bundle all the classes that are bound to fulcrum.
>
> I'm not really sure what you mean here... What do you intend to put in
> o.a.t.s.fulcrum? (Keep in mind I don't know the current state of
> the repo).
I still don't know what you plan to do with fulcrum. Moreover, I would
like to know if the basic functionality of TSM as I implemented it is
good enough for your purposes:
Subject getSubject(String id)
Permission getPermission(String id)
Authenticator getAuthenticator(Subject subject)
=> boolean checkSubjectCredentials(Subject subject,
Credentials credentials)
Authorizer getAuthorizer(Subject subject)
=> boolean checkSubjectPermission(Subject subject,
Permission permission)
Maybe the last two could be collapsed into a single call through
TSM, so that the caller would never know about Authenticators and
Authorizers:
boolean checkSubjectCredentials(Subject subject,
Credentials credentials)
boolean checkSubjectPermission(Subject subject,
Permission permission)
> I disagree. The code in fulcrum makes explicit use of Roles and Groups.
> One of the big pushes in the new design is to simplify as much as possible
> the design. I'm not saying Roles and Groups are bad or anything; in fact,
> I like role-based security, and probably would use it almost everywhere.
> But the basic implementation should be that: basic. And of course it
> should allow for role-based security.
This is a good example of the flexibility of Authorizers: you could define
a new authorizer, RoleGroupAuthorizer, that would answer the call to
checkSubjectPermission by checking if the user inherits the permission
through any of his roles in the current group. Notice that you could do
this in a completely independent manner on how the user is authenticated
(against LDAP, /etc/passwd, whatever).
Finally, since there seem to be several, pretty different proposals floating
around, how about this: I recommit my proposal under o.a.t.s.gonzo, an Eric
does likewise under o.a.t.s.eric. We leave a SINGLE file under o.a.t.s,
the empty interface SecurityManager. Jason chooses whatever implementation
he wants. Opinions?
--
Gonzalo A. Diethelm
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
