Authentication and Access Control


Player-based and User-based Authentication

Authentication provides a way for the Web site administrator to control who has access to specific clips. That access can take the form of merely asking a visitor's name once to requiring that the user enter a password and additional information every time he or she seeks access.

RealServer uses two types of authentication: Player-based authentication and User-based authentication.

Player-based authentication is most appropriate for situations where minimal user interaction is desired. The Authentication portion of RealServer is configured to allow or deny access to individual RealPlayers (usually one per computer), rather than to specific people, and authentication is transparent to the visitor-a dialog box warning only appears when the visitor attempts to access content for which he or she is not authorized. Player authentication is best suited to applications like fan clubs, premium groups, microcommerce, intranet, and demographic tracking.

User-based authentication is most appropriate for situations where higher security is desired. RealServer allows or denies access to individual users, and authorization requires user interaction-a username and password challenge dialog box appears whenever the visitor attempts to enter a zone containing secure content, and the resulting exchange is encrypted. User-based authentication is tied to the person, rather than to the RealPlayer. With User-based authentication, it does not matter which computer a visitor uses to connect to the Web site. User-based authentication is best suited to applications like pay-per-view, executive briefing, and distance learning.

Player-based and user-based authentication can be run simultaneously on the same Web pages and applied to different clips, but this requires two RealServers, one for each type of authentication.

The following table describes how the two types of authentication appear to a Web site visitor:
Player-based Authentication User-based Authentication
Registration
  1. Web page prompts user to create a user ID or password.
  2. Visitor clicks Submit.
  3. Server activates RealPlayer and returns a confirmation Web page.
  4. Visitor confirms the submitted information.
  1. Web page prompts user to create a user ID and password.
  2. Visitor clicks Submit and is confirmed in a single step.
Action When Attempting To View Secure Content None. When user enters secure clip area, RealPlayer prompts user to enter user ID and password.
When Privileges Are Established by Administrator System administrator sets visitor's privileges concurrent with or after RealPlayer installation.

System administrator sets visitor's privileges at any time.

System administrator can independently distribute User IDs and passwords.

Clip Request Visitor clicks link or directly types clip address into RealPlayer. Same as Player-based Authentication.


Access Control

Access control features determine how long a user can view a particular clip or allots a certain length of time for viewing clips.

There are three types of authentication access:

A single RealServer can simultaneously deliver multiple types of access.

Event-based Access

In event-based access, the visitor registers in advance for unlimited access to one or more specific media clips. The steps involved are:

  1. When a visitor clicks a link on a Web site, the site's Web server sends a metafile to the visitor's Web browser. Depending on which type of Authentication is in place, registration is automatic or requires a password.
  2. The visitor's browser starts RealPlayer and passes it the metafile.
  3. RealPlayer reads the pnm:// address in the metafile and contacts RealServer for the appropriate clip.

    The visitor can bypass steps 1 and 2 by typing the pnm:// address directly in RealPlayer. The pnm:// address is used specifically by RealServers.
  4. The RealServer challenges the RealPlayer. In Player-based authentication, this is transparent to the visitor. In User-based authentication, the visitor is prompted with a name and password dialog box.
  5. Upon verifying the visitor's registration, RealServer plays the media clip or live broadcast. The visitor gets endless access to the clip.

Duration-based Access

In duration-based access, a visitor is granted the right to access a media clip or event for a specific length of time.

The registration process follows that of event-based registration, but permission is granted for a specific length of time and/or event (for example, five hours total viewing time applied to any or all of some number of specified videos).

If the time granted expires while the visitor plays a clip, RealSystem halts transmission of the clip, and the following error message appears:

Server alert: Your account has expired, contact your content provider for more information.

Calendar-based Access

The process for expiration-based access follows that of event-based access, but permission is granted through a certain date (for example, unlimited viewing of any or all of some number of specified videos during the next week).

If the date and time of expiration arrives while the visitor plays a clip, transmission of that clip to RealPlayer is stopped, and an error message appears.


System Component Interaction

This section describes what happens when a visitor clicks a link on a sample Web site, which is based on the templates included with RealServer. These sample files configure the site for Player-based authentication, event-based access, and self-registration through the Web site. Files supplied with the RealServer installation are identified as such; all other files refer to files you create.

  1. Visitor opens a page that contains links to content on your Web site. The page also contains a link related to registration. For example, this link might be labeled "Click here to register now." If the page also contains links to secure content, the visitor will receive an error message if he or she attempts to access secure content before registering.
  2. Visitor clicks the "Click here to register now" link, which requests the bandwidth-negotiated media file stored at the URL listed in auth.ram. If the visitor has a version of RealPlayer prior to 4.0, RealServer detects this and sends the visitor an audio warning and redirects the Web browser to the RealNetworks upgrade page. If the visitor has RealPlayer version 4.0 or later, RealServer redirects the Web browser to the register page.
  3. Visitor registers by completing the form on the supplied register.html page hosted on the Web server, which includes a field for a unique user ID. This ID can be anything unique and memorable; email is a commonly used ID. In User-based authentication, this ID and password can also be assigned by a central administrator before the visitor connects to the site; in this case, steps 4 and 5 can be skipped.
  4. Visitor clicks "Submit," which calls ppvodemo.cgi (in Windows) or ppvmdemo.cgi (in UNIX).
  5. The ppvodemo.cgi or ppvmdemo.cgi file creates a new record in the data records.

    In Player-based authentication, ppvodemo.cgi or ppvmdemo.cgi also triggers register.rm, a non-audio file containing an rmmerged event, which in turn calls the supplied confirm.html page. The register.rm file is essential for Player-based authentication because it carries the embedded PlayerID to the RealServer. In User-based authentication, ppvodemo.cgi or ppvmdemo.cgi calls the supplied confirm.html directly.

  6. The visitor re-types his or her user ID into the Confirmation page and clicks "Confirm" or "Never Mind," calling ppvodemo.cgi or ppvmdemo.cgi again.

    Subsequent visitor access to the secured clips is transparent in Player-based authentication. Visitors access the site with no visible system interaction. Player IDs are automatically checked against the data storage whenever visitors request a clip. By contrast, in User-based authentication, visitors must reenter their user ID and password whenever they enter a different secure zone.

© 1997 RealNetworks, Inc.