[Design of JBoss Portal] - Re: Initiall identity model discussion
by bdaw
Time to push the discussion a little further. I don't have any definitive solutions at the moment, just want to categorize what need to be done and introduce some concepts.
I see several categories in this topic:
1) Identity Model - model and structure of entities (users,groups,roles and etc.) and related backend (Identity Store - DB/LDAP)
2) Authentication - SSO, pluggable auth...
3) Authorization - both Portal and JEE security
4) Portal - concepts like communities (related to point 1)
5) other - dependent services and technologies like CMS, BPM, Rules and etc.
Antoine - thanks for bringing the last point to this topic. I'm not very knowledgeable about BPM but we'll need definitely look closer at those issues.
So:
Ad 1) Identity Model
Its mostly about how we store and group users. So here we have
- Organization/Business hierarchy - probably some 'Organization' entity that can have sub organizations/entities that store users
- Administration activities - groups and roles
- Portal features - communities
We should make some kind of generic API with Entity/Identity with assigned Type, where Type expose possible relations to another types. So above list could be easily widen with other features like common profile mentioned by julien. This will also easily allow entities besides user to have dynamic properties/attributes.
IdentityStore - with generic API like this all 4 identity modules could be integrated into one with natural implementations for LDAP and DB. Generic API like searchEntity(EntityType, Name, ....). Still the design need to be cautious as there are few challenges like updating the state of entities with the backend.
Its hard to define the model without having backend in mind. The thing is that we can create flexible structure but both backend (LDAP/DB) and portal use cases apply specific constraints. The main question is what we let to store in LDAP. From one side its impossible to store all stuff in LDAP (schema is limited in the matter of user preferences for eg.). Also DB and LDAP are different worlds, and its impossible to include all LDAP semantics as its hard to map it in DB.
It would be very tempting to be able to map whole organization structure (Organization entities + group and roles + users) from LDAP while the easiest approach is to let retreive only groups/roles/users. Still stuff like communities should be DB only.
*Problems* - few portal services (mostly CMS) rely deeply on identity and I'm sure those changes will be pain in the ass for their maintainers :)
Ad 2) Authentication
- Leveraging JAAS is good. Its easy to alter things by implementing proper LoginModule or extending PAM stack. We should make integration with additional services more simple by providing generic LoginModule implementation that invoke pluggable Authenticator service.
- Currently we rely on userName for authentication. This should be configurable. In LDAP environment it often makes more sense to authenticate against email as its easier to achieve its uniqueness among whole organization structure.
- any changes for easier SSO integration?
Ad 3) Authorization
Identity changes touches both portal permissions and JEE security. Permissions should be applied to any kind of entity (organization, group, role, user, community, user ...). Two open topics here:
- Leverage Rules for security (Seam has it currently http://docs.jboss.com/seam/2.0.0.B1/reference/en/html/security.html)
- make authorization easily pluggable - for those who want to integrate with other security stacks like ACEGI or OpenSSO.
Ad 4) Portal - communities
For now the only use case for 'communities' I see is for access and management of common content/resources - pages, wiki, forum, blog etc... So this should be closely related to portal permissions and contract with those portlets/services need to be defined.
Basically this is more related to proper portal services that will leverage identity model, so we need to discuss how such 'community pages' would look like. Maybe its a subject for a separate thread....
Ad 5) other...
Antoine pointed out some issues with BPM integration. I will need to catch up with this.
When we were applying identity changes in 2.6, few issues with CMS integration pop up. Some are still there. We need to be aware of all requirements that other services have.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079391#4079391
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079391
18 years, 4 months
[Design the new POJO MicroContainer] - InstanceClassFactory extension to the ManagedObjectFactory
by scott.stark＠jboss.org
In order to deal with wrapping metadata instances like the ServiceMetaData class, I need to add an InstanceClassFactory plugin to the ManagedObjectFactory. This allows for the management annotations to be on the underlying mbean instance:
| public interface InstanceClassFactory
| {
| /**
| * Return the Class that represents the root ManagedObject to scan
| * for management object related annotations.
| *
| * @param instance - the instance a ManagedObject is to be created for.
| * @return the Class that represents the root ManagedObject.
| */
| public Class<? extends Serializable> getManagedObjectClass(Serializable instance);
| }
|
This allows one to mark up the instance the mbean service wraps. The alternative would be to assume the ServiceMetaData jmx representation is the ManagedObject. I don't think that is generally the case as the interfaces were more a description of the bean service rather than the management interface.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079349#4079349
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079349
18 years, 4 months
[Design of JCA on JBoss] - Re: Near term roadmap
by wmprice1240
Good summary
anonymous wrote :
| The JCAMetaDataRepository is up and running but really needs some work to become fully functional.
|
The biggest areas that need addressing are for the other JCA deployment types
ActivationSpec
AdminObjects
Further, this needs properly integrating with EJB3 to better support inbound adapter managment (ie activating endpoints etc, MEF managment). Also, the repository has rudimentary capabilities to report what's currently deployed. This could use some work as well.
anonymous wrote :
| 2) Pull JCA out of JBossAS
| 3) Core JCA
|
While the prototype has been checked into the SVN and Mavenized, it is indeed a prototype. I have some questions regarding the MC especially in terms of AOP integration. I will put these in a coherent format for discussion. Most of these questions simply amount to what I believe is my misunderstanding about the MC-->AOP integration stuff, as well as MC deployment in the 'new world'. Primarily my questions usually are of the form...'How to I get X attribute(s) into this interceptor for this particular JCA resource to manage things like Pool locking strategy, idle timeout etc'. Again, this is my lack of understanding about the MC/AOP model more than anything else.
Fortunately, the new deployment framework was designed so that when JCA is ported to the MC, it's simply a matter of swapping in the MC objects for the JMX stuff used today. This was the point of the builder stuff where from a deployment, objects (you don't really know what type) can be generated and deployed into either the JMX or MC environment.
anonymous wrote :
| 4) Adapters
| In conjunction with #2, the adapter set needs to be pulled out of AS *and* given its own release cycle/model. JCA core and the JCA adapters should independent of one another.
|
Correct. It is my plan to have the adapters evolve independently (as much as possible) from the core JCA container.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079325#4079325
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079325
18 years, 4 months
[Design of EJB 3.0] - Re: Redesign extended persistence context
by wolfc
"bstansberry(a)jboss.com" wrote : e) All of the above.
The 'independent' lifecycle implemented in AS 4.2 is very much broken. When I was fixing it in AS 5 I saw that multiple chains of SFSBs would emerge because of the whole NestedBeanContext, ProxiedBeanContext and two serializations going on (MarshalledObject and StatefulSessionPersistenceManager). Like you say, it's a bunch of ugle (== unmaintable) code.
"bill.burke(a)jboss.com" wrote : For #1 you're talking solely about nested SFSBs sharing the same XPC, right? I did suggest some things for nested SFSBs, specifically, having the parent SFSB manage the bean instance, injecting the bean instance into the child proxy and passing the instance along in the invocation payload, thus bypassing the child's cache.
Yes, but I don't like that. It means if the parent is removed the child is removed (or left without an XPC). SFSBs must have independent life cycles (with the exception of passivation maybe). So an XPC must be decoupled from any SFSB. So the XPC must move to an XPCHolder or something.
But I get the idea now: an XPC must be serialized together with all it's users in one shot.
Note: I suspect a race condition with the passivation thread and ctx.inUse.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079309#4079309
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079309
18 years, 4 months
[Design of Clustering on JBoss (Clusters/JBoss)] - Handling cluster state when network partitions occur
by bstansberry＠jboss.com
Forum thread to capture some thoughts from a phone discussion today and to continue the conversation. Topic is how stateful clustered applications should deal with network partitions. See necessary background reading at http://www.jgroups.org/javagroupsnew/docs/manual/html/user-advanced.html#... for an overview of the problem.
For discussion brevity, I'll refer to 3 of the ideas mentioned in the JGroups doc by shorted:
1) "Merge state". Discussed in 5.6.1 -- JGroups user manages a process to merge the state from the merging partitions.
2) "Primary partition". Discussed in 5.6.2. Nodes that realize upon merge that they weren't in the primary partition flush their state, ensuring that state must be reacquired from a shared persistent store.
3) "Read-only". Nodes realize at the time the partition occurs that they are not in the primary partition, and shift into read-only mode, throwing exceptions if an attempt is made to write. When the partition heals, they get the current state from the primary partition.
Some things mentioned in the discussion today:
* Using timestamps for "merge state" is problematic due to clock synchronization and clock granularity issues.
* "Merge state" is tricky for PojoCache, because the stored pojo doesn't have a natural timestamp or counter that can be used to determine which state to retain. JBC/PojoCache can compare state between nodes, but if there is a conflict there probably needs to be a callback to the application to allow it to decide what to do.
* "Merge state" is more useful to http sessions that don't use FIELD granularity (i.e. don't use PojoCache). Web sessions are supposed to be managed by only one node, so the difficulty of deciding which node's state is correct is reduced. The stored sessions have a timestamp and counter stored in the root node for the sessions subtree. If JBC provided a callback to the JBossCacheManager, the JBCM could easily determine which server's data to retain for each session. Bela pointed out that this reconciliation process could also be done "off-line" via a special service that multiplexes on the cache's channel -- i.e. JBC doesn't have to be directly involved.
* "Read-only" is a possible option for some webapps that don't mind throwing exceptions. E.g. a blog site wants people to be able to continue reading the blog, and doesn't mind if update functions are disrupted during the network partition.
* Entity caching is a tough problem. At first, something like the "primary partition" approach seems good; just dump cached state when the merge occurs and force Hibernate to repopulate the cache from the db. Problem is that during the partition itself the caches can become invalid. Two sub-partitions of {A, B, C} and {D, E} will not know about each others' updates, and thus Hibernate can read stale data from the cache. Variations on the "read-only" approach where {D, E} no longer provides cached data don't solve the problem, as Hibernate on D or E can still update the database, in which case the {A, B, C} caches are invalid.
For this kind of situation, having the application become unavailable on {D, E} is something we need to consider.
This is just a quick summary; I'm sure I missed stuf.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079307#4079307
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079307
18 years, 4 months
[Design of EJB 3.0] - Re: Redesign extended persistence context
by bstansberry＠jboss.com
anonymous wrote : 1. The life cycle of all SFSB using that XPC are connected. Maybe we can limit that to just the passivation/activation.
They are connected, yes, but it should be possible to independently remove the beans that use the same XPC with the existing mechanism. I'm quite certain I wrote tests for that. Admittedly, the way it works is ugly.
anonymous wrote : 2. Partial replication should be possible.
What do you mean here?
a) Partial replication of the XPC (i.e. unflushed changes)
b) Fine-grained (PojoCache) replication of the SFSBs
c) Independent replication of the SFSBs that share the XPC
d) Something else
e) All of the above.
For A, Steve Ebersole is going to work on that at the Hibernate level.
For C, the stuff discussed at http://jira.jboss.com/jira/browse/EJBTHREE-1039 can help with that. That is, alter the serialization of the bean so the the entity id is written to the stream rather than the entity. Ensure the XPC is deserialized before the bean. If we can solve that problem well, the need to serialize in one unit all the beans that use the XPC might be removed.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079282#4079282
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079282
18 years, 4 months