cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
192
Views
0
Helpful
0
Comments
cdnadmin
Level 11
Level 11
This document was generated from CDN thread

Created by: T.J. Fields on 08-01-2013 09:02:20 AM
When I make a call to list events using the XML API, I get an INVALID PASSWORD error from the call.  This only happens to some users, and I can actually log into WebEx directly with these same credentials.
What could cause this?

Subject: RE: INVALID PASSWORD when listing events
Replied by: Jade Moors on 09-01-2013 12:59:05 PM
Hi T.J.,
 
That's odd that it works when you log into the site directly using the same credentials as the error messages are generally pretty straightfoward.  Could there be a special character in their password which is causing this?  For the users which do have the issue, is it consistently occurring?  If so, would it be possible to try changing the password temporarily (maybe try something with just letters/numbers) for one of the affected users to see if continues to throw an "Invalid Password" error?  If it continues to occur, can you please provide us with your WebEx site and the date/time of the occurrence?  The more recent the better as some of our server logs are overwritten within a day due to size contraints.
 
Regards,
 
Jayde Moors
WebEx API Developer Services

Subject: RE: INVALID PASSWORD when listing events
Replied by: T.J. Fields on 09-01-2013 01:18:17 PM
Thanks for the reply Jayde.  My site is sunpower, and I just tried it about 5 mins ago, 2:10pm EST.

Subject: RE: INVALID PASSWORD when listing events
Replied by: Jade Moors on 09-01-2013 01:21:16 PM
Thanks for the quick reply.  I'll take a look at our logs and see if anything sticks out.  Just out of curiosity, was this with the original pass or a new pass?
 
Regards,
 
Jayde

Subject: RE: INVALID PASSWORD when listing events
Replied by: T.J. Fields on 09-01-2013 01:49:05 PM
This was a new pass, we had the user change it to remove a * that was included in the initial one.

Subject: RE: INVALID PASSWORD when listing events
Replied by: Jade Moors on 09-01-2013 01:55:44 PM
Thanks for confirming.  I do see quite a few requests in our logs for your site.  Is it possible to get the First and Last Name of the user you tested with @ 2:10PM EST?  Also would this have been a LstsummarySession request?  Hoping I can get this so I can narrow down the search a bit.
 
Regards,
 
Jayde

Subject: RE: INVALID PASSWORD when listing events
Replied by: T.J. Fields on 09-01-2013 02:20:17 PM
It's actually a LstsummaryEvent and the user is gisetta.

Subject: RE: INVALID PASSWORD when listing events
Replied by: Jade Moors on 09-01-2013 04:29:05 PM
Hi T.J.,

That helped tremedously.  The error in the logs is definitely pointing to a password issue.  I noticed your site is configured to use SAML SSO which means the password stored on the WebEx side is usually different than the user's LDAP/NT login.  So it would appear the password being sent in the API request does not match the password stored on the WebEx side.  Since your site is SSO, you would not be able to log into sunpower.webex.com site directly using the WebEx password as it will redirect to your internal SSO server for authentication then redirect back to WebEx.  I can see the API request in our logs; however, for security reasons the user's password is not stored.  Do you have access to the API logs on your end which are being generated during the requests?  If so, I would suggest the following to confirm the correct password is being sent to WebEx:

1.  Obtain a copy of the LstsummaryEvent request generated for gisetta
2.  Make note of the password being sent in the <securityContext> of the request (i.e. <password>pass123</password>)
3.  Use the below URL API (copy/paste into your browser) to log in directly to your WebEx site:

EXAMPLE: https://sunpower.webex.com/sunpower/p.php?AT=LI&WID=gisetta&PW=pass123&BU=www.webex.com

If they are using the correct password stored on the WebEx side, they will be logged into the WebEx site successfully.  However if the credentials are incorrect (which appears to be the case), they will be redirected to www.webex.com and will see a "FAIL" message similar to the below in their browser's address bar:

http://www.webex.com/?AT=LI&WID=gisetta&ST=FAIL&RS=BadWebExIDOrPassword

Is it a custom built integration which is utilizing our APIs?  Or are you using a 3rd party vendor which has an existing integration with WebEx?  In either case, is it possible there is another password being stored somewhere in the integration and it is sending over the "stored" password?

Regards,

Jayde

Subject: RE: INVALID PASSWORD when listing events
Replied by: T.J. Fields on 10-01-2013 08:56:54 AM
This would the issue, thank you so much for helping me out.  This is a custom integration, of which I am one of the developers.  We are seeing this issue with some of our clients.

Is there any way for us to handle this in our code so that if a site has this enabled, we can allow them to use this username and password and not the one stored in WebEx?

Subject: RE: INVALID PASSWORD when listing events
Replied by: Jade Moors on 10-01-2013 02:31:08 PM
Hi T.J.,

Since SAML SSO is being used we don't actually ever see (or know) the user's "real" password.  When the user attempts to log into WebEx, we redirect to your internal Identity System.  The user is challenged for their credentials and enter their NT login.  Once they've been authenticated successfully, your Identity System generates a signed SAML Assertion which is then passed to WebEx indicating the user was authenticated and should be logged in.  You could use the AuthenticateUser XML request to generate a "session ticket" which can then be used in place of the user's password.  In the securityContext you would pass just the user’s WebEx ID and omit the password.  For example:

<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:serv="http://www.webex.com/schemas/2002/06/service">
<header>
<securityContext>
<webExID>jaydem</webExID>
<partnerID>123abc </partnerID>
<siteID>123456</siteID>
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.service.binding.user.AuthenticateUser">
<samlResponse>$SAML_RESPONSE</samlResponse>
<protocol>SAML2.0</protocol>
</bodyContent>
</body>
</serv:message>
 
As you can see above, you would need to pass in a valid SAML assertion/response in the request.  You would then use the session ticket returned in the XML response to authenticate when (for example) pulling a list of Events:
 
<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<header>
<securityContext>
<webExID>jaydem</webExID>
<sessionTicket>$SESSION_TICKET</sessionTicket>
<partnerID>123abc</partnerID>
<siteID>123456</siteID>
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.xmlapi.service.binding.event.LstsummaryEvent">
<listControl>
<startFrom>1</startFrom>
<maximumNum>10</maximumNum>
<listMethod>OR</listMethod>
</listControl>
<order>
<orderBy>HOSTWEBEXID</orderBy>
<orderAD>ASC</orderAD>
<orderBy>EVENTNAME</orderBy>
<orderAD>ASC</orderAD>
<orderBy>STARTTIME</orderBy>
<orderAD>ASC</orderAD>
</order>
<dateScope>
<startDateStart>01/01/2013 00:00:00</startDateStart>
<timeZoneID>45</timeZoneID>
</dateScope>
</bodyContent>
</body>
</serv:message>

The tricky part (for most) is getting the SAML Assertion to place into the AuthenticateUser request.  Just a heads up, this will eventually be required for all API customers who are configured with SSO.  There is no definitive date set yet but at some point in the upcoming months it will be a requirement to use a session ticket vs user passwords for host accounts.  Not sure if you are aware but a Site Admin account could be used with "most requests" to make requests on behalf of users.  Say for example you have a Site Admin account for user jdoe with a password of pass123 which is pulling a list of Events for me (jaydem):

<?xml version="1.0" encoding="ISO-8859-1"?>
<serv:message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<header>
<securityContext>
<webExID>jdoe</webExID>
<password>pass123</password>
<partnerID>123abc</partnerID>
<siteID>123456</siteID>
</securityContext>
</header>
<body>
<bodyContent xsi:type="java:com.webex.xmlapi.service.binding.event.LstsummaryEvent">
<hostWebExID>jaydem</hostWebExID>
<listControl>
<startFrom>1</startFrom>
<maximumNum>10</maximumNum>
<listMethod>OR</listMethod>
</listControl>
<order>
<orderBy>HOSTWEBEXID</orderBy>
<orderAD>ASC</orderAD>
<orderBy>EVENTNAME</orderBy>
<orderAD>ASC</orderAD>
<orderBy>STARTTIME</orderBy>
<orderAD>ASC</orderAD>
</order>
<dateScope>
<startDateStart>01/01/2013 00:00:00</startDateStart>
<timeZoneID>45</timeZoneID>
</dateScope>
</bodyContent>
</body>
</serv:message>

The securityContext would contain the admin's credentials and the body of the request has the host <hostWebExID>jaydem</hostWebExID>.  Even after the upcoming requirement changes a Site Admin's password can continue to be used.  The upcoming changes only affects standard host accounts.  However, if you are using URL APIs (p.php?AT=LI) to log the user in you will still need to use the AuthenticateUser request to generate a session ticket.

Regards,

Jayde
 

Subject: RE: INVALID PASSWORD when listing events
Replied by: T.J. Fields on 14-01-2013 08:03:13 AM
Thank you so much for the insignt!  I do have some questions..
1. Do we have a way to tell, through the API, whether or not a site is using SSO?
2.  Are we able to tell what the provider is?
3.  Does your API provide a way to get the SAML assertion (would seem as though it should, given that WebEx knows what the provider is)?
4.  If we do manage to get the token, does it expire?
Thanks again!

Subject: RE: INVALID PASSWORD when listing events
Replied by: Jade Moors on 16-01-2013 12:52:41 PM
T.J. Fields:
Thank you so much for the insignt!  I do have some questions.. 1. Do we have a way to tell, through the API, whether or not a site is using SSO? - There are no APIs currently which returns SSO information.  This is currently being reviewed by our product team as a potential API enhancement in a future release. 2.  Are we able to tell what the provider is? - When referring to provider, do you mean the endpoint a user is redirected to for login?  If so, this is also under review by our product team for a future API release. 3.  Does your API provide a way to get the SAML assertion (would seem as though it should, given that WebEx knows what the provider is)? - Because the assertion is generated by the end user's Identity System and generally POSTed back to us, we do not have a way to automatically obtain it.  The integration would need to be able to obtain the assertion which would then be sent to us in the AuthenticateUser request. 4.  If we do manage to get the token, does it expire? - The session ticket generated is valid based on a Site level setting configured on your WebEx site.  I believe by default it is 336 hours, which is 14 days. Thanks again!
 
There is another option for handling authentication for SSO and non-SSO sites.  Since it's a bit lengthy to describe here, please see the attached doc I put together which talks about this.  Hope this helps and let me know if you have any questions or need clarification.

Regards,

Jayde
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links