Implementing an Authentication Plug-in

  • Article

banner art

Previous Next

Implementing an Authentication Plug-in

Clients must follow a two-step process to access digital media. First, the identity of the client must be established. This is usually accomplished by comparing the client credentials against those contained in a database. Second, the client must be granted permission to access content. Authentication plug-ins are used to identify clients, and authorization plug-ins are used to grant access to content. To authenticate and authorize a client, the server performs the following steps:

  1. If an anonymous authentication plug-in is enabled, the server calls the Authenticate method on the IWMSAuthenticationContext interface to determine whether the client can be identified. This plug-in grants the client the same permissions granted to a member of the Windows user account specified on the property page of the plug-in. The server queries the authorization plug-in(s) to determine what, if any, access permissions have been granted to the guest account. The same permissions are assigned to the client.
  2. If any of the authorization plug-ins fail to authorize the client's request or if the client cannot be authenticated by the anonymous authentication plug-in, then the first non-anonymous authentication plug-in is called in the selection order, and the client must go through the process of authentication and authorization again. One such non-anonymous authentication plug-in is the WMS Negotiate Authentication plug-in, which uses the client's logon credentials to authenticate the client. This plug-in uses the encrypted password and user name entered by the user during logon. The WMS Negotiate Authentication plug-in can use either the NT LAN Manager (NTLM) authentication protocol or Kerberos V5 protocol to authenticate the client, depending on what the client understands. If the client is Windows Media Player 9 Series or later, Windows Media Services will send a challenge blob using both protocols, and the client can send a response using either protocol. However, versions 7.1 and 8.0 of Windows Media Player will receive only an NTLM challenge blob because these versions do not support the Kerberos authentication protocol. If the plug-in identifies the client, the server again queries the authorization plug-in(s) to determine what, if any, access permissions have been granted.
  3. If step 2 fails to authenticate and authorize the client, the server again calls the same authentication plug-in as noted in step 2. This allows the client to authenticate with alternate credentials; however, Windows Media Player 6.4 clients will not receive this additional challenge. They will receive an access-denied message instead. If the client is not authenticated or fails an authorization request after a second time, then it will receive an access-denied message.
  4. If step 3 fails to authenticate and authorize the client, then the server calls the same authentication plug-in that was called in steps 2 and 3. If the client is not authenticated or not authorized during this step, then the client receives an access-denied message.

The following flowchart illustrates how a Windows Media Player 9 Series or later client goes through the previously described authentication process.

Flowchart showing interaction between authentication plug-ins, authorization plug-ins, and the server, when a Windows Media Player 9 Series or later client tries to authenticate.

The following flowchart illustrates how a Windows Media Player 6.4 client goes through the previously described authentication process.

Flowchart showing interaction between authentication plug-ins, authorization plug-ins, and the server when a Windows Media Player 6.4 client tries to authenticate.

See Also (General)

Previous Next