previous next

Chapter 13: Authentication

Helix Universal Server authentication provides a way to control what or who can access your Helix Universal Server, whether an encoder sending a broadcast stream, a colleague perusing Helix Administrator, or a user viewing paid content. This chapter explains how to set up user name and password authentication, as well as validation through media player IDs.

Note: Chapter 12 describes how to limit access to media based on media players' IP addresses. The section "Controlling Connections" explains how to limit connections according to outgoing bandwidth use, total number of players, and other general criteria.

Understanding Authentication

Authentication verifies the identity of the users or software programs that make requests of Helix Universal Server. It usually takes the form of user name and password validation, though this is not necessary in all cases. The following sections describe the major authentication features and components.

Types of Authentication

There are several types access requests that you can authenticate, such as viewers requesting media, or Helix Universal Server users logging into Helix Administrator.

Media Viewer Validation

The most common use of authentication is to validate viewer access to on- demand clips or broadcasts. Helix Universal Server can require a standard user name and password combination that the viewer enters when requesting secure content. Or, you can have viewers register their players' globally unique identifiers (GUIDs). Helix Universal Server then validates access requests automatically, without asking viewers for user names and passwords.

The following table lists supported media players and the types of authentication that you can use with them. Basic, RealSystem 5.0, and Windows NT LAN Manager are forms of user name and password validation, as described in "Authentication Protocols".

Media Players and Supported Authentication Types
Media Player Basic RealSystem 5.0 Windows NT LAN Manager player GUID
RealPlayer 3 and earlier no no no no
RealPlayer 4 no no no yes
RealPlayer 5 and higher yes yes yes yes
Windows Media Player no no no no
QuickTime Player yes no no no
Any other RTP-based player no no no no

For More Information: See the section "Setting Up Basic Media Authentication" for the basics of user name and password authentication. "Validating Media Player IDs" explains validation through player GUIDs.

Administrator Authentication

Accessing Helix Administrator requires a valid user name and password. As explained in "Starting Helix Administrator", the URL used to access Helix Administrator contains the /admin/ mount point, which automatically authenticates the login. The installation process creates the initial user name and password pair, but you can add additional user names and passwords to the SecureAdmin realm, as described in "Managing Users and Passwords".

Encoder Validation

User name and password authentication for live or simulated live streams sent to Helix Universal Server is generally required for these encoders:

Although these encoders can use the main user name and password you use to log into Helix Administrator, RealNetworks recommends that you add additional user name and password pairs to the SecureEncoder realm for each live broadcast encoder. See "Managing Users and Passwords" for more information.

Password Validation Not Part of the Authentication System

Communication between the following components and Helix Universal Server typically require password validation:

This validation is not performed by the authentication system, however. Generally, the required passwords are defined on the encoder in its interface or configuration file. On Helix Universal Server, you use Helix Administrator to set up the passwords, which are stored in the configuration file.

Content Caching Subscriber Authentication

Content caching subscriber authentication is initiated by the content caching file system when making a request to the publisher server from the subscriber server. Like administrator and encoder authentication, the user name and password you enter during setup is also the default user name and password required for content caching subscribers. You can add additional user name and password pairs to the SecureCDist realm, as described in "Managing Users and Passwords".

For More Information: The subscriber server sends the authentication user name and password with its request for content. For more information, see "Setting up Content Caching Subscribers".

Authentication Components

As you set up authentication, you work with several components. Databases store privileges. Realms validate user names and passwords. Commerce rules determine which on-demand clips and live broadcasts are secure. And permissions grant access to content on a user-by-user basis.

Databases

On each authentication request, Helix Universal Server verifies the user's password and permissions in a database. Helix Universal Server installs a number of flat file databases, as described in "Using Databases". It uses different databases for different types of authentication. One database holds permissions for media players, for example, while another verifies the identity of encoders that deliver live broadcast streams.

To implement authentication on a limited scale (a few hundred users, for example), use the predefined flat file databases. This requires no additional database configuration. For large-scale implementations of authentication, however, you can tie Helix Universal Server's authentication system to an ODBC-compliant or mSQL relational database. On Windows NT systems, you can also tie authentication into an existing LAN manager database.

For More Information: For more about databases, see "Using Databases". Appendix C explains the database structure, which you'll need to know to use a relational database for authentication. See also "Windows NT LAN Manager".

Realms

An authentication realm indicates the database that stores a user's name and password, and specifies the authentication protocol used to validate the user's identity. An authentication protocol, which is not related to streaming protocols such as RTSP, determines how passwords are encrypted in the database. You can use a basic encryption protocol, or a more secure protocol that works with RealNetworks media players only.

Tip: Helix Universal Server predefines several realms. Depending on your authentication needs, you may not need to change or add realms. For more on realms, see "Setting Up Realms".

Commerce Rules

Commerce rules determine which on-demand clips or live broadcasts require authentication. Helix Universal Server predefines a set of commerce rules, each rule creating a protected path that leads to secure content. One rule protects all on-demand clips residing in the default security directory, for example. You can set up additional commerce rules as needed. For example, you'll need to create a new commerce rule, or modify an existing one, to secure clips that reside on a network drive.

Note: Commerce rules work only for media access, and do not apply to other forms of authentication, such as encoder validation. For more information, see "Defining Commerce Rules".

Permissions

Permissions attach to commerce rules to govern which users can view which clips or broadcasts. Using permissions, you can grant different users access to different secured clips. You can also grant viewing access that expires at a certain date and time, for example, or that is limited to a total amount of time. Although permissions are enforced by default, you can turn them off to give all authenticated users unlimited access to the content protected by a commerce rule. When you turn off permissions for on-demand content, for instance, all authenticated users have unlimited access to all secured, on- demand clips.

For More Information: For specifics about the permissions that you can grant, see "Handling User Permissions".

Authentication Used with Other Features

Authentication works with all other Helix Universal Server features. There are few special considerations for each feature, however.

Authentication Used with Other Features
Other Feature Notes
On-Demand Streaming All on-demand files stored in the Secure directory (or in any subdirectories) are authenticated automatically, once the authentication feature has been set up.
Live Unicasting Once the authentication feature has been set up, live broadcasts are authenticated automatically if they include /secure/ as part of the path when you encode the events.
Archiving Archived files are on-demand files that can be authenticated if they are moved to the correct location. They must be placed in the Secure directory or in a subdirectory of Secure, or the archiving feature must be configured to use the Secure directory.
SLTA Just like any other live event, broadcasts created by SLTA can be authenticated, as long as you include /secure/ in the broadcast path.
Splitting If you are sending a stream to a Helix Universal Server that is acting as a receiver, you must put copies of all the databases that store authentication information on the receiver. This distributes the authentication load.
Multicasting In back-channel multicasts, the user or client is authenticated through the initial control channel connection. Be sure the multicast (/) path is on the list of commerce rules. Authentication does not function with scalable multicasts.
Helix Universal Proxy Helix Universal Proxy makes requests on behalf of clients, and caches the streams it receives. Although Helix Universal Proxy stores the streamed data, it requires a control channel between the requesting client and Helix Universal Server. Helix Universal Server uses the control channel to request and receive authentication information.
Firewalls Authentication is performed over the two-way control channel. As long as the client can establish a connection through the firewall to Helix Universal Server, all material can be authenticated for clients behind firewalls.
Access Control Access control verification, which checks the client's IP address against a list of allowed addresses, occurs before authentication. So if a client's IP address is blocked, authentication will not take place. If users who should be able to view secure material receive error messages, check the list of access rules to see if their client addresses are disallowed.
ISP Hosting Authentication of content cannot be applied to the files of ISP-hosted customers. Their material is always available. Depending on the access needs, you may be able to apply access control rules so that customers can allow or deny certain users' access to content.
Monitoring You can monitor which secure presentations are in use by viewing the paths of the files in Server Monitor. Those that contain the /secure/ mount point are authenticated.
Reporting Efforts to authenticate users are not included in the access log; records are created for successful serves. You can identify authenticated material in the access log by the GET statement. Secure material always contains the /secure/ mount point in the path. In addition, connection attempts for authenticated material are stored in the accesslog.txt file in the Logs directory of appropriate data storage directory (if you are using the text file method), or in the Access_log table (if you are using the database method).

Setting Up Basic Media Authentication

The following sections explain the basics of how to secure on-demand clips and broadcasts through user name and password validation. They explain where to place clips, how to secure a broadcast originating from an encoder, and how to write URLs to the secure content. When you use the Helix Universal Server default settings, there are two setup steps you need to perform through Helix Administrator to implement user name and password checking:

  1. Add user name and password combinations according to the instructions in "Managing Users and Passwords".
  2. Define user permissions (or turn them off), as described in "Handling User Permissions".

In some cases, you may need to change certain default settings for databases and realms, depending on your authentication needs:

Securing On-Demand Content

To require user name and password validation, you place clips in Helix Universal Server's Secure directory instead of in its Content directory. In a default installation on Windows, the Secure directory is here:

C:\Program Files\Real\Helix Server\Secure

Installation paths vary on UNIX, but the Secure directory is under the main installation directory, as in this example:

/usr/local/Real/HelixServer/Secure

Helix Universal Server identifies requests for secure, on-demand clips through a /secure/ mount point that precedes the clip name in the request URL. This mount point is created during installation, and automatically requires authentication for all content in the Secure directory. The following is an example of a Web page URL to a secure clip:

http://helixserver.example.com/ramgen/secure/video1.rm

For More Information: See "Writing Links to Content" for background on link formats, mount points, and URLs used in Ram files.

Adding Subdirectories to Implement Permissions

You may want to create subdirectories within the Secure directory, then set up permissions as described in "Handling User Permissions" to define exactly which viewers can access which clips in which subdirectories. In this case, the request URL includes the subdirectory path, which can be any number of levels deep, after the /secure/ mount point:

http://helixserver.example.com/ramgen/secure/dailyvideo/video1.rm

Placing Secure Clips in Other Directories

You can store secure, on-demand clips in directories other than the default Secure directory. This allows you to store secured clips on other drives or network machines. To do this, you define a new, secure mount point used in place of the default /secure/ mount point.

To create a new security mount point for on-demand clips:

  1. Create a directory on your Helix Universal Server machine or your network to store your secure clips. This directory must not be a subdirectory of the existing Content or Secure directory.
  2. Add a new mount point, such as /secure2/, that points to the new directory. For instructions on doing this, see "Adding a Mount Point for On-Demand Clips".
  3. Follow the instructions in "Adding or Modifying Commerce Rules" to create a commerce rule that provides access to this new protected path.
  4. Set up permissions for individual users to view content in the new protected path, as described in "Handling User Permissions".

As shown in the following example, a URL to a clip in the new secure directory uses the mount point you define:

http://helixserver.example.com/ramgen/secure2/video1.rm

When Helix Universal Server receives a request to this protected path, it initiates authentication to verify that the user or player exists in the proper database according to the commerce rule that protects the /secure2/ path.

Securing Broadcasts

To secure a live or simulated live broadcast, you include the /secure/ mount point after the broadcast mount point in the request URL:

http://helixserver.example.com/ramgen/broadcast/secure/live.rm

Live or simulated live broadcasts do not correspond to actual files on Helix Universal Server. When a broadcast mount point such as /broadcast/, /encoder/, or /live/ precedes the /secure/ mount point, Helix Universal Server performs authentication, but does not search for a file in its Secure directory. Instead, it delivers the live stream associated with the broadcast mount point.

Specifying the Secure Path on the Encoder

The encoder that delivers the live or simulated live stream must include the /secure/ virtual path along with the broadcast file name to indicate that this stream requires authentication. In Helix Producer, for example, you specify the live stream as secure/live.rm instead of just live.rm.

For More Information: Predefined commerce rules govern access to broadcasts from different encoders. For more information, see "Default Commerce Rules".

Managing Users and Passwords

The following sections explain how to manage the user names and passwords of authorized users for any type of authentication, whether individuals requesting secured clips, encoders connecting with live streams, or additional users of Helix Administrator.

Note: If you are using Windows NT/2000/XP to manage the list of users, passwords, and groups, use those tools instead of the instructions below. To use Windows passwords, you need to set the NTLM authentication protocol in your selected realm, as described in "Creating or Modifying a Realm".

Adding a User

Follow the procedure below to add a user and password to an authentication realm. To use a database other than one that is predefined, you must create that database and associate it with the proper realm before adding users. Refer to "Using Databases" and "Setting Up Realms" for more information.

Note: The Helix Administrator interface does not provide a way to add multiple user names and passwords at one time.

To add a user name and password:

  1. Click Security>Authentication.
  2. In the Authentication Realms list, select the realm to which you want to add a user. The following realms are predefined:

    SecureAdmin Helix Administrator users
    SecureCDist content caching subscribers
    SecureContent media player users
    SecureEncoder RealProducer G2 through 8.5 delivering live broadcast streams
    SecureRBSEncoder Helix Producer delivering live broadcast streams, and SLTA delivering simulated live streams in basic mode
  3. For More Information: Realms are described in "Setting Up Realms".

  4. Click Add a User to Realm.
  5. In the pop-up window, define the user's name in the Name box. User names are case-sensitive. You can use separate words if, for example, you want to use full names of users.
  6. In the Password box, supply the user's password. Passwords are case-sensitive. RealNetworks recommends following good password practices:
  7. In the Confirm Password box, type the password again.
  8. Click OK.

Deleting a User

The following procedure explains how to delete a user from a database. Helix Administrator does not have a bulk delete feature.

To remove a user:

  1. Click Security>Authentication.
  2. In the Authentication Realms list, select the name of the realm in which you want to delete a user. The predefined realms are described in "Setting Up Realms".
  3. Click Remove a User from Realm.
  4. In the new window that appears, enter the user's name in the Name box.
  5. Click OK.

Browsing All User Names

The browsing feature lists all user names defined for an authentication realm.

To browse all users:

  1. Click Security>Authentication.
  2. In the Authentication Realms list, select the realm you want to browse. The default realms are described in "Setting Up Realms".
  3. Click Browse Users in Realm. The pop-up window lists all user names defined for that realm.

Changing a Password

The following procedure explains how to change the password for an existing user. The Helix Administrator interface does not allow you to look up existing passwords.

To change a password:

  1. Click Security>Authentication.
  2. In the Authentication Realms list, select the name of the realm that contains the user. The predefined realms are described in "Setting Up Realms".
  3. Click Change User Password.
  4. In the new window that appears, enter the user's name in the Name box.
  5. In the Password box, specify the user's new password.
  6. In the Confirm Password box, type the password again.
  7. Click OK.

Using the Password Tool

When it uses the RealSystem 5.0 authentication protocol, Helix Universal Server encrypts passwords, so you cannot look up the passwords directly. However, you can add or change passwords in a flat file or relational database by using a command-line utility. You can even create a password interface by integrating this utility with your own CGI scripts and Web pages.

For More Information: See "Authentication Protocols".

To use the password tool:

  1. Open a command prompt and navigate to the Bin directory under Helix Universal Server's main installation directory.
  2. Enter the following command:
  3. mkpnpass username realm
    

    using the following values:

    username The user name exactly as it is entered, or will be entered, in the authentication database.
    realm The value of the Realm variable specified in the relevant list.

    For Helix Producer, this is given in the Authentication field under Broadcasting>RealNetworks Encoding. In the configuration file, it is given by the value of the Realm variable in the G2_Encoders list.

    For Helix Administrator users, use the value of the Realm variable in the RealAdministrator_Files list within the FSMount list in the configuration file.

  4. A password prompt appears, followed by a prompt to type the password again. The resulting encrypted password is displayed on the screen.
  5. Helix Universal Server encrypts passwords with the MD5 hashing algorithm. It uses the form MD5("username:realm:new_password"). On BSD systems and some other UNIX systems, you can generate these passwords with the following command:

    echo -n "username:realm:new_password" | md5
    

  6. Add the resulting encrypted password into the appropriate field of the database:

Using Databases

In its default configuration, Helix Universal Server uses a set of flat files to store user names, passwords, and permissions. For large-scale implementations of authentication, RealNetworks recommends that you tie Helix Universal Server into an ODBC-compliant or mSQL database that stores this information. The following table lists the flat file databases automatically installed with Helix Universal Server.

Default Databases
Name User Names and Passwords Purpose
Admin_Basic Helix Administrator. Validate access to Helix Administrator.
CDist_Basic registered content caching subscribers Verify subscribers requesting content from a publisher.
Content_RN5 content users Validate users requesting secured on-demand or live content.
Encoder_Basic Helix Producer Verify content creators delivering live or simulated live broadcasts.
Encoder_RN5 RealProducer G2 through 8.5 Verify content creators delivering live or simulated live broadcasts.
PlayerContent player GUIDs and user names for viewers accessing content Validate unique IDs for players accessing content.

Supported Database Types

Helix Universal Server provides interfaces to several types of databases. Appendix C contains details about the database structure, which you'll need to know to integrate Helix Universal Server's authentication system with a relational database, for example.

Flat File Database

The default databases used for authentication are flat text files, which work well for storing relatively small amounts of data, such as a few hundred user names and passwords. You may want to use them to learn the authentication data structure before linking Helix Universal Server to a more robust relational database. If you choose to use the default flat files exclusively, you do not need to perform any additional configuration.

ODBC and mSQL

Helix Universal Server includes templates for common relational databases, covering mSQL and ODBC-compliant databases. To use an ODBC or mSQL database, you must configure your database to comply with the appropriate table structure described in Appendix C.

RN5 DB Wrapper

If you used authentication features with RealSystem Server version 5, or if you have a data store plug-in created by a third-party company, you can use that plug-in with Helix Universal Server version 9.0.

Adding a Database

Follow the procedure below to add a new database that stores user names and passwords. If you are using the default flat file databases, it is typically not necessary to add a new database.

To add a database:

  1. Click Security>Databases.
  2. Click the "+" icon, and type a description for the new database in the Edit Database Name box.
  3. From the Database Type list, select the data storage method you want to use. Database types are described in "Supported Database Types".
  4. Depending on the database type method you chose, additional information is required.
    1. Flat File needs only the path to the main text file directory. For example, the enc_r_db directory under the main Helix Universal Server directory. For more information, see "Understanding Authentication Data".
    2. mSQL has two required names, and three optional items:
    3. Host Name—IP address or DNS name of computer where the database is stored.

      Database Name—Name of the database.

      Table Name Prefix—Prefix used to make field names unique, when used with an existing database.

      User Name—Name required by the database application.

      Password—Password required by the database application. Re-enter your password in the Confirm Password box to ensure that you typed it correctly.

    4. ODBC uses the same information as mSQL, but ODBC does not ask for a host name. Refer to "Setting Up Other Types of Data Storage" for further instructions.
    5. For RN5 DB Wrapper, the following items are needed:
    6. Database Name—Name or location of the data storage plug-in. Consult your plug-in documentation for information about what should go here.

      Plugin Path—Location of the plug-in.

      User Name—Name required by the database application.

      Password—Password required by the database application. Re-enter your password in the Confirm DB Login Password box to ensure that you typed it correctly.

  5. Click Apply.

Setting Up Realms

A realm connects users to databases. When you define passwords, you add them to a realm. The realm, in turn, specifies the encryption protocol, and indicates the database where information is stored. If you are using the default authentication databases, as described in "Using Databases", you can use the default realms, too, changing the authentication protocols if necessary. If you set up new databases, you need to create new realms, or point the existing realms to your new databases.

Predefined Authentication Realms
Realm Authenticates Realm ID Protocol Database
SecureAdmin Helix Administrator servername.
AdminRealm
Basic Admin_Basic
SecureCDist content caching subscribers servername.
CDistRealm
Basic CDist_Basic
SecureContent content users servername.
ContentRealm
RealSystem 5.0 Content_RN5
SecureEncoder live streams from RealProducer G2 through 8.5 servername.
EncoderRealm
RealSystem 5.0 Encoder_RN5
SecureRBSEncoder live streams from Helix Producer servername.
RBSEncoder
Realm
Basic Encoder_Basic

Authentication Protocols

Authentication protocols determine the password encryption and storage method used by Helix Universal Server. The server supports three protocols. Each realm uses just one protocol.

Basic

The Basic protocol sends the user's name password over the public Internet in a simple manner, encoding them with the Base64 algorithm. Helix Universal Server decodes and verifies the password. Information can be stored in a flat file or a relational database. This protocol works with RealNetworks media players, as well as the QuickTime Player.

RealSystem 5.0

Also called RN5, this is a RealNetworks encryption protocol that works with RealPlayer 5 and later. It is more sophisticated and secure than the Basic protocol. Use it if your material will be served exclusively to users who have RealPlayer 5 or later. Information can be stored in a flat file or a relational database.

Tip: For authentication of QuickTime Player or RealNetworks players earlier than version 5, use the Basic protocol.

Windows NT LAN Manager

The NTLM method is suitable for a Windows-based intranet. It enables Helix Universal Server to use the existing Windows NT database of user groups. It also allows access control of content through NTFS file permissions. This method requires that Helix Universal Server itself be installed on the Windows NT machine. When using NTLM authentication, be aware of the following:

Creating or Modifying a Realm

The following procedure explains how to create a new realm or modify an existing one. It is generally not necessary to do this unless you have created a new database. Use a one-to-one correspondence between realms and databases. Do not create two realms, for instance, that use the same database.

To create or modify a realm:

  1. Click Security>Authentication.
  2. To create a realm, click the "+" icon and enter a name for this realm in the Edit Realm Description box. To modify an existing realm, select it in the Authentication Realms box.
  3. In the Realm ID box, type a name that will be used in other areas of Helix Administrator. The realm name may also appear to users as part of the name and password prompt. The default realms conform to the following format:
  4. servername.Realm_Id
    

    Warning! You do not have to use the default convention, but you must include a period (.) in the realm ID or the realm will not work properly.

  5. In the Authentication Protocol list, select the authentication method you want to use for this realm, as described in "Authentication Protocols".
    1. If you choose Basic or RealSystem 5.0, select the database in the Database box.
    2. If you choose Windows NT LAN Manager, Helix Universal Server uses the NT list of names instead of a database. Type the appropriate provider in the Provider list, such as NTLM. Type the Group name in the Group box.

  6. Click Apply.

Defining Commerce Rules

Commerce rules enforce authentication by defining protected paths. For example, the default commerce rule for on-demand clips defines the protected path /secure/, which corresponds to the Secure directory. When that path appears in a URL request, Helix Universal Server authenticates the request, allowing anyone with a valid user name and password to view clips in that directory. You can modify the default commerce rules, and create new commerce rules, to carry out tasks such as the following:

Default Commerce Rules

Helix Universal Server defines a number of commerce rules that provide general access to secured content. For example, these rules allow access to on- demand clips in the /secure/ path, or to broadcasts in the /broadcast/secure/ path.

SecureG2LiveContent

The commerce rule SecureG2LiveContent grants access to live broadcasts encoded with RealProducer G2 through 8.5. The rule evaluates the protected path /encoder/secure/. Users requesting live broadcasts through this path are associated with the SecureContent realm by default, and must have a user name and password defined in this realm to gain access to the secured broadcast.

SecureLiveContent

SecureLiveContent grants access to live broadcasts encoded with Helix Producer 9 and higher, as well as simulated live broadcasts delivered through SLTA. The rule evaluates the /broadcast/secure/ protected path. Users requesting live broadcast URLs that contain this path are associated with the SecureContent realm by default, and must have a user name and password defined in this realm to gain access to the secured broadcast.

SecurePlayerContent

This commerce rule, which is used for validating media player IDs, grants access to the player directory, a subdirectory of the /secure/ mount point. User and client information must exist in the player database before viewers can access the content. The section "Validating Media Player IDs" explains player ID validation.

SecurePreG2LiveContent

You use the SecurePreG2LiveContent commerce rule for content encoded with versions of RealProducer earlier than RealProducer G2. The rule evaluates the protected path /live/secure/. Users requesting URLs containing this path are associated with the SecureContent realm and must have a user name and password defined in this realm to gain access to the secured content.

SecureUserContent

This commerce rule grants access to on-demand content in which the request URL contains the /secure/ mount point. Users requesting this content are associated with the SecureContent realm by default, and must have a user name and password defined in this realm to gain access to the secured content.

Adding or Modifying Commerce Rules

The following procedure explains how to add a commerce rule, or modify the overall attributes of existing commerce rules. The section "Handling User Permissions" explains how to define permissions for a commerce rule.

To create or modify a commerce rule:

  1. Click Security>Commerce.
  2. To create a new rule, click the "+" icon and edit the name that appears in the Edit Rule Name box. To modify a rule, select its name in the Commerce Rules box.
  3. In Protected Path, enter the path that appears in the URL to invoke the commerce rule. For example, if you set up a /secure2/ mount point for secured content, enter /secure2 (no closing slash) in the box.
  4. For More Information: For more on creating additional secure mount points, see "Placing Secure Clips in Other Directories".

  5. In User Permissions Database, select the database that will store the user permissions. The default database for on-demand content is Content_RN5. The table "Default Databases" lists the other default databases.
  6. Note: You can turn off individual user permissions for the commerce rule by selecting Do Not Evaluate User Permissions. In this case, all authenticated users have unlimited access to content protected by the commerce rule.

  7. In the Credential Type list, select Use User Authentication to require user name and password validation. The other choice, Use Player Validation, validates access attempts according to player IDs, which is described in the section "Validating Media Player IDs".
  8. If you chose user name and password validation, you next select the realm in the Realm pull-down list. The default realm for on-demand content is SecureContent. The table "Predefined Authentication Realms" lists the other default realms. User names and passwords must be defined in the selected realm, as described in "Managing Users and Passwords".
  9. Warning! You must select the realm associated with the database you chose in the User Permissions Database field.

  10. If you selected user name and password validation, you can set Allow Duplicate User IDs to Yes. This allows multiple people to use a single user account simultaneously. If you want to distribute a video to all employees in a division, for example, you can allow duplicate IDs and supply all persons in that division with the same user name and password.
  11. Click Apply.
  12. Note: The Player GUID Databases section is used only with player ID validation. The section "Modifying the GUID Database" explains how to use that part of the commerce rules page.

Handling User Permissions

Permissions are associated with commerce rules. They determine which authenticated viewers can see which content in a protected path. By setting up permissions, you can grant access to clips on a person-by-person and file-by- file basis, for instance. You can also create permissions that allow secured access to clips or broadcasts only at certain times, or for certain durations. Note the following about permissions:

Permission Types

When you associate permissions with a user, you can set up two types of access. You can allow access to entire directories. You can also set up permissions file-by-file, or use a combination of these two methods.

Directory-Level Access

Directory-level access specifies that a user can view all of the content in a certain directory, as well as in its subdirectories, which inherit the permission. For example, you might give viewer A directory-level access to this path:

/secure/confidential/

The viewer then has access to files in that path, as well as in any subdirectory below that path. Thus, viewer A can access a clip in this path:

/secure/confidential/secret/

But viewer A does not have access to a path such as this:

/secure/topsecret/

File-Level Access

File-level access grants a user access to a specific file or live broadcast stream. As described below, you can also specify the duration or manner of this access. A single user may have both directory and file access for a clip in the same directory. If the directory access has expired, but the file access is still valid, the viewer can request the valid file, but no others in the directory. Conversely, if the file access has expired but the directory access is still valid, the viewer can request all files in the directory except the expired file.

Permission Access Types

Whether you give a viewer directory-level or file-level access, you can assign an access type as described in the following table.

Permission Types
Access Type Permission Granted
Event Unlimited viewing of a given clip or a directory of clips. This is the default.
Calendar Permission expires on a certain date and time. If the expiration date and time arrive while the viewer plays a clip or broadcast, transmission stops and an error message appears.
Duration Viewer gets a finite amount of time to view presentations. All viewing time is deducted from this amount. When the duration time elapses, permission is revoked.
Credit Time spent viewing presentations is noted in the Helix Universal Server access log, and the administrator can use this information later for billing purposes. Access is granted per presentation or directory, and is unlimited. For information on the authentication access logs, see "Logs Directory".

Note: With Duration or Credit permissions, Helix Universal Server accurately reports the total time a user views a secure file. If the end time minus the start time does not equal the total viewing time, for example, the discrepancy can be attributed to the user buffering, pausing, or seeking within the file. However, the total viewing time is the value debited or credited against the user's account, depending on the permissions used.

Permissions for SMIL Presentations

With a SMIL presentation, users are authenticated once regardless of how many files in the presentation are protected. If access to any clip in the presentation expires during the presentation, the presentation halts until more viewing time is allotted. For this reason, it is a good idea to keep permissions on all clips within a SMIL presentation the same. The following are the best methods of implementing authentication for SMIL files:

SMIL Files and Directory-Level Duration Access

If you define directory-level duration access for a SMIL presentation, giving identical permission to all files (including the SMIL file) will not work as you may expect. As each clip plays, Helix Universal Server subtracts the viewing time from the directory allotment. If each clip is 10 minutes long, and there are three clips in the presentation, Helix Universal Server subtracts 30 minutes from the total viewing time. This means that in setting up this type of access, the time allotted must be the sum of all the clips.

Tip: Keeping track of all the clips, their lengths, and the total directory access time can be tricky. An easier solution is to limit the access time only for the SMIL file.

Granting Permissions

You can create user permissions for commerce rules by following the procedure listed below. Note the following about defining permissions:

To grant permissions to a user:

  1. Click Security>Commerce.
  2. Select the appropriate commerce rule in the Commerce Rules box.
  3. Click the Grant User Permission link.
  4. In the pop-up window, enter the user's name in the User Name box.
  5. For Path Type, select Directory or File depending on the type of permission you want to add. For more information, see "Permission Types".
  6. The Path box indicates the directory or file that the viewer can access. It initially lists the protected path associated with the selected commerce rule. For example, if you're adding permissions to the default commerce rule for on-demand content (SecureUserContent), the path looks like this:
  7. secure/
    

    1. If you've chosen directory-level access, add to the protected path the subdirectory the viewer can access, as in the following:
    2. secure/confidential
      

      Note: The viewer can view clips in all subdirectories of the selected path.

    3. If you've selected file-level access, enter the subdirectory, if necessary, and the clip file name, as shown here:
    4. secure/confidential/report.rm
      

  8. The Access Type pull-down list corresponds to permission types described in "Permission Access Types".
    1. Set the menu to Event to allow unlimited access to the content.
    2. If you choose Calendar, set an expiration date in this format:
    3. mm/dd/yyyy:hh:mm:ss
      

    4. For Duration, set in seconds the total amount of viewing time allowed.
    5. Choose Credit to log the viewer's total access time in the access logs.

  9. Click OK.

Editing User Permissions

After you assign permissions to a user, you can edit those permissions to change the viewing expiration date, for example, or give the viewer more or less total viewing time on a directory or file.

To modify user permissions:

  1. Click Security>Commerce.
  2. Select the appropriate commerce rule in the Commerce Rules box.
  3. Click the Edit User Permission link.
  4. In the pop-up window, enter the user's name in the User Name box. See "Browsing All User Names" for information about listing user names.
  5. For Path Type, you can select Directory or File to change the type of permission. For more information, see "Permission Types".
  6. The Path box indicates the directory or file that the viewer can access. For more information on this, see Step 6 in the procedure for granting permissions.
  7. If you had set an expiration date on the user permissions, you can enter a new date in the New Expiration Date box in this format:
  8.  mm/dd/yyyy:hh:mm:ss
    

    After doing so, click Set New Date.

  9. If you set a duration on the user permissions, you can modify the viewing time allowed. Choose Add or Subtract, and enter the amount of time in seconds. Then click Change Time.
  10. Click Close Window.

Revoking User Permissions

You can revoke some or all permissions granted to a user. Keep in mind, though, that each revocation applies only to the selected commerce rule. If a user has permissions defined for other commerce rules, you must revoke those permissions separately. Helix Administrator does not provide a means for revoking permissions for several users or several commerce rules at a time.

Tip: See "Browsing All User Names" for information about listing user names.

To revoke a single permission for a user:

  1. Click Security>Commerce.
  2. Select the appropriate commerce rule in the Commerce Rules box.
  3. Click the Revoke User Permission link.
  4. In the pop-up window, enter the user's name in the User Name box.
  5. For Path Type, select Directory or File according to the type of permission you want to revoke. For more information, see "Permission Types".
  6. The Path box indicates the directory or file that the viewer can access. For more information on this, see Step 6 in the procedure for granting permissions.
  7. Click OK.

To revoke all permissions for a user:

  1. Click Security>Commerce.
  2. Select the appropriate commerce rule in the Commerce Rules box.
  3. Click the Revoke All Permissions link.
  4. In the pop-up window, enter the user's name in the User Name box.
  5. Click OK.

Validating Media Player IDs

For authentication of on-demand content or broadcasts, you can validate media player IDs rather than user name and password combinations. For the privacy reasons described below, this method of authentication is better suited for an intranet, although you can use it with the public Internet. With player ID authentication, users first register their player IDs through a special URL. They can then view protected content without having to enter a user name and password. Media player ID validation works only with RealPlayer 4 and higher.

Player IDs and User Privacy

For player ID validation to work, players must be configured to send a globally unique ID (GUID) to Helix Universal Server. For privacy protection, the standard RealOne Player that viewers download over the Internet is set by default not to send a GUID, in accordance with RealNetworks' Consumer Software Privacy Statement, which is published on the following Web page:

http://www.realnetworks.com/company/privacy/software.html

Because sending a GUID is solely at the discretion of each user, you must request users to change their default GUID setting (on RealOne Player, the command is Tools>Preferences>Connection>Internet Settings) to register their GUIDs and enable player ID authentication for material delivered over the Internet. Users who decline to do so will be denied access to secure content. However, you can reroute these users to a non-secure Web URL that explains their options, as described in "Setting Up Commerce Rules".

Using Player ID Validation on an Intranet

In an enterprise setting, you can control whether or not RealOne Player transmits its GUID when you use RealNetworks' Desktop Resource Manager. You can turn GUID registration on by default for all users, making it easier to set up player ID validation on an intranet. For more on Desktop Resource Manager, visit the following Web page:

http://www.realnetworks.com/products/ria/rdm/index.html

Choosing a Database and Realm for User Names

Helix Universal Server installs a default database, PlayerContent, for use with player ID validation. You can use this database, or add your own relational database. You need to associate a realm with the player ID database only to populate it with user names initially. After that, Helix Universal Server refers directly to the database to validate player IDs, and does not refer to the realm again. Note the following:

The section "Creating or Modifying a Realm" explains how to create a new realm or modify the SecureContent realm. For the realm you decide to use, select the PlayerContent database (or the relational database you're using) in the Database pull-down list. You can set the Authentication Protocol to Basic or RealSystem 5.0. Passwords are not used, so either protocol setting has the same effect.

Adding User Names to the Player ID Database

After you select your realm for player ID validation, add user names to that realm for each user as described in "Adding a User". Users will then register with Helix Universal Server once using their user names. Helix Universal Server associates each user name with the unique player ID in its database. It validates subsequent access attempts through the ID without asking the user to enter a user name. Because user names are associated with player IDs, though, you can use the names to set up permissions.

Note: The database structure requires that you enter a password for each user, even though passwords aren't used with player ID validation. You can therefore enter the same password for each user.

Setting Up Commerce Rules

Helix Universal Server provides a default commerce rule called SecurePlayerContent that authenticates access attempts through player IDs. You do not have to change any settings to use this default rule to secure on- demand content. To modify this rule or create a new one, refer to the instructions in "Adding or Modifying Commerce Rules". Note the following about commerce rules used with player ID validation:

Modifying the GUID Database

The Helix Administrator Commerce page allows you to select the database that registers player IDs. You do not need to change the default setting if you are using the default PlayerContent database. You need to change the GUID database settings only if you are not using the default database, or you want to change the prefix used in URLs to register users.

To modify the GUID database:

  1. Click Security>Commerce.
  2. Select an existing database name, or click the "+" icon to create a new database entry, naming the database in the Edit Description field. The name is for your reference only.
  3. Enter a prefix in the Player Registration Prefix field. You'll use this prefix in URLs that viewers click to register their player IDs, as described in "Creating Registration URLs".
  4. Select the database to use through the Player Database pull-down list.
  5. Click Apply.

Creating Registration URLs

To register individual RealOne Players, you create a link that viewers click once to add their players' GUIDs to the database. The registration URL, which users can enter in the File>Open Location box of RealOne Player, looks like this:

rtsp://helixserver.example.com/registerName!clip.rm

If you add the URL to a Web page link, you use an HTTP URL and /ramgen/, as shown here:

http://helixserver.example.com/ramgen/registerName!clip.rm

Note the following:

Writing Content URLs

After viewers contact Helix Universal Server through the registration URL, they can begin to access content for which they have permission. Media clips go in the secure directory defined by the commerce rule, as described in "Setting Up Commerce Rules". The default path is the player subdirectory (which must be created manually) of the Secure directory. Web page links to this content look like this:

http://helixserver.example.com/ramgen/secure/player/business/video1.rm

In the preceding example, /business/ is an optional path that corresponds to an actual subdirectory in the protected path. These subdirectories can be any number of levels deep, and you can assign various users privileges for different subdirectories as described in "Granting Permissions".

A Web page link to a live broadcast looks like this:

http://helixserver.example.com/ramgen/broadcast/secure/player/live.rm

Here, /broadcast/ is the appropriate broadcast mount point, as described in Chapter 7. The encoder that sends the stream to Helix Universal Server must supply the /secure/player virtual path along with the broadcast stream name.

Note: As noted in "Setting Up Commerce Rules", a commerce rule for the /broadcast/secure/player protected path is not predefined, so you must create it to secure broadcasts through player ID validation.

For More Information: For background on URLs and links, see "Writing Links to Content".


RealNetworks, Inc. © 2002 RealNetworks, Inc. All rights reserved.
For more information, visit RealNetworks
Click here if the Table of Contents frame is not visible at the left side of your screen.
previous next