I develop a webservice client for an existing webservice. I am using Apache CXF 2.2. The service requires security with Username and plain text password, which I configured like this:
<bean id="myPasswordCallback"
class="com.kraemer_imd.mobilized.m2m_adapter.ClientPasswordCallback"/>
<jaxws:client id="m2mClientService"
serviceClass="de.vodafone.easypu.ws.EasyPUOrderServicePortType"
address="http://m2m.vodafone.de/speasy/services/EasyPUOrderService"
bindingId="http://www.w3.org/2003/05/soap/bindings/HTTP/">
<jaxws:outInterceptors>
<bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
<constructor-arg>
<map>
<entry key="action" value="UsernameToken Timestamp"/>
<entry key="passwordType" value="PasswordText"/>
<entry key="user" value="myusername"/>
<entry key="passwordCallbackRef">
<ref bean="myPasswordCallback"/>
</entry>
</map>
</constructor-arg>
</bean>
</jaxws:outInterceptors>
</jaxws:client>
That works quite well. But I did not understand why I have to provide the password via a callback handler instead of just providing it via configuration. The documentation says it is for security reasons, but I don´t see why this should be more secure to have a callback handler that reads it from a property file (or worse has it hard coded in the callback).
So, could somebody explain this to me? Maybe the callback is intended for some magic stuff that I missed..
Thanks
Michel
The password callback is provided by Apache CXF as a mechanism for the client application to retrieve the credentials for the targeted webservice, which at runtime is likely to be stored in the database, configuration fiels, LDAP or some other store. This callback hook provides the flexibility to the application to retrieve the credentials from application specific configuration.
If password is stored in clear text in the configuration then this approach may not give you any extra security.
However having password stored as clear text in some configuration may have some security issues as there can be folks that may need access to this configuration and will be able to hold of password although it may not have been intended to.
Better is to store the encrypted password in the configuration. In this case, you need some code that will decrypt this password before it's use. Password callback will come to rescue in this scenario.
Related
I want to deal with Spring Security SAML. For this, I start to explore Spring Security SAML. At the beginning, I create an account at SSOCircle. Than I configurated of IDP metadata and generation of SP metadata (4.2.2 and 4.2.3). At entityId I set:
<bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.MetadataGenerator">
<property name="entityId" value="http://idp.ssocircle.com"/>
</bean>
</constructor-arg>
</bean>
When I start application, I have:
Error occurred:
Reason: Unable to do Single Sign On or Federation.
or
Error occurred:
Reason: Unable to get AuthnRequest.
How to configure Spring Security SAML?
Follow the steps in the QuickStart chapter. Some differences to note:
Sign up at http://www.ssocircle.com/. You need to verify your email address.
The metadataGeneratorFilter section of sample/src/main/webapp/WEB-INF/securityContext.xml should look like this (Note: signMetadata property is commented out):
<bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.MetadataGenerator">
<property name="entityId" value="urn:test:YourName:YourCity"/>
<!--<property name="signMetadata" value="false"/>-->
</bean>
</constructor-arg>
Build and start the web server locally. Then download the metadata at http://localhost:8080/spring-security-saml2-sample/saml/metadata. Copy the contents to your clipboard.
Update the metadata of your new profile at https://idp.ssocircle.com/sso/hos/ManageSPMetadata.jsp.
Enter the FQDN of the service as "urn:test:YourName:YourCity". You need to enter unique values for Your Name and Your City. Paste in the metadata from above.
To Test:
Logout of SSO Circle Service.
Go to http://localhost:8080/spring-security-saml2-sample
You should be redirected to the SSO Circle login.
Login with your SSO Circle credentials.
You should be redirected to your local service provider page and authenticated.
The metadata generator filter generates metadata for your application (service provider). The entity id you're providing (http://idp.ssocircle.com) is already used by the SSO Circle, you should create a unique value which describes your application, e.g. urn:test:helsinki:myapp
Just like the manual says:
make sure to replace the entityId value with a string which is unique
within the SSO Circle service (e.g. urn:test:yourname:yourcity)
I have a setup with an apache HTTP server front facing tomcat server. The Apache server uses LDAP for authentication.
I am using an Embedded LDAP server (Apache DS) and have configured to disable anonymous bind using
service.setAllowAnonymousAccess(false); // Disable Anonymous Access
service.setAccessControlEnabled(true); // Enable basic access control check (allow only System Admin to login to LDAP Server)
My application uses Spring LDAP to connect and perform user operations like Adding a user. I have configured it in spring.xml as follows:
<bean id="ldapContextSource" class="org.springframework.ldap.core.support.LdapContextSource">
<property name="url" value="ldap://localhost:389" />
<property name="base" value="dc=test,dc=com" />
<property name="userDn" value="uid=admin,ou=system" />
<property name="password" value="secret" />
</bean>
Apache httpd.conf is configured to use basic auth
AuthLDAPBindDN "uid=admin,ou=system"
AuthLDAPBindPassword "{SHA}<Hash for secret>"
ISSUE 1 : When trying to login to ldap server using a client (say jexplorer), I am able to login using both Hashed password and using the plain text "secret". How is that possible?
In this case , if someone gets to know the AuthLDAPBindDN and AuthLDAPBindPassword which is a hashed one in my case, They will be able to login using the same to the LDAP server with full access which is a security threat.
Also, I want to replace the password in spring.xml with a hashed one. Since, admin can change the LDAP password, How do I ensure my application to use the updated hashed password as we are hard-coding it in spring.xml?
With regards to your second question: you should typically never hardcode stuff like server URLs, user names, passwords, etc in your XML file. These things should typically be externalized to a property file and processed using <context:property-placeholder>. Say, for instance, that you have a property file with the following contents:
ldap.server.url=ldap://localhost:389
ldap.base=dc=test,dc=com
ldap.userDn=uid=admin,ou=system
ldap.password=secret
You can then refer to these properties in your configuration file, e.g.:
<context:property-placeholder ignore-resource-not-found="true"
location="classpath:/ldap.properties,
file:/etc/mysystem/ldap.properties" />
<bean id="ldapContextSource" class="org.springframework.ldap.core.support.LdapContextSource">
<property name="url" value="${ldap.server.url}" />
<property name="base" value="${ldap.base}" />
<property name="userDn" value="${ldap.userDn}" />
<property name="password" value="${ldap.password}" />
</bean>
Spring will automatically replace the stuff within ${} with the corresponding values from your properties file.
Note that I specified two property file locations in the <context:property-placeholder> element, and that I also included ignore-resource-not-found="true". This is useful, because it enables you to include a properties file with your source for simple development setup, but in production, if you place a properties file under /etc/mysystem/ldap.properties, this will override the stuff in the bundled properties file.
This way, if the password is changed by admin in production environment, all you need to do is change the properties file; you don't need to rebuild the application.
With regards to why the apache DS accepts the hashed password; one reason might be that your LDAP server is set up to accept anonymous access for read operation, which means that it actually doesn't authenticate at all when you're just reading. Might be something else though, you'll have to direct the question to Apache DS support.
I am creating a Spring MVC application which is a SOAP client. To communicate with SOAP web-service I am suppose to pass the login credentials. My application doesn't need to store any details dynamically and hence I am not using any db for this application. So kindly suggest a recommended practice to store the sensitive credential for my application. This credential will we managed by the system admin and must be easy for him to change according to the requirement.
Thanks in advance.
Store the username and password in a properties file external to your webapp spring context. That way the sysadmin can easily lock down read access on the properties file to the relevant parties (e.g. your application and himself). That should stop prying eyes seeing the password.
In your spring context have something like:
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<list>
<value>/path/to/config.properties</value>
</list>
</property>
<property name="ignoreUnresolvablePlaceholders" value="true"/>
</bean>
<bean id="myBean" class="...">
<property name="username" value="{usernameFromExternalPropFile}" />
<property name="password" value="{passwordFromExternalPropFile}" />
</bean>
The sysadmin will then also be able to change the username/password independently from a build.
See http://www.javaworld.com/community/node/8309/
The simplest option would be to store them in your application context XML configuration file as properties to the bean which is communicating with the SOAP webservice.
In CXF, you can enable logging using this:
<cxf:bus>
<cxf:features>
<cxf:logging/>
</cxf:features>
</cxf:bus>
Source: http://cxf.apache.org/docs/configuration.html
Everything seems to go to files or console and can be configured using Log4j as well it seems.
My question is, how do you enable logging on server side so that you can intercept these raw requests and responses and store them in a table in the database along with other application specific information related to the service call.
This is all for server-side service implementation class.
The example you quoted was the simplest possible config to do basic logging. If you look at the example right before, you can see a slightly more expanded approach to logging interceptors:
<cxf:bus>
<cxf:inInterceptors>
<ref bean="logInbound"/>
</cxf:inInterceptors>
<cxf:outInterceptors>
<ref bean="logOutbound"/>
</cxf:outInterceptors>
<cxf:inFaultInterceptors>
<ref bean="logOutbound"/>
</cxf:inFaultInterceptors>
</cxf:bus>
Here, the logInbound, logOutbound and logOutbound beans are any implementation of CXF's interceptor interface. You can implement your own interceptor beans to do any type of logging you choose, including database logging.
I have a JAX-RPC web service that I am attempting to consume using Spring. This is my first time using Spring to consume a web service, so right now I'm just trying to get it to integrate with the JAX-RPC web service as a test.
The web service has several dozen operations in it, but for right now I only care about one. Here are the interfaces I've created on the Spring/client side:
public interface WSClient {
public boolean userExists(int userid);
}
public interface WSService {
//this method matches the method signature of the Web Service
public com.company.data.User getUser(int userid);
}
And here is my applicationContext.xml:
<bean id="WSClient" class="com.company.ws.test.WSClientImpl">
<property name="service" ref="myWebService"></property>
</bean>
<bean id="myWebService" class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean">
<property name="serviceInterface" value="com.company.ws.test.WSService"/>
<property name="endpointAddress" value="http://1.2.3.4/web-service/data"/>
<property name="namespaceUri" value="http://www.company.com/wdsl"/>
<property name="serviceName" value="CompanyWebService"/>
<property name="username" value="username"/>
<property name="password" value="password"/>
<property name="maintainSession" value="true"/>
</bean>
Using this configuration of JaxRpcPortProxyFactoryBean, invoking the Service returns the following exception:
org.springframework.remoting.RemoteProxyFailureException: Invalid JAX-RPC call configuration; nested exception is operation style: "rpc" not supported
I've never fully understood the difference between RPC and document-style web services; however, I believe this web service is using RPC-style - so this exception confuses me.
Second, I'm confused on which properties I should be setting with JaxRpcPortProxyFactoryBean:
If I set the wsdlDocumentUrl property, I end up getting a HTTP 401 error as this web service sits behind HTTP Basic Authentication, and it seems Spring does not use the username/password properties when fetching the WSDL.
If I specify a PortInterface property (with a value of CompanyWebServiceInterfacePort), then I get a different Exception stating:
Failed to initialize service for JAX-RPC port [{http://www.company.com/wdsl}CompanyWebServiceInterfacePort]; nested exception is WSDL data missing, this operation is not available
In other words, it's telling me that the WSDL is missing - which I can't set since Spring won't use the username/password to fetch it from the server!
I'm not sure if any of this makes any sense, but in essence what I'm unsure of is:
For a JAX-RPC service, do I need to set the PortInterface property? Is this the path I should be going down?
Similiarly, does Spring need me to set the wsdlDocumentUrl property? If so, is there any way I can tell Spring which WSDL and get around the authentication problem?
I eventually solved this by saving a copy of the WSDL file locally, and, since JaxRpcPortProxyFactoryBean expects a java.net.URL for the wsdlDocumentUrl property, had to set it with a path like file:///c:/.../blah.wsdl.
This isn't really all that desireable, I would hate to have to put a file:/// URI in a Spring context file that might be deployed on a server, especially on a different platform - seems odd that this class behaves this way.
I'm guessing most people aren't using Spring aren't using JAX-RPC anyway.