|
|
| Previous | Next |
This section explains in detail the interaction between the client, the server running Windows Media Services, and the authenticator.
The following topics are covered in this section:
At startup the server queries the system registry for all authentication plug-in components that have been configured in the server. When startup is successful, the server retrieves the class identifier (CLSID) of the plug-in components and creates instances of the plug-in components. Then the server calls the Initialize method of each component to initialize the instantiated objects, passing in a pointer to the server context. This context contains properties describing certain attributes of the server. These properties include, but are not limited to:
The Initialize method provides an opportunity for the authenticator to perform any preliminary authentication tasks, such as establishing a link to the user account database, and allocating system resources that are used by the authenticator.
During initialization, the authenticator also informs the server whether data exchanged with the client during authentication is to be in text-based or binary format. HTTP-BASIC is text-based, while NTLM is binary.
Note During the server startup, the Initialize() method is always called on all authentication plug-in components that have been configured in the server. This method call happens even if the plug-in is disabled. As a consequence, if any disabled plug-in returns a failure code on the Initialize() method call, the server still starts up, but without the necessary information for performing an authentication task, it cannot stream.
After initializing the authentication plug-in object, the server calls the GetAuthenticationType method to retrieve the authentication type being used by the authenticator. This type must be recognizable by Windows Media Player. Currently, Windows Media Player only supports the following authentication types:
A user authentication object, managed by an authenticator object that implements the INSSAuthenticator interface, inspects and verifies user information each time a user connects. There is a different user authentication object created each time a user connects to the server. The server calls the authenticator’s CreateUserAuthentication method to create a user authentication object. Authentication for the instance of the client connection is done through the user authentication object.
Each time a client makes a request to open a title, the server notifies Windows Media Player that user authentication is required. Regardless of which authentication type is being used, authentication involves the exchange of data between the client, the server, and the authenticator. The server requests data from the client, such as a user name and password, and passes that data to the authenticator for inspection. The authenticator uses those credentials passed in by the server against the corresponding user account database, and notifies the server through a callback method that either the authentication is finished, or a further exchange of data is necessary to complete the authentication process.
The exchange of data continues until either the authenticator notifies the server through the callback that authentication is finished, or an error occurs. Theoretically, the data exchange can continue forever; however, most authentication schemes involve only one through three exchanges.
Windows Media Player prompts the user for user name and password credentials, and dispatches the credentials to the server. The server then passes them to the authenticator for inspection and validation. The authenticator, using its own private user account database, validates the data, and notifies the server of the result. The server then grants or denies the client access to the content based on the result.
The following chart depicts the interaction between the client, the server, and the authenticator using the HTTP-BASIC authentication protocol.
After authentication, the component notifies the server of the result, passing along the pointer to the user authentication context. When the user identity is validated, the server copies this pointer into the NSS_USER_AUTHENTICATION property of the user context. The authentication results and the user name are retrievable through the INSSUserAuthentication interface.
When the server is successfully authenticated, it can impersonate the user whenever necessary.
| Previous | Next |