Re: [jboss-dev-forums] [JBoss Web Services Development] - JBWS-2210 : CXF Username Token JAAS integration
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion
"JBWS-2210 : CXF Username Token JAAS integration"
To view the discussion, visit: http://community.jboss.org/message/536504#536504
--------------------------------------------------------------
Thanks Darran and Anil for the involvement in this thread.
> The approach of having two interceptors (one for authentication and one for authorization) is probably the biggest part of this problem already solved.
+1
> Where this becomes really apparent is where endpoints are deployed as EJB3 session beans, in this case the container can already be configured to perform authentication and authorization - as a deployed session bean can potentially be called from multiple different clients it makes sense for the authorization checks to remain with the bean.
> A second requirement would be related to endpoints deployed as POJOs - although these do not have any container security before the invocation there is still the potential that the implementations will call other secured resources so any identity would need to be propagated for these calls.
I think I've mentioned this to Sergey offline before, but the comments above better clarify the concept, thanks Darran.
> A final feature related to this that I know there is user demand for would be the ability to annotate the POJO endpoints with the same role annotations as used on EJB3 sesstion beans - we were unable to do this for our Native implementation of this as we had to support JAX-RPC as well as JAX-WS but as this would be JAX-WS only this could be an option and may help simplify the role configuration.
Definitely a good idea, that could also simplify the user experience. JAX-RPC endpoints are not going to be deployed using the CXF impl, so it's actually JAX-WS only. We might want to think about a proper roles' configuration with a xml descriptor too later, but the annotation solution is probably the idea one for the first implementation.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536504#536504]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 12 months
Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)
by Emanuel Muckenhuber
Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion
"To scope or not to scope (domain.xml)"
To view the discussion, visit: http://community.jboss.org/message/536496#536496
--------------------------------------------------------------
> Brian Stansberry wrote:
>
> The part of our existing profile discussion I was thinking of was what's shown here: http://community.jboss.org/docs/DOC-14742 http://community.jboss.org/docs/DOC-14742. Basically a fairly compact listing of required capabilities, an indication of where a deploy directory is (which could perhaps be defaulted). Then add stuff like jdbc-resources, jms-resources, threads, etc. That's pretty end-user-oriented; the heavy implementation detail stuff is in http://community.jboss.org/docs/DOC-14743 http://community.jboss.org/docs/DOC-14743.
> If we didn't need the required capabilities bit (e.g. could infer them from the rest of domain.xml content), that's nice. But I don't know if we can do that, not if we allow a deploy dir with contents not fully specified in domain.xml.
Having this part of the domain model was basically the reason why i tried to separate "user configuration" from the server side module configuration. We can obviously also change the names in the configuration files, to make things a more obvious.
In the end - I think if you configure clustering it would make sense to also deploy the needed service. Where you definitely should not care about which deployments are needed for this. Since we are going to have a domain specific model - each fragment could export a requirement on a module.
But, yes - in case we have don't have this part of a separate "module" and deployments are still in deploy dirs, then this would not make much sense.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536496#536496]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 12 months
Re: [jboss-dev-forums] [JBoss Web Services Development] - JBWS-2210 : CXF Username Token JAAS integration
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/darran.lofthouse%40jboss.com] replied to the discussion
"JBWS-2210 : CXF Username Token JAAS integration"
To view the discussion, visit: http://community.jboss.org/message/536495#536495
--------------------------------------------------------------
Hi Sergey - I have worked on some of the similar areas you are looking at here in our Native stack so have been interested to see your comments here.
Looking at your comments regarding the changes needed in CXF it looks like you are along the same lines I would consider, essentially I came to the same conclusion that the UsernameTokenProcessor within WSS4J is making an unsuitable assumption that you can obtain a users password.
Regarding how all of this would fit with the application server there are a couple of other things to consider, when integrating with the application server we are really looking to pass as much back to the application server provided containers as possible and not just have an independent authentication / authorization process within the web services stack.
The approach of having two interceptors (one for authentication and one for authorization) is probably the biggest part of this problem already solved.
Where this becomes really apparent is where endpoints are deployed as EJB3 session beans, in this case the container can already be configured to perform authentication and authorization - as a deployed session bean can potentially be called from multiple different clients it makes sense for the authorization checks to remain with the bean.
A second requirement would be related to endpoints deployed as POJOs - although these do not have any container security before the invocation there is still the potential that the implementations will call other secured resources so any identity would need to be propagated for these calls.
The point of these two comments really is to highlight that this is not just a case of obtaining a Subject from whatever app server you are running in but actually associating the users identity with the request so that is propagates for further calls within the application server. Using the APIs suggested from Anil should help with this so this is just something to keep in mind.
A final feature related to this that I know there is user demand for would be the ability to annotate the POJO endpoints with the same role annotations as used on EJB3 sesstion beans - we were unable to do this for our Native implementation of this as we had to support JAX-RPC as well as JAX-WS but as this would be JAX-WS only this could be an option and may help simplify the role configuration.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536495#536495]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 12 months
[JBoss Web Services Development] - CXF jms integration
by Jim Ma
Jim Ma [http://community.jboss.org/people/jim.ma] created the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/536441#536441
--------------------------------------------------------------
After looked at Alessio's work about cxf descriptor deployment and lazy bus load removal , I'd like to discuss with you about my thoughts about jms integration. Here is what in my mind so far .As we talked before , we need to introduce other deployer or deployerAspect to make cxf stack directly deploy/load jbossws-cxf.xml. IMO, the easy approach to implement this is adding several real stage deployers to the current deployer chain to take care of the jms deployment without web.xml: `--org.jboss.webservices.integration.deployers.WSEJBAdapterDeployer@4007f4 `--org.jboss.webservices.integration.deployers.WSTypeDeployer@d6f833 `--org.jboss.webservices.integration.deployers.WSDeploymentDeployer@103ddfd `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1279d82(org.jboss.wsf.framework.deployment.EndpointMetricsDeploymentAspect(a)b77801) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1fa6e43(org.jboss.webservices.integration.metadata.ContainerMetaDataDeploymentAspect(a)1e7c7fb) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@fcc66a(org.jboss.wsf.framework.deployment.EndpointHandlerDeploymentAspect(a)18b3f9a) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@124a94(org.jboss.wsf.framework.deployment.BackwardCompatibleContextRootDeploymentAspect(a)6fcd57) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@4aba6a(org.jboss.wsf.framework.deployment.URLPatternDeploymentAspect(a)fb39f6) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@8d69f8(org.jboss.wsf.framework.deployment.EndpointAddressDeploymentAspect(a)13bf9ce) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1f99aa6(org.jboss.wsf.framework.deployment.EndpointNameDeploymentAspect(a)929ed4) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1f8a03f(org.jboss.wsf.framework.deployment.VirtualHostDeploymentAspect(a)4a9acb) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@e9635a(org.jboss.wsf.framework.deployment.JAXBIntroDeploymentAspect(a)12cebd2) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1744996(org.jboss.wsf.stack.cxf.deployment.aspect.DescriptorDeploymentAspect(a)1e890b4) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@864ae7(org.jboss.wsf.stack.cxf.deployment.aspect.ResourceResolverDeploymentAspect(a)1214a13) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@4fdf56(org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect(a)79bca4) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@6e1cbf(org.jboss.wsf.framework.deployment.ContextPropertiesDeploymentAspect(a)827b51) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@786a44(org.jboss.webservices.integration.tomcat.WebMetaDataCreatingDeploymentAspect(a)c9f31e) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1850507(org.jboss.webservices.integration.tomcat.WebMetaDataModifyingDeploymentAspect(a)b6cddb) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1ee86f2(org.jboss.webservices.integration.security.JACCPermissionsDeploymentAspect(a)1ec0b9d) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@31613(org.jboss.webservices.integration.injection.InjectionMetaDataDeploymentAspect(a)182ac61) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1d61032(org.jboss.wsf.framework.deployment.EndpointRegistryDeploymentAspect(a)d91c60) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1d37602(org.jboss.wsf.framework.deployment.EndpointRecordProcessorDeploymentAspect(a)9f987a) `--org.jboss.webservices.integration.deployers.WSDeploymentAspectDeployer@1a30367(org.jboss.wsf.framework.deployment.EndpointLifecycleDeploymentAspect(a)1bb1dd2) + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFMetaDataDeployer(to parse the jbossws-cxf.xml and create JBossWSCXFMetaData) + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFJAXBIntroDeploymentDeployer(to do the jaxb databinding customization) + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFDeploymentBuilderDeployer(to create deployment, service and endpoint etc) + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFDeploymentDeployer(to let the cxf bus load the jbossws-cxf.xml) + org.jboss.wsf.stack.cxf.deployment.JBossWSCXFEndpointRegistryDeployer(to register the endpoint) I marked the new add deployer with "+" prefix and these new add deployers will be put the end of the DeploymentAspect deplyers. As you can see ,there will be some duplicate work/code in the these deployers with above DeploymentAspects. But it makes the deployer structure more clear and these new added deployers are dedicated to handle the jms deployment and other stack specific deployment without web.xml. The another option is we handle it both in integration layer and cxf stack : 1. Create a unified MetaData/holder to reprsent or place the stack specific deployment :jbossws-cxf.xml. 2. Modify the WSDeploymentDeployer to handle the deployment without JBossWebMetaData 3. Add the code in the current DepoymentAspects ,for example EndpointHandlerDeploymentAspect, DescriptorDeploymentAspect and BusDeploymentAspectin to process the stack specific deployment (without web.xml). We can put the code to process the cxf jms deployment in each DeploymentAspect, so this approach will reuse the function in each deployment aspect.This will change a lot in current integration layer and deployers framework and it's a little bit complex. After the comparison, I prefer to the first approach. Because at the moment, only cxf has this requirement to deploy stack specific deployment. And it is also simple :only adding some new additional deployers for cxf stack can make it work . It will not impact the other components : integration layer , spi and framework codebase. You thoughts ?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536441#536441]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 12 months
