Microsoft Live Services Plug In For Moodle Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Microsoft Live Services Plug-in for Moodle extends Windows Live Services to provide users working in Moodle with quick access to some of their favorite online services, like Windows Live Hotmail, Windows Live Messenger, Bing search, and more. Moodle is an extensible framework that allows third-party developers to create different types of plug-ins to augment the core functionality. Microsoft Education Labs researched the types of plug-ins supported by Moodle, and created a set of two plug-ins-a Windows Live ID authentication plug-in to handle the process of logging into Moodle with a Windows Live ID and a Microsoft Live Services block plug-in to display Live Services on a Moodle site.

Windows Live ID Authentication Plug-in

The authentication plug-in is a set of PHP files that manage the authentication process when a user logs into Moodle with their Windows Live ID. Before the authentication plug-in can work, the Moodle administrator needs to request an Application ID (AppID) from Microsoft. This App ID ensures that users are logging into the proper Web site and allows Live Services to send the user back to the correct Web site after successfully authenticating their Windows Live ID.

This plug-in performs the type of Windows Live Connect authentication (which use latest version of the OAuth protocol). During Live Connect Auth, the user is redirected "" to enter their Windows Live ID through When the user is returned to the Moodle Web site, Microsoft sends an encrypted token that indicates a successful authentication. Once a user has authenticated with Access Token, the plug in also requires that they give the Moodle Web site temporary access to read their Windows Live ID account information. This consent is required so that the plug in can determine which Moodle user is logging in. Figure 1 presents a high level overview of the Access Token process for loading a user's Windows Live Messenger contacts.

Figure 1:

Live Connect Access Token authentication data flow for accessing a user's Windows Live Messenger contacts

File Overview

Each authentication plug-in is installed in the "auth" directory which is located in the Moodle root directory. Each authentication plug-in is self-contained in its own directory. The authentication plug-in for Microsoft Live Services is called "liveid".

The "auth/liveid" folder contains the following files:


This file contains three classes that process the authentication tokens returned from to validate that the user has been successfully authenticated. This file was created by Microsoft as part of the Windows Live Messenger Connect Developer Guide V5.0.


This file is a simple class factory for the WindowsLiveLogin class, which is found in windowslivelogin.php. We created this separate file, because WindowsLiveLogin expects the configuration settings (e.g., the AppID, etc) to be located in an XML file and we wanted to store the configuration settings within Moodle. Our function is called initFromMoodleConfig().


This file starts the login process. When a user clicks the link to login with their Windows Live ID, they are redirected to this file. This file instantiates a WindowsLiveLogin class using the WindowsLiveLogin_Factory and calls its getLoginUrl() function. The user is redirected to the formatted URL that is returned. Here's the code:

$wll = WindowsLiveLogin_Factory::initFromMoodleConfig( $CFG );

$loginUrl = $wll->getLoginUrl();

header( "Location: $loginUrl" );


This page receive the code returned by, once the user click yes to get consent user's information, this file will use code to get access token and set cookie for tokens.


This page works with OAuthWrapCallBack.php to validate the user and provide feedback to the user if their login fails. Once the user has consented to live connect access auth, this page passes the user's encrypted live connect Access token to Windows Live Connect Rest API that returns the user's Windows Live ID account. The page uses the Windows Live ID account to determine the Moodle user's username.

Here's the code:

// get the user's Live ID

$request ="".$AccessToken;

$curl = new CurlLib();


$response = $curl->getRestResponse( $request, $httpHeaders );




for($i =0; $i < count($array); $i++)


//The first element in the matches array is the combination

//of both matches.







throw new Exception('No id exist.');




for($j=0; $j<count($array['emails']);$j++)








throw new Exception('please sign in, and add you account emails info.');





// make sure this user is in Moodle

$moodleUserName = get_field_sql('SELECT username FROM '.$CFG->prefix.'user WHERE msn=\'' . $liveId . '\' and deleted=0');


This file implements the Moodle authentication plug-in interface. After authenticate.php determines the user's username, it passes it to Moodle's core login logic. Moodle queries its database to see which authentication plug-in should validate the user and calls its user_login() function. The plug-in confirms the user by re-validating the user's encrypted Windows Live Connect Access token. Live Services ends their session.


This file is very similar to login.php. When a user logs out of Moodle, the prelogout_hook() function in auth.php tells the Moodle to redirect to this file once the core logout logic is complete. The user is redirected to the URL returned by the WindowsLiveLogin::getLogoutUrl() function and returns the user to Moodle.

Other Files

authenticate.jpg is an image that appears at the top of the authenticate.php page and allows schools to co-brand the site.

Lang is a folder that contains a single file, auth_liveid.php, which specifies a localized name for the plug-in.

policy.html is a file that contains your site's privacy policy.

settings.php is a file that contains the names of various settings used by the other files.

Important: Windows Live ID login screens allow a user to save her password on a computer for subsequent sessions. However, saving the password is not an option when logging in to Windows Live ID from Moodle. This is by design and is consistent with Moodle's login security standards. It is also aligns with the security required for shared computer scenarios.

Please note that if a user uses a Windows Live ID to sign into another Web application that supports password saving, then that password will also be used when logging into Moodle. For example, if a user logs into Outlook Live with their Windows Live ID, and selects the option to save the password, that same saved password can be applied when subsequently logging into Moodle with that Windows Live ID.

Microsoft Live Services Block Plug-in

The plug-in is a set of PHP files that manage the presentation of Live Services to the Moodle user. Because Microsoft's set of Live Services is always evolving, we built the plug-in so that it can easily incorporate new services and service changes. Modeling our code upon Moodle's extensibility architecture, we designed our plug-in to consume new Live Services easily.

Core Files

These are the main files found in the root folder of the Microsoft Live Services block. They load and render the Microsoft Live Services block.


This is the main entry point in the Microsoft Live Services block. Moodle calls this code which implements a specific set of methods, so that Moodle can render it on the page.


This is an HTML page for the configuration screen that administrators can use to configure the settings of the Microsoft Live Services block.


This is the FAQ page about Microsoft Live Services Plug-in for Moodle. You can customize this content and distribute to your end-users.


This file is called by block_live_services.php and is the main executing portion of the Microsoft Live Services block. It loads the user's identity (from the identity service) and calls the individual services that the user should see based on the configuration.


This file contains helper functions used to make REST API calls and SOAP calls using CURL.


This file is included in popup_dialog.php and provides JavaScript functions used by instances of the lightbox popup dialog. Functions in this file include graying out the page background, display of the lightbox, and closing of the lightbox.


This file renders a lightbox that is a container for the Send Alert, Quick Message, Quick Event, View Message, and View Event pages.


This file contains style definitions for the div located inside the IFRAME in the popup_dialog.php file.


This file contains IE-specific style definitions for the popup_dialog.php file if the style cannot be rendered in IE6 or IE7 in a browser-neutral way.


This file contains style definitions for the outer portion of the popup_dialog.php file.


This file contains helper and utility functions that can be shared across multiple services.

When the block is loaded, render_content.php calls each service that has been installed on the server. In order to maintain an extensible model, each service is self-contained in its own directory.

Services and Code Files

The following is a full list of services and their code files.


The identity service is required. It uses the information returned by the login process to validate the user and load their information, so that it is available to the other services.

It has one PHP file and a few graphics:

background.png (Windows Live ID authentication module)

This is the blue fade in the background of the Microsoft Live Services block.


This is the identity service class. It also presents several properties that allow other services in the block to perform user specific tasks.


This is the image file shown on the administrator configuration page that shows what the Microsoft Live Services block looks like.


This is the image file for the Windows Live Messenger icon.

// search ( no sign in needed )

if( class_exists( 'SearchService' ) && !empty( $CFG->block_live_services_showSearch ) )


$searchServiceObject = new SearchService();

$content_html .= $searchServiceObject->Render();


if( $identity->IsSignedIn() )


// email

if( class_exists( 'EmailService' ) )


$emailServiceObject = new EmailService();

$content_html .= $emailServiceObject->Render();


E-mail and Calendar

The E-mail and Calendar service supports both Hotmail and Microsoft Hosted Exchange. Connectivity to Exchange functionality is provided through the Exchange Web Services (EWS) API. EWS authentication uses WS-Trust, which is supported by Microsoft Hosted Exchange. Currently a user's Windows Live ID is not federated with the Microsoft Hosted Exchange endpoint.

Instead, we use an Exchange service account that is given impersonation rights to all users. All calls to EWS use the WS-Trust token for the service account and impersonate the logged in user. Before Moodle can make calls to EWS, the system must acquire an authentication token for EWS.

The EWS authentication flow is a follows:

Auto-discover the Exchange endpoint for the service account.

Get the authentication metadata:

Get the authentication STS endpoint from FederationMetaData.xml.

Get the Device Registration PUID.

Get the WS-Trust token for the Exchange endpoint (from the endpoint retrieved in step 1) using the authentication endpoint (retrieved in step 2.a) with the registered Device PUID (retrieved in step 2.b).

The E-mail and Calendar service contains the following files:


This file provides all the functionality needed to get the WS-Trust token for a given e-mail address and password. The token is cached and refreshed as needed.


This file provides the interfaces to the EWS methods that are used by the application.


This class is responsible for rendering the e-mail and calendar sections of the block. If Exchange is enabled it will first attempt to get the WS-Trust token for the service account. If a WS-Trust token is successfully acquired it will then attempt to get the unread e-mail and upcoming calendar items by making a call to ews.php. If Exchange is not enabled, or if the logged in user does not have an account on the Exchange server, the application renders the Hotmail e-mail and calendar views.


This is the popup window that is used to send an e-mail using Exchange.


This is the popup window that is used to view an e-mail from Exchange.


This is the popup window that is used to create a new calendar item using Exchange.


This is the popup window that is used to view a calendar item from Exchange.


This file provides pseudo Web services that are used to make AJAX calls to EWS. It supports creating a new calendar item (Appointment) and sending an e-mail. This file is called from pop_email.php and pop_event.php.

Windows Live Messenger


This is the image file for the Windows Live Messenger icon.


This file renders the Windows Live Messenger portion of the block. For each student or teacher who is in the user's contacts list and in the user's class, a link is provided to show the Windows Live Messenger Web client.

The following code renders the user links:

for( $i = 0; $i < count( $users ); $i++ )


$row = explode( '|', $users[ $i ] );

$email = $row[ 0 ];

$name = $row[ 1 ];

if( strlen( $name ) > 20 ) { $name = substr( $name, 0, 20 ) . '...'; }

$href = "'javascript:void\"$messengerServicePath/popIM.php?invitee=$email\", \"messengerChat\",\"menubar=1,resizable=1,scrollbars=0,width=450,height=450\");'";

$returnHtml .= "<li><img style='border:none; vertical-align: middle; padding: 0px;' onerror='this.src=\"$messengerServicePath/status_unknown.png\";' width='16' height='16'

src=''.$email.'/presenceimage/?mkt=en-US' title='online status' /><a

target='_parent' href=$href>$name</a></li>";



The Windows Live Messenger Web client container. It contains an iframe with a link to the Windows Live Messenger Web client page with a URL of:[email protected]&mkt=en-US


The image file used in the administrative setup that shows what Windows Live Messenger looks like in the Microsoft Live Services block.


An image file that indicates that the user's status is unknown.



This class provides support functions used by other alerts-related classes.


This class is responsible for rendering the alerts section of the block. If the user is subscribed for alerts, a link to unsubscribe will be displayed. If the user is not subscribed for alerts, a link to subscribe will be displayed. Users who are in a teacher role will be shown a "Send an Alert" link if the user is subscribed for alerts.


The close button in the pop_alert.php Web page.


Settings in this file include the URLs for the WSDLs, transport type, language locale, and version (1.0).


The class that defines an alert message and provides a method to deliver an alert message to a group of recipients. The "groupDeliver" method encapsulates the call to the Alerts service Web method of the same name.


This file displays a Web page that provides the user with the ability to send an alert. When the user enters an alert subject and body and clicks Send, the message is sent via AJAX and HTTP POST to the send_alert.php file, which handles the request.

The AJAX call is implemented with Yahoo's YUI in the following manner:

function makeRequest()


var sUrl = "send_alert.php";

var alertSubject = document.getElementById( 'alertSubject' );

var alertBody = document.getElementById( 'alertBody' );

var courseId = document.getElementById('courseId');

var postData = "alertSubject=" + alertSubject.value +

"&alertBody=" + alertBody.value +

"&courseId=" + courseId.value;

YAHOO.util.Connect.asyncRequest( 'POST', sUrl, callback, postData );


The callback function will be called when the data is posted back to the page. If the alert was sent successfully the page will close. If there is an error a JavaScript alert will be shown that displays a user-friendly description of the error.


The class that defines the properties of a Windows Live Messenger contact who can receive an alert.


The class that defines the properties of a group alert message. Windows Live Alerts supports several message versions including HTML and branded messaging, but to simplify things we set all versions to the same text-based message.


The image file used in the administrative setup that shows what Windows Live Alerts look like in the Microsoft Live Services block.


This file processes the AJAX call from the pop_alert.php Web page to the "groupDeliver" method with this call:

$groupMessage = new RecServicesGroupMessage( '', $subject, $body, $contacts, $groupName,

$body, $body, $body );

$result = $message->groupDeliver( $groupMessage );

echo( $result );


This is a child window that opens when the subscribe link is clicked. Unlike the pop_alert.php page, which posts to another page that handles the request, this page posts to itself. Calls are made to methods of the subscription class, and messaging is displayed based on the user's alerts status.


This class encapsulates calls to the Alerts Service Subscription Web Methods. Methods provide the ability to add a group, add and remove subscribers from group, validate membership in a group, and initiate signup.


This is a child window that is shown when the unsubscribe link is clicked. The architecture of this page is the same as subscribe_pop.php.



The Bing logo image file.


The Powerset logo image file.


The image file used in the administrative setup that shows what search looks like in the Microsoft Live Services block.


This file contains the JavaScript functions that perform the Bing and Powerset searches.


The file that renders the search portion of the Microsoft Live Services block.

Contact Information

If you have any questions or feedback about the Microsoft Live Services Plug-in for Moodle, please contact us at [email protected]

Microsoft, Bing, Hotmail, and Windows Live are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

This documentation is licensed under the Creative Commons Attribution License. To view a copy of this license,

(a) visit; or,

(b) send a letter to Creative Commons, 171 2nd Street, Suite 300, San Francisco, California, 94105, USA.