David, Jonathan,
I had a look on the trunk and saw nothing about WS-Security.
I attached a patch file to OPENEJB-1004.
@David: I took into account your changes to avoid NPE.
@Jon: Maven (thought pom.xml file) creates public/private keys and
associated keystores to enable test cases.
Any input is welcome.
Hope to submit a first draft to describe this feature this evening.
I changed a little the JaxWsUtils (see patch file) to be more compliant with
the specification.
Index:
container/openejb-core/src/main/java/org/apache/openejb/core/webservices/JaxWsUtils.java
===================================================================
---
container/openejb-core/src/main/java/org/apache/openejb/core/webservices/JaxWsUtils.java
(revision 756243)
+++
container/openejb-core/src/main/java/org/apache/openejb/core/webservices/JaxWsUtils.java
(working copy)
@@ -47,7 +47,7 @@
if (webService != null) {
String localName = webService.name();
if (localName == null || localName.length() == 0) {
- localName = seiClass.getName();
+ localName = seiClass.getSimpleName();
}
String namespace = webService.targetNamespace();
return new QName(getNamespace(seiClass, namespace), localName);
Finally, tests have been made using CXF 2.0.9 which is much more stable and
functional.
So, to create a web service stub, Service.create now requires a QName. So
don't be afraid if the simple-webservice and webservice-security tests fail.
You can change
Service calcService = Service.create(new
URL("http://127.0.0.1:4204/CalculatorImpl?wsdl";), null);
To
Service calcService = Service.create(
new URL("http://127.0.0.1:4204/CalculatorImpl?wsdl";),
new QName("http://superbiz.org/wsdl";, "CalculatorWsService"));
OPENEJB-977 is about moving from 2.0.4-incubator to 2.0.9. It can be done
out of the box (only changing pom.xml file). We are actually working to
update to a 2.1.x as suggested by Jacek. But it requires some other changes.
Jean-Louis
David Blevins wrote:
>
> Had to change up part of this code to fix OPENEJB-1021: "NPE in
> AppInfoBuilder.configureWebserviceSecurity()" which shows up in the
> Geronimo build.
>
> I rearranged the configureWebserviceSecurity method just slightly.
> It's functionally equivalent, the only behavior change is the null
> check on sessionBean.getWebServiceSecurity().
>
> Added some TODOs as it seems like there's some room to be more vocal
> about potential user mistakes and issues. Not too familiar with the
> config setup, no not sure what to recommend. Here's the code in
> question:
>
> List<PortInfo> infoList = ejbJarInfo.portInfos;
> for (PortInfo portInfo : infoList) {
>
> org.apache.openejb.jee.oejb2.EnterpriseBean bean =
> beans.get(portInfo.serviceLink);
>
> if (bean == null) continue; /* TODO: throw something? */
> if (!(bean instanceof SessionBeanType)) continue; /* TODO:
> throw something? */
>
> SessionBeanType sessionBean = (SessionBeanType) bean;
> WebServiceSecurityType webServiceSecurityType =
> sessionBean.getWebServiceSecurity();
>
> if (webServiceSecurityType == null) {
> //TODO: this ok?
> continue;
> }
>
> portInfo.realmName = webServiceSecurityType.getRealmName();
> portInfo.securityRealmName =
> webServiceSecurityType.getSecurityRealmName();
> if (webServiceSecurityType.getTransportGuarantee() != null) {
> portInfo.transportGuarantee =
> webServiceSecurityType.getTransportGuarantee().value();
> } else {
> portInfo.transportGuarantee = "NONE";
> }
>
> if (webServiceSecurityType.getAuthMethod() != null) {
> portInfo.authMethod =
> webServiceSecurityType.getAuthMethod().value();
> } else {
> portInfo.authMethod = "NONE";
> }
> }
>
>
> Any thoughts on what we should do with the todos?
>
> Seems like the first one indicates they don't have any metadata in the
> openejb-jar.xml for the bean. Are there defaults that we want to fill
> in in that situation?
>
> The second seems to indicate there is metadata for the bean, but it is
> not what we expect. Seems there's definitely some action to be taken
> there.
>
> The third (the one I just added), not sure what the right approach
> is. Seems like a variation on the first one. Might be fine to ignore
> it, wonder if we need some defaults in there. Seems we supply "NONE"
> for transportGuarantee and authMethod as the defaults when there is
> some metadata give, wonder if we need to do that for when there is no
> metadata given.
>
> -David
>
>
>
--
View this message in context:
http://www.nabble.com/Re%3A-Securing-a-webservice-tp22265166p23175502.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
