This is especially relevant to me as I'm about to embark on a project using TAMeB and LC ( and Portal and Quickr ) together, and I'm also presenting a piece on TAMeB etc. to the upcoming WebSphere User Group meeting at IBM Bedfont next week - Thursday 18 March, which is nice.
Tuesday, 9 March 2010
Configuring IBM Tivoli Access Manager SSO for IBM Lotus Connections 2.5
My IBM colleagues, En Hui Chen and Chao Feng Yang, have produced a potentially very useful document showing how IBM Tivoli Access Manager for e-Business ( aka TAMeB ) can be used to secure Lotus Connections, via a "front-end" reverse web proxy server.
Subscribe to:
Post Comments (Atom)
2 comments:
G'Day Dave,
Thanks for pointing this out. I did exactly this (well when I say "I" what I mean is I did all the Connections/Websphere parts of it and a Tivoli guru did the TAM/Webseal parts of it) for a client a couple of weeks back. It worked very well.
The only problem we have is that in their TAM/Webseal environment they have some users that authenticate as what is referred to as Pass Thru Participants (or Transient users). These users are authenticated via remote directories and don't actually exist in the federated LDAP repository. So from what I am told these users don't get issued with the LTPA token and hence the SSO does not work for them. So we have hit a bit of a wall at the moment. Any thoughts?
Obviously also these users would need to be populated to the Connections Profiles database as well which is achievable in a number of ways but we are yet to solve the SSO aspect for them.
Adam, we've had a similar requirement from another client, and we're considering a solution using the IBM Tivoli Federated Identity Manager (TFIM) product, a limited entitlement to which WAS ND customers get.
Here's some information about TFIM and WAS entitlements: -
http://www-01.ibm.com/software/tivoli/products/federated-identity-mgr-websphere/
The thing that you'd need to consider is that, as far as I understand it, TFIM uses an identity assertion mechanism called Secure Assertion Markup Language (SAML) and, at present, WAS doesn't support that as a default authentication mechanism. Therefore, it's necessary to write a custom Trust Association Interceptor (TAI) in WAS 6.1 in order for it to trust the inbound user request.
I'm not 100% sure if TFIM would act as a "gateway", taking the inbound SAML token and then issuing, say, a LTPA token that the WAS 6.1 server on which Connections sits could trust the user.
Sounds feasible ...
Might want to talk to your local Tivoli guru - otherwise, I can introduce you to a UK chap who's absolutely awesome in that regard.
Let me know how you get on ...
Post a Comment