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.
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.) 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...
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.
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...
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.
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.
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 :)
Best,
-- Elliot
Dave wrote:
I'm working on two new proposals (see below) for externalizing user
and permissions management, which is something that I need and others
have requested, for example Elliot of Lulu.com and James Snell of IBM.
These proposals are not complete, but I'd like to get some feedback
now before I go too far into design.
So, interested parties, please take a look and provide feedback. Does
this meet our common requirements for externalized user profiles and
permissions? What about the implementation? See any red flags for
performance or scalability?
