cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

If your Cloud Collaboration question is not answered quickly, please email devsupport@webex.com for additional help

939
Views
1
Helpful
4
Replies
emerrill999
Beginner

Semi-permanent API credentials?

I have a tool that does work on behalf of users (create/edit/etc meetings, recordings). Right now I have to store the password in a database so that I can continue to do things as that user - which is... sub optimal.

Every other API I've ever dealt with you can send the username and password of a user and get back a set of keys to be used for future requests - that way you don't need to keep the password, and individual keys can be revoked if they are compromised.

Does WebEx provide any similar functionality? We are not using SSO (SAML), we are just using built in WebEx authentication.

Thanks!

1 ACCEPTED SOLUTION

Accepted Solutions

Hello,

     Site Admin gained DelRecording permissions for all users in XML 6.0, according to release notes. Unfortunately, the most recently available reference guide is for XML 5.9 and has not yet been updated. You are right about the SAML authentication token expiring if you were to go the single sign-on route. Note that XML API is intended for server to server communication and requires HTTPS, so an end user should not be able to capture login details. If you need to log a user in to the site, you can retrieve a login URL that contains a one time ticket instead of password, using GetloginurlUser.

View solution in original post

4 REPLIES 4
nmorrow
Cisco Employee

Hello,

     Recordings can be managed by a single site admin user, allowing you to store only 1 user's credentials. Alternately, WebEx does support SAML based single sign-on. With SAML enabled, your host accounts no longer have passwords and authentication is handled by security certificate exchange and a signed authentication request. XML API supports SAML authentication via the command AuthenticateUser, which accepts a valid SAML certificate and returns a session based authentication token, which is good for the duration of the current session and is used instead of password for subsequent XML requests.

You can't delete recordings, you can only edit them, as the site admin.

And even if we used SAML (which we don't), it sounds like you can't use that for longer term access (months), since it is based on session times, which are in the realm of hours. It's fine if it's not possible, it just seems very odd that the API doesn't provide OAuth style token exchange (and/or that site admins have such limited powers).

A related question:

Lets say we have 2 users, admin (a site admin) and user (a normal user). Under user, we assign the schedulingPermission to admin. Admin creates a meeting, with user as the host (now either admin or host can edit or delete that meeting). User hosts the meeting and makes a recording. Can admin delete that recording, or is user the only one who can?

Hello,

     Site Admin gained DelRecording permissions for all users in XML 6.0, according to release notes. Unfortunately, the most recently available reference guide is for XML 5.9 and has not yet been updated. You are right about the SAML authentication token expiring if you were to go the single sign-on route. Note that XML API is intended for server to server communication and requires HTTPS, so an end user should not be able to capture login details. If you need to log a user in to the site, you can retrieve a login URL that contains a one time ticket instead of password, using GetloginurlUser.

View solution in original post

I'll have to give it a try - I thought when I tested DelRecording as admin it didn't work - but I may have just thought that because of XML guide.

We are using the XML API in a way where use user *may* never user the WebEx website, doing everything from within the LMS. But I think that with a combination of schedulingPermission and other abilities, we can do everything as an admin. Will need to test it all out.

I still vote that OAuth would be a good addition to the API interface (then we wouldn't have to store admin creds either).

Thanks for your help.

Content for Community-Ad