Integration?

This is a guide to integrating applications into Zaltana.

Levels of Integration

There are a number of levels of integration that are documented in IntegrationLevelList

• Remote - Remote systems, integrated only by APIs such as Mashup, RSS, REST, SOAP etc.
• Authentication - Only authentication has been done, application is independent
• Public - The normal public user will see the interface as if it was a local monolythic application
• User - The logged in user will see the interface as if it was local.
• Admin - The admin interface appears to be local

There are also some optional integration levels.

• Storage - The system is using the common user disk storage - this is an advanced feature
• Admin - Provides necessary hooks for a common admin system to get data (e.g. disk usage of a users webmail).

Authentication

The first part of integration is to change the authentication to a standard system.

Using Apache Trust

At its simplest level, Aapche will set the 'user' and the REMOTE_USER environtment variable only if a user is logged in. Many developers of web applications have wrongly assumed for years that this means Apache Basic Auth - because that was the default. It means any authentication system from NTLM to Time of day (although technically time of day should be access control, not authenticaiton). Writing a secure authentication code - e.g. Cookies via SSL form passwords - is easy to do. Writing it in applications leaves many possible problems.

Many applications (e.g. ApplicationTwiki?) has already been modified to accept apache authentication and trust it. Those applications can be dropped in with local access with no changes, or sometimes only a module/plugin change.

Modification

Most well engineered applications will use a central point for checking access control. This can usually be changed by using the environmenv variable or user method of apache (C and Perl - not sure about others) to pass authentication or not. Some rare applications will check the cookie directly throughout the code - these are obviously harder to change.

Some applications (e.g. ApplicationSquirrelMail) ned the authentication to move on to the next part - e.g. log into the IMAP server. This is not really possible as is, and is not the advised secure way to login to IMAP anyway. A better approach is to use the login name and something like the Master Password system of Dovecot to do the login. Where the apache server is then 'trusted' to login as any user, by first logging in as another user. Alternatively (although not recommended) extra variables can be assigned from the authentication system.

Public vs Authenticated

Many systems have the idea (epsecially systems such as a ComponentCMS) of the same URL being accessed by the public (unauthenticated) and by the logged in and administration users. This can still be easily achieved by either just checking if the the user ris blank, or by setting the user to something known such as 'public'. The AuthenticationList provides discussion and implementations. Note that it is also very useful to have a public vs guest user - where guest is not logged in either, but has been confirmed in some way (e.g. not being a bot - by confirming against an image etc).

Extra Data

One of the harder (but optional) parts of the authentication is then the user other information. Simple things like email are not so bad, because they are normally fairly common. But access groups specific to a product (like a ComponentCMS editor or publish group) are harder to share.

The AuthenticationSystem (Environment Variables) is the beginning of a common set of information available from the authentication system to all subsystems.

Some systems requiring more information may use the login name as a key directly into another system such as mysql or LDAP - this of couse assumes you use the same system and the same schema as the app does - it is better to use the variables passed in (also much faster and more secure).

Presentation

Simple Template Changes

The easiest way to get a common look and feel is to change the templates so that they are producing the necessary HTML that the CSS and Images will work with. Combined with the authentication this gives the user a common look and feel and single sign on, but does not allow the applications to truely integrate. For example, this will not allow a common menu structure, or the ability to take content from this application into a window or section (expanding via WidgetObject) of another applicaiton (e.g. desktop).

XSL or other converting / Wrapping

What is desired is the standard intermediate xml that can be converted by the common style system. This can then be wrapped and expanded to include common headers, footers, navigaiton etc. It can also then be called as components into another, popups and more

One of the easiest ways to do that is to try and wrap the html. LibXML? can even parse reasonable HTML. Writing an XSL which can wrap the content of the output via an Apache Filter and change it into the form that we require.

Remote Calls

Put simply, this is a method of accessing the content by using remote calls. Some systems allow full control in this manner. If you only want to do IntegrationLevelPublic - this is a way of achieving it, but really by only doing IntgrationLevelRemote?.

A good example of this is accessing calendar entries, to allow the public (or even the user) to see the calendar entries, or even to download the exported calendars - but leave the administration of those calendars to the 3rd party system, either remotely, or locally but without any modifications.

Full Template Changes

The ideal modification is to convert the templates, or code, to output the correct XML across the whole system. This should produce the Intermediate XML described by WidgetList.

Things like navigation should be removed (site navigation, page and local object navigation should remain). Once this is done parts of the page can be used, systems can be integrated - e.g. having mail be updated in a window in a portal (desktop) by calling into Squirrel Mail.

As these templates produce known xml it can also be converted by the presentation system to include things like context sensitve lookup (e.g. clicking on an email will show details about that user - live even, like if they are logged into Jabber).

Action Integration

Applications benefit mostly from cross application integration. Therefore, being able to access details about email for a user (e.g. Squirrel mail could provide an Aciton that shows the most recent email subject, and number of messages by a particular user) as an action means that we can have that information when we moust over or right click on a users email address anywhere on the site.

Most of these "Actions" will not be available by default and will need to be created, however many applicaitons now have AJAX actions which can often be reused or slightly modified to produce the functionality.