Factotum: Documentation Handyman

At JavaOne, Ericcson and Sun announced that they have teamed up on open source IP Multimedia Subsystem (IMS) functionality through the Glassfish project. In the Communications Suite world, this means having SIP functionality natively available for use in Sun Java System Instant Messaging.

The SIP application server donated by Ericsson has become the SailFin project. And here's an example of an application, Conference Manager, which was developed in Sun Labs.

One hopes that this development produces some exciting new SIP applications, both in the community and within Sun.

(Hat tip Doug G. & Jonathon K.)

Ya know, it's actually kinda cool when we use our own products. I'm talking about getting pop-up reminders on your desktop for your Calendar Server appointments. As long as you're running both Calendar Server and Instant Messaging, you can make this happen. And believe it or not, we actually do just that at Sun. Here's how.

To get pop-up reminders, you must have Instant Messaging installed on your network and you must be logged into Instant Messenger. (Instant Messenger can be iconified if you like). With Sun Java Communications Suite 5, the IM configuration wizard configures the iim.conf file for pop-up notifications and there is nothing you need to add to the iim.conf file, unless you want to define an optional password. You still need to modify the Calendar Server ics.conf file and enable calendar reminders in the IM client.

How to do it:

1. Edit the Instant Messaging iim.conf file as shown below, and restart Instant Messaging. (Only required for versions of IM prior to IM 7.2. You can skip the iim.conf configuration steps if running IM 7.2 or later.)

   ! calendar event config
   jms.consumers=cal
   
   jms.providers=ens
   jms.provider.ens.broker=.domain:57997
   jms.provider.ens.factory=com.iplanet.ens.jms.EnsTopicConnFactory
   !
   jms.consumer.cal.destination=enp:///ics/customalarm
   jms.consumer.cal.provider=ens
   jms.consumer.cal.originator=.domain
   jms.consumer.cal.type=topic
   jms.consumer.cal.factory=com.iplanet.im.server.JMSCalendarMessageListener
   jms.consumer.cal.param="eventtype=calendar.alarm"
   iim_agent.enable=true
   iim_agent.agent-calendar.enable=true
   agent-calendar.jid=calimbot..domain
   agent-calendar.password=
   iim_server.components=agent-calendar
   
   *Note: .domain is the fully qualified hostname of the calendar server such as megademo.demo.iplanet.com
   

2. Edit the Calendar Server ics.conf as show belown, and restart Calendar Server.

   caldb.serveralarms = "yes"
   caldb.serveralarms.dispatch = "yes"
   caldb.serveralarms.url = "enp:///ics/customalarm"
   caldb.serveralarms.contenttype = "text/xml"
   caldb.serveralarms.dispatchtype = "ens"
   

3. Click the "Show Calendar Reminders" checkbox in the Instant Messenger client. This is contained in the "Alerts" tab in the Instant Messenger "Settings" popup.

   

Occasionally, someone at Sun actually reads the documents that I write. (Just kidding.) And when they do, they just might not find what they were looking for. So, like good little Sun people, they file a documentation bug. And through the miracle of modern email, that bug ends up in my inbox, alerting me to the dire crisis in the doc.

Don't get me wrong, doc bugs are a good thing, a necessary thing, it's just that I might have an opinion if it's the most important priority that I should be addressing in my Sun life, or if it can wait until some time when I'm not dealing with the usual fires.

That's what happened around the following body of information for Instant Messaging. Some group within Sun, which is tasked with ensuring that we are providing the proper security planning information on all our software products, nailed me for lack of information on Instant Messaging. Here, then, is a summary of what you'll find in the forthcoming Sun Java Communications Suite 5 Deployment Planning Guide.

Overview of Instant Messaging Security

Instant Messaging supports the following levels of security:

• No Security. Communication is all plain text from client through the multiplexor to the server.

• Legacy SSL. Secure communication between client and multiplexor, and plain text between multiplexor and server. (This is only relevant if you are using the multiplexor).

• startTLS. End-to-end secure communication between client and server. If you enable the multiplexor, it does not process any data but instead passes it on to the server.

The startTLS option enables end-to-end encryption (the communication between client-multiplexor-server is all in encryption form), while legacy SSL enables encryption between the Instant Messenger client up to the multiplexor: the communication between multiplexor and server is in plain text (though in a proprietary protocol). Use startTLS if you require a higher level of security. If you use startTLS, you do not need an alternate means of securing the multiplexor-to-server communication (it will be secure).

Protecting Instant Messaging Server and Multiplexor

Instant Messaging supports TLS (Transport Layer Security) and legacy SSL (Secure Sockets Layer) for secure communications. Instant Messaging uses a startTLS extension to the Transport Layer Security (TLS) 1.0 protocol for client-to-server and server-to-server encrypted communications and for certificate-based authentication between servers. In addition, Instant Messaging supports a legacy implementation of the SSL protocol (version 3.0) for encrypted communications between the Instant Messenger client and the multiplexor.

The Instant Messaging default installation supports only SASL Plain. If you require a higher level of security, use the Instant Messaging public Service Provider Interface. SASL Plain and jabber:iq:auth are two forms of plain text authentication. That is, in both, the password is sent in the clear (encoded perhaps, but still clear text) and so both are insecure forms of authentication. Nevertheless, this is an issue only if end-to-end encryption (through startTLS for direct socket connection, and HTTPS for httpbind) is not enabled. If end-to-end encryption is enabled, the password is not “seen” in the clear on the network.

Alternatively, if you do not want to transmit passwords in the clear (even if over an encrypted stream), use the Instant Messaging SPI for plugging in authentication mechanism's at the server side through SASLRealm. You can implement custom SASL mechanisms as implementations but you will then need an Instant Messaging client that supports this custom mechanism. The Sun Java System Instant Messaging client supports only SASL Plain, jabber:iq:auth (both insecure).

Providing Instant Messaging Client Access Through a Firewall

The XMPP/HTTP Gateway (httpbind) provides Instant Messaging access to XMPP-based clients, such as HTML based clients, and clients that are behind firewalls that allow HTTP traffic only and don't permit XMPP traffic. The gateway proxies Instant Messaging traffic to the XMPP server on behalf of HTTP clients.

Protecting the Instant Messaging Archive

Instant Messaging has the capability to archive instant messages for later retrieval and searching. If you enable the email archive, you need to decide which administrators will receive email containing archived instant messages. You can configure a separate list of administrators to receive polls, news, conference, alerts, or chat sessions. You can also configure Instant Messaging to use the extended RFC 822 header. Doing so allows mail clients to filter messages based on the header content. If you do enable the Portal archive, you can decide which administrators can access the Portal archive database.