Thursday, May 19, 2016

LDAP Authentication in JbossFuse (17/250-2016)

Step1: Add WSS4JInInterceptor & JAASLoginInterceptor to cxf:endpoint


<cxf:cxfEndpoint id="ridpEndpoint" address="XXXX" serviceClass="xxxx" wsdlURL="xxx">
    <cxf:inInterceptors>
 <bean id="wss4jInInterceptor" class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
  <property name="properties">
   <map>
    <entry key="passwordType" value="PasswordText" />
    <entry key="action" value="UsernameToken" />
   </map>
  </property>
 </bean>
 <ref component-id="authenticationInterceptor"/>
    </cxf:inInterceptors>
    <cxf:properties>
         <entry key="ws-security.validate.token" value="false"/>
    </cxf:properties>
</cxf:cxfEndpoint>

<bean id="authenticationInterceptor" class="org.apache.cxf.interceptor.security.JAASLoginInterceptor">
      <property name="contextName" value="karaf"/>
</bean>

Within the cxf:inInterceptor, two more interceptors are added.


WSS4JInInterceptor - the Java class to implement the Interceptor is mentioned over here. 
The passwordType and action is defined over here.
The entry in the properties - security action - UsernameToken is mandatory.

ws-security.validate.token - set to false.

We have to tell WSS4J not to authenticate the UsernameToken itself, but just to process it and store it for later authentication via the JAASLoginInterceptor. This is done by setting the JAX-WS property "ws-security.validate.token" to "false". 


JAASLoginInterceptor -  it is necessary to set the "contextName" attribute of the JAASLoginInterceptor, which references the JAAS Context Name to use. It is also possible to define how to retrieve roles as part of the authentication process, by default CXF assumes that javax.security.acl.Group Objects are interpreted as "role" Principals. 


Step2: Using JAAS LoginModules in Apache CXF

Validating a Username + Password to LDAP / Active Directory  - 

2.1 com.sun.security.auth.module.LdapLoginModule - copy the xml(blueprint) below - and create a new file, and place the file in the deploy folder of Jboss Fuse Installation.


<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

  <jaas:config name="karaf" rank="1">
    <jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule"
                 flags="required">
      initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
      connection.username=uid=admin,ou=system
      connection.password=secret
      connection.protocol=
      connection.url=ldap://localhost:10389
      user.base.dn=ou=users,ou=system
      user.filter=(uid=%u)
      user.search.subtree=true
      role.base.dn=ou=roles,ou=system
      role.name.attribute=cn
      role.filter=(member=uid=%u)
      role.search.subtree=true
      authentication=simple
    </jaas:module>
  </jaas:config>
</blueprint>

or 

2.2 org.eclipse.jetty.plus.jaas.spi.LdapLoginModule - Available via the org.eclipse.jetty/jetty-plus dependency. This login module is useful as it's easy to retrieve roles associated with the authenticated user.


sun {
 com.sun.security.auth.module.LdapLoginModule REQUIRED
 userProvider="ldap://localhost:portno/"
 authIdentity="cn={USERNAME},ou=users,dc=example,dc=com"
 useSSL=false
 debug=true;
};

jetty {
    org.eclipse.jetty.plus.jaas.spi.LdapLoginModule required
    debug="true"
    contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
    hostname="localhost"
    port="portno"
    bindDn="uid=admin,dc=example,dc=com"
    bindPassword="ldap_su"
    authenticationMethod="simple"
    forceBindingLogin="false"
    userBaseDn="ou=users,dc=example,dc=com"
    userRdnAttribute="cn"
    userIdAttribute="cn"
    userPasswordAttribute="userPassword"
    userObjectClass="inetOrgPerson"
    authenticated="true";
};







Friday, May 13, 2016

Force Fuse to use TLS1.2 (16/250-2016)

Add the attribute secureSocketProtocol="TLSv1.2" in tlsClientParamaters under the conduit tag

<http:conduit name="https://.*/.*">
<http:tlsClientParameters disableCNCheck="true" secureSocketProtocol="TLSv1.2">


1)mvn clean install

Optional
2)mvn -Pserver -Djavax.net.debug=all (Run server)
3)mvn -Psecure.client -Djavax.net.debug=all (client)

Add "javax.net.debug=all" in system.properties in fuse/etc to start the server in all debug logging.




What is a nonce? (15/250-2016)

In cryptography, a nonce is an arbitrary number that may only be used once.
It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.

May include 

  • timestamp (requires clock synchronization between organizations)







Reference:
https://en.wikipedia.org/wiki/Cryptographic_nonce

Wednesday, May 11, 2016

Troubleshooting - com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x8b (at char #2, byte #-1) (14/250-2016)


Error:
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)[118:org.apache.cxf.cxf-core:3.0.4.redhat-620133]
 at java.lang.Thread.run(Thread.java:745)[:1.7.0_79]
Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x8b (at char #2, byte #-1)
 at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:550)[112:woodstox-core-asl:4.4.1]

Scenario:

SOAPUI --> ESB --> Backend Service Provider
ESB invokes the backend Service Provider, but fails when the service provider sends a response back to ESB.

Caused By:

By default SOAP UI is set to "Accept compressed responses from host". Since client mentions that it can accept GZIP format of the response, the service provider sends the response in a GZIP format.




Analysis:

SOAPUI mentions that it can accept compressed response message, but ESB is not able to handle the GZIP format of the response from the backend service provider.

Resolution:
In ESB, in the producer cxf endpoint (which goes out to the backend service), we have to mention in the InInterceptor to unzip the response from the Backend Service Provider.





Troubleshooting - javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (13/250-2016)

Exception
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Scenario:
This exception occurs when trying to invoke a webservice with a privateKey (JKS file).

Cause:
The provider of the service expects the JKS file to also contain the public certificate

Resolution:

1. Download the public certificate from the webservice endpoint.
    a. open the endpoint in browser
    b. click on "view site information"
    c. click on details --> view certificate --> Certificate - details --> copy to file --> Export fileformat base64.

2. User the keytool to import the public certificate into the jks file (the private certificate)

keytool -import -alias symantec -keystore symantec_vip.jks -trustcacerts -file D:\installs\JFuse6.2_Dev\jboss-fuse-6.2.0.redhat-133\etc\vip_cert.cer

3. Resume testing.

Tuesday, May 10, 2016

Troubleshooting Bundle not Starting- (12/250-2016)


1. Feature or Bundle not installed 
JBossFuse:karaf@root> osgi:install MyBundleURL
JBossFuse:karaf@root> dev:dynamic-import <<bundle_id>>
JBossFuse:karaf@root> osgi:resolve <<bundle_id>>
JBossFuse:karaf@root> packages:imports <<bundle_id>>

2. Import-Package header is incomplete

Import package can be verified by using below commands on JBoss Fuse.
>>imports <bundle-id>
>>headers <bundle-id>


References:
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Deploying_into_the_Container/files/ch12s04.html