"bdaw" wrote : Sorry for not responding for so long.
|
It doesn't matter, I had enough other to work do ;-)
"bdaw" wrote :
| The whole idea of MembershipModule interface is to decouple Role and User. The reason
is that in LDAP the relationship beetween them can be defined in several different ways -
it's not so straight forward like in DB. So the main difference is NOT to have
Role.getUsers() method. So Role and RoleModule know nothing about User and vice versa. And
the functionallity is moved to MembershipModule to be able to resolve different ways of
relationships just by swaping this module.
|
| I don't understand what .getName() method are you looking for there?
|
Thanks for the explanation, I thought that "Membership" was meant as a
GroupMembership... Since it is not, I see that the getName() method is not needed.
"bdaw" wrote :
| I was discussing your ideas with julien. There are few things in this subject:
|
| 1) Roadmap and features for 2.6 are already defined and we don't want to change
them. The things you propose can be discussed to be placed in 3.0 roadmap - there is a
plan to rethink and redesign this part already. Adding groups in the shape you descrived
will need some changes in management portlets and other work so it's not an option at
the moment.
|
| 2) Still, you can implement this functionality and we can integrate it in portal
codebase as OPTIONAL. So simply it won't be enabled by default, but it can be used by
changing portal configuration. If you agreed on this your code will need to meet few
conditions:
| - it must be written in non intrusive way for what is in portal codebase. So it
can't require changes to portal classes (or at least not much).
| - if you use DB your code can't breake the current schema. So you will probably
need to add separate hibernate configuration with own tables - not a big effort as
currently identity, portal objects and security schemas are also separated.
|
| I think it can be easily done. You can just add Group object and GroupModule that
manage the relationship with User and Role. We can advise you how to plug into hibernate
and etc in non intrusive way.
|
| 3) It may be possible to achive what you want just by providing implementation of
LoginModule. Look at org.jboss.portal.identity.auth.IdentityLoginModule. It's portal
implementation that plugs into JAAS in AS.
| So it could simply discover the group membership of the authenticating user and bind
the relation with portal roles.
|
| How do you feal about it?
|
I feel good about it, because I know a bit about software development, roadmaps and
"last minute add-ons"...
But our customer needs it earlier, currently we decided to build a prototype with main
business features based on the 2.4 CR1 codebase.
Thanks for your solution approach, which confirms my understanding of the code. I already
have the hibernate extension, group object, group module and portlet - for at least
display/add/change/remove groups and display users within the group.
For this I extended the common files:
in: core/src/resources/portal-core-sar:
- jboss-service.xml
in: core/src/resources/portal-core-war:
- Resource.properties
- jboss-portlet.xml
- portlet.xml
- portlet-instances.xml
in identity/src/resources/hibernate:
- domain.hbm.xml
This may not be the 'non intrusive way' you proposed.
A few days ago I read, that the admin UI is being re-designed... therefore it's not
wise to go ahead (or even commit the changes) with the portlet until the re-design has
been finished.
I'm interested in that design - will contact Roy?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985052#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...