|
| AccessDeniedPage | | The Access Denied Page is displayed if a user attempts to view a page for which he does not have access rights. If this attribute is left blank, the user will still be denied and will receive the standard error page.
|
| AuthenticationClientAddresses | | Used only when AuthenticationSource="SecureKey", AuthenticationClientAddresses is a comma-delimited list of IP addresses or Hostnames for approved external applications requesting keys under Logi SecureKey Authentication.
Specify ranges of IP addresses with wildcards. To use wildcards, specify an IP address, the space character, then the wildcard mask. For example to allow all addresses in the range of 172.16.*.*, specify:
172.16.0.0 0.0.255.255
For more information defining wildcard masks, visit http://en.wikipedia.org/wiki/Wildcard_mask
When host names are used instead of addresses, the server does a DNS host name lookup (reverse lookup) of the requesting address to test for a match.
AuthenticationClientAddresses is required for AuthenticationSource="SecureKey".
|
| AuthenticationSource | | Standard |
| SecureKey |
| AuthSession |
| AuthNT |
| (Required) Sets how the server determines the current user.
"AuthNT" uses the operating system's security to get the Username. For this option, you can either turn off Anonymous access for the report web site in IIS, or you can build your own custom logon page that sets an Authentication Ticket.
"AuthSession" authentication uses a session variable, "rdUsername", that you set in your own custom logon process.
"Standard" authentication displays a Form-based logon page. You can use either the built-in logon page, or specify your own. The web form should return to the server request parameters which are used in a DataLayer to query a user database. When a row is returned in the DataLayer, the user is authenticated.
"SecureKey" makes it possible for another application to do the authentication, then pass the user to this application. The other "main" application calls rdTemplate/rdGetSecureKey.aspx, passing Username (and possibly Roles and Rights), then getting back a key. Then the main application redirects the user to this application passing the key as a parameter rdSecureKey. If both a list of Roles and Rights are passed, the list of Rights is used to set User Rights directly.
For a more detail, see the following DevNet article.
|
| CacheRights | | When set to "Session", Roles and Rights are only determined at the beginning of the session. Otherwise, Roles and Rights are determined with each request.
Use "Session" when changes to users' roles and rights do not need to be applied until new sessions are started. This can greatly reduce the number of times required to query the security database.
The default is "False", except that it is "Session" when using AuthenticationSource="SecureKey". |
| DevelopmentClientAddresses | | DevelomentClientAddresses is a comma-delimited list of IP addresses. The default is "127.0.0.1,::1", which is the localhost address of the web server.
This no-security functionality is enabled when DevelopmentUsername is set. If the user comes with an address matching one of the DevelomentClientAddresses then the username is automatically set to DevelopmentUsername, and the "usual" security is skipped.
Do not deploy production applications with DevelopmentUsername set.
|
| DevelopmentUsername | | Set this attribute to disable security when testing during development. Working without security helps with Studio Preview and wizard features. It makes it easy to test with a specific username without having to actually login with each test.
Do not deploy production applications with DevelopmentUsername set.
This no-security functionality is enabled when DevelopmentUsername is set. If the user comes with an address matching one of the DevelomentClientAddresses then the username is automatically set to DevelopmentUsername, and the "usual" security is skipped. |
| LogonFailPage | | The LogonFailPage attribute identifies a page where users are sent when an attempted logon fails. The page can either be your own logon page, or a page that gives the user additional instructions and will guide them to the main logon page for the application.
This attribute may remain blank if the application does not require user authentication. For Standard security, the default is rdLogon.aspx, which is the built-in logon form. |
| LogonPage | | The Logon Page works with Standard and AuthSession security. It allows the display of a custom logon form to gain access to the system.
With Standard security, when LogonPage is blank, the system uses its own built-in logon form, which is rdLogon.aspx. To create a custom form, copy rdLogon.aspx to your own file, make appropriate modifications, and specify the new logon form in the Logon Page.
With AuthSession security, when LogonPage is blank, an error is thrown. Instead, provide the URL to the calling application's logon URL. |
| MetadataAdminSecurityRightIDs | | MetadataAdminSecurityRightIDs secures access to the Metadata Builder and Connections web user interface.
The Metadata Builder UI enables administration of connections to data sources. Administrators may also create and edit Metadata to define how end users view and analyze information in those data sources.
Access the Metadata Builder UI from this URL:
http://myServer/myApp/rdTemplate/rdMetadata.aspx
or
http://myServer/myApp/rdPage.aspx?rdReport=rdTemplate/rdMetadata/Connections
The default is "rdMetadataAdmin". To give administrators access either give them the "rdMetadataAdmin" right, or set this attribute to an existing administrator right.
Alternatively, access to the Metadata Builder can be globally restricted with the Settings/General@DisableMetadataBuilder attribute.
|
| NTAuthenticationDomain | | For NT Authentication, you may set this value to name of the Domain that is authenticating users. The system will only accept users authenticated from that domain, and the domain name will be removed from the user name. So username "MyDomain\Username" become simply "Username". Also, when working with the UserRoles.NT element, only those roles defined in that Domain will be added to the Role list. The domain name is not case sensitive. |
| RestartSession | | Restart session clears out all session variables during an attempted login. This prevents session variables that were established during the first user's session from being used during the second user's session. You can also end sessions with the Action.Exit element.
This attribute only applies to SecureKey.
|
| SchedulerUsername | | SchedulerUsername sets the account that will be used to run scheduled process definitions. This applies when using the Scheduler with Standard authentication or Session authentication, so that the username, roles and rights get set.
This attribute is not used if the scheduled task is saved with a username in the SchedulerRunAs attribute.
With NT Authentication, this attribute is not used. Instead, the Username is determined by the account set for Scheduler service.
To run a sheduled process with a different user, set the session variable "rdUserName" to the desired user. This value can come from a parameter passed into the scheduled process.
|
| SecureKeyDbConnectionID | | When SecureKey authentication is enabled and this attribute's value is a ConnectionID, temporary SecureKey storage is held in a relational database rather than the file system.
The temporary values are stored in a database table "rdSecureKey". The table is automatically created in the connection's database the first time a SecureKey is made.
Supported databases are:
SQL Server
Oracle
MySQL
PostgreSQL
|
| SecureKeySessionless | | When True, and SecureKey authentication is enabled, SecureKeys are not stored in session state, they are kept in the Data Cache folder, by default ApplicationRoot/rdDataCache. Every Report and Data definition request must include the rdSecureKey parameter with a valid SecureKey token.
SecureKey files do get cleaned/expired (deleted) from the Data Cache folder once no additional requests have been received for a particular key for a period of time matching the session timeout.
SecureKeySessionless="True" is especially useful when securing access to Data definitions to retrieve JSON data, since such requests are sessionless.
|
| SecureKeySharedFolder | | Used only when AuthenticationSource="SecureKey", SecureKeySharedFolder allows SecureKey to work in clustered configuration with web farms and web gardens.
In a single-server configuration, SecureKey keeps SecureKey requests in Application state. With multiple servers, this information must be stored in files in this folder that is shared among the web servers. The account used by (or impersonated by) the web application must have network access rights to read, write and delete files from this folder.
Set SecureKeySharedFolder to a network path, like:
//mySharedServer/SecureKeyFolder
Old files in the SecureKeyFolder are automatically deleted over time, so do not use this folder to store other files. |
| SecurityEnabled | | Enables or disables security.
The default value is False. |