It's all about the answers!

Ask a question

[closed] Trouble with LTPA - SSO used within Jazz (ccm/qm)


Simon Eickel (1.1k75457) | asked Jan 24 '13, 8:52 a.m.
closed Sep 16 '13, 1:09 a.m.
Hi folks,

again I'm facing problems but this time it's with the LTPA token.
When I login to /ccm and click on the little arrow next to the home symbol it shows my applications but for /qm it first said I should loginto but now it sais "There are no projects".
When I click on "All Projects" it shows me the login screen of /qm. The curious thing is: /rm is working with LTPA.

This confuses me a bit, because both applications are on the same server but in different WAS profiles. Both profiles do have as authentication mechanism LTPA activated.

I'm using a webserver (webserver1) to get all applications accessible through the servername without a port number.

Any ideas? Here some pics to tell you this problem:
      

Greetings,
Simon

The question has been closed for the following reason: "The question is answered, right answer was accepted" by eickel Sep 16 '13, 1:09 a.m.

Accepted answer


permanent link
Guido Schneider (3.4k1486115) | answered Jan 24 '13, 4:25 p.m.
edited Jan 25 '13, 5:39 a.m.

Have you configured the SSO domain on all profiles to same value? e.g. ".jazz.mydomain.com"

Have you exported the SSO keys on the first profile and imported this on all other profiles? This are NOT the certificate key stores. This are other Keys used for the LTPA tokens.

Here what I'm doing in WAS to configure SSO with multiple profiles:


== Single-Sign-On configuration for the WAS Profiles, FIRST Profile

- prerequisite: WAS security is configured, all WAS profiles have same administrator and administrator password configured
- Enable Single-Sign-On Security if multiple profiles are used
- Start WAS Console for first Profile (9060, JTS)
- Login as WAS Administrator
<Security/Global Security>
<Web and SIP security/Single sign-on (sso)>
select Enabled
select Requires SSL
Domain name: .mydomain1.com;.mydomain2.net;.mydomain3.net
select Web inbound security attribute propagation
<OK>
<Save>
&ltApply>
wait 10-20 seconds
<Save>

- Export LTPA-SSO Keys of first Profile so it can be imported on the other profiles
<Security/Global Security>
<LTPA>
Password for the SSO Key file
retype Password
Filename for export file: c:\IBM\LTPA_SSO_.mydomain1.com.keys
<Export>
<OK>
<Save>
<Apply>
<Save>

== SSO all other profiles

- Do the SSO Setup for the other profiles
<Logout>
- Start WAS Console for second/third/fourth) Profile (9061/9062/9063, CCM,RRC, RQM )
<Security/Global Security>
<Web and SIP security/Single sign-on (sso)>
select Enabled
select Requires SSL
Domain name: .mydomain1.com;.mydomain2.net;.mydomain3.net
select Web inbound security attribute propagation
<OK>
<Save>

- Import LTPA-SSO Keys of first Profile so it can be imported on the other profiles
<Security/Global Security>
<LTPA>
Password for the SSO key file
retype Password
Filename for import file: c:\IBM\LTPA_SSO_.mydomain1.com.keys
<Import>
<Save>
<Apply>
Wait 10-20 seconds
<Save>

Repeat for all additional profiles

==

- Test SSO by closing Browser complettly and login on first Profile with the WAS Console
- Then change Port Number in URL to next WAS Console and login on second, third, fourth profile. This should work without login again. If it works within WAS Consoles it should also work for the Jazz applications through IHS.

Simon Eickel selected this answer as the correct answer

Comments
Simon Eickel commented Jan 25 '13, 4:39 a.m.

Hi Guido,

yes, the domain is configured as the same for all profiles. In our case ".rsint.net".
I checked the certificates and imported them on the other profile from the ccm profile. Both, cmskeystore (webserver) and nodedefaultkeystore (default keystore). But this fixed nothing.

Or do you mean different keys /keystores?

Today I got this pic which I mentioned above:


Greetings,
Simon


Simon Eickel commented Jan 25 '13, 4:59 a.m. | edited Jan 25 '13, 5:20 a.m.

I checked with another testserver in our environment where it's working and found that at the testserver the key was imported to the NodeDefaultTrustStore, also.

So I did this on the new server but this even does not help ...



Guido Schneider commented Jan 25 '13, 5:36 a.m.

I enhanced this answer, see above.


Simon Eickel commented Jan 25 '13, 6:40 a.m.

Thanks for this more detailed explanation.
The export / import of the LTPA-SSO keys was missed.

Greetings,
Simon