Thursday Aug 02, 2007

They're Head Over Heels: Comms Suite 5 Deployment Example for Linux

Yes, Comms Suite runs on more than Solaris, remember that other OS--Linux? Thanks to Shane H., we now have an 'offical' quick start guide for installing the Comms Suite 5 stack on Linux.

Get the doc here:

Wednesday Mar 14, 2007

Communications Suite 5 Doc Leak: Installing on a Single Host

I know we're not shipping Communications Suite 5 until March 23, but you can go ahead and grab a copy of single host deployment example now:

http://docs.sun.com/app/docs/doc/820-0086

This deployment example describes how to install Sun Java Communications Suite 5 software on one computer for a functioning deployment. This document is intended for any evaluator, system administrator, or installation technician who wants to install and evaluate the services delivered by these components.

Now all you have to do is wait for the bits.

Update In the past, this example has documented how to install the Communications Channels (portlets) provided by our Portal Server product. That's a thing of the past. Looks like Portal is no longer providing these specific Comms Channels anymore, though the 'capability' to deploy these channels still exists. Heads-up to those of you who have used this out-of-the-box functionality in previous releases.

Monday Mar 12, 2007

Locking Down a Sun Java System Instant Messaging Deployment

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.

Tuesday Jan 30, 2007

Wanted: A Few Good Communications Suite Examples

We in documentation hear what customers want: more examples. Communications Suite examples, especially for deployment, are unfortunately far and few between. Good news is that I'm updating the single-host deployment example for the upcoming Communications Suite 5 release.

And more good news: the document itself is shrinking by a number of pages. Does this mean that the Comms Suite stack (along with the Java ES components it requires) is getting easier to install? Well, maybe. Some changes in the Communications Suite 5 release that are reflected in this doc include:

  • Portal Server is no longer installed. (That alone probably accounts for the page reduction I mentioned above.)
  • Solaris Operating System (OS) 10 is used.
  • Hosted domains are now configured.
  • Proxy auth is now the way that Single Sign-On is accomplished. As a result, Access Manager is no longer required for Communications Express and there are fewer configuration settings that you have to enter. (Sigh of relief there.)

I should have this document ready at release time, unlike in the past, where we had some lag time between getting the release bits installed to be able to test the doc and get it out.

BTW, if you are looking for current Communications Suite (aka Communications Services) examples, check them out here:

About

Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today