The CXF components undergirding the SonicConnect services appear to support Spring Security features. We have a business need to obtain client certificate details upon client requests with X.509 certificates.
I've made adjustments to the spring.xml configuration file to include these additonal bean elements:
<bean id="esb.security.soapLeitscDetailsSource"
class="our.package.webservice.sonic.security.spring.SOAPLeitscAuthenticationDetailsSource"/>
<bean id="esb.security.x509PreAuthenticatedFilter"
class="our.package.webservice.sonic.security.spring.X509JurisdictionPreAuthenticatedProcessingFilter">
<security:custom-filter position="FIRST"/>
<property name="authenticationManager" ref="esb.security.authenticationManager"/>
<property name="authenticationDetailsSource" ref="esb.security.soapLeitscDetailsSource"/>
</bean>
<bean id="esb.security.jurisdictionUserDetailsService"
class="our.package.webservice.sonic.security.spring.JurisdictionAuthenticationUserDetailsService"/>
<bean id="esb.security.x509PreAuthenticationProvider"
class="org.springframework.security.providers.preauth.PreAuthenticatedAuthenticationProvider">
<security:custom-authentication-provider />
<property name="preAuthenticatedUserDetailsService" ref="esb.security.jurisdictionUserDetailsService"/>
</bean>
<bean id="esb.security.authenticationManager" class="org.springframework.security.providers.ProviderManager">
<property name="providers">
<list>
<ref local="esb.security.x509PreAuthenticationProvider"/>
</list>
</property>
</bean>
Info level logging in the container logs is showing these classes are being initialized by the framework. However, when we make requests with client certs which get matched to certs in our keystore/certstore, these classes don't appear to be invoked or called.
Thanks.
I don't really see anything wrong with your configuration but I think it can be simplied a bit. Perhaps, you can give it a try.
class="our.package.webservice.sonic.security.spring.SOAPLeitscAuthenticationDetailsSource"/>
class="our.package.webservice.sonic.security.spring.X509JurisdictionPreAuthenticatedProcessingFilter">
class="our.package.webservice.sonic.security.spring.JurisdictionAuthenticationUserDetailsService"/>
class="org.springframework.security.providers.preauth.PreAuthenticatedAuthenticationProvider">
Sonic Connect only ships two spring-security jars (namely, spring-security-core.jar and spring-security-core-tiger.jar version 2.0.4). Any chance it is related to class not found problem?
William, thanks for the reply.
I am trying to over-ride the log4j configuration in the dev_ESBTest container. I've used the system property on the Java environment tab settings to specify the log4j xml configuration file. The log shows it being used and on the SonicConnect service with the additional spring security in the spring.xml configuration file, it shows the info level logging from these services being initialized. However, when a request with a client cert is made to the platform, these services should show at least info level logging when they are invoked. We see no logging from the specific pre-authentication filters which initialize. It's as if the Sonic framework is not invoking them. See below (trimmed for brevity):
[11/03/31 15:25:37] (config)
Sonic Management
Release 8.0.1 Build Number 196
Copyright (c) 1999-2010 Progress Software Corporation.
All rights reserved.
Local host: EDCMobile (Windows XP - 5.1)
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Sun Microsystems Inc. (home c:\Program Files\java\jre1.5.0_22, version 1.5.0_22)
Java HotSpot(TM) Client VM (build 1.5.0_22-b03, mixed mode)
Configured Arguments : -Xms64m -Xmx512m -Xdebug -Xnoagent -XX:PermSize=64m -XX:MaxPermSize=128m -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,suspend=n,server=y,address=7999 -Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl -DSonicESB.log4j.configuration=sonicfs:///workspace/docs/config/log4j.xml
Configured Properties:
[11/03/31 15:25:37] (info) "Domain1.dev_ESBTest" starting...
[11/03/31 15:25:38] (info) Management connection (re)established (Socket[addr=/192.168.1.147,port=2506,localport=4772])
[11/03/31 15:25:38] (info) Sonic logging interceptor enabled
[11/03/31 15:25:38] (info) Loaded ID=AGENT
[11/03/31 15:25:39] ID=dev_ESBTest (info) Intra-container messaging is enabled ..
[11/03/31 15:25:39] ID=dev_ESBTest (info) dev_ESBTest initializing...
Sonic ESB Professional Developer Edition [Serial Number: 999999999]
Release 8.0.1 Build Number 199
Copyright (c) 2001-2010 Progress Software Corporation.
All Rights Reserved.
[11/03/31 15:25:39] ID=dev_ESBTest (info) Applying log4j configuration: sonicfs:///workspace/docs/config/log4j.xml
[11/03/31 15:25:39] ID=dev_ESBTest (info) ...
Then the SonicConnect Service portion with the added Spring Security features:
Sonic Connect
Version 8.0 Build Number 174
Copyright (c) 2010 Progress Software Corporation.
All rights reserved.
Mar 31, 2011 3:26:35 PM com.edc.c2c.esb.webservice.sonic.security.spring.X509JurisdictionPreAuthenticatedProcessingFilter
INFO: ***** Creating X509 Jurisdiction pre-authenticated filter.
Mar 31, 2011 3:26:36 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromWSDL
INFO: Creating Service {http://www.mycompany.com/app/}app from WSDL: resources/wsdl/app.wsdl
Mar 31, 2011 3:26:37 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be https://192.168.1.147:488/webservices/app/appService.svc
Mar 31, 2011 3:26:37 PM org.mortbay.log.Slf4jLog info
INFO: jetty-6.1.21
Mar 31, 2011 3:26:37 PM org.apache.cxf.transport.https.SSLUtils getCiphersuites
INFO: The cipher suites have not been configured, falling back to cipher suite filters.
Mar 31, 2011 3:26:37 PM org.apache.cxf.transport.https.SSLUtils getCiphersuites
INFO: The cipher suite filters have not been configured, falling back to default filters.
Mar 31, 2011 3:26:37 PM org.apache.cxf.transport.https_jetty.CXFJettySslSocketConnector newServerSocket
INFO: The cipher suites have been set to [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA].
Mar 31, 2011 3:26:37 PM org.mortbay.log.Slf4jLog info
INFO: Started CXFJettySslSocketConnector@0.0.0.0:488
[11/03/31 15:26:37] ID=dev_ESBTest (info) [WebServiceSonicConnectService] Initialized.
[11/03/31 15:26:37] ID=dev_ESBTest (info) Actional instrumentation is disabled for this container
[11/03/31 15:26:37] ID=dev_ESBTest (info) Initializing Mitigation context factory class: com.sonicsw.xqimpl.actional.lg.visitor.StabilizerHelper
[11/03/31 15:26:37] (info) Loaded ID=dev_ESBTest
[11/03/31 15:26:37] ID=dev_ESBTest (info) Container's ESB (JMS) Connection: jms_defaultConnection
[11/03/31 15:26:37] ID=dev_ESBTest (info) Container's HTTP Routing Connection: http_defaultConnection
[11/03/31 15:26:37] (info) ...startup complete
[11/03/31 15:26:38] ID=dev_ESBTest (info) Attempting to (re)establish connection: jms_defaultConnection
[11/03/31 15:26:39] ID=dev_ESBTest (info) Connection to endpoint 'AuthenticateProcess.Entry' (re)established for connection 'jms_defaultConnection' at localhost:2506
Mar 31, 2011 3:27:58 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor addPropsToEsbContext
INFO: Service Connect Security Context properties : {TLSX509SubjectDN=CN=city,OU=Unknown,O=cityRMS,L=city,ST=VA,C=US, HTTPBasicAuth=null, AIPropagatedIDLong=null, TLSX509SubjectFirstCN=city, AIPropagatedID=null, PrincipalName=city, PrincipalSource=TLSX509SubjectFirstCN, HTTPDigestAuth=null}
Mar 31, 2011 3:28:13 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor addPropsToEsbContext
INFO: Service Connect Security Context properties : {TLSX509SubjectDN=CN=county,OU=Unknown,O=countyRMS,L=county,ST=VA,C=US, HTTPBasicAuth=null, AIPropagatedIDLong=null, TLSX509SubjectFirstCN=county, AIPropagatedID=null, PrincipalName=county, PrincipalSource=TLSX509SubjectFirstCN, HTTPDigestAuth=null}
These last two entries are submissions to the services by the client presenting the client certificates which are contained in our keystore. We expect the pre-authentication filter which is initialized to be executed, but it does not appear to be executing. If it were executing, we ought to see more (info) level logging.
Perhaps, you can try
of
which may sound more promising than "FIRST".
Also, I wonder raising the log level to DEBUG will give out more hints.
Thanks William. We did not want the default pre-auth to supercede our desired pre-auth customer filter, thus we simply desired to use "FIRST" as the position attribute value.
Our log4j is specifying debug level logging and I've enabled all possible, pertinent debug level trace logging in the container trace properties. It became clear that when I overrode the log4j configuration, only info level logging was being pushed into the container log on startup and initialization, thus, we have made all of our logging info level. That's how we were able to get that "**** INFO" line which said the custom filter was initialized. Could the fact that we were not getting debug level logging be
The crux of the issue is the custom pre-auth filter is initialized but is not being used as an interceptor. The com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor is being invoked and is logging that basic detail which is contained in my initial post in bold-faced text. The custom pre-auth filter is not being invoked.
We have tried a more strict security setup as well and still cannot intercept the request into our custom filters which are initialized, just the SonicConnectSecurityInInterceptor. In the spring.xml configuration file:
class="my.package.esb.webservice.sonic.security.spring.SOAPLeitscAuthenticationDetailsSource"/>
class="my.package.esb.webservice.sonic.security.spring.X509JurisdictionPreAuthenticatedProcessingFilter">
class="my.package.esb.webservice.sonic.security.spring.JurisdictionAuthenticationUserDetailsService"/>
class="org.springframework.security.providers.preauth.PreAuthenticatedAuthenticationProvider">
class="org.springframework.security.ui.preauth.PreAuthenticatedProcessingFilterEntryPoint"/>
class="org.springframework.security.vote.AffirmativeBased">
class="org.springframework.security.vote.RoleVoter"/>
class="org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter">
class="org.springframework.security.intercept.web.FilterSecurityInterceptor">
class="org.springframework.security.context.HttpSessionContextIntegrationFilter"/>
class="org.springframework.security.ui.ExceptionTranslationFilter">
class="org.springframework.security.util.FilterChainProxy">
We've tried to force the filtering security intercept like this as well:
class="org.springframework.security.intercept.web.FilterSecurityInterceptor">
requires-channel="https"/>
The schema validates and supports this attribute to force the SSL channel handling, but the Sonic framework says this attribute, requires-channel, is not allowed here. We had hoped to get any URL to be intercepted by our custom filtering. Could it be that https/SSL filtering is not supported in the esb fsi? That doesn't seem reasonable, but neither does the custom filtering not being invoked when initialized and specified.
It looks like SonicConnectSecurityInInterceptor threw a Fault shortly after logging the INFO level message, which could prevent your filter from getting invoked. Do you have the error message of the Fault?
I think I know why it is not working for you. The "scsec:ServiceConnectInboundSecurity" feature only supports Basic Auth and it will throw a fault if Basic Auth fails. Please disable scsec:ServiceConnectInboundSecurity and see if it helps. You don't need it for using Spring Security.
Regarding setting the log level to DEBUG. I have some suggestion for you to try (if you feel like it).
1) In SMC, select "dev_ESBTEST in the tree on the left pane
I.e. Go to Manage -> Containers -> dev_ESBTest
2) Then, right click on "dev_ESBTest" on the right pane and select "Properties"
3) Click on the "Tracing" tab and you can configure the log level. (see attached screenshot).
I don't see the fault you are referring to in your previous post. The logging about the cipher suites is a message that occurs on every SonicConnect service that publishes an HTTPS endpoint.
I had enabled all of the pertinent trace logging during runtime after starting up and initializing everything. Submitting a request with logging enhanced to the higher levels did not produce any more detail than we have in the output from my initial post - it shows the SonicSecurityInInterceptor information exactly the same, but nothing more.
We are going to try disabling or removing the feature and see if your hunch is correct. We have this enabled on all SonicConnect services which expose their endpoint as HTTPS per the SonicConnect documentation. It is not clear that it threw an error using it, but we are certainly not authenticating with username/password, we are authenticating with the certificate supplied by the client.
Some additional information: The SonicConnect documentation directed us to add this into the spring.xml configuration file to enable HTTPS on the endpoint (web_services.pdf in documentation, Activiating the Sonic Connect inbound security feature topic, page 45):
This was still in place like this when we could not figure out why our custom spring security pre-authentication filters were being intialized but not being executed. This configuration above would allow a client presenting a cert which was in our keystore to have its request processed. Reading further into the documentation in the Core Security section (Chapter 4, Web Service Security, Using Sonic Connect core security, page 39), indicates that it should look like this to specifically use spring security:
The first case, simply specifying the empty element, allows the request to process, it logs the basic SonicSecurityInIntercept logging I noted in my initial posting, says it is adding props of the cert to the ESB context in the message. The second case with the expanded element with the element blocks the request altogther as unauthorized.
[11/04/06 13:37:01] ID=dev_ESBTest (info)
Sonic Connect
Version 8.0 Build Number 174
Copyright (c) 2010 Progress Software Corporation.
All rights reserved.
Apr 6, 2011 1:37:03 PM com.edc.c2c.esb.webservice.sonic.security.spring.X509JurisdictionPreAuthenticatedProcessingFilter
INFO: ***** Creating X509 Jurisdiction pre-authenticated filter.
Apr 6, 2011 1:37:05 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromWSDL
INFO: Creating Service {http://www.mycompany.com/myApp/}myApp from WSDL: resources/wsdl/myApp.wsdl
Apr 6, 2011 1:37:06 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be https://192.168.1.147:488/webservices/myApp/myAppService.svc
Apr 6, 2011 1:37:06 PM org.mortbay.log.Slf4jLog info
INFO: jetty-6.1.21
Apr 6, 2011 1:37:06 PM org.apache.cxf.transport.https.SSLUtils getCiphersuites
INFO: The cipher suites have not been configured, falling back to cipher suite filters.
Apr 6, 2011 1:37:06 PM org.apache.cxf.transport.https.SSLUtils getCiphersuites
INFO: The cipher suite filters have not been configured, falling back to default filters.
Apr 6, 2011 1:37:06 PM org.apache.cxf.transport.https_jetty.CXFJettySslSocketConnector newServerSocket
INFO: The cipher suites have been set to [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA].
Apr 6, 2011 1:37:06 PM org.mortbay.log.Slf4jLog info
INFO: Started CXFJettySslSocketConnector@0.0.0.0:488
[11/04/06 13:37:06] ID=dev_ESBTest (info) [WebServiceSonicConnectService] Initialized.
[11/04/06 13:37:06] ID=dev_ESBTest (info) Actional instrumentation is disabled for this container
[11/04/06 13:37:06] ID=dev_ESBTest (info) Initializing Mitigation context factory class: com.sonicsw.xqimpl.actional.lg.visitor.StabilizerHelper
[11/04/06 13:37:06] (info) Loaded ID=dev_ESBTest
[11/04/06 13:37:06] ID=dev_ESBTest (info) Container's ESB (JMS) Connection: jms_defaultConnection
[11/04/06 13:37:06] ID=dev_ESBTest (info) Container's HTTP Routing Connection: http_defaultConnection
[11/04/06 13:37:06] (info) ...startup complete
[11/04/06 13:37:07] ID=dev_ESBTest (info) Attempting to (re)establish connection: jms_defaultConnection
[11/04/06 13:37:08] ID=dev_ESBTest (info) Connection to endpoint 'AuthenticateProcess.Entry' (re)established for connection 'jms_defaultConnection' at localhost:2506
Apr 6, 2011 1:37:37 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor replyUnauthorized
INFO: Sending HTTP 401 Response challenge for Realm : SonicESB HTTP(S) Authentication Realm
Apr 6, 2011 1:37:47 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor replyUnauthorized
INFO: Sending HTTP 401 Response challenge for Realm : SonicESB HTTP(S) Authentication Realm
Recall, earlier, the requests were allowed and processed, but the output was:
Mar 31, 2011 3:27:58 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor addPropsToEsbContext
INFO: Service Connect Security Context properties : {TLSX509SubjectDN=CN=city,OU=Unknown,O=cityRMS,L=city,ST=VA,C=US, HTTPBasicAuth=null, AIPropagatedIDLong=null, TLSX509SubjectFirstCN=city, AIPropagatedID=null, PrincipalName=city, PrincipalSource=TLSX509SubjectFirstCN, HTTPDigestAuth=null}
Mar 31, 2011 3:28:13 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor addPropsToEsbContext
INFO: Service Connect Security Context properties : {TLSX509SubjectDN=CN=county,OU=Unknown,O=countyRMS,L=county,ST=VA,C=US, HTTPBasicAuth=null, AIPropagatedIDLong=null, TLSX509SubjectFirstCN=county, AIPropagatedID=null, PrincipalName=county, PrincipalSource=TLSX509SubjectFirstCN, HTTPDigestAuth=null}
Still no logging or indications that our custom filter is being invoked. I'm going to attach the full spring.xml configuraiton file we are using with this SonicConnectWebService implementation:
William, the lack of debug logging in the Sonic core information is a little problematic. Enabling the Commons Logging attributes and the runtime ESB container Tracing settings doesn't add anything of apparent value. I'm wondering how we could get more information about the unauthorized reply in an above reply in the this forum thread.
I'm attaching our custom log4j.xml file specified on the environment as a Java system property. Perhaps I need a Sonic specific appender I've seen mentioned in some documentation? If so, what sonic package template match should be applied? com.progress or com.sonicsw? Thanks.
I've included the Sonic Appender in my over-arching log4j file for com.progress and com.sonicsw classes but there is some logging configuration that has to be getting loaded in advance of my log4j.xml configuration even though it is specified in the Java system properties.
Here's the container log output when making a client request to this service using "FIRST", "PRE_AUTH_FILTER", or "X509_FILTER" attribute on the attribute. The request from the client supplies a cert that we 'know' and contain in our keystore:
Apr 7, 2011 10:55:34 AM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor replyUnauthorized
INFO: Sending HTTP 401 Response challenge for Realm : SonicESB HTTP(S) Authentication Realm
In our element configuration, with it simplified, before realized we further needed to reference the authenticationManager, the request would pass through and we see these messages in the container log:
Mar 31, 2011 3:27:58 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor addPropsToEsbContext
INFO: Service Connect Security Context properties : {TLSX509SubjectDN=CN=city,OU=Unknown,O=cityRMS,L=city,ST=VA,C=US, HTTPBasicAuth=null, AIPropagatedIDLong=null, TLSX509SubjectFirstCN=city, AIPropagatedID=null, PrincipalName=city, PrincipalSource=TLSX509SubjectFirstCN, HTTPDigestAuth=null}
Mar 31, 2011 3:28:13 PM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor addPropsToEsbContext
INFO: Service Connect Security Context properties : {TLSX509SubjectDN=CN=county,OU=Unknown,O=countyRMS,L=county,ST=VA,C=US, HTTPBasicAuth=null, AIPropagatedIDLong=null, TLSX509SubjectFirstCN=county, AIPropagatedID=null, PrincipalName=county, PrincipalSource=TLSX509SubjectFirstCN, HTTPDigestAuth=null}
With the more specific element configuration, we see these messages in the container log and the request denied. The authenticationManager configuration setup is noted in this thread as well:
Apr 7, 2011 10:55:34 AM com.progress.sonic.esb.service.connect.security.interceptor.SonicConnectSecurityInInterceptor replyUnauthorized
INFO: Sending HTTP 401 Response challenge for Realm : SonicESB HTTP(S) Authentication Realm
I was mistaken. ServiceConnectInboundSecurity feature is needed in order to dispatch to Spring Security.
Regarding to the custom authentication provider (below).
class="org.springframework.security.providers.preauth.PreAuthenticatedAuthenticationProvider">
It is a limitation of ServiceConnectInboundSecurity feature (as mentioned on page 39 in "Sonic ESB Working with Web Services) that "authenticationType" only supports "Basic" (Basic Auth). I verified it with a debugger. So, what happening is that ServiceConnectInboundSecurity can only create UsernamePasswordAuthenticationToken. Unfortunately, PreAuthenticatedAuthenticationProvider does not support UsernamePasswordAuthenticationToken. Therefore, the custom auth provider is not activated. (I am still looking into the problems with filters).
Regarding to the logging issue, what logging APIs do you use in your code? (common logging, log4j, java util logging, etc)
I think the issue with Filters not getting invoked is due to there is nothing to dispatch Servlet requests to Spring Security's FilterChainProxy. Unlike "regular" servlet containers, you can configure the filter mapping in web.xml. It does not seem possbile in Sonic Conect. I'd suggest you to log a feature enhancement request with technical support.
William, I will log this as an enhancement request.
For the benefit of the other readers, we were able to get the certificate request details, "TLSX509SubjectDN" information propagated as message header properties simply by removing the "TLSX509SubjectDN" element from the "outFilter" rules in the spring.xml file. I think this will suffice right now and the customizations were were attempting to place into the pre-auth filtering, we can place into a custom security service within the SonicConnect service as a workaround. It's not ideal since it means the message must get into the ESB versus being handled at the pre-auth-filter level, but it suffices for the time being.