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. |
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.
There are several types access requests that you can authenticate, such as viewers requesting media, or Helix Universal Server users logging into Helix Administrator.
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".
| 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. |
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".
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.
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 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". |
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.
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". |
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 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 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 works with all other Helix Universal Server features. There are few special considerations for each feature, however.
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:
In some cases, you may need to change certain default settings for databases and realms, depending on your authentication needs:
Basic authentication protocol in your authentication realms. For instructions on doing this, see "Creating or Modifying a Realm".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 |
| For More Information: See "Writing Links to Content" for background on link formats, mount points, and URLs used in Ram files. |
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 |
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: |
Content or Secure directory./secure2/, that points to the new directory. For instructions on doing this, see "Adding a Mount Point for On-Demand Clips".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 |
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.
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 |
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.
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". |
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". |
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: |
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 |
| For More Information: Realms are described in "Setting Up Realms". |
| Tip: Keep track of the passwords you assign. Helix Administrator allows you to change passwords, but not to look them up. |
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: |
The browsing feature lists all user names defined for an authentication realm.
| To browse all users: |
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: |
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: |
Bin directory under Helix Universal Server's main installation directory.mkpnpass username realm |
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 " |
Users directory. See "Users Directory".Users table. See "Users Table".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.
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.
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.
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.
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.
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: |
Host NameIP address or DNS name of computer where the database is stored.
Database NameName of the database.
Table Name PrefixPrefix used to make field names unique, when used with an existing database.
User NameName required by the database application.
PasswordPassword required by the database application. Re-enter your password in the Confirm Password box to ensure that you typed it correctly.
Database NameName or location of the data storage plug-in. Consult your plug-in documentation for information about what should go here.
Plugin PathLocation of the plug-in.
User NameName required by the database application.
PasswordPassword required by the database application. Re-enter your password in the Confirm DB Login Password box to ensure that you typed it correctly.
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.
| Realm | Authenticates | Realm ID | Protocol | Database |
|---|---|---|---|---|
SecureAdmin |
Helix Administrator | servername. |
Basic |
Admin_Basic |
SecureCDist |
content caching subscribers | servername. |
Basic |
CDist_Basic |
SecureContent |
content users | servername. |
RealSystem 5.0 |
Content_RN5 |
SecureEncoder |
live streams from RealProducer G2 through 8.5 | servername. |
RealSystem 5.0 |
Encoder_RN5 |
SecureRBSEncoder |
live streams from Helix Producer | servername. |
Basic |
Encoder_Basic |
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.
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.
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. |
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:
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: |
|
| 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. |
Basic or RealSystem 5.0, select the database in the Database box. 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.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:
Secure directory. You can create a new commerce rule to secure the Archive directory, for example. As the section "Placing Secure Clips in Other Directories" explains, you can also store clips on different network drives or machines, creating a new commerce rule to secure those assets./broadcast/secure/ or /encoder/secure/. However, broadcasts that use just the broadcast mount points, such as /broadcast/ or /encoder/, are not secured by default.Tip:
If you changed the protected paths to /broadcast/ and
/encoder/, you would secure all broadcasts automatically.
|
| Note: Commerce rules apply only to viewers attempting to access secure clips or broadcasts. They do not apply to encoders or Helix Administrator users, for example. |
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.
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 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.
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.
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.
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.
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: |
/secure2/ mount point for secured content, enter /secure2 (no closing slash) in the box.| For More Information: For more on creating additional secure mount points, see "Placing Secure Clips in Other Directories". |
Content_RN5. The table "Default Databases" lists the other default databases.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.
|
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".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".| Warning! You must select the realm associated with the database you chose in the User Permissions Database field. |
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.| 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. |
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:
Do Not Evaluate User Permissions in the User Permissions Database pull-down list. In this case, all users with valid user names and passwords have unlimited access to all content protected by the commerce rule. For instructions on doing this, see "Adding or Modifying Commerce Rules".Windows NT LAN Manager authentication protocol. If you are using that protocol, there is no need to define permissions.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 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 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.
Whether you give a viewer directory-level or file-level access, you can assign an access type as described in the following table.
| 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. |
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:
| For More Information: See "Displaying Source Information". |
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. |
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: |
Directory or File depending on the type of permission you want to add. For more information, see "Permission Types".SecureUserContent), the path looks like this:secure/ |
secure/confidential |
| Note: The viewer can view clips in all subdirectories of the selected path. |
secure/confidential/report.rm |
Event to allow unlimited access to the content.Calendar, set an expiration date in this format:mm/dd/yyyy:hh:mm:ss |
Duration, set in seconds the total amount of viewing time allowed.Credit to log the viewer's total access time in the access logs.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: |
Directory or File to change the type of permission. For more information, see "Permission Types".mm/dd/yyyy:hh:mm:ss |
After doing so, click Set New Date.
Add or Subtract, and enter the amount of time in seconds. Then click Change Time.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: |
Directory or File according to the type of permission you want to revoke. For more information, see "Permission Types".| To revoke all permissions for a user: |
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.
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".
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
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:
PlayerContent database (you want to use a relational database instead, for instance), set up your database first, as described in "Using Databases".SecureContent realm with the player ID database you use.SecureContent realm available for user name and password validation.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.
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. |
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:
/secure/player rather than /secure, which is used with user name and password validation. The /secure/player path corresponds to a player subdirectory of the Secure directory. This subdirectory is not created during installation, however, so you need to create it to use player validation.| Tip: You can use another directory on your network. To do this, follow the instructions in "Placing Secure Clips in Other Directories", modifying your commerce rule appropriately. |
PlayerContent. Change the database choice if you are using a different database. If you do not want to evaluate permissions, and wish simply to grant all authenticated users access to all content in the protected path, select Do Not Evaluate User Permissions.| Note: If you plan to use permissions for individual viewers, follow the instructions in "Granting Permissions". |
Use Player Validation for player ID authentication to work./broadcast/secure/player (for broadcasts from Helix Producer 9 and later) or /encoder/secure/player (for broadcasts from RealProducer G2 through 8.5). On the encoder, specify the virtual path secure/player/ along with the stream name when starting the broadcast.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: |
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/register |
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/register |
register by default, but can be changed as described in "Modifying the GUID Database". registerMiguel21.clip.rm, specify a clip in the unsecured Content directory, not a clip in a secured directory. This can be any clip that the player can display. It may simply be a graphic that indicates a successful registration.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". |
|
|
© 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. |