Accepted Solutions
That is correct. FYI On the ITL recovery certificate, I’ve never used that myself for any SSO deployment, so I have zero experience of how it works. That said I have a hard time seeing how this should work as it’s a self signed certificate and normally you’d use a CA signed certificate for this.
I think that is related to something else than the refresh token. Apart from that it’s six years old and a lot has changed for Webex in that time. In 2017 there was no new Webex application, so likely what is referenced as Webex in that publication is Webex Meetings and that’s something all together different.
Yes. In that same section there is another setting that is recommended to be changed for getting a good working solution for any devices with iOS. The default is for these clients to use the embedded web browser and that doesn’t result in a good UX for your users. For a better experience it is recommended to set this to the other option, where it uses Safari as the web browser instead. This is so that the application on the Apple device can access the certificate trust store on the device.
The big difference is that you’ll create and maintain individual trusts in the IdP with per node. From a UX perspective for end users services there is no noticeable difference. The big difference is really the amount of work needed to maintain the setup. Whenever you can go for cluster wide that would be recommended, that being this or for certificates for example. My guess is that there are two options for the SSO setup due to that some IdPs not handling a per cluster setup, but I can’t tell any specific IdP solution that has that characteristic.
The certificate is not really related to a per node IdP setup. You can use either multi SAN or individual, but MSAN would be the recommendation. As compared to if you where to use per cluster setup, then you’d need to use MSAN certificate.
There is no difference how to setup per node compared to per cluster, you’d just repeat the process for the creation of the trust in the IdP once per node, so you can use the same documentation as for per cluster.
The CM and the IdP doesn’t communicate directly, the CM tells the client that connects to communicate with the IdP and then the IdP authenticates the client.
Regardless we select
"self-signed certificate ITL Recovery"
or "Tomcat" for SSO mode.
It will not affect or change the certs in UCM that can cause phone to unregister or secure cluster call to break ?
That is correct. FYI On the ITL recovery certificate, I’ve never used that myself for any SSO deployment, so I have zero experience of how it works. That said I have a hard time seeing how this should work as it’s a self signed certificate and normally you’d use a CA signed certificate for this.
No action that you take in the settings for SSO will ever change any of your certificates. Those are two totally different things that are managed in different parts of the UI.
That would depend on your setup. If you’re using refresh tokens, which is recommended, it should be pretty seamless until the token expires. Once that happens the individual user should get a login sequence.
No, a restart of the Tomcat service will not restart Jabber. Please do note that if you do not use refresh tokens and turn on SSO the UX for your Jabber users will not be very good as it would require them to login as soon as the IdP token expires and that often happens once per day. With refresh token the default time span is 60 days, providing a much more seamless UX.
