Communications Express doesn't create access Manager SSO session

Question

Hi all,
I'm running Communications Express, Sun Access Manager and Sun messaging server, each on seperate hosts.
Single Sign On works i.e. when users have a valid session and point their browser at the Communications Express URL they can access their mail, calendar and addressbooks without further ado.
When they don't have a valid session though and the users go to the Communications Express URL they get a username and password prompt. If they enter valid credentials they will be logged in, but the session created is only a local session, not an Access Manager SSO session. This behaviour has changed from the previous versions of Comm Exp which wouldn't work at all without SSO.
Is it possible to configure communications express to either redirect users to the Access Manager's authentication page or have Comm Exp create the SSO session on the users behalf?
TIA
Herman
Versions:
- Communications Express 6.3 update 1
- Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)
libimta.so 6.3-4.01 (built 17:13:29, Aug 3 2007; 32bit)

Answer 1

Hi Shane,
as always your anwer is better then I could have expected. A more or less complete manual
just hours after asking my question. Thanks!
shane_hjorth wrote:
The cleanest solution I could develop to address the behavioural change was to
leverage a web-server policy agent to perform the redirections.
I wrote up a guide but never received any feedback unfortunately so results-may-vary.
I have republished this guide externally - feedback is welcome:
http://msg.wikidoc.info/index.php/AM_redirection_using_Policy_AgentTook me some time to implement, test and write feedback:
The setup we have is a little more complex then the a single box scenario you
have tested on:
From the internet working inwards we have load balanced
SSL accelerators (apache+SSL doing reverse proxy) in front of
dedicated application servers running communications express.
Mail is retrieved from separate mail-store clusters.
Access manager is configured similarly: load balanced SSL accelerators
in front of application servers running the login page (disributed
authentication UI). Those then talk to the access manager cluster.
Firewalls and access lists between each of those layers. None of the
applications can be accessed directly from the internet and they are
limited in what they can access in the DMZ as well.
I followed your recipe to the letter. After a bit of tweaking everything
worked like a charm. Policy agent installed and configured on the
SUN webserver where communications express is deployed.
Instructions were very good on detail and easy to follow.
We deploy uwc in the root of the server not in /uwc. Something I didn't notice right away.
It would seem that the policy agent expects the values com.sun.am.naming.url
(The URL for the Access Manager Naming service) and
com.sun.am.policy.am.login.url (The URL of the login page on the Access Manager
where users should enter their credentials) to be the same host.
In our setup the URL/host users have to use to log in can't be accessed by the policy agent.
The policy agent should verify sessions directly against the access manager cluster.
I played with some of the override settings in the policy agent configuration file but
without much success. Eventually I used the hostname our users have to use to log
in and abused the /etc/hosts file to map the external hostname to the internal address
of the access manager cluster. Users end up on the correct login page, and the policy
agent can verify the sessions. Ugly, but it works.
The other issue is that the policy agent redirects to:
com.sun.am.policy.am.login.url?goto=URL_Protected_by_Policy_Agent
When a users enters incorrect credentials they get the default login url, without the
goto parameter. (May be bug in access manager or by design...) After entering their
credentials correctly on their second or third try users won't be redirected back to UWC,
but will end up on the default page defined by their iplanet-am-user-success-url LDAP attribute.
I solved that in the policy agents configuration file by adding the gotoOnFail=URL in the
definition of com.sun.am.policy.am.login.url:
com.sun.am.policy.am.login.url = https://login.domain.com:443/amserver/UI/Login?gotoOnFail=https://uwc.domain.com:443When you enter incorrect credentials you'll be redirected back to uwc (where the policy agent
will again intercept you and send you on to the login page for your next try). May be more of
an issue in the policy agent then your manual.
Regards,
Herman