Hello,
here a few things that the Boleslaw post make me think of :
// ***********************************************
1) Identity Model
// ***********************************************
yes for all.
plus : the Model could be open/extendable with general java object (in the
properties/attributes).
There is this in the user profile properties mechanisme, but it may be with direct access
from the user (see here under).
The java objects would contains all the details of the users, that are company specific.
Informations that are implied in the authorization processing
Such as :
- Organisation, subsidiary, department the User belong to.
- Activity the user is working in (call center, accounting, ...)
All these information are not "portal requiered", but the portal user may carry
the one that are involved in the authorization processing.
There is an example of this in the UserDetail concept/class in Acegi.
Then the authorization manager can be the same for all the application (portal and other
company application). Easier for integration, maintenance... and security reliability.
// ***********************************************
1 bis) Identity Model processing (create, modify, suspend, suppress...)
// ***********************************************
I have just found another problem in the Identity Services.
Lets say the UserBP (business process <=> company User) has a typical Audit
capability (creator id, creator date, modifier id, modifier date).
This audit capability is typical to know who has created the user, who has modified some
role, and when.
The UserService, as a JMX service, has no idea of all this. With the API methods there is
no way to add this kind of feature to any User/Role manipulation.
I think adding a "IdentityTreatmentContext" parameter in all the methods of the
Identity Services would allow to implement specific treatment in the methods.
It will allow to extend the User/Role features, when creating, modifying, suspending a
user.
The requester that call the method would provide the proper IdentityTreatmentContext and
the specific implementation of the service would do the work with it.
Another example : today, the ldap is queried through the data source, with only one user
defined for all the queries. If the query of the source (ldap, db, legacy) require some
"who is asking this information about a user", the IdentityTreatmentContext
param is a way to extends the Identity Services to this company specific feature.
(this is like the command model of the portal controler... Julien's way of doing ;-).
// ***********************************************
3) Authorization
// ***********************************************
The rule based authorization model seems very good.
I had no time to look at the Seam one.
First time I see something (open source) like that.
On my opinion, could be a separate project of JBoss.
The Authorization processing can be complex : the information requiered to do that work
could be in a property dedicated to that.
The API of User could give direct access to it, and not through the heavy profile property
mechanism.
// ***********************************************
4) Portal - communities
// ***********************************************
As for me, yes, these services/application are part of the whole bunch of application
federated inside a portal. As well as any company application.
// ***********************************************
5 ) Business Process application of the companies
// ***********************************************
I mean any application that is part of the information system of a company.
In a insurance company I worked for recently, the portal is used to provide the tool to
any employee, with the internal business application (no forum, no google gadget...).
The issue in this case is to provide the user identification and authorization to the
portal, that is related to the business process authorisation.
Example : a user has the authorization to provide a proposal to a customer (very fine
grained security model).
Another one has the authorization for only viewing a proposal, but not build one.
The portal must see, for both, the authorization to access to the
Page/window/instance/portlet that provide the "proposal builder" (view mode for
all these portalobject).
There is a kind of matrix of the portal authorization against the business authorization.
The rule base mechanism should be usefull for this.
In many cases, the organisation that uses the portal for federating some application will
:
- provide it's source of users and authorization model and implementation
- plug this into the portal api and services
- rewrite all the user/role administration tools (as a user is never created "from
scratch", but belong to a sub organisation, department, etc...). Or use it's own
other tool for user admin.
// ***********************************************
A) naming
// ***********************************************
User and Role is short and nice.
but in an organisation, the portal is one application among the other.
the "User" and "Role" are the word used to talk about the one of the
company : wider definition of User and Role than the one for the portal.
I would name these interface "UserPortal" and "RolePortal", and let
free the User and Role class names.
Even with packaging, it is more clear for java developers.
When building a bridge between the User/Role for the portal and the User/Role from the
business process, the code is much more precise and clear.
// ***********************************************
Globally :
// ***********************************************
- the portal Identity framework must support only what is requiered for the portal. It is
a sub part of the organisation identity/security definition.
- provide a very extendable api with a "mechanism of bridge" between the
User/Authorisation feature for the portal, and the global one of the company.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079589#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...