According to the XML guide, admins have site wide GetloginTicket permissions, but the spec provides to way of passing the WebEx ID of the user you want the ticket for. Is there a way to retrieve a login ticket for a host user that you do not have the password for?
The permissions table appears to have a misprint for GetLoginTicket, this is a self only method as the login ticket allows you to log in as the user that it belongs to. Thank you for bringing the incorrect details to our attention.
Then there is another behavior that I need to clarify (as to if it is a bug, or works as intended).
I can get a login ticket for a user by scheduling a meeting for them (and I can set schedulingPermission as an admin), then calling GethosturlMeeting on that meeting. It will give me the login url with ticket for the host, not the calling user (and it is described as such in the API documentation). That behavior is very useful, but it seems weird that you can't get a login ticket otherwise as an admin - so I want to clarify as to if that is a security flaw that will be patched, or works as intended - because right now I depend on that behavior.
Basically we have a setup like this:
LMS integration with WebEx.
Users may be created in WebEx, in which case the user knows their password.
Users may be created by the LMS integration, with a random password - the user doesn't know their password (but later on they could reset it).
We are trying to avoid storing any passwords (except admin) in the DB.
We use the admin user to create meetings with the user set as the hostWebExID.
We would like the user to be able to click "host meeting" and be automatically logged in, regardless of the users password. That is how GethosturlMeeting works at this time.
We would like to let users login to WebEx by clicking a link, without knowing their password (the authentication is being provided by the LMS). That doesn't seem to be possible at this time - except by hosting a meeting.
There are no current plans to change this behavior. I cannot promise that security will not tighten around this command at a later date, but there is no indication of this happening at this time.