Typically, there are three ways to integrate external applications into a portal. Below, I show these methods and describe how Liferay implements each option.
Presentation Level
- iFrame – an iFrame portlet is included out of the box. Requires SSO to be in place. Authentication information can be supplied to the portlet, so the administrator would enter a global ID and Password. Individual user authentication can be supplied by the portlet. The portlet supports from based authentication, so the password entered is not secure unless you use HTTPS.
Proxy
- Web Proxy – this is similar to the iFrame, but it works on chunks of HTML instead of retrieving the entire page. Links are automatically rewritten as well as other content can be rewritten. The portlet supports Basic or NTLM authentication.
- WSRP – uses the WSRP 2.0 standard and requires a WSRP-compliant producer to be available. Liferay’s consumer implementation propagates the user identity that was used to login to Liferay. This can be troublesome when the producer’s identity is different than the consumer, especially in a federated environment.
Full/Native
- Native application – this involves writing a native portlet that accesses the target system through APIs or services. You have to write this application yourself and you must deal with authentication and authorization issues.
What about integrating other areas, such as search or social?
Integrating Search
Liferay uses Lucene for their search engine. You can integrate search in several ways, including modify the Search Portlet, using OpenSearch to replace the search engine, or incorporating an external Search Engine.
Integrating Social
Liferay supports OpenSocial gadgets, so you can install these gadgets on Liferay. For authentication, you can implement OpenID, CAS or other open authentication systems.
