[PicketBox Development] - AS7 : Authentication and Authorization
by Marcus Moyses
Marcus Moyses [http://community.jboss.org/people/mmoyses] created the discussion
"AS7 : Authentication and Authorization"
To view the discussion, visit: http://community.jboss.org/message/582428#582428
--------------------------------------------------------------
For AS7 I'm thinking about rewriting all our login modules to separate authentication (caller principal mapping) from authorization (role mapping) during the JAAS process.
Currently the majority of our login modules does both things: validates password to assign the user principal to the subject and adds the roles to the subject.
In my opinion this is getting messy as new functionality needs to be added to login modules to allow different combinations of them so customers can use only one for authentication and another for role mapping. This is bad as we keep adding new options to the LMs in order to accomodate such features.
If we separate the functionalities I believe the code will be easier to manage, to extend (subclass for custom needs), to configure and it will also allow for many other combinations to suit every need.
What do you think?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/582428#582428]
Start a new discussion in PicketBox Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 3 months
[JBoss AS7 Development] - ManagementConsoleRoadmap
by Heiko Braun
Heiko Braun [http://community.jboss.org/people/heiko.braun%40jboss.com] modified the document:
"ManagementConsoleRoadmap"
To view the document, visit: http://community.jboss.org/docs/DOC-16376
--------------------------------------------------------------
h1. Roadmap for the AS7 Management Console
(Work in progress)
h4. Rough categorization of work (feature sets):
- Project setup (codebase, repo, JIRA, etc)
- Authentication
- UI Framework (both domain and standalone)
- rough UI layout
- maybe outer most domain tree (domain, profiles, server-groups, etc)
- excluding subsystems and management operations
- goal: explore outermost conceptual model
- risk: might not reflect ambiguity in information design w/o example subsystem
- depends: project setup
- Server Group configuration
- goal: configure, launch, shutdown server instances
- domain sceanrio only
- depends: management infrastructure in place and console being deployable
- potential release candidate
- Provide UI extension hooks
- minimal API: i.e. GWT 2.1 PlaceManager, plus boiler plate magic (borrowed from Errai Workspaces)
- goal: baseline for subsystem integration, extensibility
- Feedback from layered products (JON, Drools)
- Example subsystem management completed
- complete functional set
- distinction between domain and host level operations
- goal: explore detailed conceptual model, verify management API, remove ambiguity
- depends: rough UI framework, extension hooks
- potential release candiate
- Example Metrics completed
- covers a typical metric request (domain, host, subsystem)
- re-use example subsystem
- goal: verify management API exposes runtime state correctly/sufficiently
- Client Server API mature (pivot)
- Match AS7 management API
- Deployment on Domain Controller
- Integrated with AS build/deliverables
- Deployment on Standalone Server
- Integrated with AS build/deliverables
- Iterate over remaining subsystems
- goal: complete management functionality
- risk: might reveal issues with the overall conceptual model
- depends: example subsystem, rough UI framework
- with each subsystem another potential release candiate
- Management Operation Plans
- Deployment Plans
- User management
- Integrate themes (.org & RH):
- early in the game
- provide means for design people to work on this
- goal: introduce customization hooks, verify i18n issues, work towards JON
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16376]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months
[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about the AS7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
4. Managed entities are detached at transaction end time.
2. No transaction invocation
1. Managed entities are detached at end of bean method call EntityManager call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. Managed entities continue to be managed at transaction commit time.
5. Managed entities are detached at transaction rollback time.
6. XPC is closed when dependent session bean(s) are closed (via @remove method).
7. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
4. If invoked without a JTA transaction and a transaction scoped persistence context is used, will throw TransactionRequiredException for any calls to entity manager remove/merge/persist/refresh.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
1. Determine the available persistence providers following JPA 9.3
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
3. Consider any EM (container) extensions that make it easier to measure performance (perhaps based on Hibernate statistics). Its always nice to see how long each transaction took and the units of work within the transaction. It would be nice if we could do this with any persistence provider (for performance comparison).
4. Deal with the Hibernate persistence provider via the same way as we would interact with other persistence providers (via PersistenceProvider mentioned above).
5. It should be easy to switch to a new persistence provider.
6. If an application bundles a persistence provider that is referenced from their persistence unit(s), use the bundled persistence provider (even if its a different version of a JPA 2.0 provider that is also available to all applications). This should handle bundling a different version of Hibernate.
7. Peace.
9. Questions1. The JPA specification section 7.9.1 (Container Responsibilities) implies that only one (container managed) entity manager will be associated with the JTA transaction. However, what if someone injects multiple persistence contexts (different persistent units) in separate entity managers for the same bean. Should that be considered an application error or allowed behaviour (e.g. each separate entity manager is joined to the JTA transaction). *ANSWER: we will allow it and design for it.*
2. For a few different cases, we will need to know which EntityManager was injected into a component. One such case is for XPC inheritance. For example, SFSB1 (with extended persistence context) gets injected into a web component and SFSB2 (with extended persistence context) gets injected into SFSB1. SFSB2 should inherit the XPC from SFSB1. Open question is how we want to maintain the bookkeeping for this. The JPA layer could expose a SPI like BeanToEntityManager{ List<EntityManager> getEntityManagers(); } that can be passed in on other SPI calls (basically depending on the EJB container to track injected EntityMangers via other magic). Another solution would be to track the mapping in the JPA layer (might be a pretty big map with a lot of weak references that need to be considerate of GC/undeploy concerns). Or perhaps there will some other solution that will appear for this. :)
3. What about injecting a Hibernate session or session factory as mentioned http://bill.burkecentral.com/2007/07/06/co-existence-with-hibernate-jpa-a... here. Do we want to carry this into AS7? Is there another way to do this that we would want to implement for AS7? [Emmanuel] I think this is valuable and quite natural. An alternative approach would be to let all injection logic be handle by Seam 3 which does Session/SessionFactory injection already (it also inject FullTextEntityManager and FullTextSession form Hibernate Search for that matter).
4. Should the jboss-jpa project continue to have its own release cycle or should it live in the AS7 source repo? If anything outside AS7 wants to consume the JPA integration project, then jboss-jpa will need to have its own release cycle. One obvious case is the EJB container, if that continues lives in its own project, jboss-jpa will have to follow suit. I'm not aware of any other projects that desire that.
5. For the JPA EE container integration, should we integrate with a component level invocation context or purely with the containers directly? At this point, I'm assuming direct container integration but we might be able to refactor some of that to be more generic. This will make more sense soon. :)
Illustration of how a stateful session bean (SFSB) named SFSB_XPC1 interacts with a stateless session bean (SLSB) named SLSB_PC2. Note that the extended persistence context (XPC) is injected into SFSB_XPC1 at bean creation time. Also note that the SFSB_XPC1 persistence context is bound to the JTA transaction and will be injected into the SLSB_PC2 by the EJB container as part of each invocation. The XPC1 will retain changes made by each invocation to SLSB_PC2 until the transaction commits.
|| *Action* || *Transaction* || *PersistenceContext
* ||
| SFSB_XPC1 created |
| XPC1 injected into SFSB_XPC1 |
| SFSB_XPC1.updateInventory | T1 started | XPC1 bound to T1 |
| SFSB_XPC1 calls SLSB_PC2 | T1 |
|
| SLSB_PC2.dowork | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity item1 | T1 | item1 is loaded |
| SLSB_PC2 persists new entity order1 | T1 | order1 will be saved at commit time |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 calls SLB_PC2 again | T1 |
|
| SLSB_PC2.morework | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity order1 | T1 | order1 is returned from XPC1 |
| SLSB_PC2 calls order1.increase(4) | T1 | change made in XPC1 held entity |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 returns | T1 commit | XPC1 changes are saved, item1 + order1 remain in XPC1 |
| SFSB_XPC1 removed |
| XPC1 is closed |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months
