sso does not connect back after session timeout

[Former Member]

Good greetings to you. We have BI41 SP06 running on AIX platform. We are using the Tomcat web application server. We have implemented Trusted authentication using http_header. The Single Sign ON is configured using IBM Tivoli access manager. The SSO is successfully configured and is working well. But when the session timeout happens, the users are prompted with user account and password prompt.

I noticed that when we clicked  the session timeout pinger warning it adds a parameter called skipSso=true in the url. Can it be configured to false? If so in which config file?

The steps to reproduce is as follows

1. Launch the Launchpad using url : https://host/tam/BOE/BI/login.jsp

2. Wait for the session timeout warning

3. When clicking OK at session timeout, the Launchpad renders the following url asking the users to enter their user account and password

https://hostname/tam/BOE/portal/1602041119/InfoView/logon.faces?bttoken=&skipSso=true

(1602041119 is the date and time when BI41 SP06 was installed)

I am guessing that the parameter value skipSso=true is the cause of asking user to logon.

The users do not know or remember their user account and password. So I need to make sure that users should be reconnected without asking for user account and password.

I tried using url.exit to connect back. But whenever the user click logout, they are getting connected back too. This adds additional concurrent license burden. Do you folks know how to turn off the skipSso to false?

Appreciate your help on this

[former_member434106]

is there any load balancer you are using for your web servers?

[Former Member]

Yes. There is a load balancer used by the IBM ISAM junction which is used for SSO.

[Former Member]

What the users have to do is hit back the original URL again after they are logged out: https://host/tam/BOE/BI/login.jsp

[former_member205194]

Hi Melwin,

As Kashif mentioned, just re-hitting the URL should take the users directly into BILuanchpad.

Regards,

Monish

[former_member187093]

Hi there, I was also using trusted authentication (siteminder and oracle OID) but never faced this issue.

as long as the session (siteminder/ Oracle OID/SSO_header) is available then BO will allow in.

[Former Member]

Hi Siva

Thanks for your response.

I did not face this issue in BO 3.1. But after upgrading to 4.1 SP06, I am getting this behaviour. Very strange and I do not get proper response from the BO support too.

[former_member205194]

Hi Melwin,

Greetings !!

Not sure if I understand the exact scenario of yours, but since I have implemented something similar, let me see if I can be of any help.

We have implemented something on similar lines in our environment. Its Windows environment, SSO using trusted Auth mechanism using Siteminder for authentication purpose.

We have not come across this scenario mentioned above, (let me check on this behavior and get back to you).

1) For us, when the user logs in for the first time he needs to enter the credentials for authenticating the Siteminder once. Do your users need to authenticate at-least for the first time against the IBM tivoli access manager ?

2) For us, I guess, after the session timeout, the user would be required to authenticate against the Siteminder, but that seems okay to me. Is that something you are trying to avoid ? I really do not see it as an issue, though.

3) You mentioned that the user do not know or remember their password, and thats why you are trying to fix this. For us, the ONLY password the user need to enter are the credentials they use to login into their Laptop. So they DO NOT have to remember anything else, which is why SSO has configured in first place.

Let me know your thoughts.

Thanks & Regards,

Monish

[Former Member]

Hi Monish

Thank you for the response.

1. The users are not needed to enter the credentials for the first time.

2. So when the session time out, the user click the OK prompt pinger. At this time, the user is prompted for user name and password. I believe, it happens because of the url presented in the browser (as mentioned in my problem)

3. Yes. I agree. That's why we implement SSO. Users only know the windows user account and password. Suddenly they are prompted for a different user account and password which they are not aware of.