BeginSignIn accepts invalid credentials

Question

I am developing an Lync 2010 SDK client app using Lync in UISuppressed mode.  During application start-up, I prompt the user for login details showing their SIP URI (from LyncClient.Uri) and ask for domain\username and password.  I then call BeginSignIn with those credentials.  The sign-in works even if the domain, username and password are invalid.

I'd prefer to use auto-sign in by passing null, but the Walkthrough for Singing in with UI Suppression states:

If the new client state is ClientState.SignedOut, Call the BeginSignIn method.When UI Suppression is enabled, the user credential parameters should not be null. When required credentials are not passed in the sign in method, the operation raises the CredentialRequested event. You call Submit, passing user credentials in the first two arguments of the method. The sign-in process is completed when acceptable credentials have been submitted.

I respond to CredentialRequested() but it's never called.  It looks like the Lync Client has previously cached the credentials and just passes them in.

Should this be the case?

Is it safe to call BeginSignIn() with null user credentials if the LyncClient Uri is not empty or null, and only prompt the user if Uri is unknown?

In this case would CredentialRequested() be called prompting the user again(?).   CredentialRequestedEventArgs.Submit would be called with savePassword = true.

---

-- Richard Carde

Answer 1

The keyword in the quoted text is "should".  It is a good practice to require the user to supply credentials at the time of sign in. Why? Because you cannot guarantee that the previously cached credentials belong to the user who is now trying to sign in.

Imagine User A has signed into Windows and then signed into Lync. His credentials are cached.  User A signs out and walks away from computer without signing out.  User B sits in front of computer and launches Lync without being challenged for fresh credentials. User B is now signed in as User A. Aside from the privacy issues with User B now seeing User A's contact list, there are issues with impersonation which arise when User B starts a conversation as User A.

As to why you are not getting the CredentialRequested event, that is a bit of a head-scratcher.  If the credentials are truly invalid and you are not getting the event, then the client platform must be falling back to the last good credentials. To test this, examine the contact list that you get after the sign in.  If the contacts in the list belong to another user (such as the last user to sign in), then the last user's credentials are being cached and used.

---

John Austin Senior Programming Writer Microsoft

Answer 2

I'm all for requesting credentials where necessary to avoid impersonation.  My concern is that, in code, we can impersonate a previous session by calling BeginSignIn() without needing to know username/password on cached SIP Uri.

I guess this isn't a big deal unless the same (generic?) login is shared by different "sign in"/SIP addresses.  In this case, it's not so good.

CredentialRequested() is definitely NOT called when you pass in a Uri that's got previously cached credentials.  Strangely, the Lync client itself doesn't fall for this - but BeginSignIn() does.

---

-- Richard Carde

Answer 3

Richard,

I get the same behaviour with CredentialRequested() not firing when BeginSignIn is called with null credentials.

How did you clear the cached credentials?

Brian

Answer 4

I changed the behaviour of the application to try and work around the issue.  The behaviour persists that if there is a cached set of credentials, the password is irrelevant.

I've not tested to see if the Lync 2010 March 2013 Update fixes this behaviour.

This update does suggest a change to credential caching.  See http://support.microsoft.com/kb/2796741. 

The fix does not mention UI Suppressed Mode but I wonder if the issue was affected and is now fixed.

I will test this update today if I have time.

---

-- Richard Carde

Answer 5

I've not tested to see if the Lync 2010 March 2013 Update fixes this behaviour.

No change.  If I call BeginSignin() with a valid and previously used SIP address, I can pass in junk for the username and password and it still signs in.  Odd.

---

-- Richard Carde