Triggering SSO login and redirection by GET parameters to CH site

[Lajos Demeter]

Could someone at Cisco Webex please confirm that the following behavior is not planned to be changed in future?

When a user opens the following URL with an SSO integrated Control Hub managed Meetings site:

https://site.webex.com/dispatcher/CIAuthService.do?cmd=login&siteurl=site&returnURL=someURL&email=some@email.com

then this action results in Webex redirecting the some@email.com user without any question to the proper IdP along with a proper SAML AuthnRequest, and when the valid SAML Assertion comes back, Webex puts the user in logged-in state on the Control Hub managed Meetings site but redirect the user to "someURL".

I am trying to find a future-proof way to have users programmatically log in to a Meetings site without XML API, which is going to be deprecated  

The above method works fine now but I don't see it documented, this is why I am asking if I can trust that it will work also in the future. If not, please let me know the recommended method to achive the same result. (In April @Gasper A at Cisco wrote "this is currently not supported via the Rest API".)

Thanks in advance for your confirmation.

[Raffaele Lagana]

Not sure where you got that link/syntax from, did you perhaps try to reverse-engineer it from the native apps or something?

In any case, we can't really comment on that as it is not an API functionality. 

Furthermore, if your plan is to replace the XML APIs, the way to do it is with our Meetings REST APIs.

The authorization side of things is then managed through integrations, as described here.

It's not really clear how you're currently managing login with XML APIs, but the way forward would be with above suggestions, not what you tried. We can't guarantee that the functionality you were trying to access won't be changed, as it seems to be the native functionality you were trying to access.

Please feel free to reply here if you have any queries or if we are misunderstanding something.

[Lajos Demeter]

Hi Raffaele,

Thanks for your reply. Our current use case:

1. Our users use Webex from our service page via XML API integration, not directly from the Webex pages. They do not even know their Webex login names and passwords.
2. We are using the "GetloginTicket" XML API (returning a "ticket") and the "AT=LI&TK={ticket}" URL API to push the users into logged-in status on Webex, then redirect them to our pages
3. We are using the AT=JM URL API to push the users join or start a meeting when needed.

The Meetings REST API set recommended to be used, has a shortage: It does not provide any ticket to be used by URL API, in order to push the users into logged-in status on Webex. The URL API does not accept the access token received from the REST API OAuth. (I submitted the FR for that HERE but there is no reply. So we are trying to find any workaround. This is why we are investigating SSO, where we control the user login.

Our problem: How can we push the users directly to the logged-in status on the CH managed Meetings site?

• IdP initiated scenario would be OK, but it is not supported.
• SP initiated would be also OK if we could somehow trigger the Webex site to send the SAML redirection to our IdP, without the need for the user manually click on the "Log In" button on the site

Understanding that the solution I discovered is not future-proof, what can you suggest to push the users to logged-in status on the Meetings site? As @Gasper A at Cisco wrote HERE: "this is currently not possible via Rest".

So what is the recommendation to achieve the goal?

[Raffaele Lagana]

Thanks for this information. There isn't really an exact match to the loginTicket functionality or the URL API's login options. The newer REST APIs are built on different concepts. I think there are plans to get closer to these functionalities but they're not yet available.

What we do have that may allow you to achieve similar goals, but with different ideals, is by using the Browser SDK . The SDK allows to embed the meetings functionalities in your own web application. It uses the OAuth integration that REST APIs use for authentication and then you can have users join meetings and do most things that the native webex apps can do with meetings. The SDK also provides functionality for webex messaging if required.

Not sure whether this can help your goals, please review and let us know in case of any queries.

[Lajos Demeter]

Hi Raffaele, thanks for your answer.

Yes, we are aware of the Browser SDK and the Meetings Widget, capable of joining a meeting using the OAUth access token.

However, these are browser based solutions, which use a SIP based join to the meeting media, much like what the video endpoints do, but implemented on the browser side as WebRTC based media access. These are (in my understanding, but please correct me if I am wrong!) by far not in feature parity with the desktop client. I think of NBR start-stop, whiteboard, host muting policy, etc.

So this is not really a usable solution for us. This XML API deprecation with lacking basic functions is a nightmare for us, and I think it is the same for all deep integrations of the XML API. (I am not sure all of them knows about this change, as it was not widely advertised.)

Please support -- if you can-- that either the URL API accepts the OAuth access token as in my FR submitted HERE  or that the IdP initiated SSO login becomes supported (like it is supported on "Classic" Meetings sites, my related FR is HERE ).

Both seem to be an easy-to-implement features, and would solve this programmatical user login problem.

[Raffaele Lagana]

Ok a few points to make. The SDK can allow SSO login in its own way, through OAuth Integration. When you create an integration there is an OAuth Authorization URL that is generated. You can use that for your Sign-in link. That will direct users to sign-in to Webex using the SSO credentials for their Webex org and then generate an access token and refresh token. Once you have the first access token and the refresh token you can manage the tokens on your end and use the refresh token to generate new access tokens programmatically for the users so they don't have to go through the OAuth flow again after the first time.

Another thing is that the SDK doesn't just use SIP based joins. It's also possible to create meeting objects by roomId (for space meetings), user email and personId. These would be known as destination types. We have a really good sample here: https://webexsamples.github.io/browser-sdk-samples/browser-plugin-meetings/ , might be of use to see the SDK's capabilities.

You were also mentioning NBR start-stop, now I am not sure exactly whether you simply mean recording start-stop, but if yes the SDK does provide recording functionality. It also provides pretty similar muting functionalities as what the native apps provide. The above sample showcases both of these too.

Of course, I can understand that this would be a pretty big shift as it works in a different way to the older XML and URL APIs, but it does provide fairly robust functionality for a lot of the features available through native apps.

No doubt we still have gaps to fill compared to XML and URL APIs, but we are working to cover those and hopefully we should be a lot closer by the time the XML APIs are deprecated.

There is more information that may be of use here: https://developer.cisco.com/docs/webex-meetings/#!xml-to-rest-migration-guide/webex-meetings-xml-to-rest-migration-guide .

Feel free to add any other queries you may have.

[Lajos Demeter]

Hi Raffaele, thanks for your answer.

We do not plan to introduce Teams (space) meetings as long as we have site meetings and the space meetings have less features. I am glad to hear that the feature gap between the REST API and the XML API is known and will be hopefully closed. We are waiting and in the meantime will check other solutions like usage of the Browser SDK you suggested.

Thanks again for your kind guidance.