Login Configuration

Cams uses the Java Authentication and Authorization Service (JAAS) to provide user authentication services. JAAS was introduced as an optional package to the Java 2 SDK, Standard Edition (J2SDK) 1.3. This was also known as JAAS 1.0. JAAS was officially integrated into the J2SDK with the 1.4. Cams does not use the authorization features of JAAS.

The JAAS authentication API defines a Java version of the Pluggable Authentication Module (PAM) framework, which permits applications to remain independent from underlying authentication technologies. The PAM framework allows the use of new or updated authentication technologies without requiring modification to applications.

This chapter describes how to configure Cams login modules. See also the Login Configuration Tag Reference for more information on all the XML tags used in the login-config.xml file.

NOTE: If an existing Cams login module does not meet your needs, then you may want to consult the Programming Cams JAAS Login Modules chapter of the Cams Programmer's Guide to understand how to create a new Cams login module. Source code is provided as a reference for all existing Cams Login Modules.

Login Configuration File

Each Cams security domain must have a login configuration defined by a login-config.xml file, which is loaded by Cams during login module initialization. The login-config.xml file contains both required and optional data, specific to each login module. One or more login module configurations can be specified by nesting values within one or multiple <login-config-entry name="name"> and </login-config-entry> tags, as you can see in the sample login-config.xml file. You invoke a configuration by starting the Cams service and referencing a specific <login-config-entry> name.

Within the <login-config-entry> open and close tags, you can specify how one more more login modules will be used for a configuration. The parameters className and flag are required for each login module entry as show in example 1. The class name specifies the fully qualified location of the Java class for the given login module. The login modules currently shipped with Cams include:

• com.cafesoft.cams.auth.login.module.ActiveDirectoryLoginModule
• com.cafesoft.cams.auth.login.module.JdbcLoginModule
• com.cafesoft.cams.auth.login.module.LdapLoginModule
• com.cafesoft.cams.auth.login.module.SiteServerLoginModule
• com.cafesoft.cams.auth.login.module.XmlLoginModule

<login-config-entry name="http">
	<login-module-entry
		className="com.cafesoft.cams.auth.login.module.XmlLoginModule"
		flag="REQUIRED">
		<options>
			<option name="serviceId" value="cams-user-repository"/>
			<option name="debug" value="true"/>
		</options>
	</login-module-entry>
</login-config-entry>	

A <login-config-entry> can have one or more <login-module-entry>. The flag parameter determines the behavior when multiple login modules are used by specifying whether a module is required, requisite, sufficient, or optional.

• REQUIRED - Normally set when authentication by this module is a must. With this flag, any module failure results in the PAM framework returning the error to the caller after executing all other modules on the stack. For the function to be able to return success to the application, all required modules have to report success.
• REQUISITE - The module must be successfully checked in order for the authentication to be successful. If a requisite module check fails, the user is notified immediately with a message reflecting the first failed required or requisite module.
• SUFFICIENT - Used if the module succeeds the PAM framework, then returns success to the application immediately without trying any other modules. For failure cases, the sufficient modules are treated as optional.
• OPTIONAL - Used when the user is allowed access, even if that module has failed. With this flag, the PAM framework ignores the module failure and continues processing the next module in sequence.

Specifying more than one <login-module-entry> for a single <login-config-entry> configuration is also known as stacking. The interaction between flags when stacking is complicated. It is recommended that you keep these configurations as simple as possible. In most cases, you'll specify a single login module with flag value of REQUIRED.

The optional values are specific to each login module and will be explained below in the sections for each login module. All options tags require name and value parameters. For example, all Cams login modules include a debug option to toggle on/off debug. The tag is <option name="debug" value="true"/> with the value either true or false.

Login Modules

The login modules included with Cams are:

• Active Directory Login Module - for use with Microsoft Active Directory
• JDBC Login Module - for use with SQL databases that have JDBC drivers
• LDAP Login Module - for use with most LDAPv3 compliant directories
• Site Server Login Module - for use with the Microsoft Site Server LDAP server
• XML Login Module - for use with the Cams XML user directory

Support for Password Digests

Password digests are one-way hashes that securely store a password using secure, industry standard hashing algorithms. Cams login modules that retrieve the password value from the database implement support for Cams to do digests within the login module. In this case, when a user supplies a password for authentication the Cams login module determines how the password in the user directory was hashed and then uses the same formula to hash the password to be validated. If the resulting digest is the same as the digest stored in the user directory, the user is authenticated.

Cams provides supports for Unix Crypt, SHA (with and without salt), and MD5 (with and without salt) digests. Typically, encryption authorities today recommend use of the SHA algorithm with random salt bytes. For more information on how Cams implements support of digest, see the Password Digests appendix.

Active Directory Login Module

You use this login module to access user data that is stored in the Microsoft Active Directory server. Active Directory, like most directory servers, can be configured to support virtually any schema. The Cams Active Directory login module provides support for the default Active Directory schema as shown in example 2.

The Active Directory login module expects to find a schema as shown in example 2, with the user values stored in specific attributes. The steps the Active Directory login module must successfully perform are:

1. Authentication - The Active Directory user principal names (UPN) such as name@company.com is required for authentication. The Active Directory Login Module attempts to bind to Active Directory using the UPN and the password. If successful, the users roles are then queried and saved.
2. Role Assignment - Once successful authentication is performed, the Cams Active Directory login module then assigns the user roles based upon the role attribute supplied during configuration. Active Directory often use the group memberOf attribute, which specifies the groups to which the user belongs. The individual group names are fully qualified distinguished names and must be exploded to obtain the common name, which is expected to be found in the left most component (e.g., the group name for distinguished name cn=mygroup,cn=users,dc=mycompany,dc=com would be mygroup).

Example 3 shows the sample entry for the Active Directory login module.

<login-module-entry
  className="com.cafesoft.cams.auth.login.module.ActiveDirectoryLoginModule"
  flag="REQUIRED">
 <options>
  <option name="debug"    value="false"/>
  <option name="host"     value="host.company.com"/>
  <option name="port"     value="389"/>
  <option name="baseDN"   value="cn=Users,dc=company,dc=com"/>
  <option name="scope"    value="ONE"/>
  <option name="filter"   value="(&amp;(objectclass=user)(userPrincipalName={username}))"/>
  <option name="roleAttr" value="memberOf"/> 
 </options>
</login-module-entry>

The required Active Directory login module options values are:

• host - The DNS host name or IP address of the Active Directory server.
• port - The Active Directory server connection port (389 by default). Note that the Active Directory login module may also connect to the Global Catalog (port 3268 by default).
• baseDN - The base distinguished name for the user search. Always cn=Users,dc=company,dc=com for Active Directory's default schema, where the values company and com correspond to the domain configured for the particular directory.
• scope - Specifies the search scope to use. Valid values are BASE (search is done only at the base dn tree node), ONE (search is done only at the first child tree node of the base dn), and SUB (search is done at the base dn node and all child nodes). This should be set to ONE for most Active Directory sites.
• filter - The filter to use to search for a user's roles. The UPN entered by the the user at login will be substituted for the value "{username}".
• roleAttr - The name of the attribute that contains the role distinguished names. Thought groups and roles are not the same, many Active Directory sites use the memberOf group attribute for this purpose.

JDBC Login Module

You use this login module to access user repository information that is stored in SQL databases such as Oracle, DB2, Microsoft SQL, MySQL, Sybase, and virtually any other database with a JDBC driver. The sample configuration uses the JDBC to ODBC bridge that ships with the JDK to access a Windows datasource (DSN) named SampleJdbcLogin. You can configure the sample Microsoft Access database with the SampleJdbcModule DSN to test the JDBC login module. Example 4 shows the sample entry for the JDBC login module.

<login-module-entry
  className="com.cafesoft.cams.auth.login.module.JdbcLoginModule"
  flag="REQUIRED">
 <options>
  <option name="debug" value="false"/>
  <option name="jdbcDriver" value="sun.jdbc.odbc.JdbcOdbcDriver"/>
  <option name="jdbcUrl" value="jdbc:odbc:SampleJdbcLogin"/>
  <option name="jdbcUsername" value="sa"/>
  <option name="jdbcPassword" value="password"/>
  <option name="userPreparedStatement" 
         value="SELECT PASSWORD FROM USERS WHERE USERNAME = ? "/>
  <option name="passwordColumn" value="PASSWORD"/>
  <option name="rolePreparedStatement" 
         value="SELECT ROLE FROM USER_ROLES WHERE USERNAME = ? "/>
  <option name="roleColumn" value="ROLE"/>
 </options>
</login-module-entry>
<callback-handler classname="com.cafesoft.cams.auth.callback.NamePasswordCallbackHandler"/> 

Example 4 - Cams Jdbc login module sample

The required JDBC login module options values are:

• jdbcDriver - The fully qualified name of the JDBC driver for your database.
• jdbcUrl - The URL required to access the database (see the JDBC driver documentation).
• jdbcUsername - The username required to access the database (can be null).
• jdbcPassword - The password required to access the database (can be null).
• userPreparedStatement - The SQL prepared statement to select the user's password from the database. The username entered by the the user at login will be substituted for the "?".
• passwordColumn - The table column where the user's password is stored.
• rolePreparedStatement - The SQL prepared statement to select the user's groups/roles from the database. The username entered by the the user at login will be substituted for the "?".
• roleColumn - The table column where the roles are stored.

The JDBC login module supports password digests using Unix Crypt, MD5, and SHA, SMD5, and SSHA. The algorithm is specified within curly brackets in a label that precedes a base 64 encoding of the hashed password (e.g., {CRYPT}, {MD5}, {SHA}, {SMD5}, {SSHA}), which may also include salt bytes.

NOTE: If you need to use a JDBC driver other than the JDBC to ODBC bridge that ships with the J2SDK, you must supply and install the driver. To use the JDBC driver with Cams, copy the driver's jar file the CAMS_HOME/cams/lib directory. Under Linux/UNIX, you will also need to edit runcams.sh and add the driver to the classpath. You can alternatively copy the driver to the ext directory of your J2SDK installation. For example, if you want to use MySQL with the standard J2SDK installation, you would copy mm.mysql-2.0.14-bin.jar to JAVA_HOME/jre/lib/ext.

Using JDBC Connection Pooling

To use JDBC connection pooling from the JDBC login module, you must:

1. Setup a Cams JDBC connection pool service
2. Configure the JDBC login module to use the Cams-provided pooling JDBC driver as shown in example 5
   

<login-module-entry
  className="com.cafesoft.cams.auth.login.module.JdbcLoginModule"
  flag="REQUIRED">
 <options>
  <option name="debug" value="false"/>
  <option name="jdbcDriver" value="com.cafesoft.core.jdbc.PoolingConnectionDriver"/>
  <option name="jdbcUrl" value="jdbc:cafesoft:pool:myusersdb_pool"/>
  <option name="jdbcUsername" value="my_pool_user"/>
  <option name="jdbcPassword" value="my_pool_password"/>
  <option name="userPreparedStatement" 
         value="SELECT PASSWORD FROM USERS WHERE USERNAME = ? "/>
  <option name="passwordColumn" value="PASSWORD"/>
  <option name="rolePreparedStatement" 
         value="SELECT ROLE FROM USER_ROLES WHERE USERNAME = ? "/>
  <option name="roleColumn" value="ROLE"/>
 </options>
</login-module-entry>

Example 5 - Using pooled JDBC connections with the JDBC login module

1. jdbcDriver - use the Cams PoolingConnectionDriver as shown.
2. jdbcUrl - must start with jdbc:cafesoft:pool: and must end with the poolName as configured in the connection pooling service.
3. jdbcUsername and jdbcPassword - use the poolUser and poolPassword credentials specified in the connection pooling service.

All other JDBC login module values are configured as shown in example 2.

LDAP Login Module

You use this login module to access user data that is stored in a directory such as SunOne Directory Server, OpenLDAP, and most other LDAPv3 compliant directories. LDAP directory schema will vary from site to site. This login module supports X.500 and DNS schemas that are similar to those that originated from the University of Michigan LDAP server and Netscape as shown in example 6.

The LDAP login module expects to find a schema similar to the one specified in example 6. The steps the LDAP login module must successfully perform are:

1. Authentication - The user's distinguished name (such as cn=username,ou=people,dc=company,dc=com) is required for authentication. The LDAP login module substitutes the username that the user enters when prompted for authentication against the userPattern parameter. Three password validation methods are available depending upon your security requirements and LDAP server access control settings. The three methods are:
   1. Cams - Retreive the userPassword attribute value and let the Cams LDAP login module do the password validation. The primary advantage of this method is that you can take advantage of all supported Cams password digests, which including Unix Crypt, MD5, MD5 with salt, SHA, and SHA with salt.
   2. Compare - Performs an LDAP compare method call, which delegates the comparison of the user's userPassword attribute to the LDAP server. The primary advantage of this method is performance, the check is performed on the server and a boolean value is returned to the Cams LDAP login module indicating success or failure. Depending upon the LDAP server, the compare method may do hashing to match against a hashed value. This method can be used if the LDAP server access control policy denies userPassword retrieval but allows comparison (especially important if the password is stored in cleartext and the LDAP server is publically available).
   3. Bind - Attempts to bind to the LDAP server using the user's distinguished name and password. If the bind is successful, then Cams authenticates the user. The primary advantage of this method is that it is the only one you can use if the LDAP server access control policy prohibits retreival and comparison of the userPassword attribute. The disadvantage is that binding has a greater performance hit than the other two methods.
      
2. Role Assignment - Once successful authentication is performend, the Cams LDAP login module then performs the role search to retrieve and assign the user roles. Sites often use group attributes for role assignments (though they really are different). You must specifiy the based distinguished name, search scope, search filter, and role attribute name that will be used to find the roles.

The LDAP login module configuration options include parameters to flexibily query user and role information from many LDAP schemas. Your LDAP server may use a schema slightly different from the one specified above that will still work with the LDAP login module. Also, issues with respect to your site LDAP server access control policy may effect the integration with Cams. The recommended approach is to use a general purpose LDAP search tool (usually supplied with your LDAP server) to ensure that your searches return the expected results. Once you acheive success, you can enter the values in login-module.xml and test with Cams. For example, searches such as:

base distinguished name: ou=People,dc=company,dc=com
filter: (ou=myUserName,ou=People,dc=company,dc=com)
scope: one
attributes: userPassword

can be used to determine if the userPassword value can be returned for a user. If your search tool supports sepecification of calling the compare method, you can use similar values with it to determine if a compare can be done. Searches such as:

base distinguished name: ou=Groups,dc=company,dc=com
filter: (uniqueMember=uid=myUserName,dc=company,dc=com)
scope: one
attributes: cn

can be used to determine the roles.

Example 7 shows the sample entry for the LDAP login module.

<login-module-entry
  className="com.cafesoft.cams.auth.login.module.LdapLoginModule"
  flag="REQUIRED">
 <options>
  <option name="debug" value="false"/>
  <option name="host" value="host.company.com"/>
  <option name="port" value="389"/>
  <option name="passwordValidationMethod" value="Cams"/>
  <option name="adminUsername" value="admin"/>
  <option name="adminPassword" value="password"/>
  <option name="userDN" value="uid={username},ou=people,dc=company,dc=com"/>
  <option name="roleBaseDN" value="ou=groups,dc=company,dc=com"/>
  <option name="roleScope" value="ONE"/>
  <option name="roleFilter" 
         value="(uniqueMember=uid={username},ou=people,dc=company,dc=com)"/>
  <option name="roleAttrName" value="cn"/>
 </options>
</login-module-entry>

Example 7 - Cams LDAP login module login-config.xml sample

The required LDAP login module options values are:

• debug - Enables/disables debugging for the LoginModule.
• host - The LDAP server host name or IP address.
• port - The LDAP server port number.
• passwordValidationMethod - Specifies how the LDAP login module will do password validation. Valid values are Cams (validation is done by Cams LDAP login module using Password Digests), Compare (validation is done by the LDAP server using the compare method call), and Bind (validation is done the LDAP server using an LDAP connection bind call).
• adminUsername - A user account that has access control privleges that allow it to perform searches against the user and role nodes values in the LDAP directory. This value is required when the passwordValidationMethod of Cams or Compare is used, but optional for the Bind method. The Bind method uses the connection bound to the authenticated user to lookup role values.
• adminPassword - The password for the adminUsername account.
• userDN - The distinguished name pattern to match to find a user. The username entered by the the user at login will be substituted for the value "{username}". The LDAP login module will not successfully find users in schemas that use a distinguished name that does not use the username to distinguish users.
• roleBaseDN - The base distinguished name to use for your LDAP schema role searches.
• roleScope - Specifies the LDAP search scope to use for role searches. Valid values are BASE (search is done only at the base dn tree node), ONE (search is done only at the first child tree node of the base dn), and SUB (search is done at the base dn node and all child nodes).
• roleAttrName - The name of the attribute used to store the role names.
• roleFilter - The filter to use to search for a users roles. The username entered by the the user at login will be substituted for the value "{username}".

Site Server Login Module

You use this login module to access user data that is stored in the Microsoft Site Server LDAP directory. Site Server LDAP directory, like most directory servers, can be configured to support virtually any schema. The Cams Site Server login module provides support for the default Site Server LDAP directory schema as shown in example 8.

The Site Server login module expects to find a schema as shown in example 8, with the user values stored in specific attributes. The steps the Site Server login module must successfully perform are:

1. Authentication - The user's distinguished name (such as cn=username,ou=Members,o=company.com) is required for authentication. The LDAP login module substitutes the username that the user enters when prompted for authentication against the {username} in the userDN parameter to create the user's distinguished name. The user's DN can be used to attempt authentication. Three password validation methods are available depending upon your security requirements and LDAP server access control settings. The three methods are:
   1. Cams - Retreive the userPassword attribute value and let the Cams Site Server login module do the password validation. The primary advantage of this method is that you can take advantage of all supported Cams password digests, which include Unix Crypt, MD5, MD5 with salt, SHA, and SHA with salt.
   2. Compare - Performs an LDAP compare method call, which delegates the comparison of the user's userPassword attribute to the LDAP server. The primary advantage of this method is performance, the check is performed on the server and a boolean value is returned to the Cams Site Server login module indicating success or failure. This method can be used if the LDAP server access control policy denies userPassword retrieval but allows comparison (especially important if the password is stored in cleartext and the LDAP server is publically available).
   3. Bind - Attempts to bind to the LDAP server using the user's distinguished name and password. If the bind is successful, then Cams authenticates the user. The primary advantage of this method is that it is the only one you can use if the LDAP server access control policy prohibits retreival and comparison of the userPassword attribute. The disadvantage is that binding has a greater performance hit than the other two methods.
      
2. Role Assignment - Once successful authentication is performed, the Cams Site Server login module then assigns the user roles based on the user entity groups attribute, which specifies the groups to which the user belongs. The individual group names are fully qualified distiguished names to the groups and must be exploded to obtain the group common name, which is expected to be found in the left most component of the group DN (e.g., the group name for distinguishied name cn=mygroup,ou=Groups,o=mycompany.com would be mygroup).

Example 9 shows the sample entry for the Site Server login module.

<login-module-entry
  className="com.cafesoft.cams.auth.login.module.LdapLoginModule"
  flag="REQUIRED">
 <options>
  <option name="debug"                    value="false"/>
  <option name="host"                     value="host.company.com"/>
  <option name="port"                     value="389"/>
  <option name="passwordValidationMethod" value="Cams"/>
  <option name="adminUsername"            value="admin"/>
  <option name="adminPassword"            value="password"/>
  <option name="userDN"                   value="cn={username},ou=Members,o=company.com"/>
  <option name="roleAttrName"             value="groups"/>
 </options>
</login-module-entry>

Example 9 - Cams LDAP login module login-config.xml sample

The required SiteServer login module options values are:

• debug - Enables/disables debugging for the LoginModule.
• host - The SiteServer LDAP server host name or IP address.
• port - The SiteServer LDAP server port number.
• passwordValidationMethod - Specifies how the Site Server login module will do password validation. Valid values are Cams (validation is done by Cams LDAP login module using Password Digests), Compare (validation is done by the LDAP server using the compare method call), and Bind (validation is done the LDAP server using an LDAP connection bind call).
• adminUsername - A user account that has access control privleges that allow it to perform searches against the Member node values in the Site Server LDAP directory. This value is required when the passwordValidationMethod of Cams or Compare is used, but optional for the Bind method. The Bind method uses the connection bound to the authenticated user to lookup role values.
• adminPassword - The password for the adminUsername account.
• userDN - The distinguished name pattern to match to find a user. The username entered by the the user at login will be substituted for the value "{username}" to complete the distinguished name. The distinguished name is used to authenticate the user and to read the user's groups attribute, which contains the names of the groups that will be assigned to the user as roles.
• roleAttrName - The name of the attribute used to store the role names.

XML Login Module

Example 10 shows the sample entry for the XML login module. You use this login module to access user data stored in a cams-users.xml directory, found by default in each security domain. This user directory is supplied with Cams for convenience and is not recommend for a large number of users as the entire contents of the file are read into memory.

The XML login module does not process the contents of the cams-users.xml file directly. Instead, it makes use of a Cams service, which loads the XML file and reloads it if modifications are made. This Cams service (defined in security-domain.xml) caches username, password, and role information in memory, greatly improving the efficiency of authentication. The path to Cams user directory and the XML handler that knows how to parse the file are specified in the service manager configuration.

<!-- In login-config.xml, register a cams-users.xml directory service -->
<login-config-entry>
 ...
 <login-module-entry
   className="com.cafesoft.cams.auth.login.module.XmlLoginModule"
   flag="REQUIRED">
  <options>
   <option name="debug" value="false"/>
   <option name="serviceId" value="cams-user-repository"/>
  </options>
 </login-module-entry>
 ...
<login-config-entry>

<!-- In security-domain.xml, register a cams-users.xml directory service -->
<service manager>
 ...
 <service id="cams-directory" enabled="true">
  <service-type>com.cafesoft.cams.service.UserRepositoryService</service-type>
  <service-class>com.cafesoft.security.engine.service.UserRepositoryServiceImpl</service-class>
  <param-list>
   <param name="repositoryFilePath"
         value="${cams.security-domain.home}/cams-users.xml"/>
   <param name="repositoryFactoryClass"
         value="com.cafesoft.security.engine.auth.login.userrepository.XmlUserRepositoryFactory"/>
   <param name="handlerClass"
         value="com.cafesoft.security.engine.auth.login.userrepository.CamsXmlUserRepositoryHandler"/> 
   <param name="debug" value="false"/>
  </param-list>
 </service>
 ...
</service-manager>

Example 10 - Sample Cams XML login module as defined in login-config.xml and by the associated security-domain.xml service

The required XML login module options values are:

• serviceId - The unique identifier of the Cams XML user repostiory service (configured in security-domain.xml) that you will use with the XML login module.

The XML login module supports password digests using Unix Crypt, MD5, and SHA, SMD5, and SSHA. The algorithm is specified within curly brackets in a label that precedes a base 64 encoding of the hashed password (e.g., {CRYPT}, {MD5}, {SHA}, {SMD5}, {SSHA}), which may also include salt bytes. See Password Digests for more information.

See Security Domain Configuration - Cams XML User Repository Service for information on how to configure services.

Callback Handlers

Cams uses callback handlers to pass login credentials from the calling application to the login module. In the web or HTTP space, most webapps use form authentication, typically requesting a username and password for authentication. In this case you can use the Cams NamePasswordCallbackHandler, which takes a username and password as input and provides them to the login module. It is possible to create login modules that require many types of credentials. In some cases you may need to write and register your own callback handler.

To specify a callback handler for use with a Cams login module, each login-config-entry includes the following required tag:

<callback-handler 
  classname="com.cafesoft.cams.auth.callback.NamePasswordCallbackHandler"/>  		 

The Cams JDBC, LDAP, and XML login modules all require the callback handler to supply a username and password. These login modules work well with the NamePasswordCallbackHandler. However, Cams has a pluggable callback framework to associate custom callback handlers with login modules. If the NamePasswordCallbackHandler does not meet your needs, see the Cams Callback Handlers chapter of the Cams Programmer's Guide to understand how to create a new one. For example, you may want to specify a third authentication credential in addition to username and password, such as the last four digits of a user's social security number or a pin.

Login Parameters

Login parameters are optional tags that further define the login configuration. As shown in example 11, the Cams server will redirect to the login page specified by the camsLoginUrl when user authentication is required. This can be an absolute or relative URL. Any server with a Cams web agent can be used as the Cams authentication server provided the server is in the same Internet domain.

<login-parameters>
 	<login-parameter name="camsLoginUrl" 
 	value="/cams/login.jsp"/>
</login-parameters>

Example 11 - Cams login parameters

NOTE: The value /cams/login.jsp is provided by default. You must change this value to correspond to the login page in use at your site. For example, IIS sites might use /cams/login.asp and Apache sites might use
/cgi-bin/cams-login.sh.

© Copyright 1996-2003 Cafésoft LLC. All rights reserved.