UCWA by the numbers – #2 Authentication

After Autodiscovery the next step in UCWA is Authentication. In UCWA Authentication has a few possible routes based on grant type:

• urn:microsoft.rtc:windows – windows-based credentials
• password – typical user name and password
• urn:microsoft.rtc:anonmeeting – anonymous meeting join
• urn:microsoft.rtc:passive – ADFS / two-factor authentication

Documentation on Authentication can be found on the Lync Web Developer Portal at GettingStarted-Authentication

To see which grant types are available it is possible to make a request on the user href from Autodiscovery to get a 401 (Unauthorized) containing WWW-Authenticate headers listing possible grant types:

In this case the WWW-Authenticate header lists the MsRtcOAuth service at https://lync.domain.com/WebTicket/oauthtoken and supports urn:microsoft.rtc:windows, urn:microsoft.rtc:anonmeeting, and password.

urn:microsoft.rtc:windows

This type of authentication will use IWA, Integrated Windows Authentication, which can be thought of as the familiar Windows Login prompt. On a Windows system that is authenticated on the same domain as a Lync Server it is possible (browser depending) that the dialog box will not show up and credentials will magically flow through to UCWA. This can sometime be a pain when you want to control the user that is logging in.

To see this grant type in action by using the UCWA helper libraries and hosting them in your favorite web server (IIS/Apache) assuming you have it on the allowed list! Browse to the samples and choose My own topology and provide the Sign-in Address and attempt to login.

Sample Trace

password

This type of authentication provides more control over who is logging in, but requires user name and password sent. It functions similar to urn:microsoft.rtc:windows with the except of requiring user name and password in the request.

To see this grant type in action by using the UCWA helper libraries and hosting them in your favorite web server (IIS/Apache) assuming you have it on the allowed list! Browse to the samples and choose My own topology and provide the Sign-in Address and Password and attempt to login.

Sample Trace

Shared code

Both urn:microsoft.rtc:windows and password grant types follow the same next steps in authentication:

• Make a GET request on user href from initial Autodiscovery with new OAuth token
• Make a POST request on applications href with userAgent, endpointId, culture
• Make a GET request on makeMeAvailable href with SupportedModalities (Messaging)
• Make a GET request on applications href to get updated capabilities

Sample Trace

urn:microsoft.rtc:anonmeeting

This type of authentication provides a mechanism for anonymous users to join online meetings with authenticated users. The first step is acquiring a meeting Uri and the easiest way I have found is to start a Meet Now via the settings wheel in the Lync 2013 Client. Once the meeting has loaded up, click the ellipses in the lower right choosing Meeting Entry Info and click Copy All Info. Paste this information into a text editor and grab the meeting href which should look like: https://meet.domain.com/user_name/unique_id.

The idea is to take this information and constructor a meeting Uri for anonymous authentication in the form of: grant_type=urn:microsoft.rtc:anonmeeting&password=unique_id&
ms_rtc_conferenceuri=sip:user_name@domain.com;gruu;opaque=app:conf:focus:id:unique_id

After successfully authenticating using the anonymous meeting grant type the follow steps are recommended:

• Make a GET request on user href from initial Autodiscovery with new OAuth token
• Make a POST request on applications href with userAgent, endpointId, culture
• Make a GET request on applications href to get capabilities
• Make a GET request on events href to start listening to events (messaging at the very least)
• Make a POST request on joinOnlineMeeting href with anonymousDisplayName and onlineMeetingUri
• In the first burst of event data you will see a messaging event with a state of Disconnected and you can make a POST request on addMessaging href with operationId to enable the messaging modality

Sample Trace

urn:microsoft.rtc:passive

I cannot speak much to this grant type as it is not enable in the environment I test with.

Bugs

I found 2 bugs in the FiddlerScript I wrote a few posts back (UCWA – Obscuring confidential data in Fiddler traces). I had not handled any Windows-based Authentication in UCWA for awhile and thus did not have any traces locally where I would see headers containing an NTLM token. Now checks are in place to check the Authorization header (requests) and WWW-Authenticate header (responses) and replace the value with “NTLM user_ntlm_token”.

The second bug related to Request Urls and not checking to see if they contained a domain that could be obscured. If you look at the user href it will be something like: https://lync.domain.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=domain.com. In the response data this was handled properly, but not in when it came to the Request Url (oops!).

In any sense both have been addressed and the update can be found here: Fiddler2 Obscure

Next Up

Next in line is a look at Conversation and/or Conferencing.