Integration – Kamran Zafar

October 18, 2016June 8, 2019

CAS and distributed Infinispan integration

CAS is a centralised authentication server that makes it very easy to implement single sign-on (SSO) in java application, and is a very good OAuth alternative. For distributed/clustered environments CAS also offers integration with a number of caching technologies in order to support single-logout (SLO). Recently we had an issue on clustered Wildfly J2EE servers where we had to support SLO in our distributed spring-boot based applications. Infinispan is the default distributed caching technology used by Wildfly, and unfortunately we didn’t find any integration support provided by CAS for Infinispan. So I wrote an integration library for CAS & Infinispan, which is available on github under Apache License. This library makes it possible to achieve SLO in distributed J2EE applications on Wildfly.

In order integrate CAS on the client side add the following dependency to the application’s POM file:

<dependency>
    <groupId>org.kamranzafar.cas.client</groupId>
    <artifactId>cas-client-support-distributed-infinispan</artifactId>
    <version>1.1</version>
</dependency>

<groupId>org.kamranzafar.cas.client</groupId>

<artifactId>cas-client-support-distributed-infinispan</artifactId>

</dependency>

We then lookup the distributed Infinispan cache using JNDI and use it as storage for CAS tickets. Please see my previous post for more information on Infinispan and Spring boot integration.

// Lookup the relevant Cache that will be used to store CAS proxy granting tickets
@Bean
public Cache defaultCache() throws NamingException {
    return (Cache) ((DefaultCacheContainer) new JndiTemplate().lookup("java:jboss/infinispan/container/sso")).getCache();
}
.
.
.
// Create the bean for InfinispanProxyGrantingTicketStorage
@Bean
public ProxyGrantingTicketStorage proxyGrantingTicketStorage(){
    return new InfinispanProxyGrantingTicketStorage(defaultCache());
}
.
.
.
// Setup CasAuthenticationFilter to use Infinispan
CasAuthenticationFilter casAuthenticationFilter = new CasAuthenticationFilter();
casAuthenticationFilter.setProxyGrantingTicketStorage(proxyGrantingTicketStorage());
.
.
// Setup Cas20ProxyTicketValidator to use Infinispan
Cas20ProxyTicketValidator cas20ProxyTicketValidator = new Cas20ProxyTicketValidator("...");
cas20ProxyTicketValidator.setProxyGrantingTicketStorage(proxyGrantingTicketStorage());

// Lookup the relevant Cache that will be used to store CAS proxy granting tickets

@Bean

public Cache defaultCache() throws NamingException {

return (Cache) ((DefaultCacheContainer) new JndiTemplate().lookup("java:jboss/infinispan/container/sso")).getCache();

}

// Create the bean for InfinispanProxyGrantingTicketStorage

@Bean

public ProxyGrantingTicketStorage proxyGrantingTicketStorage(){

return new InfinispanProxyGrantingTicketStorage(defaultCache());

}

// Setup CasAuthenticationFilter to use Infinispan

CasAuthenticationFilter casAuthenticationFilter = new CasAuthenticationFilter();

casAuthenticationFilter.setProxyGrantingTicketStorage(proxyGrantingTicketStorage());

// Setup Cas20ProxyTicketValidator to use Infinispan

Cas20ProxyTicketValidator cas20ProxyTicketValidator = new Cas20ProxyTicketValidator("...");

cas20ProxyTicketValidator.setProxyGrantingTicketStorage(proxyGrantingTicketStorage());

With this CAS will use the distributed Infinispan on Wildfly to cache the authentication tickets. The authentication tickets are deleted on user logout. So now when the user logs out from one of the applications, deployed on Wildfly, he/she will be logged out from all the clustered applications; hence achieving single-logout (SLO).

For more information please see the CAS-Infinispan integration client on Github.

September 17, 2016June 8, 2019

Spring and Infinispan Integration on Wildfly Cluster

Spring framework provides a caching abstraction API that makes it very easy and consistent to use a lot of embeddable caching frameworks like, EHCache, Infinispan, Hazelcast etc. But sometimes it is also necessary to integrate with the underlying application server’s caching framework, especially in a clustered, distributed environment. In this post I will show how we can integrate a spring-boot application, deployed on clustered Wildfly application servers (version 10.1.0.Final), to integrate with the distributed Infinispan cache. Below is an illustration:

Wildfly already packs Infinispan caching framework as a subsystem, which the applications can leverage from in order to cache shared/private objects. So lets first create a custom replicated-cache container which we can use to share cached objects across a cluster of Wildfly servers. In order to use replicated cache, each instance of Wildfly needs to be started with full-ha profile via standalone-full-ha.xml configuration file. Below is what we need to add in this configuration file in order to create a replicated cache container:

<cache-container name="mycache" aliases="ha-partition" default-cache="default" module="org.wildfly.clustering.server">
    <transport lock-timeout="60000"/>
    <replicated-cache name="default" mode="SYNC">
        <transaction mode="BATCH"/>
    </replicated-cache>
</cache-container>

<cache-container name="mycache" aliases="ha-partition" default-cache="default" module="org.wildfly.clustering.server">

<replicated-cache name="default" mode="SYNC">

</replicated-cache>

</cache-container>

We can lookup this cache container using the following JNDI name:

java:jboss/infinispan/container/mycache

1	java:jboss/infinispan/container/mycache

In the Spring Boot Application we need the following dependency added to lookup and use the Infinispan cache.

<dependency>
    <groupId>org.wildfly</groupId>
    <artifactId>wildfly-clustering-infinispan-extension</artifactId>
    <version>10.1.0.Final</version>
    <scope>provided</scope>
    <exclusions>
        <exclusion>
            <groupId>org.jboss.metadata</groupId>
            <artifactId>jboss-metadata-common</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.jboss.metadata</groupId>
            <artifactId>jboss-metadata-ejb</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.jboss.metadata</groupId>
            <artifactId>jboss-metadata-ear</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.jboss.openjdk-orb</groupId>
            <artifactId>openjdk-orb</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<groupId>org.wildfly</groupId>

<artifactId>wildfly-clustering-infinispan-extension</artifactId>

<version>10.1.0.Final</version>

<scope>provided</scope>

<groupId>org.jboss.metadata</groupId>

<artifactId>jboss-metadata-common</artifactId>

</exclusion>

<groupId>org.jboss.metadata</groupId>

<artifactId>jboss-metadata-ejb</artifactId>

</exclusion>

<groupId>org.jboss.metadata</groupId>

<artifactId>jboss-metadata-ear</artifactId>

</exclusion>

<groupId>org.jboss.openjdk-orb</groupId>

<artifactId>openjdk-orb</artifactId>

</exclusion>

</exclusions>

</dependency>

Also because the dependency is “provided” by the application server, we need to add manifest entries so that we have access to all the required classes on runtime. In order to achieve this we’ll add the following plugin to the pom file.

<plugin>
    <artifactId>maven-war-plugin</artifactId>
    <configuration>
        <failOnMissingWebXml>false</failOnMissingWebXml>
        <archive>
            <manifestEntries>
                <Dependencies>org.infinispan, org.infinispan.commons, org.jboss.as.clustering.infinispan
                    export
                </Dependencies>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

<artifactId>maven-war-plugin</artifactId>

<failOnMissingWebXml>false</failOnMissingWebXml>

<Dependencies>org.infinispan, org.infinispan.commons, org.jboss.as.clustering.infinispan

export

</Dependencies>

</manifestEntries>

</archive>

</configuration>

</plugin>

Now the application is all setup to lookup and use the distributed Infinispan cache, below is how we can do this:

String cacheContainerJndi ="java:jboss/infinispan/container/mycache";

Cache cache = (Cache) ((DefaultCacheContainer) new JndiTemplate().lookup(cacheContainerJndi)).getCache();
cache.put("mykey", "myvalue");

String val = cache.get("mykey");

String cacheContainerJndi ="java:jboss/infinispan/container/mycache";

Cache cache = (Cache) ((DefaultCacheContainer) new JndiTemplate().lookup(cacheContainerJndi)).getCache();

cache.put("mykey", "myvalue");

String val = cache.get("mykey");

The complete Spring Boot application is available on Github.

This is just a simple usecase that shows how we can use Wildfly’s distributed cache in applications. In the next blog entry I will demonstrate how this distributed Infinispan cache can be used to integrate CAS Single Sign On in order to effectively achieve SSO/SLO in a clustered/distributed Wildfly environment.

August 8, 2016June 8, 2019

Spring Boot and WordPress CMS Integration

There are a lot of excellent open source content management systems available today, WordPress being one of them, which is widely used. WordPress is a PHP based CMS so not a lot of cohesion is available with other technologies like Java, and is simply ignored as a viable content management option just for being non-Java.

In this post I will demonstrate how WordPress can be integrated with Spring Boot applications, all made possible with WordPress REST plugin and a Spring client. Both of these are open source and available for free. Below is a simple design diagram that explains how this integration works. This post assumes that the reader has prior knowledge of WordPress and Spring Boot.

First install and activate WP-API v2 plugin on the WordPress site. After activation, you could verify that the plugin is working by accessing http://yoursite/wp-json/wp/v2/posts, which should display all the posts in JSON format.

In the spring boot application add the following dependency in order to include the Spring WP-API client.

<dependency>
    <groupId>org.kamranzafar.spring.wpapi</groupId>
    <artifactId>spring-wpapi-client</artifactId>
    <version>0.1</version>
</dependency>

<groupId>org.kamranzafar.spring.wpapi</groupId>

<artifactId>spring-wpapi-client</artifactId>

</dependency>

Below is a sample configuration we need in the application.properties file, so that we can connect our Spring Boot application to our WordPress site.

wpapi.host=yoursite.com
wpapi.port=443   # Optional, default is 80
wpapi.https=true # Optional, default is false

wpapi.host=yoursite.com

wpapi.port=443 # Optional, default is 80

wpapi.https=true # Optional, default is false

The Spring WP-API client needs the RestTemplate so lets create a bean in our Application and autowire the Spring client. We also need to add component scan annotation so that Spring finds and autowires all the required dependencies.

@SpringBootApplication
@ComponentScan("org.kamranzafar.spring.wpapi")
public class Application implements CommandLineRunner {
    public static void main(String args[]) {
        SpringApplication.run(Application.class);
    }

    @Autowired
    private WpApiClient wpApiClient;

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

@SpringBootApplication

@ComponentScan("org.kamranzafar.spring.wpapi")

public class Application implements CommandLineRunner {

public static void main(String args[]) {

SpringApplication.run(Application.class);

}

@Autowired

private WpApiClient wpApiClient;

@Bean

public RestTemplate restTemplate() {

return new RestTemplate();

}

Now our spring boot application is all setup to connect to out WordPress site in order to retrieve and create content. So lets try and lookup all the posts having the keyword “Spring”, below is how we can do this.

Map<String, String> params = new HashMap<>();
params.put("search", "Spring");
params.put("per_page", "2"); // results per page
params.put("page", "1"); // current page

// See WP-API Documentation more parameters
// http://v2.wp-api.org/reference/

Post[] posts = wpApiClient.getPostService().getAll(params);

for (Post p : posts) {
    log.info("Post: " + p.getId());
    log.info("" + p.getContent());
}

Map<String, String> params = new HashMap<>();

params.put("search", "Spring");

params.put("per_page", "2"); // results per page

params.put("page", "1"); // current page

// See WP-API Documentation more parameters

// http://v2.wp-api.org/reference/

Post[] posts = wpApiClient.getPostService().getAll(params);

for (Post p : posts) {

log.info("Post: " + p.getId());

log.info("" + p.getContent());

}

The complete test application is available with the Spring WP-API client on Github.

This is just a small example of how we can integrate Spring Boot and WordPress. We can take this further by properly integrating WordPress in the Spring web applications platform, e.g. by enabling Single Sign On using the CAS plugin.

And we can evolve this design even further by having a second-level content storage, like a database or an in-memory caching solution etc. This storage can serve as a cache and can also be used for additional configuration, so that we display relevant content faster in our Spring applications.

For more information please see the documentation of the WordPress REST plugin and Spring WP-API client.

April 7, 2016June 8, 2019

Using Standalone ActiveMQ Broker with Wildfly

Wildfly is an open source J2EE container, which comes with an embedded HornetQ JMS broker enabled by default in it’s full configuration. The embedded HornetQ works great out of the box, but sometimes it can be handy to use an existing JMS broker, like ActiveMQ. ActiveMQ includes a JCA resource adaptor that can be used to integrate it with J2EE containers. Below we will see how to integrate standalone ActiveMQ 5.13.2 with Wildfly 9.0.2 server.

The first step is to download, tweak and deploy the ActiveMQ Resource Adaptor (RA) on Wildfly. ActiveMQ RA binaries are available on Apache’s site for download. So lets download and unpack the adaptor.


wget https://repository.apache.org/content/repositories/releases/org/apache/activemq/activemq-rar/5.13.2/activemq-rar-5.13.2.rar
unzip -d activemq-rar activemq-rar-5.13.2.rar

wget https://repository.apache.org/content/repositories/releases/org/apache/activemq/activemq-rar/5.13.2/activemq-rar-5.13.2.rar

unzip -d activemq-rar activemq-rar-5.13.2.rar

Now, because we don’t need to run ActiveMQ embedded in Wildfly, we’ll comment out the necessary configuration. This can be done by editing the activemq-rar/META-INF/ra.xml, and removing the config-property with the following comment:


<!-- NOTE disable the following property if you do not wish to deploy an embedded broker -->

After this we’ll pack the adaptor and deploy it on Wildfly.


cd activemq-rar # Directory where the rar file was unpacked in the previous step
zip activemq-rar-5.13.2.rar .
cp activemq-rar-5.13.2.rar $WILDFLY_HOME/standalone/deployments

cd activemq-rar # Directory where the rar file was unpacked in the previous step

zip activemq-rar-5.13.2.rar .

cp activemq-rar-5.13.2.rar $WILDFLY_HOME/standalone/deployments

We can now configure this Resource Adaptor on Wildfly in order to create and bind an ActiveMQ connection factory in JNDI. Below is a sample configuration that we need in Wildfly’s standalone.xml configuration file (or the server’s current domain configuration file depending on the setup). The resource adaptor configuration reference is available on Apache’s site


<subsystem xmlns="urn:jboss:domain:resource-adapters:3.0">
    <resource-adapters>
        <resource-adapter id="activemq">
            <archive>activemq-rar-5.13.2.rar</archive>
            <transaction-support>XATransaction</transaction-support>
            <config-property name="UseInboundSession">false</config-property>
            <config-property name="ServerUrl">tcp://localhost:61616</config-property>
            <connection-definitions>
                <connection-definition class-name="org.apache.activemq.ra.ActiveMQManagedConnectionFactory" jndi-name="java:/ConnectionFactory" enabled="true" pool-name="ConnectionFactory">
                    <xa-pool>
                        <min-pool-size>1</min-pool-size>
                        <max-pool-size>20</max-pool-size>
                        <prefill>false</prefill>
                        <is-same-rm-override>false</is-same-rm-override>
                    </xa-pool>
                </connection-definition>
            </connection-definitions>
            <admin-objects>
                <admin-object class-name="org.apache.activemq.command.ActiveMQQueue" jndi-name="java:/jms/queue/test-queue" use-java-context="true" pool-name="test-queue">
                    <config-property name="PhysicalName">jms/queue/test-queue</config-property>
                </admin-object>
            </admin-objects>
        </resource-adapter>
    </resource-adapters>
</subsystem>

<resource-adapters>

<resource-adapter id="activemq">

<archive>activemq-rar-5.13.2.rar</archive>

<transaction-support>XATransaction</transaction-support>

<config-property name="UseInboundSession">false</config-property>

<config-property name="ServerUrl">tcp://localhost:61616</config-property>

<connection-definitions>

<connection-definition class-name="org.apache.activemq.ra.ActiveMQManagedConnectionFactory" jndi-name="java:/ConnectionFactory" enabled="true" pool-name="ConnectionFactory">

<xa-pool>

<min-pool-size>1</min-pool-size>

<max-pool-size>20</max-pool-size>

<prefill>false</prefill>

<is-same-rm-override>false</is-same-rm-override>

</xa-pool>

</connection-definition>

</connection-definitions>

<admin-objects>

<admin-object class-name="org.apache.activemq.command.ActiveMQQueue" jndi-name="java:/jms/queue/test-queue" use-java-context="true" pool-name="test-queue">

<config-property name="PhysicalName">jms/queue/test-queue</config-property>

</admin-object>

</admin-objects>

</resource-adapter>

</resource-adapters>

</subsystem>

After this, in our applications deployed on Wildfly, we can simply lookup the ActiveMQConnectionFactory from JNDI (java:/ConnectionFactory) and start sending and receiving messages.

August 5, 2015

XMPP web chat with ejabberd, Converse.js and Spring MVC

Converse.js is a fine little XMPP web chat client that can easily be used in web applications. It can integrate with various online XMPP services, like Google Talk, MSN etc. In this post I will demonstrate how to use converse.js with ejabberd in a Spring based application. I used Ubuntu linux box to for this demo.

ejabberd is available in main Ubuntu repositories so can be installed by using the following command.


sudo apt-get install ejabberd

sudo apt-get install ejabberd

The first thing to do is to add an admin user, by adding the following to the /etc/ejabberd/ejabberd.cfg configuration file.


{acl, admin, {user, "admin", "localhost"}}.

{acl, admin, {user, "admin", "localhost"}}.

Then restart ejabberd


sudo service ejabberd restart

sudo service ejabberd restart

Now register the admin user by entering the following command on the shell prompt.


sudo ejabberdctl register admin localhost password

sudo ejabberdctl register admin localhost password

For more details on ejabberd setup and additional options, follow this tutorial.

[turbo_widget widget-prefix=text&obj-class=WP_Widget_Text&widget-text–title=&widget-text–text=%3C!–+Post+Ad+–%3E%0A%3Cins+class%3D%22adsbygoogle%22%0A+++++style%3D%22display%3Ablock%22%0A+++++data-ad-client%3D%22ca-pub-4433761869744390%22%0A+++++data-ad-slot%3D%229020480262%22%0A+++++data-ad-format%3D%22auto%22%3E%3C%2Fins%3E%0A%3Cscript%3E%0A(adsbygoogle+%3D+window.adsbygoogle+%7C%7C+%5B%5D).push(%7B%7D)%3B%0A%3C%2Fscript%3E&widget-text–filter=false]

Next we enable http binding, which is required because converse.js will communicate with ejabberd using the BOSH protocol. In order to do this look for the 5280 (ejabberd_http) port setup in the configuration file and update it to look like below:


{5280, ejabberd_http, [
         http_bind,
         http_poll,
         web_admin
         ]}

{5280, ejabberd_http, [

http_bind,

http_poll,

web_admin

]}

Then add the http_bind module under the modules section, then restart ejabberd.


{mod_http_bind,[]}

{mod_http_bind,[]}

Now the XMPP server is setup for this demo. The http binding can be verified by opening the following link in the web browser.


http://localhost:5280/http-bind

http://localhost:5280/http-bind

Optionally we can also setup Apache/Nginx web server to proxy the http bind requests to ejabberd. If required add something like the following to the web server configuration. This is useful, if ejabberd port 5280 is blocked by the firewall.


    ProxyPass http://localhost:5280/http-bind/
    ProxyPassReverse http://localhost:5280/http-bind/
    Order allow,deny
    Allow from all

ProxyPass http://localhost:5280/http-bind/

ProxyPassReverse http://localhost:5280/http-bind/

Order allow,deny

Allow from all

Converse.js can now talk to the ejabberd server. The javascript snippet below shows how to use it in the web application.


converse.initialize({
    bosh_service_url: 'http://localhost:5280/http-bind/',
    keepalive: true,
    message_carbons: true,
    play_sounds: true,
    roster_groups: true,
    show_controlbox_by_default: true,
    xhr_user_search: false
 });

converse.initialize({

bosh_service_url: 'http://localhost:5280/http-bind/',

keepalive: true,

message_carbons: true,

play_sounds: true,

roster_groups: true,

show_controlbox_by_default: true,

xhr_user_search: false

});

This requires login, and also allows registration of new users from the frontend.

ejabberd HTTP Pre-binding

Sometimes it is desirable not to ask the users to login again, if they are already logged on to the parent application. Which means that the parent application should login to ejabberd from the backend, and then attach the ejabberd session to converse.js. This is achieved by something known as “http pre-binding”, which is supported by converse.js. In order to use an existing ejabberd session, created by the parent application, converse.js needs three pieces of information:

JID (ejabberd user id)
SID (ejabberd session id)
RID (request id)

These IDs are obtained by the parent application, after initiating the session, from the backend, by logging on to ejabberd. In the demo, it is done from a custom spring security AuthenticationProvider.

The converse.js javascript snippet below shows how pre-binding is configured on the frontend.


require(['converse'], function (converse) {
    converse.initialize({
        prebind:true,
        prebind_url: 'http://localhost:8080/prebind', // The prebind URL
        bosh_service_url: 'http://localhost:5280/http-bind', // The http bind URL
        jid: 'admin@localhost', // The jabber id of the logged in user
        keepalive: true,
        allow_logout: false,
        allow_registration: false
    });
});

require(['converse'], function (converse) {

converse.initialize({

prebind:true,

prebind_url: 'http://localhost:8080/prebind', // The prebind URL

bosh_service_url: 'http://localhost:5280/http-bind', // The http bind URL

jid: 'admin@localhost', // The jabber id of the logged in user

keepalive: true,

allow_logout: false,

allow_registration: false

});

The prebind URL must return the three IDs, mentioned above, in JSON format. More information on prebind_url is available on converse.js homepage.

The complete Spring boot application is available on Github, which covers ejabber authentication and pre-binding.

September 14, 2007

Cas-Acegi-Spring integration on JBoss

CAS and Acegi are popular open source authentication and identity solutions available for enterprise java applications. CAS is a Centralized Authentication Server used for single sign-on and to decouple authentication mechanism from applications. Acegi is an authentication API used to put role-based access control on application. This is a simple example that shows how to integrate CAS and Acegi using Spring IoC container in a JBoss Application Server.

This example was tested on JBoss 4.0.4. See the readme file for more details.

Download Example Source