On 7/12/07, Elliot Lee <[EMAIL PROTECTED]> wrote:
Hi Dave and others,
Looks like an interesting start. Here are some comments :)
On externalizing user management...
Abstracting the directory of user profiles: In 2.1.2 (Possible
solutions), possible solution #1, you state that the user object is
needed because it's used in joins and queries. There's no fundamental
reason that I can see why it is needed in the big picture. The only
thing you really need to know about the user is a unique identifier.
Roller looks like it uses random hex strings, while Lulu's system
happens to use consecutive integers. Unless hibernate requires The
userID should be the only thing that needs to be stored within Roller -
all the other details should be retrieved from the UserDirectory on
demand. I don't know if hibernate needs a user table there just to
satisfy foreign key constraints from other objects that are owned by a
user, though.
Perhaps I'm being to conservative here, but I'd like to keep our
existing queries and foreign key relationships in-tact for users.
User profile modification: It's definitely nice to abstract this at the
API level, but I think it's also important to take it into account at
the UI level. Some installations (e.g. Lulu) may want to require users
to use their own UI's for editing settings such as password, locale,
etc. It's worth considering a bit more about how this abstracting can
happen at the UI layer as well.
For example maybe it'd be good to allow
the sysadmin to configure URLs for a login page, logout page,
registration page, profile editing page, etc.)
Good feedback. I think that should be part of the proposal.
I think it's also important at the API level, a UserDirectory implementation is
not
required to implement the profile saving methods. The profile saving
methods are really important only to the pieces of roller that tie in
with the roller UI's to do that...
Correct. And those methods are only important when Roller is running
standalone without an external user mgmt/perms system.
Authentication: Acegi looked fairly powerful & flexible for Lulu's
needs. It seemed reasonably easy to implement a
LuluAuthenticationProvider. I think the main hangup was more on the
roller side - the implicit passing of RollerUserDetails between Acegi
and CustomUserRegistry seems like a hack. I guess this is really more a
problem on the user directory side of things than in the actual
authentication functionality, though. If Acegi is going to continue to
be an option, it needs to be made clear how acegi authentication
providers are going to provide directory info to Roller.
I definitely want Acegi to remain an option so you are correct, my
design needs to account for how externalized auth will work with
Acegi.
On the authorization side of user management: this really seems to tie
in with externalizing user permissions. I see global roles as no
different from per-blog permissions or per-post permissions or
per-comment permissions (etc. etc.) So...
My initial thinking was that global roles come from the Java EE
authorization system but weblog permissions are different because they
are Roller application specific.
After looking at how a couple other popular Java web applications
handle auth/auth and externalization, I'm starting to rethink that.
On externalizing user permissions:
I'm really not big on the approach suggested - it doesn't seem general
enough to allow tying in a wide range of authorization systems. From my
perspective, I'd like to see something like the following:
bool canExecuteOperation(Object subject, String operation, Object
on_object, Object[] context);
'subject' would identify the user who wants to carry out this
particular action (e.g. 'Joe')
'operation' would identify the action the user is trying to
carry out (e.g. 'edit an existing comment')
'on_object' would identify the object (if any) that the user is
trying to execute the operation on (for example 'comment #1234')
'context' could identify some objects that are relevant to the
operation (for example 'blog #43' and 'blog post #432', because Joe is
trying to edit his comment #1234 which was previously submitted to blog
post #432 in blog #43)
The approach above allows for authorization implementations that have no
way to answer the question "what operations is this user allowed to
do?". The Lulu permissions manager is an example - although some of the
yes/no authorization decision is driven by settings stored in the
database, it is mostly code-driven and has to take into account
situations such as moderated submissions, and book listings exclusive to
one group.
At the same time, the approach above should still accommodates
authorization implementations that offer an API similar to the one you
proposed. This approach also allows the authorization system to define
and manage roles internally, and decide how those roles map to specific
operations.
Yes, I like that type of approach better too and I think it aligns
better with standard Java security (principals, policy, etc.).
I'm not sure about including permissions updates/editing in the API.
This mainly goes back to the UI issues mentioned in my comments on
authentication. Yes, Roller has UI to manage permissions, but that's
only because it also has code to manage permissions. The UI for this
feature should be abstracted along with the code, so that the
RollerPermissionsEditingAPI is implemented by the
RollerDefaultPermissionsImplementation code and only used by the
RollerDefaultPermissionsImplementation UI/controller. I think it's
fairly likely that plugging in new authorization systems will require
plugging in new UI as well.
Yes, when Roller is used with an externalized perms system the
existing Roller permssions UI should be disabled, do we also need
links to the external perms management UI?
There are lots of pieces of Roller that I don't understand yet, which
means a lot of this may be totally off. Please let me know what doesn't
make sense :)
Thanks for the feedback. I'm working on another rev of the proposal now.
- Dave
