SSO only works sometimes

I’ve got a UX model connecting to two TM1 models. SSO works for the first model. When I try to launch the dashboards for the second model, SSO is not triggered and I get the User Name / Password screen.

But if I go to app management, and create a “new” dashboard and select the second model, SSO is triggered and everything works for the session (and I can access my existing dashboards).

Any ideas?

In the instances.json file does the loginInstances parameter point to only the 1st instance or to both instances?

Are the user credentials and login mechanism identical for all 3 instances? (i.e. contentStore, instance1 & instance2)

Yes, loginInstances parameters contain both instances. Credentials and login mechanisms are the same for all environments (all 3 using SSL).

Human Resources is the troublesome one (instance 2):

I’ve gone through the config files of instance1 and 2 to compare, and I can’t see a difference (in terms of authentication) between them.

When I click through to instance 2, I’m greeted with login screen per below, and after entering credentials, the SSO seems to be triggered. But I’m not redirected to instance 2 dashboard. If I click on instance 2 dashboard, then it loads.

I think you only need “Human Resources” and “Consolidation” for logininstances parameter. That may be the cause?

There are other instances which I may need in future, that is why they are listed. But just in case, I removed them and tried again, no luck.

If you want to login to more than one instance creat app for each and hook up to each individually

Thanks, might go this route.

1 Like

Just in case someone encounters the same problem:

I duplicated the Human Resources model and called it Human_Resources, and had no problem connecting.

I didn’t notice you had a space in the instance name “Human Resources” in instances.json

No you shouldn’t do that. Because we are in the land of html and not the land of TM1 instance names and webapp names are case and space sensitive. Although technically spaces are “ok” they are best avoided.

Hi @cw-ch,

Just wanted to make sure I understood this correctly, it shouldn’t be using spaces on the name of the model in the Instances.json file, on the “Name” parameter, but the TM1 Instance itself should be fine to have spaces on it…
is that correct? or better to avoid even in the TM1 Instance name?

There’s no connection between the instance names you define in tm1s.cfg and instances.json. The rest API isn’t even aware of the server name. It only cares about the connection URL. In UX the instance name that is defined in the instances.json file is just used as a reference to look up the base URL.

To not get confused and to be familiar for users who may use other interfaces I think it’s a good idea to make the instance name in UX as similar as possible to the original but it doesn’t have to be.

1 Like

Ok, thanks for confirming it!
That’s what I thought, as it uses the http port and the URL for the connection…

I agree, just thinking whenever we are building UX on top of existing instances of a client…

So for the example in this thread, it should solve by just changing on the Instances.json to “Human_Resources”, and the instance name in tm1s.cfg remains as Human Resources…